“La rete è sotto attacco.” Questa è la frase che quasi tutte le PMI, comprensibilmente, hanno il terrore di dover un giorno affrontare. Un terrore che, però, non deve assolutamente venire assecondato. Pena vederlo trasformare in panico nel malaugurato, ma purtroppo non così raro caso, nel quale l’azienda debba effettivamente fare i conti con un Cyber attacco.
Esistono delle linee guida? Sì, certo. Ma…
Nel mondo ideale descritto dalle documentazioni, un Incident Response dovrebbe seguire fasi ben strutturate e lineari. Tuttavia, nella realtà quotidiana delle aziende le cose si svolgono spesso in modo assai diverso. Questo articolo è volto a compiere una panoramica sulla situazione reale, così come riscontrata dal nostro SOC (Security Operation Center) nei tanti casi di SOS Cyber Attack affrontati dagli analisti del Terzo Livello; per poi delineare delle linee guida realistiche, in armonia con quelle ufficiali, ma calate nel contesto pratico della PMI.
Obiettivo: fornire un contenuto valido per redigere un piano di Incident Response sensato, attuabile e, soprattutto, efficace in caso di attacco.
Le Linee Guida ufficiali
Sintetizziamo, al netto dei vari framework proposti da diverse agenzie governative e non, le fasi di Incident Response come “da manuale”:
- Preparazione
Installazione, configurazione, mantenimento delle soluzioni di sicurezza e definizione di procedure di risposta in caso di incidente. - Identificazione
Intercettazione di un evento malevolo. - Contenimento
Analisi e azioni per impedire il diffondersi della problematica identificata (isolamento macchina, blocco utenza, ecc.). - Risposta
Analisi e azioni per rimuovere la problematica (rimozione del codice malevolo, patching, restore dei dati compromessi). - Risoluzione
Eventuale ripristino dei sistemi, verifica della risoluzione della problematica e delle sue cause. - Analisi post-incidente
Identificazione delle cause che hanno portato al problema, identificazione di soluzioni per evitare il ripetersi di situazioni simili (quelle identiche sono già state risolte al punto precedente). Generazione di reportistica relativa all’incidente e comunicazione interna verso le parti dell’azienda interessate dall’evento, dalle sue cause o dalla sua risoluzione.
Ciò che realmente accade quando si verifica un incidente.
Un incidente prima di tutto deve essere rilevato (detection). Un attacco informatico può superare le difese aziendali per diversi motivi: vuoi per mancanza o inadeguatezza delle stesse, per errore umano (che è poi il motivo principale per cui esiste la Cyber Security Awareness!) o per elevata raffinatezza dell’attacco.
In questi casi la scoperta dell’incidente è spesso fortuita. Ciò significa che un attacco andato a buon fine, soprattutto per un’azienda non ben strutturata sulla cybersecurity, è più facile da rilevare grazie a comportamenti anomali del sistema, ad ESEMPIO:
- Risorse che improvvisamente non sono più disponibili
- Modifiche o incremento nel traffico in entrata o uscita
- Creazione di nuovi file, cartelle o utenze
- Modifiche alle configurazioni, specie quelle di sicurezza
Sintesi di come NON dovrebbe andare e, invece, spesso accade
Una volta individuato l’incidente, la reazione iniziale ha un tratto comune: IL PANICO. Una caratteristica che porta spesso ad azioni impulsive, come scollegare server o disattivare account nel tentativo di fermare l’incidente, che rischiano spesso di causare danni all’azienda tanto quanto (e in alcuni casi addirittura oltre) quelle svolte dagli attaccanti.
Ora è il Team di Incident Response a dover prendere in mano la situazione. Ma non tutte le aziende, o meglio poche aziende hanno un team di Incident Response predefinito. E così viene assemblato in fretta e furia un gruppo di persone con competenze diverse, che cercano di collaborare per risolvere il problema. Questa mancanza di preparazione può rallentare le operazioni e creare confusione sui ruoli e le responsabilità.
Inoltre, va facilmente a complicare la corretta comprensione dell’entità dell’incidente: con una raccolta di informazioni frammentate e incomplete, che rischiano di falsare e non di poco le analisi, portando a ipotizzare situazioni e cause estremamente differenti da quelle reali.
A questo punto si evince che sia l’azione di contenimento che quella di comunicazione interna può pagare l’instabilità delle fasi precedenti: le misure prese (come il tentativo di isolamento dei sistemi compromessi) si rivelano inefficaci o addirittura dannose, e il personale non sa cosa dire ai clienti o ai partner, e possono circolare informazioni errate, ad aggravare l’impatto dell’incidente sulla reputazione aziendale.
La pressione per tornare alla normalità porta spesso al ripristino dei sistemi senza aver affrontato completamente le cause dell’incidente. Questo può lasciare aperte le vulnerabilità che hanno causato il problema iniziale, aumentando il rischio di futuri incidenti, anche immediati.
Una volta risolto l’incidente, l’analisi delle cause è spesso trascurata per mancanza di tempo, risorse o interesse. Ciò si traduce in una comprensione limitata di ciò che è accaduto, impedendo di implementare misure preventive efficaci e aumentando il rischio di incorrere nuovamente in un attacco. Ma anche di non produrre la documentazione adeguata prevista dalle Normative (come GDPR, nLPD e NIS2) e di rischiare così un ulteriore danno di sanzioni, anche severe.
8 punti per un approccio realistico all’Incident Response
“Gli incidenti capitano anche nelle migliori famiglie.”
CHARLES DICKENS – Scrittore
Dopo aver esaminato come spesso si svolge l’Incident Response nella pratica quotidiana, ci prendiamo l’onere di suggerirti come potrebbe, e quindi a questo punto dovrebbe (senza se e senza ma) essere gestito efficacemente un processo di Incident Response.
Prima, durante e dopo:
PRIMA
- Preparazione Pragmatica (Security Posture)
- Creazione del Team: creare un team dedicato all’Incident Response e assegnare ruoli chiari all’interno del team, sapendo chi, in caso di incidente; è responsabile di cosa.
- Asset di Sicurezza: implementare soluzioni di sicurezza proporzionate alle dimensioni e alle esigenze dell’azienda, senza eccedere in complessità inutili. Un’analisi dei rischi ben fatta potrebbe essere lo strumento ideale per identificare anche il budget da investire nella sicurezza informatica: dalla valutazione degli strumenti da acquistare, al coinvolgimento di esperti di settore esterni per colmare le lacune interne.
- Piani di Emergenza: avere piani documentati ma flessibili per diversi tipi di incidenti, facilmente accessibili e comprensibili da tutto il team. Le procedure sono volte a supportare il team durante la situazione di emergenza con efficacia e flessibilità, a seconda dei diversi eventi malevoli che potrebbero generarsi.
- Cyber Security Awareness: fornire al personale una formazione regolare sulle migliori pratiche di sicurezza e sulle procedure di risposta agli incidenti. Riconoscere e premiare comportamenti che contribuiscono alla sicurezza dell’azienda, incoraggiando il personale a fornire riscontri sulle procedure di sicurezza e a segnalare potenziali criticità o miglioramenti.
- Rilevamento Proattivo
- Monitoraggio Costante: utilizzare sistemi di monitoraggio affidati a un team di esperti, per individuare anomalie e potenziali minacce in tempo reale.
- Segnalazione Facilitata: creare canali semplici e diretti per permettere ai dipendenti di segnalare sospetti o problemi senza ostacoli burocratici.
- Analisi dei Log (Treath Hunting): far effettuare regolari revisioni dei log di sistema (idealmente ogni giorno, realisticamente ogni settimana) per identificare attività insolite.
DURANTE
- Risposta Coordinata
- Attivazione del Piano: una volta rilevato un incidente procedere velocemente, ma senza panico e senza improvvisare soluzioni alternative.
- Comunicazione Interna: informare immediatamente le persone chiave e il team coinvolto, mantenendo una comunicazione chiara e diretta.
- Valutazione Rapida: comprendere rapidamente l’entità dell’incidente per prendere decisioni coerenti sulle azioni successive.
- Contenimento Efficace
- Isolamento dei Sistemi: isolare i sistemi compromessi per impedire la diffusione dell’incidente, minimizzando al contempo l’impatto sulle operazioni aziendali.
- Applicazione di Patch: se possibile applicare patch o soluzioni temporanee per mitigare la vulnerabilità sfruttata dall’attacco in corso.
- Monitoraggio Aggiuntivo: aumentare il più possibile il livello di monitoraggio sui sistemi coinvolti per rilevare l’eventualità di ulteriori attività sospette.
- Eradicazione e Ripristino
- Rimozione delle Minacce: eliminare il malware o le componenti malevole identificate durante l’incidente.
- Ripristino Sicuro: utilizzare backup puliti per il ripristino e, prima di riconnettere alla rete operativa gli strumenti e le macchine, accertarsi che le vulnerabilità siano state affrontate e risolte.
- Verifica dell’Integrità: effettuare un controllo completo per assicurarsi che i sistemi e i dati siano integri e non siano stati alterati.
- Comunicazione Trasparente
- Compliance e Supply Chain: informare clienti, partner e autorità competenti in modo tempestivo, rispettando così le normative sulla privacy e sulla sicurezza. Ma anche per dimostrare cura e senso di responsabilità nei rapporti con i propri stakeholder; così rafforzando, invece che indebolendo, la reputazione aziendale.
- Comunicazione verso l’esterno: preparare un comunicato chiaro che spieghi l’incidente, l’impatto e le azioni intraprese con trasparenza e “a testa alta”, poiché gli attacchi informatici rappresentano una realtà ormai ben nota e in grado di produrre empatia su un vasto pubblico.
DOPO
- Analisi Post-Incidente
- Revisione Dettagliata: condurre una riunione post-incidente con il team di Incident Response per analizzare le cause, le azioni intraprese e l’efficacia della risposta.
- Documentazione: registrare tutte le informazioni rilevanti, inclusi tempi, decisioni e risultati, per creare un registro completo dell’incidente. Ciò è utile per una valutazione strategica da fornire al Consiglio di amministrazione dell’azienda, ma anche per farsi trovare proattivi nei confronti di un eventuale controllo da parte delle Autorità competenti in materia.
- Miglioramento Continuo
- Aggiornamento delle Procedure: identificare aree di miglioramento e, se necessario, aggiornare senza indugio i piani e le procedure in base alle esperienze acquisite.
- Formazione Straordinaria: predisporre un incontro di aggiornamento per tutto il personale d’azienda, andando così a valorizzare le lezioni apprese e creando un ambiente di lavoro più consapevole e sicuro.
- Investimento in Sicurezza: valutare in modo cauto e assennato l’implementazione di eventuali nuovi strumenti o risorse, qualora si fossero rivelati necessari per sviluppare una più adeguata capacità di risposta nel futuro.
“Un uomo non farebbe nulla se aspettasse fino a poterlo fare così bene che nessuno possa trovarvi dei difetti.” JOHN HENRY NEWMAN – Filosofo
Un efficace processo di Incident Response non richiede perfezione, ma un approccio strutturato, pragmatico e adattabile. Le aziende dovrebbero mirare a essere preparate, reattive e aperte all’apprendimento continuo, riconoscendo che gli incidenti sono inevitabili ma gestibili. Implementando queste pratiche, è possibile mitigare gli effetti negativi degli incidenti e rafforzare la resilienza dell’organizzazione nel lungo termine.
