Cosa significa Incident Response? E di cosa si tratta esattamente? Per rispondere a queste domande è fondamentale, innanzitutto, definire il contesto. Gli incidenti di natura informatica stanno falcidiando le aziende, obbligandole a rispondere con tecnologie e misure adeguate alla crescente minaccia cybercriminale, soprattutto nei confronti degli attacchi ransomware e delle altre attività malevole finalizzate a violare i dati (data breach), sia a scopo ricattatorio, sia per ottenere vantaggi grazie allo spionaggio industriale.
Nonostante le misure di protezione dei sistemi e dei dati siano mediamente sempre più performanti, i metodi e le tecnologie utilizzate dai cybercriminali mutano continuamente, per cui è sempre probabile che un attacco vada a segno, riuscendo a penetrare le misure di sicurezza previste dalle aziende. Rimanere vittima di un attacco non vuol dire finire automaticamente in balia dei criminali.
Per reagire e, in generale, assumere un atteggiamento proattivo nei confronti degli incidenti di sicurezza informatica è infatti nata la disciplina dell’incident response, la cui popolarità è in continua crescita, grazie all’efficacia degli strumenti che riesce a predisporre per contenere la minaccia, soprattutto nei casi più critici, quando l’attacco va irrimediabilmente a segno.
Cos’è l’incident response
L’incident response è sostanzialmente un insieme di varie procedure, necessarie per rispondere in maniera efficace agli incidenti di sicurezza informatica. L’obiettivo è infatti quello di minimizzare i danni, mitigando l’azione in atto e favorendo il ripristino nel minor tempo possibile dei sistemi e dei dati aziendali alla condizione normale, quella che ha preceduto l’incidente stesso.
Le aziende possono adottare una strategia grazie all’adozione e all’implementazione di un piano di incident response (IRP), solitamente affidato al CSIRT (Computer Security Incident Response Team). Tale strumento contiene le istruzioni operative per attivare le procedure di emergenza nel caso in cui si verifichi, o si abbia sospetto, di un incidente di sicurezza informatica.
L’incident response è una pratica fondamentale e va organizzata in maniera scrupolosa, affinché possa risultare efficace soprattutto in questi contesti di grande tensione e nervosismo che caratterizzano il verificarsi di un incidente di sicurezza informatica. Si tratta infatti di momenti in cui si rischia di compromettere il corretto esercizio dei sistemi IT e soprattutto di perdere dati di rilevanza critica. Tali episodi, oltre a comportare un pesante contraccolpo sul piano economico, spesso mettono a repentaglio la sopravvivenza stessa delle aziende.
L’ incident response plan
Il piano di incident response, dall’inglese incident response plan, è una raccolta di informazioni e procedure predisposte per affrontare qualsiasi situazione di emergenza derivante dall’azione di ransomware, malware, phishing, attacchi denial-of-service (DDoS), intrusioni nei sistemi della rete, oltre all’ampio parco di vulnerabilità delle applicazioni e alla minaccia interna, che può derivare da un tentativo di sabotaggio o da semplici errori dei dipendenti dovuti ad una cattiva igiene informatica e ad un’ampia gamma di errori comportamentali.
L’obiettivo del piano di incident response è quello di rilevare, rispondere e limitare gli effetti dannosi derivanti da qualsiasi attacco alla sicurezza informatica dell’azienda.
Esistono vari framework che dispongono linee guida utili a strutturare in modo corretto un piano di incident response. Per ragioni di semplicità divulgativa faremo riferimento ad una classica struttura a sei fasi, che prevede la preparation, l’identification, il containment, l’eradication, il recovery e il follow up.
Le descrizioni che seguono non costituiscono ovviamente l’unica alternativa disponibile, ma possono risultare utili soprattutto a chi intende conoscere la struttura di un piano di incident response, prendendo atto delle funzioni che prevede e degli impatti che può garantire nella sua azione mitigatoria. Semplici azioni, se ben pianificate e strutturate, possono letteralmente salvare la vita di un’azienda quando viene colpita da un incidente di sicurezza informatica.
Le fasi dell’incident response
Il piano di incident response prevede sei fasi attuative, in taluni casi ridotte a quattro, pur senza variare nella sostanza le indicazioni contenute. Si tratta di un percorso end-to-end, di natura ciclica e sequenziale, che mirano a garantire un elevato livello di resilienza per le aziende colpite da attacchi informatici.
La formazione del piano è ovviamente a cura del team di incident response, a prescindere che questi sia disponibile in-house o in outsourcing e non andrebbe mai confuso con il piano di continuità di business, che contiene informazioni di carattere molto più ampio, in grado di coinvolgere i sistemi IT riguardo guasti ed altri imprevisti che nulla hanno a che vedere con la minaccia cybercriminale.
L’incident response management deve prevedere una serie di procedure che non si limitano all’ambito IT, favorendo piuttosto una visione complessiva per gestire integralmente lo scenario in cui si verifica un incidente, coinvolgendo anche una serie di conseguenze di natura indiretta.
Esaminiamo più nel dettaglio in cosa costituiscono le fasi dell’incident response.
Incident response plan – fase 1: preparation
La prima fase del piano di incident response risiede nella preparazione. Si tratta di una serie piuttosto ampia di attività, che vengono adoperate per creare le condizioni necessarie per arrivare a gestire in maniera corretta ed efficace gli incidenti di sicurezza, a cominciare da ciò che si rivela utile durante la loro prevenzione.
Si rende pertanto necessaria un’azione analitica sui sistemi di sicurezza di cui un’organizzazione dispone, verificando ad esempio l’efficacia, se presenti, dei sistemi di monitoraggio, per capire se sono effettivamente in grado di garantire un’adeguata visibilità di quelle zone della rete che potrebbero rivelarsi a rischio, per le ragioni più disparate.
In questa fase è assolutamente auspicabile la collaborazione tra l’incident response team e il team IT aziendale, ossia l’organo che più di ogni altro dovrebbe conoscere ciò di cui l’azienda dispone in materia informatica.
Tra le fasi preparatorie in un’attività di pianificazione dell’incident response, può essere introdotta un’attività precauzionale di vulnerability assessment e penetration test, utili a identificare e mitigare nel modo più efficace possibile le eventuali vulnerabilità presenti sui sistemi e sulle applicazioni, qualora venissero valutate sufficientemente critiche da risultare degne di nota.
Incident response plan – fase 2: identification e scoping
La seconda fase prevista dal piano entra nel merito del rilevamento di un incidente, un’attività caratterizzata da molti fattori, a cominciare dal valutare o meno se quanto in oggetto corrisponda o meno ad un vero e proprio incidente di sicurezza informatica, oppure ad un falso allarme se non ad un guasto imprevisto che nulla ha a che vedere con un’azione di natura cybercriminale.
Per identificare in maniera corretta un incidente è indispensabile godere di dati e informazioni utili a ricostruire una timeline. Si rende pertanto opportuno disporre di sistemi di monitoraggio in grado di acquisire e analizzare i log dei vari elementi e dispositivi che compongono l’IT aziendale. La visibilità diventa quindi un requisito essenziale a cui fare riferimento. Un efficace sistema di monitoraggio potrebbe ad esempio identificare un’anomalia derivante dall’azione di un’infezione latente, laddove la minaccia è presente sui sistemi pur senza manifestarsi con azioni di natura violenta.
Lo scoping si lega in maniera diretta l’identificazione dell’incidente, per quegli aspetti che mirano a comprendere gli scopi dell’attaccante. Capire le intenzioni di un criminale consente di fare i passi successivi in maniera più consapevole, prevedendone spesso le mosse. Lo scoping si occupa ad esempio di capire come si è verificato il primo attacco e il comportamento tenuto dall’intruso una volta che è riuscito a penetrare con successo all’interno della rete aziendale. Tali operazioni riguardano gli aspetti di natura tecnologica che quelli metodologici.
Incident response plan – fase 3: containment
Una volta appreso di essere rimasti vittima di un incidente informatico e di aver identificato in maniera circostanziata la natura e gli scopi dell’attacco, diventa essenziale l’avvio di una fase di contenimento, che coincide nell’attivare una serie di operazioni per mitigare gli effetti malevoli affinché il danno non si propaghi ulteriormente, oltre a guadagnare tempo per consentire all’incident response team di predisporre le azioni utili all’estinzione della minaccia e al ripristino totale dei sistemi e dei dati violati.
Incident response plan – fase 4: eradication
Identificazione e contenimento costituiscono le condizioni necessarie per procedere alla definitiva rimozione della minaccia, ed è quanto si intende per la quarta fase dell’incident response plan, relativa alla cosiddetta eradication.
Lo sradicamento degli agenti malevoli non deve essere precipitoso, in quanto si rischierebbe di interrompere un’azione in corso senza averla compresa fino in fondo, vanificando pertanto gli obiettivi di intelligence fondamentali per ottenere la completa visibilità dell’attacco subito.
La tempestività dell’azione non andrebbe mai confusa con l’impulsività nell’agire. Una volta sradicata la minaccia, è opportuno procedere con azioni di monitoraggio utili per capire se le misure intraprese sono efficaci anche ai fini di evitare che l’attacco si ripeta. I cybercriminali, grazie a strumenti in grado di automatizzare queste procedure, provano spesso a colpire nuovamente la vittima, per cercare di sfruttare eventuali vulnerabilità non risolte.
In questo frangente assume particolare rilevanza l’aspetto psicologico da parte dell’incident response plan, che non deve mai sottovalutare la porta di un attacco, nemmeno dopo averne compreso nei dettagli la sua effettiva magnitudo. A tale scopo si rivela fondamentale una solida attività di threat intelligence.
Incident response plan – fase 5: recovery
Il recupero dei sistemi violati conclude sostanzialmente le fasi attive di intervento sull’incidente e viene solitamente intrapreso contestualmente alla rimozione della minaccia. In conformità con le misure previste da un piano di continuità di business, la fase di recovery prevista dall’IRP mira a rendere nuovamente operativi i sistemi colpiti durante l’attacco, oltre a garantire la totale integrità dei dati potenzialmente o effettivamente coinvolti.
Dal punto di vista strumentale, si tratta di operazioni tipiche dell’IT, in cui si rispristinano i device e i sistemi operativi violati, così come le applicazioni e le configurazioni attive nel momento dell’attacco, eliminando inoltre gli account compromessi. Qualora tale procedura non sia stata ancora implementata, vengono cambiate le password degli account stessi, oltre a cercare di implementare un sistema di aggiornamento automatico utile a prevedere che le impostazioni di accesso dei dipendenti non rimangano le stesse per lunghi periodi, aumentando sensibilmente l’esposizione ai rischi di furto dei dati di login.
Non è infatti sufficiente ripristinare una situazione precedente all’attacco, qualora questa continui a manifestare evidenti criticità in materia di sicurezza informatica. Nell’ottica di una strategia di miglioramento continuo della sicurezza informatica aziendale, prende corpo il sesto ed ultimo punto previsto dal piano di incident response: il follow-up.
Incident response plan – fase 6: follow-up
Le prime cinque fasi costituiscono la risposta operativa all’incidente. Tuttavia, il loro sforzo rischierebbe di risultare vano qualora non venisse intrapresa una strategia finalizzata a migliorare la sicurezza globale dell’azienda, sia per quanto riguarda le tecnologie impiegate, che i metodi utili a rendere efficace la risposta ad una minaccia sempre più variegata e difficile da prevedere, al punto che ormai appare quasi necessario prevedere che, prima o poi, un attacco andrà a buon fine.
Occorre pertanto farsi trovare pronti, a cominciare dall’analisi delle esperienze negative che hanno coinvolto i sistemi di sicurezza durante lo svolgimento di un attacco di natura informatica. L’identificazione e lo scoping costituiscono due attività utili a sostenere l’azione di intelligence relativa all’incidente, oltre a porre le basi per un’adeguata fase di follow-up dello stesso.
La reportistica relativa all’incidente è fondamentale per capire, in primo luogo, se le procedure effettuate sono conformi rispetto a quelle previste dal piano di incident response. In caso contrario, occorre ad esempio capire se il team non fosse sufficientemente preparato o a conoscenza dei contenuti, oppure se il piano stesso dispone di elementi di natura problematica, che il team di incident response ha dovuto adeguare in corso d’opera per condurre con successo le proprie attività di mitigazione.
Il follow-up consiste quindi in un momento di indagine e riflessione al di fuori della frenesia e della concitazione che coincide quando l’incidente è in corso. L’obiettivo di una consapevole attività di follow-up dell’incidente mira a sostenere una strategia di miglioramento continuo della gestione, oltre che a stabilire le misure da predisporre o integrare affinché si riduca sia la possibilità di subire incidenti, sia la gravità dei possibili effetti nell’eventualità in cui vadano a segno.
