Un incidente informatico non e questione di "se" ma di "quando". Questa frase la senti ripetere ovunque nel mondo della cybersicurezza, e per una buona ragione: e vera. Anche con le migliori difese, prima o poi qualcosa puo andare storto. La differenza tra un'organizzazione che sopravvive a un incidente e una che ne esce devastata sta nella preparazione.
La NIS2 lo dice chiaramente: ogni soggetto obbligato deve avere procedure documentate per la gestione degli incidenti. Non un generico "chiamiamo qualcuno se succede qualcosa", ma un piano strutturato con ruoli, responsabilita, procedure e tempistiche. Un Incident Response Plan (IRP).
Le 6 fasi dell'incident response
Il modello di riferimento e quello del NIST (SP 800-61), adottato anche dal Framework Nazionale per la Cybersicurezza. Prevede sei fasi che, nella pratica, spesso si sovrappongono:
1. Preparazione
La preparazione e tutto cio che fai prima che l'incidente accada. Il team di incident response deve essere formato, i ruoli assegnati, gli strumenti predisposti, i contatti aggiornati (CSIRT Italia, consulenti forensi, legali, comunicazione). I playbook — procedure predefinite per i tipi di incidente piu comuni — vanno scritti e testati. E servono le esercitazioni: almeno una tabletop exercise all'anno.
2. Identificazione
Come ti accorgi che qualcosa non va? Alert del SIEM, segnalazione di un dipendente, notifica di un fornitore, rilevamento dell'antivirus. L'identificazione e la fase piu critica: piu velocemente rilevi un incidente, meno danni causa. Il tempo medio di rilevamento (MTTD) nelle aziende italiane e ancora troppo alto — spesso settimane o mesi.
3. Contenimento
Una volta identificato l'incidente, bisogna limitare il danno. Contenimento a breve termine: isolare i sistemi compromessi, bloccare l'accesso dell'attaccante. Contenimento a lungo termine: applicare le patch, cambiare le credenziali compromesse, rafforzare i controlli. Attenzione a non distruggere le evidenze forensi nel processo — servono per capire cosa e successo.
4. Eradicazione
Eliminare la causa dell'incidente. Se si tratta di malware, rimuoverlo da tutti i sistemi. Se e un'intrusione, chiudere tutti i punti di accesso dell'attaccante. Se c'e una vulnerabilita sfruttata, patchare. L'eradicazione deve essere completa: se l'attaccante ha lasciato backdoor non scoperte, tornera.
5. Ripristino
Riportare i sistemi alla normalita. Ripristinare i backup (dopo aver verificato che non siano compromessi), riaccendere i servizi, monitorare intensivamente per assicurarsi che l'attaccante non sia ancora presente. Il ripristino deve essere graduale e controllato — non riaccendere tutto insieme.
6. Lezioni apprese
La fase piu ignorata e la piu importante. Dopo ogni incidente: cosa e successo? Perche e successo? Cosa ha funzionato nella risposta? Cosa no? Come evitare che si ripeta? La relazione finale richiesta dalla NIS2 (entro 30 giorni) dovrebbe incorporare queste riflessioni.
Il team di incident response
Chi gestisce un incidente? Non solo l'IT. Un team di incident response efficace include:
- Incident Commander — coordina la risposta, prende le decisioni chiave
- Analista tecnico — investiga l'incidente, analizza le evidenze
- Comunicazione — gestisce le comunicazioni interne ed esterne
- Legale — valuta gli obblighi normativi (NIS2, GDPR), gestisce le notifiche
- Management — prende le decisioni di business (pagare il riscatto? fermare la produzione?)
- Consulente forense esterno — se l'incidente e grave, serve competenza specializzata
Playbook per gli scenari piu comuni
Un IRP generico non basta. Servono playbook specifici per i tipi di incidente piu probabili: ransomware, phishing con compromissione account, data breach, DDoS, compromissione fornitore, insider threat. Ogni playbook deve descrivere i passi specifici da seguire, le persone da contattare e le decisioni da prendere. Un playbook ransomware, ad esempio, deve affrontare la domanda piu scomoda: si paga il riscatto? (Spoiler: nella maggior parte dei casi, no.)
Esercitazioni e test
Un piano non testato e un piano che non funziona. Le esercitazioni possono essere di diversi livelli: tabletop exercise (simulazione discussa al tavolo), drill (esercitazione parziale su un aspetto specifico) o full-scale exercise (simulazione completa con sistemi reali). Per la NIS2, almeno un tabletop exercise all'anno e il minimo consigliato.
Durante le esercitazioni emergono sempre sorprese: numeri di telefono obsoleti, procedure che non funzionano nella pratica, ruoli non chiari, strumenti non accessibili. Meglio scoprirlo in un'esercitazione che durante un vero incidente alle 3 di notte.