Il primo martello della NIS2: un campanello d'allarme da milioni di euro

Cosa è successo

Con una decisione storica pubblicata il 15-11-2025, le autorità di regolamentazione dell'UE hanno imposto le prime multe sostanziali ai sensi della direttiva NIS2. Un operatore di infrastrutture critiche, responsabile di servizi essenziali in diversi Stati membri, ha ricevuto una sanzione di diversi milioni di euro. L'infrazione principale non è stata l'incidente di sicurezza iniziale, ma un grave fallimento nell'aderire alle tempistiche prescritte per la segnalazione degli incidenti e ai requisiti informativi.

L'organismo di regolamentazione ha citato carenze sistemiche nel programma di risposta agli incidenti (IR) dell'operatore. In particolare, la notifica iniziale di un incidente di cybersicurezza significativo è stata ritardata di oltre 72 ore, superando di gran lunga le soglie di preavviso di 24 ore e di segnalazione completa di 72 ore imposte dall'articolo 23 della NIS2. Anche gli aggiornamenti successivi sono stati ritenuti insufficienti, privi di dettagli critici sull'ambito, l'impatto e le azioni di mitigazione dell'incidente.

Questa azione di enforcement sottolinea l'impegno dell'UE per una solida governance della cybersicurezza. Invia un chiaro messaggio che la conformità agli obblighi di segnalazione non è solo un onere amministrativo, ma una componente critica della resilienza alla cybersicurezza nazionale e regionale. L'ammontare della sanzione riflette la gravità della non conformità, in particolare data la designazione dell'operatore come settore critico.

Perché questo schema continua a ripetersi

Il fallimento nella segnalazione degli incidenti osservato riflette una sfida pervasiva all'interno di molte organizzazioni: la disconnessione tra i piani IR teorici e l'esecuzione pratica sotto pressione. Sebbene la maggior parte delle aziende mature possieda playbook di risposta agli incidenti, questi spesso rimangono documenti statici, raramente sottoposti a stress test rispetto a scenari di attacco reali o a mandati normativi in evoluzione.

I silos operativi esacerbano questo problema. I centri operativi di sicurezza (SOC) potrebbero rilevare un'anomalia, ma il processo di escalation, convalida e segnalazione formale di un incidente spesso coinvolge più team – legale, comunicazioni, leadership esecutiva – ognuno con le proprie priorità e la propria comprensione dell'urgenza. Questo attrito nel passaggio di consegne introduce ritardi significativi, specialmente quando si tratta di intelligence sulle minacce ambigua o in evoluzione.

Inoltre, l'enorme volume e la complessità dei quadri normativi (NIS2, DORA, GDPR, CCPA, HIPAA, ecc.) creano 'fatica da conformità'. Le organizzazioni spesso si concentrano sul spuntare le caselle per gli audit piuttosto che sull'incorporare veramente i requisiti di conformità nel loro DNA operativo. Quando si verifica un incidente reale, le specifiche sfumature di ogni tempistica normativa e requisito di dati possono essere facilmente trascurate o interpretate erroneamente.

L'effetto 'Nebbia di guerra'

Durante un incidente di sicurezza attivo, in particolare uno sofisticato come un attacco ransomware o un'intrusione APT di uno stato-nazione, i team sono sotto un'immensa pressione. Le risorse sono scarse, le informazioni sono frammentate e la priorità spesso è la contenimento e l'eradicazione. La segnalazione normativa, sebbene critica, può essere percepita come una preoccupazione secondaria, portando a invii affrettati, incompleti o ritardati.

Questo effetto 'nebbia di guerra' è aggravato dalla mancanza di canali di comunicazione e modelli predefiniti e chiari per l'impegno normativo. Senza questi, i responsabili della risposta agli incidenti devono creare comunicazioni ad hoc, consumando ulteriormente tempo prezioso e aumentando il rischio di non conformità.

Il playbook dell'attaccante passo dopo passo

Gli attaccanti sfruttano costantemente le debolezze nelle capacità di rilevamento, risposta e segnalazione di un'organizzazione. Una tipica catena di attacco che porta a tali fallimenti nella segnalazione spesso segue un modello simile alle TTP del framework MITRE ATT&CK:

