Gestione degli incidenti NIS 2 ai sensi dell'articolo 21(2)(b)
L'articolo 21(2)(b) è il dovere interno: rilevare, contenere, ripristinare, documentare, apprendere. L'articolo 23 è il dovere esterno: informare il BSI o il tuo CSIRT nazionale. Due doveri diversi, spesso confusi. Il CIR (UE) 2024/2690 §3 specifica quello interno.
La versione breve
La gestione degli incidenti è il punto (b) dell'elenco di dieci doveri di cybersicurezza dell'articolo 21(2). Riguarda ciò che fai dentro l'azienda quando qualcosa va storto: individuarlo, contenerlo, ripristinare, mettere per iscritto cos'è successo, apprenderne.
Il CIR (UE) 2024/2690 §3 riempie il dettaglio in sei sotto-sezioni: §3.1 un concetto scritto di gestione degli incidenti, §3.2 monitoraggio e logging, §3.3 escalation interna degli eventi, §3.4 classificazione, §3.5 la risposta vera e propria (contenimento, eradicazione, ripristino), §3.6 la revisione post-incidente. Se gestisci DNS, cloud, un data center, un MSP o qualsiasi altro settore dell'allegato CIR, questo ti vincola direttamente.
La Germania recepisce lo stesso dovere nel diritto nazionale tramite il §30(2)(2) BSIG. La formula è 'Bewältigung von Sicherheitsvorfällen', le stesse parole della direttiva. Questa pagina ripercorre la direttiva, il regolamento UE attuativo e il recepimento tedesco in quest'ordine.
Articolo 21(2)(b) Direttiva NIS 2 (2022/2555)
Incident handling.
Il punto (b) dell'elenco di dieci misure di cybersicurezza. Due parole nel testo della direttiva. Il CIR §3 trasforma quelle due parole in dettaglio operativo. Importante: questo è il dovere di gestione interna. Il dovere esterno di notificare al CSIRT vive nell'articolo 23 ed è una pagina separata.
CIR (UE) 2024/2690, Allegato §3
For the purposes of Article 21(2)(b) of Directive (EU) 2022/2555, the relevant entities shall establish and implement a policy on incident handling, defining roles, responsibilities and procedures for the timely detection, analysis, containment or response, recovery as well as documentation and reporting of incidents.
Poiché si tratta di un regolamento, è diritto UE direttamente vincolante. Non serve alcun recepimento nazionale. L'allegato §3 scompone il dovere in sei sotto-sezioni: concetto (§3.1), logging (§3.2), escalation interna (§3.3), classificazione (§3.4), risposta (§3.5), revisione post-incidente (§3.6).
§30(2)(2) BSIG (Germania)
Bewältigung von Sicherheitsvorfällen.
La Germania copia la formulazione della direttiva parola per parola. La sostanza è identica all'articolo 21(2)(b). Il BSI usa poi i moduli IT-Grundschutz (in particolare DER.2 'Vorfall-Bewältigung') per mostrare come si presenta in pratica un concetto scritto di gestione degli incidenti.
Un concetto scritto di gestione degli incidenti
Metti per iscritto chi fa cosa quando qualcosa va storto. Ruoli, responsabilità, i passaggi per rilevamento, analisi, contenimento, ripristino, documentazione e segnalazione interna. Il CIR §3.1.1 esige che il concetto esista prima dell'incidente, non dopo. L'organo di gestione deve approvarlo.
Monitoraggio e logging
Non puoi gestire ciò che non puoi vedere. Il CIR §3.2 elenca dodici tipi di evento che devi registrare (tentativi di accesso, modifiche dei privilegi, rilevamenti di malware, anomalie di rete e altri). I log devono essere resistenti alle manomissioni e conservati abbastanza a lungo da supportare l'analisi. Questo è il livello di rilevamento.
Fasi di risposta: contenimento, eradicazione, ripristino
Il CIR §3.5 suddivide la risposta in tre fasi. Il contenimento impedisce all'incidente di propagarsi. L'eradicazione rimuove la causa radice. Il ripristino riporta i sistemi a uno stato noto e integro. Ogni fase deve essere documentata man mano, così che il §3.6 (revisione post-incidente) abbia materiale su cui lavorare.
La gestione interna non è la notifica esterna
L'articolo 21(2)(b) è ciò che fai dentro l'azienda. L'articolo 23 è ciò che comunichi al regolatore (preallarme entro 24 ore, notifica dell'incidente entro 72 ore, relazione finale entro un mese al BSI o al tuo CSIRT nazionale). Due doveri separati. Effettuare la notifica non assolve la gestione, ed effettuare la gestione non assolve la notifica.
La revisione post-incidente confluisce nella gestione dei rischi
Il CIR §3.6 chiude il ciclo. Le lezioni di ogni incidente confluiscono nel framework di gestione dei rischi del CIR §2. Vengono aggiunti nuovi rischi, aggiornati i piani di trattamento, adeguati i controlli. È il ciclo PDCA. Un incidente che gestisci ma da cui non apprendi è un lavoro a metà.
BSI / §30(2)(2) BSIG
Il BSI elenca la gestione degli incidenti negli Infopakete come la seconda delle dieci misure dell'articolo 21(2). Il recepimento tedesco usa la stessa formula della direttiva. Il BSI indica il modulo IT-Grundschutz DER.2 ('Vorfall-Bewältigung') come via pratica. DER.2 ti guida attraverso il concetto, il playbook, i ruoli e la revisione post-incidente.
ENISA Technical Implementation Guidance
La TIG di ENISA prende il CIR §3 e ti mostra come si presentano le prove in pratica: il concetto scritto, il playbook, i registri delle simulazioni, le note di revisione post-incidente. Mappa inoltre il §3 sui controlli consolidati di ISO/IEC 27001:2022 (clausole da A.5.24 a A.5.28) e NIST CSF 2.0 (le funzioni Respond e Recover), così una certificazione esistente ti dà un vantaggio iniziale.
Leggi nazionali di recepimento
Ogni Stato membro ha la propria legge di recepimento (Paesi Bassi: Cyberbeveiligingswet, Austria: NISG, Belgio: NIS2-Wet). Il dovere è lo stesso perché la direttiva fissa un unico standard valido in tutta l'UE. Ciò che differisce: quale CSIRT contatti per la notifica dell'articolo 23, e come ciascuna autorità nazionale formula gli orientamenti pratici.
Notifichiamo al BSI quando succede qualcosa, quindi siamo coperti.
Questo copre l'articolo 23, non l'articolo 21(2)(b). Notificare al CSIRT è il dovere esterno. L'articolo 21(2)(b) è quello interno: rilevare, contenere, ripristinare, documentare, riesaminare. Entrambi devono esistere. Un auditor chiederà di vedere il concetto di gestione degli incidenti (CIR §3.1) oltre al registro delle notifiche dell'articolo 23.
Scriveremo il playbook quando succederà qualcosa.
Il CIR §3.1.1 è esplicito: il concetto deve essere 'definito e attuato' prima dell'incidente. Ruoli, responsabilità, procedure, tutto su carta, approvati dalla dirigenza. Scriverlo durante l'incidente non è gestione, è improvvisazione. Gli auditor controllano per primo il concetto datato e firmato.
Se ne occupa il team IT, basta così.
Il CIR §3.1.1 esige ruoli e responsabilità documentati. Chi dichiara un incidente. Chi decide il contenimento. Chi parla con il legale. Chi approva il ripristino. L'organo di gestione deve approvare il concetto. 'Se ne occupa il team IT' non è una struttura, è un presupposto.
La lacuna tipica del Mittelstand è la documentazione, non la capacità. Il rilevamento avviene (qualcuno se ne accorge, l'IT indaga, il problema viene risolto). La documentazione no. Senza il registro datato di chi ha fatto cosa, l'auditor non ha modo di verificare che il §3 sia stato seguito. La soluzione è costruire prima il playbook, poi simulare due volte l'anno, poi raccogliere le lezioni nel modello di revisione post-incidente.
Due simulazioni all'anno è ciò su cui converge la maggior parte degli operatori con cui parliamo. Una tabletop (persone attorno a un tavolo che ripercorrono il playbook su uno scenario), una tecnica (un ripristino controllato da backup, un'esercitazione di risposta al phishing, qualcosa che metta alla prova gli strumenti). Lo scopo è trovare le lacune prima di un auditor, o prima di un incidente reale. La proporzionalità dell'articolo 21(1) ti consente di dimensionare la simulazione sulle tue dimensioni e sul tuo quadro di rischio; non ti consente di saltarle.
Abbiamo integrato il CIR §3 nella piattaforma come modulo INC. Registri un incidente, acquisisci la classificazione ai sensi del §3.4, ripercorri le fasi di risposta (contenimento, eradicazione, ripristino) con marche temporali ed esegui la revisione post-incidente alla fine. L'audit trail registra ogni passaggio. Nessun cumulo di fogli di calcolo.
La revisione post-incidente del §3.6 è la parte che la maggior parte dei team salta. L'abbiamo resa un campo obbligatorio prima che un incidente possa essere chiuso: cosa è andato storto, cosa ha funzionato, quali modifiche confluiscono nel framework di rischio del CIR §2. La notifica dell'articolo 23 (24h / 72h / un mese) è un modulo separato che usa lo stesso record di incidente, così non digiti i fatti due volte.
- Direttiva (UE) 2022/2555 (NIS 2), Articolo 21(2)(b) — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Regolamento di esecuzione (UE) 2024/2690 della Commissione (CIR), Allegato §3 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- Legge BSI (BSIG), §30(2)(2) come modificato dalla legge di attuazione di NIS2 e di rafforzamento della cybersicurezza
- Modulo IT-Grundschutz del BSI DER.2 'Vorfall-Bewältigung' — bsi.bund.de/grundschutz
- ENISA Technical Implementation Guidance per il CIR (UE) 2024/2690, mappatura del §3 su ISO/IEC 27001:2022 e NIST CSF 2.0