Incident response: come costruire un piano che funzioni davvero durante un attacco
Quasi tutte le aziende hanno un piano di incident response. Molte lo scoprono inutilizzabile nel momento in cui serve: nessuno sa chi decide l'isolamento di un server di produzione, il numero del consulente legale è su un foglio nel cassetto di qualcuno in ferie, e la prima riunione dura due ore solo per capire chi parla con il cliente finale.
Un piano che funziona non è un documento più lungo: è un insieme di decisioni prese prima, di responsabilità assegnate e di esercitazioni fatte. In questo articolo vediamo come costruirlo con riferimenti verificabili, partendo da un dato che cambia il quadro: dal 2025 il riferimento internazionale per l'incident response è cambiato, e non è un dettaglio formale.
Il riferimento è cambiato: NIST SP 800-61 Rev. 3
Per vent'anni il punto di riferimento è stato il NIST SP 800-61 Rev. 2, pubblicato nel 2012. Nell'aprile 2025 NIST ha pubblicato la Rev. 3, intitolata Incident Response Recommendations and Considerations for Cybersecurity Risk Management, che sostituisce la Rev. 2.
La novità sostanziale è l'impostazione: la Rev. 3 non descrive l'incident response come una procedura separata dal resto della sicurezza, ma la integra nel risk management descritto dal NIST Cybersecurity Framework 2.0, con il quale condivide le funzioni Govern, Identify, Protect, Detect, Respond e Recover. Il messaggio operativo è chiaro: la capacità di rispondere a un incidente si costruisce prima, nelle funzioni di governo, identificazione e protezione, non nel momento in cui l'attacco è in corso.
Chi lavora in Italia può affiancare a questo riferimento un modello più procedurale, come i nove stadi dell'Incident Handling and Response proposti da EC-Council nel percorso ECIH: preparazione, registrazione e assegnazione, triage, notifica, contenimento, raccolta delle evidenze e analisi forense, eradicazione, ripristino, attività post-incidente. I due approcci non sono alternativi: il primo dà la cornice di gestione del rischio, il secondo la sequenza operativa.
Le cinque decisioni da prendere prima
Prima di scrivere playbook, servono decisioni che spettano al management e che nessun strumento può prendere al posto suo.
1. Che cosa consideriamo un incidente. Senza una soglia dichiarata, tutto è emergenza o niente lo è. La soglia va espressa in termini verificabili: accesso non autorizzato a un sistema che tratta dati personali, esfiltrazione sospetta, cifratura di file, indisponibilità di un servizio critico oltre una certa durata.
2. Chi può ordinare l'isolamento di un sistema. La persona che risponde deve poter staccare la rete di un server di produzione senza attendere tre approvazioni. Va deciso il nome, il sostituto e il perimetro di questa autorità.
3. Chi parla all'esterno. Un solo canale verso clienti, fornitori, autorità e stampa, con un portavoce designato e un vicario. Le comunicazioni frammentate sono uno dei modi più rapidi per trasformare un incidente tecnico in una crisi reputazionale.
4. Quali obblighi normativi scattano, e in che tempi. Per i soggetti NIS, il decreto legislativo 4 settembre 2024, n. 138 prevede la notifica al CSIRT Italia degli incidenti significativi, secondo le specifiche di base definite dalla determinazione ACN 379907/2025. Le finestre temporali e le soglie di significatività vanno conosciute prima dell'evento, non durante.
5. Chi tiene i rapporti con il legale e con l'assicuratore. Indagini interne, comunicazioni alle autorità e coperture cyber richiedono informazioni che vanno raccolte con criteri precisi fin dal primo minuto.
Gli elementi minimi del piano
Un piano utilizzabile contiene poche cose, ma tutte verificabili.
- Inventario dei sistemi critici, con proprietario, dipendenze, dati trattati e posizione dei backup. Senza questo elenco non si decide cosa proteggere per primo.
- Contatti ed escalation, con numeri alternativi e responsabilità per fascia oraria. Un piano che funziona solo negli orari d'ufficio è un piano parziale.
- Ruoli, non nomi generici: incident commander, referente tecnico, referente legale, comunicazione, relazioni con i fornitori.
- Playbook per i quattro o cinque scenari più probabili, non per tutti: ransomware, compromissione di credenziali, phishing con accesso alla posta, esposizione di dati, indisponibilità di un servizio critico.
- Accessi e strumenti di emergenza, con credenziali conservate fuori dai sistemi che potrebbero essere compromessi e con una procedura di break-glass documentata.
- Log e conservazione, con il periodo di retention necessario a ricostruire gli eventi e la certezza che i log siano integri e non modificabili dagli attaccanti.
- Gestione delle evidenze, con catena di custodia: chi ha raccolto il dato, quando, come è stato conservato.
- Canali di comunicazione alternativi, perché la posta aziendale è spesso il primo bersaglio.
Un errore ricorrente è scrivere il piano pensando alla propria azienda come se fosse isolata. La maggior parte degli incidenti coinvolge fornitori, partner o servizi cloud: il piano deve dire come si attiva il fornitore, chi ha il contatto tecnico e quali clausole contrattuali si applicano.
Come si testa un piano
Il piano non testato è un'ipotesi. Le modalità di verifica hanno costi e rese diverse, e servono tutte, in ordine di crescente realismo:
- Walkthrough. Il team rilegge il piano e verifica che i contatti esistano e che i ruoli siano coperti. Costa un'ora e trova già metà dei problemi.
- Tabletop exercise. Si simula uno scenario e si discute, minuto per minuto, chi fa cosa. Emergono i conflitti di autorità e le lacune di informazione, senza toccare la produzione.
- Simulazione tecnica controllata. Si verifica davvero la capacità di isolare un host, ripristinare un backup, revocare credenziali in blocco e ruotare le chiavi.
- Esercitazione con red team, se l'organizzazione ha la maturità per sostenerla: serve a misurare il tempo di rilevamento, non solo la capacità di reazione.
Ogni esercitazione deve produrre un elenco di azioni con un proprietario e una data. Se non produce azioni, è stata una recita.
Le metriche che contano
Le metriche utili sono poche e tutte misurabili:
- Tempo medio di rilevamento di un evento anomalo, dalla prima traccia alla presa in carico.
- Tempo di contenimento dall'apertura dell'incidente all'isolamento dell'area coinvolta.
- Percentuale di backup verificati con ripristino riuscito negli ultimi dodici mesi.
- Percentuale di playbook testati almeno una volta nell'anno.
- Tempo di notifica verso l'autorità competente, quando applicabile.
Sono indicatori che il management può leggere e che il team tecnico può migliorare. Al contrario, il numero di alert generati da un SIEM non dice nulla sulla capacità di rispondere.
Il quadro normativo italiano in due righe
Per i soggetti che rientrano nel perimetro NIS, il decreto 138/2024 è in vigore dal 16 ottobre 2024. L'Agenzia per la cybersicurezza nazionale è l'autorità competente e il punto di contatto unico; la registrazione avviene annualmente tra il 1° gennaio e il 28 febbraio, l'aggiornamento delle informazioni tra metà aprile e il 31 maggio. Per gli obblighi di base, il decreto prevede una finestra di nove mesi per le notifiche e di diciotto mesi per le misure di sicurezza, decorrenti dal consolidamento dell'elenco dei soggetti: da qui la scadenza di ottobre 2026 per l'adozione delle misure.
Tradotto in pratica: un'organizzazione NIS che nel 2026 non ha ancora un processo di gestione degli incidenti documentato non sta rimandando un progetto, sta accumulando un ritardo rispetto a un obbligo.
Le competenze che servono
Un piano di incident response coinvolge competenze diverse e complementari. Le certificazioni, in questo ambito, hanno un ruolo soprattutto nel dare un linguaggio comune tra team e nel fissare un metodo verificabile.
| Profilo | Competenza chiave | Riferimento |
|---|---|---|
| Incident handler | Conduzione del processo di gestione dell'incidente, dal triage alle attività post-incidente | EC-Council ECIH, accreditato ANAB e approvato DoD 8140 per il ruolo di Cyber Defense Incident Responder |
| Analista difensivo | Monitoraggio, analisi degli alert, gestione degli strumenti | Percorsi SOC e network defense |
| Ethical hacker | Verifica della capacità di rilevamento attraverso test controllati | EC-Council CEH |
| Forense | Raccolta e analisi delle evidenze, catena di custodia | Percorsi di computer forensics |
L'ECIH, in particolare, è strutturato su nove stadi del processo, un esame da 100 domande in tre ore e un requisito di almeno un anno di esperienza nel settore della sicurezza informatica: non è un corso introduttivo, ma una specializzazione per chi già lavora in ambito security.
Domande frequenti
Quanto deve essere lungo un piano di incident response? Non esiste una lunghezza corretta. Conta che contenga decisioni, ruoli e contatti, e che sia abbastanza corto da poter essere consultato durante l'emergenza. I dettagli operativi stanno nei playbook, non nel piano.
Serve un SOC per avere un piano di incident response? No, ma serve qualcuno che rilevi. Un'organizzazione senza SOC può definire chi monitora, con quali strumenti e con quali soglie, anche avvalendosi di un fornitore esterno.
Ogni quanto va aggiornato? Almeno una volta all'anno e ogni volta che cambia qualcosa di rilevante: fornitori critici, sistemi esposti, ruoli interni, obblighi normativi.
Le esercitazioni tabletop sono sufficienti? Sono necessarie ma non sufficienti. Verificano le decisioni e la comunicazione, non la capacità tecnica di isolare un host o ripristinare un backup: quella va provata davvero.
In sintesi
Un piano di incident response funziona quando le decisioni difficili sono già state prese: chi decide, con quale autorità, entro quali tempi e verso chi si comunica. Il riferimento tecnico oggi è il NIST SP 800-61 Rev. 3, che lega l'incident response alla gestione del rischio complessiva; il metodo operativo si costruisce su fasi chiare e su esercitazioni ripetute.
Se vuoi formare un team capace di gestire un incidente seguendo un processo verificabile, scopri i corsi EC-Council di Digital Lab.