Le aziende dovrebbero sempre adottare una strategia che prevede un piano di incident response (IRP), la cui creazione e gestione è solitamente affidata a una struttura specifica: il CSIRT (Computer Security Incident Response Team). Tale documento deve contenere almeno le istruzioni per le procedure di emergenza da attivare nel caso in cui si verifichi un sospetto incidente di sicurezza informatica.

L’incident response è un’attività fondamentale per la sicurezza informatica di un’azienda e va implementata con molta attenzione, con l’obiettivo di essere pronti a reagire alla minaccia informatica nel momento in cui effettivamente si verifica. Si tratta di momenti caratterizzati da notevole stress, in cui i rischi di perdere i dati e le funzionalità dei sistemi IT risultano alquanto concreti.

Un incident response plan ben organizzato offre agli stakeholder una guida fondamentale per cercare di mantenere la calma anche nelle situazioni più critiche, adottando le procedure necessarie per contenere i danni dell’incidente e gli importanti contraccolpi a livello economico e reputazionale che possono mettere a repentaglio la sopravvivenza stessa delle aziende.

Cos’è l’incident response plan?

Il piano di incident response (IRP, incident response plan), è una raccolta ragionata di informazioni e procedure utili ad affrontare le situazioni di emergenza provocate da un’ampia gamma di attacchi alla sicurezza informatica di un’azienda: ransomware, malware, phishing, attacchi DDoS, intrusioni nella rete, oltre alle vulnerabilità delle applicazioni e alle minacce interne, come gli errori dei dipendenti o i tentativi di sabotaggio. In altri termini, il principale obiettivo del piano di incident response risiede nel rilevare, rispondere e limitare i danni derivanti dagli attacchi alla sicurezza informatica dell’azienda.

Per formare un IRP, come vedremo, esistono molti framework: linee guida che consentono ai CSIRT aziendali di strutturare in maniera efficiente i principali contenuti del piano, che fanno riferimento alle sei fasi dell’incident response, secondo quanto previsto dalla NIS:

• Preparation
• Identification
• Containment
• Eradication
• Recovery
• Follow up

L’incident response plan deve essere strutturato e scritto in maniera semplice e comprensibile per consentire agli stakeholder di comprendere in breve tempo quali sono le azioni da effettuare per salvare l’integrità dei dati e, non ci stancheremo mai di ribadirlo, la vita stessa delle organizzazioni che vengono colpite da attacchi alla sicurezza informatica sempre più letali.

Perchè è importante

La fondamentale importanza dell’incident response plan è data dalla sua capacità di ridurre gli effetti nocivi degli attacchi di sicurezza informatica, per salvaguardare il più possibile l’operatività, le finanze e la reputazione delle organizzazioni colpite.

Un IRP, soprattutto nelle realtà in cui viene realizzato per la prima volta, consente di verificare che l’azienda disponga di un’adeguata cultura in merito all’igiene informatica, che i dipendenti dovrebbero curare con estrema attenzione, capitalizzando al meglio i momenti di formazione e le esercitazioni previste dal piano stesso.

Anche il miglior IRP risulterebbe vano nei suoi propositi, qualora le persone che costituiscono il motore del business non applicassero le più banali norme di sicurezza informatica.

Dato l’estremo livello di tossicità presente nella rete, appare quasi inutile partire dal presupposto di resistere a qualsiasi minaccia alla cybersecurity dell’azienda, risultando ben più responsabile un atteggiamento proattivo, oltre che reattivo nei confronti della minaccia stessa.

Per tali motivi un IRP risulta altrettanto importante nel responsabilizzare le organizzazioni, che si vedono “obbligate” a predisporre tutti i passaggi chiave da seguire qualora dovesse sorgere il sospetto di un incidente, oltre a definire con estrema chiarezza le figure da coinvolgere e contattare prima, durante e dopo le situazioni di emergenza.

I vantaggi

Le aziende che implementano una efficiente attività di incident response possono ottenere importanti benefici:

• Capacità di gestire le situazioni di emergenza
• Consapevole attività di vulnerability assessment di sistemi e dati
• Velocità nella mitigazione delle minacce
• Disaster recovery limitato
• Incremento complessivo della continuità di business
• Miglioramento della comunicazione interna ed esterna
• Miglior rispondenza ai disposti normativi relativi alla sicurezza e alla privacy dei dati critici e sensibili.

Come creare un incident response plan

La redazione di un incident response plan viene eseguita dai professionisti di un CSIRT sulla base delle linee guida proposte dai framework di istituzioni come ENISA per l’Europa o CISA e NIST per il contesto statunitense, senza trascurare il contributo offerto dai vendor.

A titolo generico e esemplificativo, un IRP potrebbe essere sviluppato affrontando i seguenti step.

Creazione delle policy

La definizione di una chiara policy per la sicurezza informatica costituisce una presa di posizione fondamentale da parte della dirigenza aziendale, per rendere autorevoli le attività legate all’incident response, partire dall’individuazione delle figure responsabili e dalla costituzione di un budget per le loro operazioni.

