Notifica di incidente OT sotto NIS2: obblighi, tempi e cosa avere pronto prima che succeda

La struttura dell'obbligo di notifica NIS2

NIS2 (recepita in Italia con il D.Lgs. 138/2024) introduce per i soggetti essenziali e importanti un obbligo di notifica degli incidenti significativi strutturato in tre fasi con scadenze precise:

Pre-alert (Early Warning): entro 24 ore dal momento in cui l'organizzazione viene a conoscenza dell'incidente. Non deve essere una notifica completa: deve comunicare la natura dell'incidente, se è sospetto di essere intenzionale (attacco), se ha potenziale impatto transfrontaliero. È un segnale precoce, non un'analisi.

Notifica dettagliata: entro 72 ore. Include una valutazione preliminare dell'incidente, la sua gravità e impatto, gli indicatori di compromissione disponibili, le misure di mitigazione adottate. Se l'analisi non è ancora completa, si fornisce lo stato dell'investigazione in corso.

Report finale: entro un mese dalla notifica dettagliata (o dalla risoluzione dell'incidente se successiva). Include l'analisi completa delle cause, l'impatto effettivo, le misure adottate per eliminare la vulnerabilità sfruttata e prevenire recidive.

Il destinatario della notifica è il CSIRT-IT (il Computer Security Incident Response Team italiano), che opera sotto ACN (Agenzia per la Cybersicurezza Nazionale). La notifica avviene attraverso il portale dedicato di ACN, previa registrazione dell'organizzazione.

Cosa conta come "incidente significativo" in ambito OT

La definizione di incidente significativo ai fini della notifica non è banale, e in ambito OT ha alcune caratteristiche specifiche rispetto all'IT.

Un incidente è significativo quando supera almeno una delle seguenti soglie (definite dalla normativa e dalle linee guida ENISA):

Impatto sulla continuità del servizio o della produzione. Interruzione o degradazione significativa dei servizi dell'organizzazione. In ambito manifatturiero, questo include fermi produttivi non programmati causati da eventi cyber: un ransomware che cifra i sistemi SCADA, una manipolazione della logica PLC che causa arresti di sicurezza non necessari, un attacco che rende indisponibili gli HMI di supervisione.

Impatto economico rilevante. La soglia esatta dipende dalla classificazione del soggetto e dalle linee guida nazionali, ma in generale perdite economiche significative (fermi produttivi prolungati, danni a impianti, costi di ripristino rilevanti) rientrano nel perimetro.

Impatto su terzi. Se l'incidente ha effetti su clienti, fornitori, o su infrastrutture di altri soggetti. In ambito OT questo può includere situazioni dove la compromissione di un sistema di controllo ha effetti sulla sicurezza pubblica (un impianto di trattamento acque, un sistema di distribuzione energetica).

Violazione della riservatezza di dati significativi. Anche in ambito OT: esfiltrazione di dati di processo, di disegni di impianto, di configurazioni dei sistemi di controllo.

La soglia di "significativo" lascia margini di interpretazione, e questo è uno degli aspetti più complessi della compliance NIS2. La raccomandazione pratica è avere una procedura interna di classificazione degli incidenti che definisca preventivamente, con esempi concreti, quali scenari attivano l'obbligo di notifica. Aspettare l'incidente per decidere se è significativo significa gestire quella decisione sotto pressione, con informazioni incomplete, in un momento in cui le risorse sono già impegnate nella risposta.

Cosa serve avere pronto prima dell'incidente

I 24 ore per il pre-alert sembrano pochi ma sono gestibili se l'organizzazione è preparata. Diventano impossibili se la risposta inizia da zero al momento dell'incidente.

Inventario degli asset OT aggiornato. Il primo elemento che CSIRT-IT chiederà è: quali sistemi sono stati coinvolti? Rispondere richiede un inventario che non solo esiste ma è aggiornato. Un inventario fatto sei mesi fa e mai rivisto non basta: nella rete OT i dispositivi cambiano (installazioni, sostituzioni, configurazioni), e l'inventario deve riflettere lo stato reale al momento dell'incidente.

Log di sistema conservati e recuperabili. Le evidenze tecniche dell'incidente vivono nei log: traffico di rete catturato dal monitoring OT, log di accesso ai sistemi, log di configurazione dei dispositivi. Questi log devono essere conservati per un periodo adeguato (NIS2 non definisce un minimo specifico, ma le buone pratiche indicano almeno sei mesi per i log di rete, un anno per gli eventi di sicurezza significativi) e devono essere recuperabili rapidamente. Un log che esiste ma richiede ore per essere estratto e reso leggibile è un problema durante un'investigazione sotto pressione.

Indicatori di baseline e di anomalia. Per descrivere un incidente in modo utile al CSIRT, è necessario poter confrontare il comportamento osservato durante l'incidente con il comportamento normale. Senza una baseline documentata del traffico OT e del comportamento dei dispositivi, è difficile dire "questo è anomalo" in modo convincente e preciso. Il monitoring continuo, oltre al suo valore operativo, è anche la fonte di evidenza che permette di costruire questa comparazione.

Contatti CSIRT-IT preregistrati e procedura di accesso al portale. La registrazione al portale ACN per le notifiche NIS2 non va fatta durante un incidente. Va fatta prima, con i dati dell'organizzazione corretti, con i referenti identificati, con le credenziali di accesso testate. Al momento del pre-alert di 24 ore, chi deve notificare deve sapere dove andare, con quali credenziali, con quale template compilare.

Responsabilità chiari su chi attiva la notifica. Chi decide che un incidente è "significativo"? Chi ha l'autorità di inviare la notifica a CSIRT-IT? Chi coordina la raccolta delle informazioni per la notifica dettagliata? Queste responsabilità devono essere documentate nella procedura di incident response e devono includere un backup per le situazioni in cui la persona primaria non è disponibile (fuori ufficio, coinvolta nella risposta tecnica, raggiunta durante le vacanze).

Il ruolo del monitoring continuo come fonte di evidenza

C'è un aspetto della notifica NIS2 che spesso non viene enfatizzato abbastanza: la qualità della notifica dipende dalla qualità delle evidenze disponibili, e le evidenze vengono dal monitoring.

Un'organizzazione che ha monitorato passivamente il traffico OT nei mesi precedenti l'incidente ha a disposizione, al momento della notifica:

• La sequenza temporale esatta degli eventi anomali, con timestamp precisi
• L'elenco dei dispositivi coinvolti nelle comunicazioni sospette
• I pattern di traffico che si discostano dalla baseline
• Gli indicatori tecnici (IP di destinazione, protocolli usati, function code, payload quando applicabile) che permettono di descrivere l'attacco in modo tecnico

Un'organizzazione senza monitoring deve ricostruire questi elementi post-hoc, spesso in modo incompleto, da log frammentati o memorie dei tecnici presenti. La notifica risultante è meno precisa, meno convincente, e più difficile da usare come base per il report finale.

Il monitoring continuo non è quindi solo un tool operativo per la detection: è anche l'infrastruttura di evidenza che rende possibile una notifica NIS2 di qualità. CSIRT-IT che riceve una notifica con IoC precisi, timeline documentata e impatto misurato può fornire un supporto più efficace rispetto a una notifica vaga.

Simulare la notifica prima che serva: l'esercitazione tabletop

La procedura di notifica NIS2 non va letta una volta e messa in un cassetto. Va esercitata.

Un'esercitazione tabletop specifica per la notifica NIS2 in ambito OT non richiede infrastruttura complessa: bastano tre o quattro ore, le persone giuste nella stanza (o in videochiamata), e uno scenario di incidente realistico.

Lo scenario può essere semplice: "Lunedì mattina il monitoring OT rileva comportamento anomalo su tre PLC della linea di produzione principale. L'analisi iniziale suggerisce accesso non autorizzato. Cosa facciamo nelle prossime 24 ore?"

L'esercitazione fa emergere le lacune reali: chi ha le credenziali del portale ACN? Dove si trova il template della notifica? Quanto tempo ci vuole per estrarre i log del monitoring OT degli ultimi 48 ore? Chi approva il testo della notifica prima dell'invio? Il responsabile legale è al corrente dell'obbligo e deve essere coinvolto?

Le lacune emerse durante un tabletop si correggono in settimane. Le stesse lacune emerse durante un incidente reale si trasformano in violazioni della normativa, con conseguenze sanzionatorie che si aggiungono al danno operativo dell'incidente.

Il timing raccomandato per l'esercitazione è almeno una volta all'anno, più spesso se l'organizzazione è nella fase iniziale di implementazione della compliance NIS2 o se ci sono stati cambiamenti significativi nell'organizzazione (nuovi referenti, nuovi sistemi OT, acquisizioni).

Cosa fare oggi per essere pronti

Un piano di preparazione alla notifica NIS2 in ambito OT che sia realizzabile in sequenza logica:

1. Verificare se l'organizzazione rientra nel perimetro NIS2 come soggetto essenziale o importante, e in quale settore. La classificazione determina le soglie e i requisiti specifici.

2. Registrare l'organizzazione sul portale ACN e identificare i referenti NIS2 ufficiali (punto di contatto, responsabile della sicurezza informatica).

3. Definire la procedura interna di classificazione degli incidenti: cosa è "significativo", con esempi concreti per il contesto OT dell'organizzazione.

4. Documentare le responsabilità nella catena di notifica: chi decide, chi notifica, chi coordina la raccolta di evidenze, chi comunica con CSIRT-IT.

5. Verificare che il monitoring OT (se presente) generi e conservi log con timestamp precisi e in formato recuperabile. Se il monitoring non c'è, questo è il gap più urgente da colmare.

6. Condurre un tabletop su uno scenario di incidente OT, con focus specifico sulla procedura di notifica nelle prime 24-72 ore.

La notifica NIS2 non è la parte più difficile della risposta a un incidente OT. La parte difficile è tutto ciò che precede: rilevare l'incidente, contenerlo, raccogliere le evidenze. Ma arrivare impreparati anche alla notifica, che è la parte più procedurale, sarebbe un errore evitabile.

L'angolo MON5

Rispettare le 24 ore del pre-alert senza un monitoraggio attivo è, come visto, quasi impossibile. La fase PROTECT di MON5 fornisce l'infrastruttura di evidenza descritta nell'articolo: monitoraggio continuo passivo del traffico OT, baseline per asset, timeline degli eventi anomali con timestamp precisi e indicatori tecnici pronti per la notifica al CSIRT-IT. L'inventario aggiornato in continuo dalla fase ANALYZE risponde alla prima domanda di ogni notifica: quali sistemi sono coinvolti.

Prepararsi prima dell'incidente significa anche sapere da dove partire. Per verificare se oggi sareste in grado di produrre queste evidenze, potete iniziare con un assessment OT.