1. Accesso Iniziale (es. Phishing, Servizi Remoti Esterni): Gli attaccanti ottengono un punto d'appoggio, spesso tramite una campagna di spear-phishing mirata (T1566.001) o sfruttando un servizio vulnerabile esposto a Internet (T1190).
2. Persistenza (es. Manipolazione Account, Attività Pianificata): Una volta all'interno, stabiliscono un accesso duraturo, magari creando nuovi account (T1136) o modificando i servizi di sistema (T1543.003) per garantire un controllo continuo anche dopo i riavvii.
3. Elusione della Difesa (es. File/Informazioni Offuscate, Rimozione Indicatori): Gli attaccanti lavorano attivamente per evitare il rilevamento. Potrebbero crittografare o codificare il malware (T1027), rimuovere i log (T1070.003) o disabilitare gli strumenti di sicurezza (T1562.001).
4. Accesso alle Credenziali (es. Dump Credenziali OS, Forza Bruta): Scalano i privilegi, spesso scaricando le credenziali dalla memoria (T1003) o sfruttando password deboli.
5. Scoperta (es. Scoperta Condivisioni di Rete, Scoperta Informazioni di Sistema): Gli attaccanti mappano la rete, identificano gli asset critici e comprendono l'ambiente (T1087, T1046).
6. Movimento Laterale (es. Servizi Remoti, Pass the Hash): Si muovono attraverso la rete, compromettendo sistemi e account aggiuntivi, spesso utilizzando strumenti come PsExec o sfruttando vulnerabilità Kerberos (T1550).
7. Impatto (es. Crittografia Dati per Impatto, Esfiltrazione Dati): La fase finale prevede il raggiungimento del loro obiettivo, sia che si tratti di crittografare i dati per il riscatto (T1486), esfiltrare informazioni sensibili (T1041) o interrompere le operazioni.

È durante la fase di 'Impatto' che un'organizzazione tipicamente viene a conoscenza della violazione. La successiva corsa per comprendere l'ambito e contenere il danno influisce direttamente sulla capacità di rispettare rigorose tempistiche di segnalazione. Gli attaccanti lo sanno e spesso temporizzano il loro impatto per i fine settimana o i giorni festivi, stressando ulteriormente i team IR e aumentando la probabilità di ritardi nella segnalazione.

Cosa i difensori hanno perso

Il fallimento dell'operatore di infrastrutture critiche non è derivato interamente da una mancanza di controlli tecnici, ma da un'interruzione nell'operatività del suo quadro di risposta agli incidenti e di conformità. Diverse aree chiave hanno probabilmente contribuito:

Innanzitutto, l'incapacità di condurre regolarmente esercizi da tavolo realistici o attività di purple teaming che testino specificamente i requisiti di segnalazione normativa. Molti esercizi si concentrano sul contenimento tecnico, trascurando gli aspetti critici di comunicazione e legali.

In secondo luogo, un'inadeguata integrazione della threat intelligence con i processi IR. Indicatori precoci, come traffico di rete anomalo o accessi sospetti, potrebbero essere stati rilevati ma non scalati con l'urgenza necessaria o correlati a potenziali implicazioni normative. Il problema del 'rapporto segnale/rumore' in molti SOC spesso oscura questi avvisi precoci critici.

Terzo, la mancanza di modelli di comunicazione e percorsi di escalation chiari e pre-approvati per gli organismi di regolamentazione. Quando si verifica un incidente, la stesura di queste comunicazioni da zero sotto pressione è una ricetta per ritardi ed errori. Senza contenuti predefiniti, i soli cicli di revisione legale possono consumare ore critiche.

"La conformità non è una casella di controllo; è una postura operativa in tempo reale. NIS2 sta semplicemente formalizzando ciò che i programmi di sicurezza maturi dovrebbero già fare: rilevamento rapido, risposta decisa e segnalazione trasparente."

Infine, una formazione interfunzionale insufficiente. Gli ingegneri della sicurezza e i team legali spesso operano in sfere separate. La comprensione delle sfumature tecniche di un incidente deve essere tradotta efficacemente in un linguaggio legalmente conforme e adatto ai regolatori, una competenza che spesso manca in entrambi i campi senza una formazione e una collaborazione specifiche.

Una pratica checklist difensiva

