La pubblicazione NIST SP 800-61 revisione 3, uscita in versione finale nell'aprile 2025, rifonda la guida alla risposta agli incidenti informatici: abbandona il vecchio ciclo di vita in quattro fasi e distribuisce le raccomandazioni lungo le sei funzioni del Cybersecurity Framework 2.0, dal governo del rischio al recupero. Anche una PMI senza un team dedicato può adottarla: servono una politica scritta, ruoli chiari, procedure provate e un riesame dopo ogni incidente. Questa guida spiega cosa cambia, come usarla in azienda e dove gli agenti AI di OverZeus possono dare supporto, lasciando le decisioni alle persone.
Cosa introduce la revisione 3 rispetto alle precedenti
Il NIST (National Institute of Standards and Technology, l'ente tecnico del governo statunitense) ha pubblicato la SP 800-61 revisione 3 nell'aprile 2025, sostituendo la revisione 2 del 2012, che si intitolava Computer Security Incident Handling Guide. Non è una semplice revisione: è un cambio di impianto.
La revisione 2 descriveva la risposta agli incidenti come un ciclo circolare in quattro fasi: preparazione; rilevamento e analisi; contenimento, eradicazione e recupero; attività post-incidente. La revisione 3 spiega perché quel modello non basta più: quando fu scritto, gli incidenti erano rari, circoscritti e si risolvevano in un giorno o due; oggi sono frequenti, causano danni maggiori e il recupero può richiedere settimane o mesi. Inoltre le lezioni apprese non possono aspettare la fine del recupero: vanno condivise appena emergono, alimentando un miglioramento continuo.
Per questo la revisione 3 non propone più un ciclo di vita lineare, ma un Community Profile del Cybersecurity Framework: un profilo condiviso che seleziona i risultati del framework più importanti per la risposta agli incidenti. Le raccomandazioni sono organizzate in due tabelle — la prima per preparazione e lezioni apprese, la seconda per la risposta vera e propria — ogni elemento riceve una priorità (alta, media, bassa) e le indicazioni operative sono marcate come raccomandazioni, considerazioni o note; le organizzazioni sono invitate ad adattare il profilo alle proprie esigenze.
Cambia anche lo scopo: poiché i dettagli tecnici della risposta cambiano troppo in fretta per un documento statico, la revisione 3 rimanda alle risorse online del NIST e si concentra su come integrare la risposta nella gestione del rischio. Ampio spazio va ai ruoli: non solo gli analisti, ma la direzione (che mantiene l'autorità sulle azioni ad alto impatto, come spegnere o ricostruire servizi critici), i tecnici, l'ufficio legale, le relazioni pubbliche, i proprietari dei sistemi e le terze parti, con responsabilità da definire per contratto.
Il collegamento con il Cybersecurity Framework 2.0
Il Cybersecurity Framework (CSF) 2.0, pubblicato dal NIST nel 2024, organizza la sicurezza in sei funzioni. La SP 800-61r3 usa queste funzioni come griglia e assegna a ciascuna un ruolo nella risposta agli incidenti:
| Funzione CSF 2.0 | Ruolo nella risposta agli incidenti |
|---|---|
| Govern (governare) | Definisce strategia, politiche e responsabilità: chi può decidere, con quali autorità e limiti. |
| Identify (identificare) | Comprende rischi e risorse; include il miglioramento continuo, dove confluiscono le lezioni apprese. |
| Protect (proteggere) | Riduce numero e impatto degli incidenti con misure preventive e prepara l'organizzazione a gestirli. |
| Detect (rilevare) | Trova e analizza possibili attacchi e compromissioni. |
| Respond (rispondere) | Gestisce l'incidente: priorità, contenimento, eradicazione, comunicazioni e notifiche. |
| Recover (recuperare) | Ripristina sistemi e operazioni colpiti dall'incidente. |
La risposta agli incidenti in senso stretto vive in Detect, Respond e Recover; Govern, Identify e Protect sono attività di gestione del rischio più ampie, che però determinano quanto la risposta sarà rapida ed efficace. Questo è il messaggio centrale della revisione 3: la risposta non è un compito isolato di un team, ma una parte della gestione del rischio che attraversa tutta l'organizzazione.
Il testo ufficiale della pubblicazione contiene raccomandazioni molto concrete. Alcuni esempi, tradotti in pratica:
- Verificare e stimare la gravità. A ogni nuova segnalazione, prima verificare che si tratti davvero di un incidente, poi stimarne gravità e urgenza, e classificarlo per tipologia (violazione di dati, ransomware, furto di account, negazione del servizio).
- Dare priorità con criteri scritti. La rapidità della risposta dipende da portata, impatto probabile, urgenza e risorse disponibili; ogni strategia ha dei compromessi, per esempio osservare l'attaccante più a lungo contro il ripristino rapido delle operazioni.
- Distinguere escalation ed elevazione. L'escalation aumenta risorse o tempi dedicati, l'elevazione coinvolge un livello gerarchico superiore; le procedure dovrebbero prevedere entrambe (ne parliamo in priorità ed escalation nel SOC).
- Conservare le evidenze secondo una procedura. La raccolta segue le politiche di conservazione, valutando la possibilità di azioni legali e i costi di mantenimento dei dati (vedi come ricostruire un incidente con timeline ed evidenze).
- Riesaminare e migliorare. Valutare periodicamente il programma di risposta, condurre esercitazioni (il NIST rimanda alla SP 800-84 per simulazioni e discussioni a tavolino) e tenere riunioni sulle lezioni apprese quando il recupero si conclude.
Cosa può fare una PMI senza un team dedicato
La pubblicazione è pensata per la maggior parte delle organizzazioni, indipendentemente da settore e dimensione. Per una piccola o media impresa senza un centro operativo di sicurezza (SOC, Security Operations Center), il percorso realistico è questo:
- Scrivere una politica breve. La revisione 3 elenca gli elementi tipici: impegno della direzione, scopo, ambito, definizioni, ruoli e autorità (per esempio chi può scollegare o spegnere un sistema), criteri di priorità e misure di efficacia. Bastano poche pagine, ma scritte.
- Assegnare i ruoli, anche a tempo parziale. Un responsabile degli incidenti e un sostituto, con una catena di elevazione verso la direzione. Se la gestione tecnica è affidata a un fornitore esterno, il contratto chiarisce cosa può fare e con quale autorità di agire.
- Documentare le procedure per gli incidenti più comuni. Non serve coprire ogni scenario: meglio poche procedure chiare (playbook) per i casi probabili, provate periodicamente.
- Allenarsi. Esercitazioni brevi e regolari, anche solo discussioni a tavolino su uno scenario, mostrano dove la procedura non regge prima che serva davvero. Approfondiamo il metodo in esercitazioni di risposta agli incidenti.
- Chiudere il cerchio. Dopo ogni incidente, una riunione sulle lezioni apprese: cosa è successo, cosa si è fatto, quanto è stato efficace. Le conclusioni aggiornano politica e procedure.
Come punto di partenza, il NIST offre anche la Small Business Quick Start Guide del CSF 2.0, pensata per piccole imprese con piani di sicurezza modesti o assenti (alla data di consultazione è disponibile in inglese, senza traduzione italiana ufficiale). La SP 800-61r3 resta il riferimento per la risposta agli incidenti: se state valutando strumenti di supporto, la griglia di criteri per scegliere un SOC AI aiuta a confrontare le offerte.
Esempio illustrativo: l'incidente del server documentale
Esempio illustrativo. Lo scenario seguente mostra come una procedura ispirata alla revisione 3 può funzionare in una media impresa; non racconta un incidente avvenuto presso un cliente.
Un'azienda di logistica di sessanta dipendenti, senza un team di sicurezza interno, ha scritto la sua politica di risposta agli incidenti: criteri di gravità (grave se coinvolge dati dei clienti o ferma le spedizioni), un responsabile e un sostituto, un accordo con il fornitore IT che definisce cosa può fare in autonomia.
Una notte, i sistemi di monitoraggio collegati segnalano modifiche massive e anomale sui file del server documentale. Seguendo la procedura, il caso viene classificato per tipologia e gravità. Ares, l'agente dedicato al SOC, riunisce i segnali disponibili, valuta quali account e condivisioni sono coinvolti e propone un piano di contenimento: isolare il server, con l'impatto spiegato in chiaro — al mattino l'ufficio documenti lavorerebbe al rallentatore. Il responsabile, raggiunto secondo la catena prevista, approva il piano: vengono eseguite solo le misure elencate e approvate. Mnemosyne conserva fonti, timeline, proposta, autorizzazione ed esiti, così il percorso resta ricostruibile anche mesi dopo.
A recupero concluso, la riunione sulle lezioni apprese scopre un problema: due versioni del runbook di ripristino si contraddicono. Nestor, che recupera manuali e procedure rispettando i permessi, evidenzia versioni, provenienza e differenze; il proprietario approva la versione corretta attraverso il processo documentale previsto. Le comunicazioni ai clienti e l'eventuale valutazione legale restano alla direzione: sono decisioni che la procedura assegna alle persone, non agli strumenti.
Dove gli agenti danno supporto e dove serve la persona
Rispetto alle funzioni del CSF 2.0, il contributo degli agenti di OverZeus si colloca in punti precisi, con responsabilità umane esplicite:
- Ares (Detect e Respond): organizza priorità, indagini, escalation e proposte di contenimento. Ogni intervento segue un piano con responsabilità e autorizzazioni chiare, ed esegue soltanto le misure elencate e approvate.
- Nestor (Govern e Protect): mantiene accessibili procedure, manuali e casi precedenti, rimandando alle fonti aziendali approvate e segnalando documenti contraddittori al proprietario della procedura.
- Mnemosyne (evidenze e miglioramento): conserva fonti, timeline, proposte, autorizzazioni ed esiti; segnala le lacune senza inventare ricostruzioni, supportando il riesame post-incidente.
Restano alle persone le decisioni ad alto impatto — contenere un servizio critico, sospendere un account, informare clienti e autorità, valutare gli aspetti legali — come la revisione 3 assegna alla direzione l'autorità sulle azioni di risposta più pesanti. Nel flusso OverZeus il silenzio non autorizza: in assenza dell'approvazione prevista, l'intervento attivo non parte. Con la modalità di sola osservazione si può concordare un periodo in cui il sistema prepara proposte senza modificare la produzione. OverZeus supporta attività ed evidenze utili ai percorsi di conformità, ma non certifica l'organizzazione e non invia nulla alle autorità da solo.
Dalla pubblicazione alle procedure
La SP 800-61 revisione 3 chiede un cambio di prospettiva: la risposta agli incidenti non è un manuale che si apre in emergenza, ma una capacità distribuita nella gestione quotidiana del rischio. Il lavoro pratico è tradurre il profilo in una politica breve, ruoli definiti, procedure provate e un riesame dopo ogni caso — con strumenti che aiutano a vedere, spiegare e conservare, mentre le decisioni restano alle persone.
Vuoi vedere come segnale, proposta e approvazione si incastrano nelle tue procedure di risposta agli incidenti?
Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.