NIS 2 e ISO/IEC 27001: un modello ibrido di procedura di gestione degli incidenti di sicurezza

La Direttiva NIS 2 può essere utilmente integrata con la ISO/IEC 27001:2022 e, come abbiamo visto in un precedente articolo:

1. i punti di contatto tra i due schemi sono molti;
2. un soggetto essenziale o importante che già dispone di un efficace sistema di gestione per la sicurezza delle informazioni (SGSI), deve limitarsi a integrazioni puntuali.

Ora, volendo estendere l’analisi, va rilevato che la Direttiva NIS 2 e la norma tecnica ISO/IEC 27001:2022 offrono prospettive complementari sulla gestione degli incidenti di sicurezza informatica.

Con questo articolo, vogliamo porre il focus proprio su questo aspetto specifico: la gestione dell’incidente sulla sicurezza delle informazioni che la NIS 2 tratta nell’art. 23. In particolare, analizzeremo come possono essere integrate le procedure richieste dalla ISO/IEC 27001:2022 nei controlli dal 5.24 al 5.30.

L’incidente di cibersicurezza su vasta scala

Le definizioni che impattano in modo specifico sull’art. 23 sono desumibili dall’art. 6/1 numeri da 5 a 8 (che riportano le definizioni di quasi incidente, di incidente e di incidente su vasta scala[1]). È interessante notare che tali definizioni fanno tutte riferimento ad un evento che compromette o – nel caso del quasi incidente, avrebbe potuto compromettere – la disponibilità, l’autenticità, l’integrità o la riservatezza dei dati trattati o, più in generale, dei servizi offerti dai sistemi o che sono accessibili tramite gli stessi.

In tale quadro, è noto che gli incidenti informatici, che sono sempre più frequenti, complessi e sofisticati, hanno il potenziale di interrompere le attività all’interno del sistema economico e produttivo su scala globale. In questi casi assumono la natura di “incidente di cibersicurezza su vasta scala” cioè, secondo la definizione dell’art.6/1, n.7) della Direttiva NIS 2, di un evento che causa un livello di perturbazione superiore alla capacità di uno Stato membro di rispondervi, o che ha un impatto significativo su almeno due Stati membri dell’UE.

Data l’ampia portata e, nella maggior parte dei casi, la natura transfrontaliera di tali incidenti, gli Stati membri dell’UE, le istituzioni, gli organismi e le agenzie competenti sono chiamati a cooperare a livello tecnico, operativo e politico per garantire una risposta rapida ed efficace.

Il prodromo di un incidente di cibersicurezza su vasta scala è il c.d. incidente significativo. Lo schema operativo disegnato dalla NIS 2 è volto a contenere gli effetti di un incidente significativo per evitare che si diffonda, trasformandosi in incidente di cibersicurezza su vasta scala.

Requisiti integrativi della procedura sull’incidente

L’articolo 23 della NIS 2, rubricato “Obblighi di segnalazione” è dedicato in modo specifico a questo tema e fornisce una serie di indicazioni puntuali che dovrebbero integrare la procedura di gestione degli incidenti sulla sicurezza delle informazioni già presente in ogni azienda che ha implementato un sistema di gestione sulla sicurezza delle informazioni. Tale procedura è anche prevista dal GDPR.

La combinazione di requisiti e misure previste dalla NIS 2, dalla ISO/IEC 27001 e dal GDPR può determinare la costruzione di un modello “ibrido” di gestione degli incidenti di sicurezza che può garantire compliance normativa e resilienza operativa.

Per realizzare questa combinazione, non ci limiteremo ad analizzare l’art. 23 della NIS 2 ma andremo ad evidenziare come i corrispondenti controlli che riguardano gli eventi sulla sicurezza delle informazioni della ISO/IEC 27001 possono soddisfare i requisiti e gli obblighi stabiliti dalla NIS 2.

Quali sono, allora, i contenuti integrativi della procedura sull’incidente delle informazioni in accordo con quanto previsto dall’art. 23 della NIS 2?

L’articolo 23 “Obblighi di segnalazione” fornisce indicazioni:

