Incident response: cos'è, fasi e piano di risposta

L'incident response è l'insieme delle attività con cui un'organizzazione rileva un incidente di sicurezza informatica, lo analizza, lo contiene, ne elimina la causa, ripristina i sistemi e ne trae lezioni. L'incident response plan (IRP) è il documento che stabilisce prima dell'incidente chi fa cosa, con quali poteri, in quali tempi e chi va avvisato, autorità comprese.

Il riferimento più usato per descriverla è la NIST SP 800-61 Rev. 3, pubblicata ad aprile 2025, che sostituisce la Rev. 2 del 2012. In Italia, per i soggetti NIS2, il D.Lgs. 138/2024 aggiunge definizioni e tempi di notifica. Questa pagina spiega i concetti di base; cosa scrivere nel piano per la NIS2 è trattato nel piano di incident response NIS2.

Che cos'è un incidente, e cosa non lo è

La NIST SP 800-61 Rev. 3 parte da tre livelli, utili per non chiamare incidente ogni allarme:

• Evento: qualsiasi fatto osservabile che coinvolge asset informatici, comprese piattaforme fisiche e virtuali, reti, servizi e ambienti cloud. Un tentativo di login, l'installazione di un aggiornamento, un'applicazione che risponde a una richiesta.
• Evento avverso: un evento con una conseguenza negativa, qualunque ne sia la causa. Spesso serve un'analisi ulteriore per capire se dietro c'è un incidente.
• Incidente di cybersecurity: un fatto che mette a rischio, in modo effettivo o imminente e senza un'autorità legittima, integrità, riservatezza o disponibilità di informazioni o sistemi, oppure che viola o minaccia di violare leggi, policy di sicurezza, procedure o regole d'uso accettabile. NIST riprende la definizione dalla legge federale statunitense FISMA del 2014.

Per i soggetti NIS2 italiani vale la definizione del D.Lgs. 138/2024 (art. 2, comma 1, lettera t): incidente è «un evento che compromette la disponibilità, l'autenticità, l'integrità o la riservatezza di dati conservati, trasmessi o elaborati o dei servizi offerti dai sistemi informativi e di rete o accessibili attraverso di essi». Lo stesso articolo definisce anche il quasi-incidente, cioè l'evento che avrebbe potuto diventare un incidente senza che questo si sia verificato, compreso il caso in cui sia stato evitato (lettera u).

Tra gli esempi di incidente che NIST elenca nell'introduzione:

• un ransomware che rende inutilizzabili i sistemi e copia i file che contengono;
• email di phishing usate per compromettere account e commettere frodi finanziarie;
• credenziali di amministratore ottenute presso un fornitore SaaS, con i dati dei suoi clienti a rischio;
• il software di un fornitore compromesso e distribuito ai clienti in quello stato;
• una vulnerabilità nuova negli apparati di gestione della rete sfruttata per accedere alle comunicazioni.

Cosa si intende per incident response

Nel glossario della SP 800-61 Rev. 3 l'incident response consiste nel porre rimedio alle violazioni delle policy di sicurezza e delle pratiche raccomandate, o nel mitigarle, sempre sulla base della FISMA. È una definizione stretta. Il D.Lgs. 138/2024 usa un perimetro più largo e parla di gestione degli incidenti: «le azioni e le procedure volte a prevenire, rilevare, analizzare e contenere un incidente o a rispondervi e recuperare da esso» (art. 2, comma 1, lettera z).

In pratica le due cose convivono. La risposta in senso stretto è quello che succede da quando un allarme diventa un incidente a quando i sistemi tornano in produzione. La gestione comprende anche il lavoro fatto prima, che decide quanto quella risposta sarà rapida. NIST lo dice in modo esplicito: le lezioni apprese e l'analisi della causa servono a migliorare la gestione del rischio, non solo a chiudere il caso.

Le fasi dell'incident response

Molte guide descrivono ancora le quattro fasi della Rev. 2 del 2012: preparazione; rilevamento e analisi; contenimento, eradicazione e ripristino; attività post incidente. La Rev. 3 conserva quella mappa ma la riorganizza sulle sei funzioni del NIST Cybersecurity Framework 2.0. Il motivo, secondo NIST, è che gli incidenti oggi sono frequenti, fanno più danni e il ripristino richiede spesso settimane o mesi: trattare la risposta come un ciclo chiuso, gestito da un team separato, non regge più.

Preparazione: Govern, Identify, Protect

Le funzioni Govern, Identify e Protect non sono risposta in senso stretto, ma la rendono possibile: ruoli e policy, inventario degli asset e dei rischi, misure che riducono il numero di incidenti e il loro impatto. NIST le colloca al livello di base del modello, come gestione del rischio che sostiene la risposta.

Rilevamento: Detect

Trovare e analizzare i possibili attacchi e compromissioni. È la fase in cui un evento avverso diventa, o non diventa, un incidente dichiarato. Qui contano la raccolta dei log, la correlazione e qualcuno che guardi gli allarmi a ogni ora: un attacco notato il lunedì mattina può essere cominciato il venerdì sera.

Risposta: Respond

Le azioni sull'incidente rilevato. NIST le articola in gestione (il piano si esegue in coordinamento con le terze parti interessate, le segnalazioni si verificano, gli incidenti si classificano e si danno priorità), analisi, comunicazione e notifica, mitigazione (contenimento ed eradicazione). Le decisioni ad alto impatto, come spegnere o ricostruire un servizio critico, possono spettare al vertice.

