L’incident response (IR, risposta agli incidenti) è il processo strutturato che un’organizzazione segue per rilevare, contenere, analizzare, eradicare e recuperare da un incidente di sicurezza informatica — e per imparare da esso per ridurre il rischio di ricorrenza. Un incidente di sicurezza è qualsiasi evento che compromette riservatezza, integrità o disponibilità delle informazioni (la Triade CIA): un’intrusione, un’infezione da malware, una violazione di dati, un attacco DDoS, una compromissione di account privilegiati.
L’IR non è un’attività improvvisata: la qualità della risposta a un incidente dipende quasi interamente dalla qualità della preparazione preventiva. Organizzazioni che non hanno un piano testato scoprono durante l’incidente — nel momento peggiore — che le comunicazioni di crisi non funzionano, che i backup non sono ripristinabili, che nessuno sa chi ha l’autorità di spegnere i server.
Il ciclo NIST SP 800-61
Il riferimento metodologico più diffuso è NIST SP 800-61 (Computer Security Incident Handling Guide), che articola il processo in quattro fasi:
1. Preparation (preparazione): definire le policy di incident response, costituire il CSIRT (Computer Security Incident Response Team), dotarsi di strumenti forensi, stabilire canali di comunicazione sicuri, definire gli accordi con fornitori esterni di IR, eseguire tabletop exercise e simulazioni. La preparazione determina la velocità e l’efficacia di tutte le fasi successive.
2. Detection & Analysis (rilevamento e analisi): identificare l’incidente, classificarlo per tipo e gravità, raccogliere le prime evidenze, determinare la portata iniziale. Le sorgenti di rilevamento includono SIEM, IDS/IPS, EDR, alert utente, notifiche da terze parti. La triage distingue incidenti reali da falsi positivi.
3. Containment, Eradication & Recovery (contenimento, eradicazione e ripristino):
- Contenimento a breve termine: isolare i sistemi compromessi per impedire la propagazione, senza distruggere le evidenze forensi.
- Contenimento a lungo termine: applicare patch, modificare credenziali compromesse, rafforzare i controlli.
- Eradicazione: rimuovere il malware, chiudere le backdoor, eliminare gli account creati dall’attaccante.
- Ripristino: riportare i sistemi alla normale operatività da backup verificati, monitorare per ricadute.
4. Post-Incident Activity (attività post-incidente): condurre una post-mortem (lessons learned) entro 1–2 settimane dall’incidente. Documentare la timeline, le decisioni prese, cosa ha funzionato, cosa no. Aggiornare il piano di IR, i playbook, i controlli di sicurezza.
Playbook
Un playbook di IR è un documento che descrive passo per passo come rispondere a una specifica tipologia di incidente (ransomware, phishing con credential theft, data breach, compromissione di account privilegiato). Riduce i tempi di risposta eliminando la necessità di improvvisare durante l’emergenza e garantisce la coerenza delle azioni tra diversi analisti.
Obblighi normativi
Il GDPR impone la notifica delle violazioni di dati personali al Garante entro 72 ore dalla scoperta. Questa finestra temporale molto stretta rende la qualità del processo di IR un obbligo normativo: senza un processo di detection e analisi rapido, la notifica nei tempi richiesti è impossibile. Analoghe obblighi di notifica esistono per i settori bancario (BCE/EBA), sanitario e infrastrutture critiche (Direttiva NIS 2).
Chain of Custody
Nella raccolta delle evidenze forensi è fondamentale mantenere la catena di custodia (chain of custody): documentare chi ha acquisito ogni evidenza, quando, con quali strumenti, e come è stata conservata. Evidenze raccolte senza catena di custodia documentata non sono utilizzabili in sede legale e possono essere contestate in un procedimento penale o civile.