1. per i soggetti essenziali e importanti che hanno subito un incidente di sicurezza;
2. per i CSIRT (Computer Security Incident Response Teams). Si tratta di team specializzati, i cui requisiti, capacità tecniche e compiti sono fissati dall’art.11 della NIS 2. I CSIRT, si occupano della gestione delle risposte agli incidenti di sicurezza informatica, attraverso il monitoraggio e l’analisi delle minacce informatiche delle vulnerabilità e degli incidenti a livello nazionale. Su richiesta, forniscono assistenza ai soggetti essenziali e importanti interessati per quanto riguarda il monitoraggio in tempo reale o prossimo al reale dei loro sistemi informatici e di rete. Emettono anche preallarmi, allerte e bollettini e divulgano informazioni ai soggetti essenziali e importanti interessati, nonché alle autorità competenti e agli altri pertinenti portatori di interessi, in merito a minacce informatiche, vulnerabilità e incidenti, se possibile in tempo prossimo al reale. Inoltre, raccolgono e analizzano dati forensi e forniscono un’analisi dinamica dei rischi e degli incidenti, nonché una consapevolezza situazionale riguardo alla cibersicurezza;
3. per gli Stati membri.

Lo stesso articolo fornisce poi alcune indicazioni che, come già accennato, possono essere integrate all’interno della procedura per la gestione degli incidenti e dei potenziali incidenti, che dovrebbe essere già stata predisposta dall’organizzazione in quanto richiesta:

1. dalla ISO/IEC 27001:2022 (vds. controllo 5.24 “Pianificazione per la gestione degli incidenti relativi alla sicurezza delle informazioni” ed in particolare nel sottocontrollo “Procedura di gestione degli incidenti” come indicato nella ISO/IEC 27002:2022);
2. dal GDPR (vds. Considerando 88).

Il paragrafo 1 dell’art. 23 prescrive che gli incidenti o gli eventuali incidenti che hanno un impatto significativo siano notificati senza indebito ritardo da parte dell’organizzazione al proprio CSIRT.

Ma qual è la funzione di questa segnalazione?

La duplice funzione della segnalazione degli incidenti

La Direttiva^[2] stabilisce un approccio in più fasi alla segnalazione degli incidenti significativi. Ciò, al fine di trovare il giusto equilibrio tra:

1. una segnalazione rapida che contribuisca ad attenuare la potenziale diffusione di incidenti e consenta ai soggetti essenziali e importanti di chiedere assistenza e,
2. una segnalazione approfondita che tragga insegnamenti preziosi dai singoli incidenti e migliori nel tempo la resilienza informatica dei singoli soggetti e di interi settori.

La segnalazione degli incidenti significativi ha quindi la duplice funzione di garantire da un lato, una risposta rapida ed efficace agli incidenti, dall’altro, di promuovere una cultura di miglioramento continuo e di apprendimento da lessons learned.

Detto obbligo di segnalazione implica che la procedura di gestione degli incidenti già esistente debba essere integrata prevedendo cosa si intenda per incidente significativo e riportando i criteri per individuare un incidente significativo.

L’incidente significativo

Secondo l’art. 23/3 della NIS 2, un incidente è considerato significativo se:

1. ha causato o è in grado di causare una grave perturbazione operativa dei servizi o perdite finanziarie per il soggetto interessato;
2. si è ripercosso o è in grado di ripercuotersi su altre persone fisiche o giuridiche causando perdite materiali o immateriali considerevoli.

Oltre questi criteri generali non vi sono altre indicazioni operative utili ad identificare un incidente significativo. È, pertanto, auspicabile che la Commissione UE, esercitando le competenze di esecuzione, alle quali fa riferimento il Considerando 139 della NIS 2, stabilisca i casi concreti in cui un incidente deve essere considerato significativo.

Riconoscere un incidente significativo oggetto degli obblighi di segnalazione

Riconoscere un incidente significativo è fondamentale per determinare la necessità e l’urgenza di adempiere agli obblighi di notifica stabiliti nell’art. 23 della NIS 2, contenendo così la possibilità che l’incidente significativo si trasformi in incidente di cibersicurezza su vasta scala.

