La direttiva NIS2 (2022/2555) rappresenta un passaggio fondamentale per ottenere una maggiore capacità di resilienza, a livello nazionale ed europeo, rispetto agli incidenti di cybersecurity. Questo obiettivo è particolarmente importante adesso che, oltre al procedere della digitalizzazione in tutte le organizzazioni e i servizi, lo scenario geopolitico ci mette di fronte ad un rischio sempre più concreto di azioni anche mirate ad ottenere un impatto sistemico.
Per raggiungere questo obiettivo, la direttiva, oltre a prevedere una serie di adempimenti per gli Stati membri, richiede anche che i soggetti (aziende, pubbliche amministrazioni ecc.) individuati come “essenziali” o “importanti”, adottino una serie di misure volte ad assicurare una gestione efficace dei rischi di cybersecurity.
NIS2, bisogna adeguarsi entro il 17 ottobre 2024
La nostra stima è di circa 12.000 – 16.000 soggetti impattati direttamente dalla direttiva in Italia. A questi si aggiungeranno almeno quelli che verranno individuati a seguito del recepimento nazionale, quelli individuati dalla direttiva CER sui soggetti critici, nonché i soggetti impattati indirettamente in quanto fornitori di soggetti in perimetro. Si vede quindi quanto la direttiva NIS2 possa rappresentare una svolta fondamentale nella gestione dei rischi di cybersecurity in Italia e in Europa, cosa che la direttiva NIS precedente, del 2016, non era riuscita a fare, per i pochi soggetti interessati e la limitata capacità di enforcement.
Il recepimento dovrà avvenire entro il 17 ottobre 2024, quindi ormai fra pochi mesi. Seppure si possa ipotizzare che a quel punto vengano indicati dei tempi per l’adeguamento da parte dei soggetti in perimetro, non sembra ipotizzabile che questi tempi possano essere molto lunghi.
NIS2 e business continuity
Guardando alla direttiva dal punto di vista della singola azienda in perimetro, si possono vedere due importanti aspetti positivi, pur nei limiti di quanto un’azienda possa apprezzare di trovarsi ulteriori obblighi normativi. Il primo è che la Direttiva chiede all’azienda, prima di tutto, di mitigare il rischio che un incidente di cybersecurity ne possa minare la capacità di erogare i propri servizi o di realizzare i propri prodotti.
Si tratta in effetti di un obiettivo che rientra anche fra quelli che l’azienda già di suo dovrebbe avere, ed in generale ha, solo che in molti casi finora non era un obiettivo prioritario rispetto ad altri, o semplicemente l’azienda finora non lo aveva affrontato perché non aveva la consapevolezza o le competenze per gestirlo. Una volta completato il processo di adeguamento quindi, l’azienda si troverà ad essere più sicura e resiliente, in grado quindi di rispondere meglio alle sfide dei prossimi anni ed alle richieste dei suoi clienti.
NIS2 e ISO 27000
Il secondo punto positivo è che la direttiva è estremamente allineata alle buone pratiche di settore, ed in particolare al framework ISO 27000, che non a caso è citato nei considerando. Questo vuole dire che la Direttiva non richiede alle aziende di implementare delle misure anomale, che sarebbero difficili da inquadrare nelle eventuali iniziative già in essere, magari realizzate proprio seguendo come riferimento la norma tecnica ISO/IEC 27001.
Al contrario, per molte aziende potrebbe essere l’occasione per muoversi in quella direzione, ottenendo una certificazione della propria gestione dei rischi da presentare a clienti, assicuratori ed investitori.
NIS2, le misure da adottare
Rimane naturalmente aperto il punto delle misure di dettaglio: la Direttiva, all’art. 21 elenca infatti, oltre alle logiche di gestione e mitigazione dei rischi, anche un insieme di misure obbligatorie, per la maggior parte definite solo ad alto livello e che hanno bisogno di un maggiore dettaglio per essere recepite dai soggetti in perimetro.
La legge delega al governo prevede, molto opportunamente, che queste misure di sicurezza non siano inserite direttamente nel testo della legge di recepimento; prevede invece che un’autorità amministrativa venga individuata come responsabile della loro definizione e dell’aggiornamento degli strumenti adottati, strumenti “flessibili atti a corrispondere al rapido sviluppo tecnologico, delle tecnologie necessarie ad assicurare l’effettiva attivazione delle misure stesse”. Il dettaglio delle misure sarà quindi disponibile a valle di questa azione dell’autorità amministrativa individuata.
Dovrà essere affrontato anche il tema non banale dell’intensità e gradualità di quanto richiesto poi nel concreto alle aziende. Il perimetro di applicabilità della direttiva copre infatti aziende molto diverse: dalla media impresa della trasformazione alimentare alla grande azienda petrolifera, dall’azienda della chimica o della farmaceutica alla pubblica amministrazione centrale, dal fornitore di servizi ICT B2B alla manifatturiera che fabbrica i macchinari più vari. È chiaro che in termini di dimensioni, rischi e maturità nel gestirli c’è una variabilità enorme.
È difficile pensare che le stesse misure di sicurezza possano essere richieste a tutte, come anche che possano essere richieste tutte da subito. In questo, fra l’altro, è previsto che ci sia un coordinamento a livello europeo, in modo che le misure di sicurezza siano il più uniformi possibili fra i diversi paesi membri, evitando che uno di essi diventi l’anello debole della resilienza complessiva. Potremo quindi forse imparare qualcosa osservando quando verrà definito in paesi ad un punto più avanzato del processo di recepimento nazionale.
Adeguamento NIS2: primo passo capire se l’azienda è nel perimetro
Ma quindi, nel concreto, cosa devono fare le aziende per adeguarsi, sulla base del testo della Direttiva? Il primo passo, naturalmente, è capire se l’azienda, o una o più aziende di un gruppo, siano in perimetro. La Direttiva è in generale abbastanza chiara al riguardo, ma ci possono comunque essere casi in cui la risposta non è immediata. È utile precisare che la Direttiva non mette direttamente obblighi in carico ai fornitori, che deriveranno quindi i loro obblighi dal contratto di fornitura, o da altre norme che fanno riferimento alla NIS2, come il Cyber Resilience Act.
Adeguamento NIS2, secondo passo: la governance dei rischi cyber
Il secondo punto, fondamentale anch’esso, deriva dall’art. 20, relativo alla governance dei rischi di cybersecurity. Questo articolo pone delle responsabilità direttamente in capo all’organo di gestione dell’azienda (ad esempio, il consiglio di amministrazione), che dovrà approvare le misure di gestione dei rischi di cibersicurezza adottate, e sovrintendere alla loro attuazione. Si vuole molto chiaramente evidenziare come la gestione di questi rischi non sia un tema “dell’IT”, ma sia invece un tema di gestione di rischio aziendale legato ad incidenti che, nei casi peggiori e come vediamo fin troppo spesso, porta al fermo completo dell’azienda o anche dei suoi clienti, fermo dal quale non sempre riesce a ripartire.
Il ruolo dell’organo di gestione
Questo ruolo dell’organo di gestione, al quale è richiesta anche una formazione specifica proprio per acquisire le conoscenze e competenze “sufficienti al fine di individuare i rischi e valutare le pratiche di gestione dei rischi di cibersicurezza e il loro impatto sui servizi offerti dal soggetto” (siamo ben lontani, quindi, dalla semplice sensibilizzazione), si porta dietro naturalmente la definizione di processi, flussi e ruoli necessari per assicurare la capacità di esercitare tale ruolo e dimostrare l’efficacia dell’azione.
Per chi conosce la norma ISO/IEC 27001, è abbastanza chiaro il rapporto con i temi come la leadership e del riesame di direzione. In effetti, già solo questo articolo porta fortemente nella direzione della realizzazione di un sistema di gestione della sicurezza delle informazioni coerente con i requisiti di questo standard. È inoltre chiaro che prevedere questa competenza a livello di organo di gestione porta verso un posizionamento del ruolo di CISO a questi livelli, e comunque certamente ad assegnare una responsabilità esplicita rispetto ai temi di cybersecurity, che coprano anche ambiti non tradizionalmente di competenza delle direzioni IT, come ad esempio l’area OT, anch’essa soggetta a incidenti di cybersecurity.
La gestione dei rischi
Il tema successivo è quello della gestione dei rischi. La NIS2, come le altre norme di settore emanate negli ultimi anni, segue le buone pratiche di settore, e quindi si basa su logiche di gestione e mitigazione dei rischi. Un’analisi dei rischi, se effettuata seriamente e non come mero “passaggio formale” per focalizzarsi sulle soluzioni tecnologiche, è uno strumento molto potente e flessibile per assicurare che quanto implementato corrisponda realmente alle esigenze dell’azienda, permettendo di graduare gli interventi, e quindi gli investimenti, secondo quelle che sono le reali esigenze di protezione dei processi aziendali.
La NIS2 non aggiunge niente a quanto già dovrebbe fare un’azienda, se non indicare che, fra i diversi impatti di un incidente di cybersecurity che si devono considerare, vi è anche l’impatto “sociale ed economico”. La direttiva, infatti, ha comunque come scopo garantire una resilienza dei soggetti in perimetro per tutelare la collettività, e quindi, ad esempio in caso di fermo dei servizi, viene richiesto di valutare l’impatto che questo fermo può avere sulla collettività stessa. Questo aspetto sarà particolarmente interessante nel caso delle pubbliche amministrazioni, per le quali può essere più complesso che per un’azienda valutare quale sia un rischio o un tempo di fermo “accettabile”.
Le misure tecniche, operative e organizzative
A valle dell’analisi dei rischi, dovranno essere implementate misure tecniche, operative ed organizzative adeguate e proporzionate per gestire i rischi posti alla sicurezza dei sistemi informatici e di rete che i soggetti utilizzano nelle loro attività o nella fornitura dei loro servizi, nonché per prevenire o ridurre al minimo l’impatto degli incidenti per i destinatari dei loro servizi e per altri servizi.
Anche qui, niente che non rientri nelle buone pratiche e nelle normali modalità di gestione dei rischi di cybersecurity in un’azienda, e anche questo è assolutamente coerente con quanto previsto dal framework ISO 27000. Vengono però indicate alcune misure di sicurezza che, come minimo, devono essere implementate. Essendo la descrizione molto di alto livello, in diversi casi è opportuno, come detto, vedere cosa potrà indicare al riguardo l’autorità amministrativa di cui sopra a valle della legge di recepimento.
NIS2, come gestire i fornitori
Ci sono però alcuni temi su cui è utile fare qualche ragionamento, ed eventualmente avviare qualche iniziativa, anche prima della normativa di recepimento. Il primo tema è quello della gestione dei fornitori. La supply chain è ormai riconosciuta essere una delle fonti principali di esposizione per le aziende in tema di cybersecurity, ed ha uno spazio importante nell’art. 21.
Viene richiesto di affrontare in particolare il tema della sicurezza della catena di approvvigionamento, compresi aspetti relativi alla sicurezza riguardanti i rapporti tra ciascun soggetto e i suoi diretti fornitori o fornitori di servizi. Questo vuole dire che non devono essere considerati solo i “fornitori IT”, ma tutti i fornitori, individuando quelli che possano presentare un rischio. Si tratta di un ampliamento importante rispetto a quello che è comune in molte aziende, ovvero di affrontare questi temi solo per i fornitori IT, o al più per quelli che trattano dati personali nel ruolo di responsabili del trattamento (limitatamente alla protezione dei dati personali stessi).
Questo ampliamento sarebbe ingestibile se non attraverso lo strumento del risk management, che permetta di graduare le azioni in funzione della criticità del fornitore stesso in termini di cybersecurity. Tuttavia, si tratta comunque di intervenire sui contratti, potenzialmente con un gran numero di fornitori. È certamente preferibile avviare le attività il prima possibile, in modo da poter intervenire in fase di contrattualizzazione o rinnovo, anziché aspettare il recepimento e poi dover intervenire massicciamente sui contratti già in essere, con le complessità che questo comporta. Naturalmente, prima del recepimento potranno essere inserite clausole un po’ meno puntuali, ma potranno comunque essere affrontati temi critici come la gestione degli incidenti o la continuità operativa.
La business continuity e NIS2
Proprio la continuità operativa è un altro dei temi su cui può essere utile avviare quanto prima alcune iniziative. Per quanto sia indicata nella Direttiva in termini molto generali, al punto c) del comma 2 dell’art. 21, si parla comunque di continuità operativa, capacità di ripristino in caso di disastro e gestione delle crisi. Fra questi temi molto alti, trova inoltre spazio la gestione dei backup, proprio per la troppo diffusa inadeguatezza della gestione di questo tema, la cui importanza per il ripristino in caso di incidente è nota da cinquant’anni.
Il ruolo della BIA – Business impact analysis
Ma tornando alla continuità operativa, certamente qualsiasi iniziativa efficace non può prescindere da una Business Impact Analysis, che valuti in particolare l’impatto sui processi operativi dell’indisponibilità di parte o di tutto il sistema informativo aziendale (compresi i sistemi OT). Ancora più che l’analisi dei rischi, una BIA ben realizzata può essere uno strumento potente nell’indirizzare investimenti che, quando si parla di continuità operativa, possono essere importanti.
Una BIA può essere inoltre un momento di sensibilizzazione degli owner dei processi di business relativamente alle dipendenze delle loro attività dai sistemi informativi. Per contro, una BIA mal realizzata può essere addirittura dannosa, indicando tempi di ripristino non coerenti con le esigenze aziendali, e potenzialmente anche inadeguati a mitigare gli impatti. Sono quindi temi che richiedono tempo già solo per le attività di analisi e la pianificazione delle azioni di mitigazione, e per i quali quindi i tempi di adeguamento alla Direttiva potrebbero risultare sfidanti.
La gestione degli incidenti e NIS2
Infine, abbiamo la gestione incidenti. Come detto all’inizio, l’obiettivo della Direttiva è molto operativo, di costituzione di una resilienza agli incidenti di cybersecurity. Questa capacità passa attraverso la raccolta di informazioni sugli incidenti in corso per costituire, e fornire alle aziende nazionali ed europee, una situational awareness e le informazioni operative utili per contenere gli incidenti, particolarmente sistemici. La raccolta e distribuzione delle informazioni viene fatta prima di tutto dalla rete europea costituita dagli CSIRT nazionali dei diversi paesi, ma per questo devono avere tempestivamente le informazioni necessarie dalle aziende colpite.
Questo spiega perché la Direttiva richiede alle aziende di notificare allo CSIRT nazionale un preallarme entro 24 da quando vengono a conoscenza di un incidente di impatto significativo che le colpisca. Questo vuole dire che se l’azienda viene a conoscenza di un incidente il sabato sera, deve averlo notificato già entro la domenica sera. Per quanto le informazioni necessarie in questo primo preallarme siano minime, il processo di escalation che porta al coinvolgimento dei livelli aziendali appropriati per valutare se e cosa comunicare allo CSIRT, deve avere tempi molto ben definiti e stretti, ed essere testato adeguatamente.
Il problema non è tanto il processo di notifica in sé, per il quale lo CSIRT Italia rende già disponibili strumenti semplici ed efficaci, quanto la valutazione se l’incidente sia significativo, e comunque il contenuto della comunicazione, che deve essere completo e veritiero, ma nello stesso tempo non deve esporre inutilmente l’azienda al dubbio che la gestione del rischio o dell’incidente non siano stati adeguati. Per questo, è opportuno che il processo sia definito e testato con un certo anticipo rispetto a quando dovrà essere effettivamente essere adottato, in modo da assicurare che al momento del bisogno non ci siano intoppi, che con tempi così stretti sarebbero deleteri. La Direttiva prevede poi anche ulteriori comunicazioni (dopo 72 ore, dopo un mese, ed eventualmente anche verso i destinatari dei servizi erogati), ma la parte più critica è quella descritta.
Conclusione
In conclusione, la Direttiva richiede ai soggetti in perimetro un impegno che può essere più o meno gravoso a seconda di quanto si siano già mossi in questa direzione come propria gestione dei rischi di cybersecurity. Alcuni oneri sono aggiuntivi, come la segnalazione allo CSIRT, ma nel complesso l’adeguamento è in buona parte in linea con quanto l’azienda farebbe se seguisse le buone pratiche di settore, primo fra tutti il framework ISO 27000, anche se il perimetro di applicazione nell’azienda è probabilmente più ampio di quello di molte delle certificazioni ISO/IEC 27001 attualmente in essere.
Per le migliaia di aziende che invece affronteranno in questa occasione per la prima volta in modo strutturato la gestione dei propri rischi di cybersecurity, l’impegno può essere significativo e i tempi potranno risultare stretti. È opportuno quindi che le aziende inizino da subito almeno a verificare il proprio stato ed a pianificare gli interventi, tenendo conto comunque che alcuni aspetti saranno chiari solo a valle del recepimento nazionale, mentre altri possono essere affrontati fin d’ora. Infine, per i gruppi con aziende in più Paesi dell’Unione, è bene ricordare che la direttiva verrà recepita diversamente nei diversi Paesi, seppure con una certa coerenza complessiva. Alcuni paesi, come il Belgio o la Slovenia, sono già in uno stato molto avanzato del processo di recepimento, e le aziende che operano in quei Paesi potrebbero dovere o volere iniziare il proprio percorso di adeguamento con maggiore anticipo rispetto ad altre.
