NIS2: le istruzioni per l’uso di Nozomi Networks

In questo articolo, Emanuele Temi, Technical Sales Engineer di Nozomi Networks, condivide le indicazioni sulle procedure da seguire per le segnalazioni degli incidenti di cybersecurity imposte dalla normativa europea NIS2, direttiva europea che intende rafforzare la sicurezza di reti e informazioni.

Buona lettura!

NIS2 e le implicazioni sulla sicurezza delle infrastrutture critiche, le raccomandazioni di Nozomi Networks

La direttiva europea NIS2 ha introdotto l’obbligo di segnalazione degli incidenti di cybersecurity anche per le infrastrutture critiche, un cambiamento significativo che richiederà un adeguamento da parte delle organizzazioni interessate. Sebbene l’entrata in vigore reale sia prevista tra il 2025 e il 2026, la complessità del processo di comunicazione delle informazioni obbligatorie richiede tempestività nella preparazione, senza contare che, spesso, la prospettiva di dover segnalare incidenti di cybersecurity evoca nei dirigenti preoccupazioni legate principalmente ai costi e all’ambiguità di cosa effettivamente costituisca un incidente “segnalabile”.

I requisiti per la segnalazione degli incidenti in NIS2

La direttiva prevede che le organizzazioni definite “essenziali e importanti” appartenenti a 11 settori critici segnalino gli incidenti significativi alle autorità nazionali competenti senza alcun “ritardo ingiustificato”. In linea con le intenzioni generali della NIS2 di rafforzare la resilienza informatica e presentare una difesa unificata di fronte alle tensioni globali, l’obbligo di segnalazione è stato concepito per permettere di individuare in anticipo le minacce e di rispondere più rapidamente anche a livello internazionale.

L’Agenzia dell’Unione europea per la sicurezza informatica (ENISA) ha pubblicato la NIS2 (UE 2022/2255) nel gennaio 2023. Gli Stati membri hanno avuto l’obbligo di recepire la direttiva nella legislazione nazionale e di adottare le misure di attuazione entro il 17 ottobre 2024 scorso. Le autorità potrebbero quindi impiegare la maggior parte del 2025 per classificare le imprese interessate come “essenziali” o “importanti” e notificarle. In altri termini, è probabile che la sua applicazione concreta avverrà nel corso del 2026, ma si avranno maggiori certezze quando gli Stati membri inizieranno a pubblicare nel dettaglio le misure implementate.

Il reporting richiesto dalla NIS2

Le informazioni da fornire nei report sugli incidenti informatici della NIS2 vengono articolate su tre (eventualmente quattro) fasi, in modo da consentire l’invio di informazioni aggiuntive ai fini di ulteriori indagini.

Le organizzazioni “essenziali e importanti” dovranno segnalare al Computer Security Incident Response Team (CSIRT) dello Stato di riferimento qualsiasi incidente che abbia un impatto significativo nella fornitura dei loro servizi, seguendo questa procedura:

• Avviso tempestivo (entro 24 ore): Segnalare se l’evento è il probabile risultato di un’attività illecita o dolosa o se rischia di avere ramificazioni transfrontaliere.
• Notifica dell’incidente (entro 72 ore): Aggiornamento delle informazioni fornite in precedenza e valutazione preliminare della gravità e degli effetti dell’incidente.
• Rapporto intermedio (se richiesto): Su esplicita indicazione dello CSIRT, bisogna fornire tutti gli aggiornamenti sullo stato di avanzamento della gestione degli incidenti e delle crisi.
• Report finale (1 mese): Presentazione di un rapporto finale contenente una descrizione approfondita dell’incidente, comprese le sue cause, strategie di mitigazione adottate ed eventuali effetti transfrontalieri.

Gli aspetti normativi

Il concetto di incidente informatico notificabile secondo la NIS2 sostituisce una definizione ritenuta troppo generica che era presente nella direttiva originaria. Tuttavia, i suoi dettagli non sono stati resi noti fino al luglio 2024, quando l’UE ha pubblicato una “bozza di regolamento di attuazione”, che delinea le misure di gestione del rischio di sicurezza informatica richieste e definisce quali incidenti debbano essere considerati “significativi”. Sia per le imprese “essenziali” che per quelle “importanti”, un incidente “significativo” è un evento che:

• Causa o può causare una perdita finanziaria che supera i 100.000 euro o il 5% del fatturato annuo del soggetto interessato, a seconda di quale sia il valore più basso
• Causa un “considerevole danno reputazionale”, tenendo conto di fattori quali la presenza o meno dell’incidente sui mezzi di comunicazione e la probabilità che il soggetto perda un volume rilevante di clienti.
• Porta alla fuoriuscita di segreti commerciali
• Porta o può portare alla morte di un individuo o a danni per la sua salute
• Si tratta di un accesso riuscito, sospetto e non autorizzato alla rete e ai sistemi informativi.
• Risulta “rilevante” se considerato insieme ad altri incidenti che si sono verificati almeno due volte nell’arco di sei mesi e che abbiano la stessa apparente causa principale.

Ulteriori definizioni si applicano agli incidenti che portano alla completa indisponibilità di un servizio di cloud computing, rete di distribuzione di contenuti, servizio DNS o servizio di data center, nonché all’interruzione dei livelli di servizio concordati per servizi di cloud computing, servizi gestiti o servizi di sicurezza gestiti. Queste definizioni prevedono soglie diverse per i servizi e gli utenti interessati.

Due sfide principali