In linea con le indicazioni riportate nel Considerando 101 della NIS 2, un incidente significativo dovrebbe essere individuato da un soggetto essenziale o importante attraverso una valutazione iniziale che dovrebbe tenere conto, tra l’altro:

1. dei sistemi informatici e di rete interessati, in particolare della loro importanza nella fornitura dei servizi del soggetto;
2. della gravità e delle caratteristiche tecniche di una minaccia informatica e delle eventuali vulnerabilità sottostanti che vengono sfruttate;
3. dell’esperienza del soggetto essenziale o importante in caso di incidenti simili.

Inoltre, indicatori utili a determinare se la perturbazione operativa del servizio è grave sono:

1. la misura in cui il funzionamento del servizio è interessato;
2. la durata di un incidente o il numero di destinatari dei servizi interessati.

Tali elementi richiesti sono assolutamente in linea con i controlli relativi alla gestione dell’incidente sulla sicurezza delle informazioni, così come individuati dalla ISO/IEC 27001:2022.

I soggetti a cui comunicare

Il paragrafo 2 dell’art. 23 NIS 2 specifica che, su indicazione degli Stati membri, le organizzazioni devono comunicare, anche in questo caso senza indebito ritardo, ai destinatari dei loro servizi potenzialmente interessati dalla minaccia, le misure o le azioni correttive che tali destinatari devono applicare come risposta alla minaccia.

Laddove opportuno i soggetti devono anche informare i destinatari sulla minaccia stessa.

Ciò implica che nella procedura devono essere definiti canali di comunicazione autorizzati all’interno dell’organizzazione, sia per comunicare verso – che per ricevere comunicazioni da – soggetti istituzionali (CSIRT).

Tale elemento richiama quanto previsto dal controllo ISO/IEC 27001:2022 5.5 “Contatti con le autorità – Sono mantenuti contatti appropriati con le autorità pertinenti”:

Tipologia di segnalazioni, tempistiche e contenuti

Il paragrafo 4 dello stesso articolo 23 stabilisce che gli Stati membri, attraverso gli strumenti normativi di recepimento della Direttiva provvedano affinché, i soggetti essenziali o importanti trasmettano al CSIRT o, se opportuno, all’autorità competente le comunicazioni/segnalazioni descritte nella tabella seguente.

Tali fattori relativi alla comunicazione devono essere oggetto di integrazione nella procedura ovvero la procedura deve richiamare quanto previsto dall’articolo in modo da fornire adeguata garanzia che, in caso di incidente siano effettuate, nei tempi previsti, le comunicazioni ai soggetti competenti.

Le entità autorizzate a rivolgersi al CSIRT

Il paragrafo 5 dell’art.23 specifica che, su richiesta del soggetto interessato, il CSIRT può fornire supporto tecnico e devono essere, quindi, anche in questo caso definite quali dovranno essere le funzioni autorizzate a rivolgersi al CSIRT per richiedere tale tipo di supporto. Deve essere indicato anche laddove si sospetta che l’incidente abbia “carattere criminale”.

La procedura dovrebbe anche prevedere, come indicato nel paragrafo 7 dell’art. 23 NIS 2, che il CSIRT o l’autorità competente possano anche valutare, se opportuno, di informare il pubblico riguardo all’incidente significativo o imporre al soggetto interessato di effettuare tale comunicazione. Ancora una volta, quindi, la procedura dovrebbe considerare specificamente:

1. i soggetti autorizzati a comunicare e a ricevere le comunicazioni;
2. come e con quale supporto esperto, devono essere messe a punto le comunicazioni (modalità e tempi) dell’evento garantendo, da un lato, la riservatezza delle stesse^[3] e, dall’altro, che i soggetti potenzialmente coinvolti dall’incidente siano informati^[4].

Le misure integrative della procedura di cui sopra dovrebbero essere richieste, opportunamente anche ai fornitori critici dei servizi delle organizzazioni, attraverso una specifica integrazione della documentazione contrattuale analogamente a quanto previsto per il GDPR.