Ripristino: Recover

Riportare in servizio asset e attività colpiti. La SP 800-61 Rev. 3 parla di una parte di ripristino del piano di incident response, che parte quando il processo di risposta la attiva: le azioni si scelgono, si delimitano e si mettono in ordine di priorità, e si verifica l'integrità degli asset ripristinati prima di confermare il ritorno al funzionamento normale.

Miglioramento continuo

Nella Rev. 3 le lezioni apprese non aspettano la fine del ripristino: confluiscono nella categoria Improvement (ID.IM) della funzione Identify appena emergono, e da lì tornano a tutte le altre funzioni. Una regola di rilevamento da correggere, un contatto sbagliato nel piano, un'autorizzazione che nessuno sapeva di dover dare.

Che cos'è un incident response plan

NIST lo descrive come la tabella di marcia per costruire la capacità di risposta agli incidenti, e lo mette accanto ad altri due piani che la toccano da vicino: quello di gestione delle vulnerabilità e quello di continuità operativa. La raccomandazione è di sincronizzare il piano di incident response con la continuità operativa, perché un incidente può mettere in difficoltà la tenuta di tutta l'azienda, e di rivederlo a intervalli regolari o quando emerge un miglioramento importante.

Sopra il piano sta la policy, che secondo la Rev. 3 contiene di solito questi elementi:

• l'impegno della direzione;
• scopo, obiettivi e ambito (a chi e a cosa si applica, in quali circostanze);
• la definizione di evento, incidente e termini collegati;
• ruoli, responsabilità e poteri, per esempio chi può sequestrare, scollegare o spegnere un sistema;
• i criteri per dare priorità agli incidenti, stimarne la gravità e avviare il ripristino;
• le misure di performance.

Sotto il piano stanno le procedure, e spesso i playbook, che le scrivono come passi concreti per scenario. NIST suggerisce di partire dagli incidenti e dalle minacce più comuni: come si costruiscono è spiegato in playbook del SOC.

Un piano scritto ma mai provato cede sulle cose piccole: un numero di telefono vecchio, un backup mai ripristinato, un'approvazione che di notte nessuno può dare. Le esercitazioni a tavolino con chi decide e le prove tecniche lo rendono credibile. Accanto al NIST, il riferimento internazionale per la gestione degli incidenti è la serie ISO/IEC 27035, la cui prima parte è la ISO/IEC 27035-1:2023, Information technology, Information security incident management, Part 1: Principles and process.

Chi si occupa di incident response

La Rev. 3 osserva che un tempo la risposta era quasi solo affare del team interno, mentre oggi dipende da molte persone dentro e fuori l'azienda. I ruoli che elenca:

• Vertice aziendale: supervisiona, assegna il budget e decide sulle azioni ad alto impatto.
• Incident handler: verificano che l'incidente ci sia, raccolgono e analizzano dati ed evidenze, danno priorità alle attività, limitano il danno, cercano la causa e ripristinano. Possono essere interni, a contratto (per esempio un SOC affidato a un fornitore di servizi di sicurezza gestiti) o disponibili al bisogno.
• Tecnici: architetti, sistemisti, responsabili di rete e cloud, sviluppatori.
• Legale: rivede piani, policy e contratti con i fornitori, e consiglia quando un incidente ha conseguenze legali.
• Comunicazione e relazioni con i media, risorse umane, sicurezza fisica e responsabili degli asset, che conoscono le priorità di ripristino dei loro sistemi e processi.

Quando parte della risposta è affidata a un fornitore, NIST parla di responsabilità condivisa e chiede che il contratto la scriva per intero: flussi di informazione, coordinamento, potere di agire per conto dell'azienda e limiti a quello che il fornitore può fare. Chi vuole un team di risposta già ingaggiato prima dell'incidente può valutare un incident response retainer.

Incident response e notifica NIS2

Per i soggetti essenziali e importanti la risposta ha anche un orologio regolatorio. L'art. 25 del D.Lgs. 138/2024 chiede di notificare al CSIRT Italia gli incidenti con impatto significativo, cioè quelli che hanno causato o possono causare una grave perturbazione operativa o perdite finanziarie, oppure perdite considerevoli ad altre persone fisiche o giuridiche. I tempi del comma 5:

• pre-notifica entro 24 ore da quando si è venuti a conoscenza dell'incidente significativo;
• notifica entro 72 ore, con una prima valutazione di gravità e impatto e, se disponibili, gli indicatori di compromissione;
• relazione finale entro un mese dalla notifica, con descrizione, causa probabile e misure di attenuazione.

Sono informazioni che produce il processo di risposta: se la raccolta delle evidenze e la cronologia non partono subito, la notifica a 72 ore arriva vuota. Il dettaglio è in notifica degli incidenti NIS2.

Dove entra un SOC gestito

Per un'azienda mid-market la parte più difficile da coprire da sola è il rilevamento e la prima risposta a ogni ora. NIST nota che un fornitore di servizi può accorgersi prima di un'attività malevola perché correla eventi tra più clienti, e ricorda di valutare il rischio legato agli accessi privilegiati che il fornitore riceve. Un SOC gestito si occupa di monitoraggio, triage e supporto al contenimento; la titolarità del piano, le decisioni di business e le notifiche restano all'azienda.

Se vuoi capire come rilevamento, indagine e contenimento continui si innestano nel tuo processo di incident response, guarda i nostri servizi di cybersecurity.