Le policy vanno illustrate con precisione in documenti programmatici in grado di fissare con chiarezza gli obiettivi aziendali, senza entrare necessariamente nel dettaglio delle procedure, per cui è prevista la redazione di appositi playbook.

Definizione del CSIRT e delle responsabilità

Una volta definito un responsabile a livello aziendale, il passo successivo risiede nella formazione di un team in grado di gestire end-to-end i processi dell’incident response: il computer security incident response team (CSIRT)

La costituzione di tale struttura dipende dalla dimensione aziendale e dalla valutazione dei rischi relativa alla sicurezza informatica che deriva dall’attività svolta. In particolare, le PMI possono definire un responsabile interno ed esternalizzare la parte prevalente delle operazioni, affidandosi ai servizi di aziende che offrono SOC (security operation center) e/o CSIRT attraverso un modello a servizio gestito. Il CSIRT ha il ruolo di definire ed aggiornare l’incident response plan lungo il suo intero ciclo di vita.

Redazione dei playbook

I playbook costituiscono delle guide che consentono di affrontare le varie tipologie di incidente di sicurezza informatica che possono verificarsi in azienda, con apposite checklist e descrizioni sulle procedure da eseguire quando ci si trova ad affrontare un sospetto attacco ransomware, oppure lo smarrimento di un dispositivo da parte di un dipendente, per citare due tra le possibili situazioni di emergenza. I playbook vengono formati ed aggiornati dal CSIRT.

Creazione di un piano di comunicazione

La gestione dell’emergenza vede il fondamentale ruolo della comunicazione interna ed esterna, per fare fronte alle pubbliche relazioni con gli stakeholder, la stampa e l’opinione pubblica, ai fini di controllare l’informazione e salvaguardare la reputazione aziendale.

Oltre alla minaccia puramente informatica, appare decisivo dedicare un piano specifico per gestire la comunicazione nelle situazioni di emergenza, a tutti i livelli. È decisamente consigliabile avvalersi di un supporto legale competente nella disciplina dei dati digitali.

Test del incident response plan

Dopo aver definito la redazione dell’IRP, occorre testarlo prima che si manifesti una situazione di vera emergenza, in modo da verificarne i contenuti e comunicare agli stakeholder le procedure pianificate per far fronte alle varie minacce alla sicurezza informatica dell’azienda.

Il test prevede simulazioni teoriche e pratiche di gestione dell’incidente in situazioni di scenario riconducibili ai possibili casi reali: ransomware, DDoS, vulnerabilità di sistema, ecc. I feedback ottenuti dagli stakeholder consentono al CSIRT di effettuare interventi correttivi e migliorativi al piano di incident response.

Documentazione degli incidenti

Dopo la gestione di un vero incidente di sicurezza informatica è fondamentale un follow up in cui si documenta la gestione dell’emergenza, a partire dall’individuazione delle cause dell’attacco, in modo da evitare che si ripeta.

Tale attività assume un ruolo fondamentale nel sensibilizzare i decisori aziendali e convincerli ad investire il budget necessario per adeguare la cybersecurity dell’organizzazione secondo le disposizioni del CISO (chief information security officer), sentito il CSIRT. Gli esperti nella comunicazione devono pertanto predisporre insight e report il cui contenuto risulti pienamente comprensibile anche per le figure non tecniche.

Aggiornamento continuo del piano

La minaccia informatica evolve continuamente. Di conseguenza il piano di incident response deve essere aggiornato con altrettanta continuità, sulla base di una costante attività di threat intelligence.

Non esistono regole fisse, ma sarebbe buona norma provvedere ad una revisione integrale del piano almeno una volta all’anno, oppure qualora dovessero intervenire modifiche significative all’infrastruttura IT o ai processi di gestione dei dati, eventi in grado di innescare nuove vulnerabilità.

Cosa dovrebbe contenere

A livello di contenuti, un incident response plan efficace dovrebbe stabilire le procedure necessarie per le seguenti circostanze:

• Identificare e rispondere a un incidente
• Valutare in maniera rapida ed accurata gli estremi dell’incidente e le possibili cause
• Notificare l’incidente agli stakeholder
• Mitigare l’attacco e rimuovere la presenza dell’attaccante
• Effettuare le procedure di ripristino necessarie a garantire la normalità operativa
• Organizzare le fasi di follow up ed accertare la risoluzione delle possibili cause

In particolare, in merito a questo ultimo punto, l’attaccante prova nella maggioranza dei casi a ripetere l’attacco, per sfruttare possibili vulnerabilità latenti o non risolte. Solitamente si tratta di attività che vengono svolte entro 2 o 3 settimane dal primo evento.

Se i sistemi di sicurezza riescono a neutralizzare una minaccia simile a quella descritta dall’investigazione di un recente incidente, ciò potrebbe costituire la prova tangibile che l’operato del CSIRT sia stato soddisfacente, almeno nella fase di gestione post-incidente.