Altre integrazioni della procedura. Esempi e tempi accettabili

Infine, la procedura potrebbe essere integrata con esempi per facilitare una rapida interpretazione del caso in esame.

La stessa dovrebbe contenere, inoltre, i tempi che l’organizzazione reputa accettabili, fermi restando quelli vincolati, ovvero che rientrano nella definizione di “indebito ritardo”. Anche in questo caso l’interpretazione dell’organizzazione potrebbe essere maggiormente conservativa rispetto a quanto previsto dalla Direttiva.

Una nota sulla procedura sulla sicurezza delle informazioni

Gli elementi forniti possono aiutare un’organizzazione ad integrare la procedura sulla gestione degli incidenti. Non va, peraltro, dimenticato che anche per il GDPR è necessario predisporre una procedura specifica per quegli eventi sulla sicurezza dell’informazione che impattano anche su dati personali.

Molte aziende già dispongono di procedure dedicate e quindi separate da quella sulla sicurezza delle informazioni. Altre, invece, hanno un’unica procedura in cui alcuni paragrafi sono specificatamente dedicati al caso in cui l’incidente va ad impattare anche su dati personali.

Analogamente a quanto finora descritto, si possono integrare gli elementi richiesti dall’articolo 23 della NIS 2 nella procedura più generale relativa agli incidenti sulla sicurezza delle informazioni.

Alcune realtà, ad esempio quelle più complesse e articolate, potrebbero invece beneficiare di procedure separate.

Ancora una volta non è possibile definire una ricetta unica. Di volta in volta, possono essere considerate soluzioni diverse in base al contesto in cui opera l’organizzazione.

Conclusioni

Un’analisi dell’articolo 23 porta a modifiche che possono essere già rese operative nella procedura già adottata dall’organizzazione per gestire gli incidenti o i quasi incidenti che impattano sul perimetro su cui insiste la direttiva NIS 2, fermo restando che devono essere ancora fornite indicazioni precise con il Decreto Legislativo di recepimento. In ogni caso, due sono gli elementi fondanti di queste procedure:

1. da un lato, i tempi regolamentati, analogamente a quanto accade per il GDPR;
2. dall’altro la definizione di opportune responsabilità per la gestione delle comunicazioni da e verso altri soggetti, oltre che il loro contenuto.

In conclusione, si è cercato di evidenziare come l’integrazione della Direttiva NIS 2 e della ISO/IEC 27001:2022 (oltre che del GDPR) nella gestione degli incidenti significativi possa comportare notevoli vantaggi in termini di capacità di risposta agli stessi incidenti, di conformità normativa e di resilienza operativa.

Il modello “ibrido” proposto consente di combinare la tempestività e il coordinamento normativo della NIS 2 con la flessibilità e l’adattabilità organizzativa dello standard sui sistemi di gestione della sicurezza delle informazioni.

Tale sinergia potenzia l’efficacia delle strategie di risposta e fortifica la gestione degli incidenti a tutto tondo, migliorando sia la protezione delle infrastrutture critiche che la continuità operativa.

[1] «quasi incidente»: un evento che avrebbe potuto compromettere la disponibilità, l’autenticità, l’integrità o la riservatezza di dati conservati, trasmessi o elaborati o dei servizi offerti dai sistemi informatici e di rete o accessibili attraverso di essi, ma che è stato efficacemente evitato o non si è verificato;

«incidente»: un evento che compromette la disponibilità, l’autenticità, l’integrità o la riservatezza di dati conservati, trasmessi o elaborati o dei servizi offerti dai sistemi informatici e di rete o accessibili attraverso di essi;

«incidente di cibersicurezza su vasta scala»: un incidente che causa un livello di perturbazione superiore alla capacità di uno Stato membro di rispondervi o che ha un impatto significativo su almeno due Stati membri.

^[2] Vds. Considerando 101 della Direttiva NIS 2.

^[3] Considerando che qualora le stesse fossero di dominio pubblico potrebbero essere usate da malintenzionati.

^[4] Si tratta di una misura molto simile a quanto previsto dal REG: EU 2016 /679.