Analizzando i requisiti di incident reporting previsti dalla NIS2, è comprensibile che i soggetti che operano nel settore delle infrastrutture critiche non siano entusiasti dell’imminente entrata in vigore di questa normativa. Questo non è un problema solo della NIS2. Infatti, quando si parla di obblighi di segnalazione, si riscontrano generalmente due preoccupazioni comuni:

• Impatto sulle risorse/impraticabilità: Le rigide tempistiche di reporting e la richiesta di dettagliati requisiti possono mettere a dura prova le risorse, sempre che si disponga dei mezzi per rilevare gli incidenti informatici. Per le organizzazioni più piccole, i requisiti di segnalazione degli incidenti presuppongono l’esistenza di strumenti di monitoraggio e di indagine che spesso non sono disponibili. Sicuramente si tratta di uno scenario auspicabile e, con i giusti incentivi, potrebbe diventare realtà. Tuttavia, se non si dispone di un SOC interno o di un MSSP a contratto, soddisfare gli obblighi di segnalazione, in particolare la presentazione di tre o quattro report per ogni incidente grave, rappresenta un onere significativo. Anche per le aziende più strutturate, a meno che non dispongano di una serie di sensori posizionati strategicamente e di un’applicazione rigida delle policy, rilevare un incidente informatico è solo il primo ostacolo; determinarne l’impatto invece è quello più grande.
• Oneri di conformità/Duplicazione: Le aziende che operano su più giurisdizioni devono affrontare notevoli ostacoli per conformarsi ai diversi requisiti di rendicontazione. NIS2 costituisce un’eccezione di rilievo. In quanto iniziativa dell’UE, non solo dovrebbe semplificare l’onere di rendicontazione, ma anche consentire un’ampia fruibilità delle informazioni raccolte.

Come procedere per la segnalazione di incidenti informatici

Come detto in precedenza, è arrivato il momento di prepararsi seguendo alcuni step che possono essere utili

1. Definire gli incidenti da segnalare. È necessario iniziare a definire cosa si intende per incidente da segnalare in base alla propria attività. Cosa viene considerato una perdita “sostanziale” di riservatezza, integrità o disponibilità? Cosa avrebbe un impatto “grave” sulla sicurezza e sulla resilienza? Quale tipo o quantità di “interruzione” avrebbe un impatto sulla capacità di operare? Si tratta di parametri che potrebbero essere già stati definiti nell’ambito di un’analisi dell’impatto aziendale. In caso contrario, questa è l’occasione giusta per farlo.
2. Iniziare a fare pratica. Utilizzando le definizioni di ciò che è da segnalare, bisogna iniziare a tenere traccia degli incidenti che raggiungono la soglia, fornendo tutte le informazioni richieste dalla NIS2. Poi, iniziare a monitorare il tempo necessario per fornire tutte le informazioni richieste, e quante volte è necessario ripetere questo processo. Alcune informazioni non sono disponibili? Sono disponibili ma ci vuole troppo tempo per raccoglierle? È il momento di identificare e documentare le difficoltà incontrate, e cercare di capire come superarle.
3. Analizzare l’andamento delle segnalazioni. Utilizzare il 2025 per quantificare il numero di incidenti segnalabili che vengono rilevati nel corso di un trimestre, semestre o un anno. Stimare il tempo impiegato per documentare questi incidenti secondo i requisiti NIS2 e determinare se si dispone delle risorse sufficienti, ipotizzando che lo stesso trend continui.
4. Applicare le lezioni apprese Ora arrivano alcune decisioni importanti. Se l’obbligo di segnalazione degli incidenti si rivelerà troppo oneroso, potrà essere necessario rivedere il modo in cui è stato definito l’impatto. Gli incidenti sono stati meno impattanti di quanto si pensava all’inizio? Il punto non è quello di lesinare sulla segnalazione di informazioni che potrebbero prevenire un altro attacco alle infrastrutture critiche, ma piuttosto di essere pragmatici con le proprie risorse. Chi è stato prudente nella definizione, potrà rivedere i punti in cui le indagini si sono ripetutamente arenate e capire come risolverli.

Come mettere a frutto la fase di preparazione

Anche se le “imprese interessate” hanno meno spazio per interpretare ciò che deve essere segnalato ai sensi della NIS2, è possibile trarre vantaggio affinando i propri processi prima della sua entrata in vigore.

• Iniziare a segnalare internamente tutti gli incidenti significativi definiti nella bozza di regolamento di attuazione (o nelle misure di attuazione del proprio Stato membro, quando saranno pubblicate).
• Creare un modello di allarme rapido, di notifica dell’incidente e di rapporto intermedio e completarli agli intervalli richiesti (24 ore, 72 ore, un mese).
• Porsi alcune domande come: Ci sono intoppi comuni a uno di questi intervalli? Il processo è troppo oneroso? Come si può snellire?

La segnalazione di incidenti informatici, soprattutto se obbligatoria, può apparire a prima vista solo un’ulteriore operazione di documentazione senza beneficio, ma non è così, specialmente se si parla di infrastrutture critiche. Questi obblighi arrivano in un momento in cui il mondo diventa sempre più digitale e pericoloso e queste infrastrutture sono il terreno di gioco preferito dagli attori criminali nazionali e non.

La condivisione di informazioni dettagliate su significativi incidenti per evitare che attacchi simili si verifichino in settori mirati è essenziale. Più tempestiva è, più sarà efficace. Inoltre, è probabile che prima o poi un attacco cessi di essere perpetrato, grazie ai dettagli riportati da altre “imprese interessate”, che saranno condivisi più rapidamente e permetteranno di agire di conseguenza per difendersi da attacchi informatici.

di Emanuele Temi, Technical Sales Engineer, Nozomi Networks