I CISO e gli ingegneri della sicurezza devono incorporare proattivamente il rigore della segnalazione a livello NIS2 nel loro ciclo di vita di risposta agli incidenti. Considera queste azioni:

• Conduci esercizi da tavolo specifici per NIS2: Simula un incidente significativo, concentrandoti esplicitamente sulle tempistiche di segnalazione di 24/72 ore. Coinvolgi il team legale, le comunicazioni e la leadership esecutiva.
• Automatizza il rilevamento e l'allerta iniziali: Implementa playbook SOAR che attivino notifiche interne immediate e redigano riepiloghi iniziali degli incidenti al rilevamento di eventi ad alta gravità.
• Pre-approva i modelli di segnalazione: Sviluppa e verifica legalmente modelli per le notifiche normative iniziali, gli aggiornamenti intermedi e i rapporti finali per vari tipi di incidenti. Includi campi segnaposto per i dettagli specifici dell'incidente.
• Stabilisci canali di comunicazione dedicati con le autorità di regolamentazione: Definisci percorsi di escalation chiari e contatti nominati per interagire con le autorità nazionali di cybersicurezza (CSIRT/NCA) e i regolatori settoriali pertinenti.
• Integra la threat intelligence con le piattaforme IR: Assicurati che le tue soluzioni SIEM/XDR possano correlare la threat intelligence in tempo reale con gli eventi di sicurezza interni per prioritizzare gli incidenti con potenziale impatto normativo.
• Forma incrociatamente i team IR e legali: Organizza workshop in cui i team IR istruiscono il team legale sulle specifiche tecniche degli incidenti e il team legale istruisce i team IR sulle sfumature normative e sui requisiti di segnalazione.
• Implementa il monitoraggio continuo dei controlli: Automatizza la raccolta e l'analisi delle prove che dimostrano l'aderenza ai controlli di segnalazione degli incidenti NIS2, garantendo una visibilità continua della postura di conformità.

Come i moderni test offensivi avrebbero rilevato questo

Test di sicurezza offensivi rigorosi e continui, che vadano oltre i tradizionali penetration test, avrebbero messo in luce queste vulnerabilità di segnalazione. Un ingaggio di red team specificamente progettato per simulare un incidente critico rilevante per NIS2 non solo metterebbe alla prova le difese tecniche, ma anche l'intero ciclo di vita della risposta agli incidenti, inclusa la fase critica di segnalazione.

Tale test implicherebbe un esercizio di emulazione dell'avversario che culmina in un evento di impatto simulato. Il red team osserverebbe e documenterebbe quindi il rilevamento, il contenimento, l'eradicazione e, soprattutto, il processo di segnalazione normativa dell'organizzazione. Ciò rivelerebbe ritardi nella comunicazione interna, colli di bottiglia nella raccolta delle informazioni e lacune nei flussi di lavoro di segnalazione formale. Il valore risiede nell'esporre questi punti di attrito operativi prima di un incidente reale e di una sanzione normativa. Le organizzazioni devono continuamente mappare i propri controlli rispetto a framework come NIS2, DORA, ISO 27001 e SOC 2, con la raccolta delle prove cablata nei sistemi esistenti, per raggiungere questo livello di preparazione.

Cosa guardare dopo

L'applicazione della direttiva NIS2 è solo all'inizio. Questa prima multa multimilionaria stabilisce un formidabile precedente. Aspettatevi che le autorità di regolamentazione in tutta l'UE intensifichino il loro controllo sulle capacità di risposta agli incidenti delle entità critiche, in particolare per quanto riguarda la tempestività della segnalazione e la qualità dei dati.

Inoltre, il Digital Operational Resilience Act (DORA) per il settore finanziario introdurrà requisiti di segnalazione simili, se non più rigorosi. Le organizzazioni che operano in settori regolamentati dovrebbero considerare la NIS2 come un presagio di tendenze normative più ampie. L'attenzione si sta spostando dalla semplice prevenzione degli incidenti alla dimostrazione di una solida resilienza e di una responsabilità trasparente quando gli incidenti si verificano inevitabilmente. La prossima ondata di azioni esecutive colpirà probabilmente altri aspetti della NIS2, come la sicurezza della catena di approvvigionamento e i quadri di gestione del rischio.