Un’attenta lettura della NIS 2 evidenzia come tale direttiva europea intervenga anche sulla necessità di garantire la continuità operativa per i soggetti interessati dalla conformità normativa.
Vero è, infatti, che i sistemi IT e OT aziendali rappresentano ormai un componente essenziale di quasi ogni processo operativo. I vantaggi sono evidenti, ma sono evidenti anche i rischi che derivano dalla dipendenza da questi sistemi: errori, guasti, interruzioni o manomissioni hanno un impatto sempre più ampio sulle organizzazioni, arrivando anche a causarne il blocco completo.
Indice degli argomenti
Incidenti cyber e continuità nell’erogazione dei servizi
Particolarmente preoccupanti sono i problemi che derivano da incidenti di cyber security: incidenti in cui l’operatività di aziende e pubbliche amministrazioni è ridotta in modo importante sono sempre più frequenti, anche in settori, come quello manifatturiero, che in passato erano risultati meno esposti.
In questo settore, infatti, i processi operativi più critici sono legati a sistemi OT, più che IT, e l’ambito OT è sempre stato particolarmente attento ai temi di continuità e affidabilità, traendo vantaggio anche da un certo isolamento.
L’evoluzione dei sistemi OT, e la convergenza in corso fra IT e OT, stanno però portando anche nel settore manifatturiero, e negli ambiti di utilizzo di tecnologie OT in generale, grandi vantaggi ma anche un’esposizione agli attacchi sempre più simile a quella dei sistemi IT.
In effetti, dove si parli di convergenza IT/OT, il tema della sicurezza, con particolare attenzione alla disponibilità, ma anche a temi di safety, è sempre un punto di attenzione necessario.
Nell’ottica di garantire che aziende e pubbliche amministrazioni rilevanti per la vita sociale ed economica dell’Unione Europea assicurino la necessaria continuità nell’erogazione dei propri servizi e nella realizzazione dei propri prodotti, sono state emanate prima la Direttiva NIS, e poi la Direttiva NIS 2, alla quale le aziende dovranno iniziare ad adeguarsi nel 2024.
La continuità operativa nella NIS 2
La Direttiva NIS 2 riprende ed esplicita questa esigenza di continuità in particolare quando, all’art. 21, prevede che le misure tecniche, operative e organizzative adottate per gestire i rischi posti alla sicurezza dei sistemi informatici e di rete e il loro ambiente fisico da incidenti, comprendono almeno, fra l’altro, “continuità operativa, come la gestione del backup e il ripristino in caso di disastro, e gestione delle crisi”.
Pur essendo la capacità di proteggere i propri sistemi e reti “per prevenire o ridurre al minimo l’impatto degli incidenti per i destinatari dei loro servizi e per altri servizi” un obiettivo generale delle misure di mitigazione del rischio di cui viene chiesta l’adozione, questo specifico requisito parla quindi esplicitamente di continuità operativa.
Il requisito è piuttosto generico e, seppure le logiche di adeguata mitigazione del rischio possano guidare l’implementazione, è legittimo aspettarsi indicazioni più specifiche in fase di recepimento della norma da parte dei singoli paesi membri, dato che una gestione “complessiva” dei temi di continuità operativa in un’azienda rappresenta un investimento in generale molto impegnativo.
I requisiti della NIS 2 su cui iniziare ad adeguarsi
Ci sono però alcuni temi che possono essere considerati fin da subito.
Protezione e completezza dei backup dati
Il primo riguarda il riferimento ai backup, che rappresentano una misura fondamentale ma sulla quale continuano ad esserci carenze gravi e diffuse, principalmente su due aspetti: la protezione dei backup stessi, da incidenti fisici (attraverso la remotizzazione rispetto ai sistemi che devono proteggere) e logici (attraverso modalità di gestione offline o read-only, che garantiscano che anche chi riesca a compromettere in modo ampio i sistemi e le reti dell’azienda non possa manomettere anche i backup), e la completezza dei backup, che devono comprendere quegli aspetti di configurazione dei sistemi, delle reti e degli ambienti di virtualizzazione, che assicurino di essere in grado di ripristinare, oltre ai dati, anche i sistemi con cui sono gestiti.
Un piano di ripristino in caso di disastro
Un secondo tema riguarda naturalmente il ripristino in caso di disastro, che si richiama alle logiche di disaster recovery tipiche della gestione di gravi incidenti IT.
Tuttavia, sappiamo anche che un piano di disaster recovery non ha molto senso se non sono chiari i requisiti di tempi e punti di ripristino che derivino dai processi operativi che i sistemi informativi supportano.
Garantire continuità operativa e gestione delle crisi
È necessario, quindi, uscire dalla prospettiva puramente IT e analizzare, invece, quello che è il vero punto di attenzione della norma, ovvero la capacità di garantire la continuità in termini di processi operativi utilizzati dall’azienda per realizzare i propri servizi e prodotti.
È in questa prospettiva che vanno inquadrati i requisiti di “continuità operativa e gestione delle crisi”.
Il primo e necessario passaggio per affrontare efficacemente i temi di continuità operativa è effettuare una Business Impact Analysis (BIA), ovvero un’analisi dell’impatto che un fermo dei singoli processi operativi aziendali avrebbe sull’azienda.
L’attenzione, in particolare, è su gravi incidenti che possano comportare fermi importanti, tanto da causare impatti che l’azienda non sarebbe disposta a tollerare.
Questa tolleranza, nella prospettiva della NIS 2, è legata anche agli impatti sociali ed economici del fermo che l’azienda è tenuta a mitigare.
L’obiettivo di una BIA è anche capire quali dipendenze abbia l’azienda da risorse critiche, in modo da individuare da una parte delle misure di mitigazione del rischio che queste risorse diventino indisponibili, dall’altra prevedere dei piani di emergenza per gestire comunque un’eventuale indisponibilità.
Con risorse si intende ogni genere di risorse, dalle materie prime, ai semilavorati, alle persone, alle competenze, ai servizi e fornitori. E anche, naturalmente, i sistemi IT e OT. Seppure l’effettuazione di una BIA sia un’occasione per avere un quadro complessivo delle dipendenze dell’azienda dalle diverse risorse, per comprendere come intervenire, è comunque possibile limitare l’analisi a determinati tipi di risorse.
NIS 2: sicurezza dei sistemi IT e OT e della supply chain
Nel caso della direttiva NIS2, essendo l’attenzione sugli incidenti di cyber security, le dipendenze che è necessario analizzare sono i sistemi IT e OT, dove gli incidenti si possono verificare direttamente, ma anche i fornitori critici, perché un incidente di cyber security presso un fornitore potrebbe comunque bloccarne l’operatività e quindi interrompere la fornitura critica.
Non a caso, la Direttiva NIS2 pone tanta attenzione proprio alla supply chain, richiedendo che i soggetti in perimetro considerino ciascun diretto fornitore.
La stessa attenzione si trova ad esempio al considerando 56, dove si sottolinea che “… attacchi della catena di approvvigionamento non solo hanno un impatto sulle piccole e medie imprese e sulle loro operazioni isolatamente, ma possono anche avere un effetto a cascata su attacchi più gravi nei confronti di soggetti di cui sono fornitori”.
Uno dei vantaggi di una BIA è proprio di riuscire ad individuare quali fornitori siano critici per la continuità dei processi operativi. Naturalmente, la Direttiva NIS2 dedica poi particolare attenzione ai fornitori IT, dato che attraverso loro vulnerabilità è possibile estendere un attacco direttamente ai sistemi IT e OT del soggetto in perimetro.
L’effettuazione di una BIA richiede quindi di analizzare efficacemente queste dipendenze, lavorando con i responsabili dei processi operativi aziendali.
Lo scopo è capire le dipendenze da sistemi IT/OT e fornitori critici, identificando i tempi di fermo e le perdite di dati che possono avere un impatto eccessivo. Si tratta, quindi, di interloquire con direttori della produzione, della logistica, direttori di stabilimento eccetera.
Difficilmente un’analisi di questo tipo può essere efficace attraverso la semplice erogazione di questionari, che presupporrebbero che i rispondenti abbiano una sufficiente padronanza della materia da poter rispondere in autonomia.
Come svolgere un’analisi d’impatto sulla continuità operativa
È più opportuno, invece, prevedere delle interviste, in cui sia possibile entrare nel merito dei processi, comprendendo le dipendenze, ma anche le misure compensative che possono già essere state incorporate nei processi stessi, come controlli manuali, forniture alternative e altre misure che consentano di continuare ad operare anche in caso di indisponibilità temporanea dei sistemi IT o di fornitori, come anche di ripianificare o ridistribuire la produzione su diverse linee per mitigare gli impatti di un fermo.
Si tratta quindi di un’analisi che, se ben gestita, può andare molto al di là della semplice conformità ad un requisito normativo, fornendo all’azienda, ai responsabili dei processi operativi, ed ai responsabili IT, un quadro reale delle dipendenze, e quindi una guida efficace sia per gli investimenti in sicurezza IT/OT, che per la gestione dei fornitori critici.
Questa attività di “BIA IT/OT” può essere svolta in modo coordinato con le attività di analisi dei rischi che sono da una parte necessarie per indirizzare anche gli investimenti in sicurezza IT/OT non strettamente legati alla continuità operativa (si pensi ad esempio a quanto richiesto dalla norma tecnica ISO/IEC 27001), dall’altra sono comunque esplicitamente richieste da diversi requisiti normativi, europei e nazionali, fra i quali naturalmente anche la Direttiva NIS 2.
Una gestione coordinata della BIA e delle analisi dei rischi richieste dalle diverse normative è in effetti parte di una gestione integrata della conformità alle norme in materia di cybersecurity che sembra essere sempre più necessaria.
L’intervento della NIS 2 nella gestione delle crisi
L’ultimo tema evidenziato dalla direttiva NIS 2 è quello della gestione delle crisi. È ormai cosa nota che la capacità di un’azienda di gestire efficacemente un grave incidente che comporti un’interruzione dell’operatività, è importante quanto essere in grado di prevenirlo.
Dato che gli incidenti avvengono, aziende che non siano preparate a gestirli possono subire impatti enormemente maggiori rispetto ad aziende che abbiano pianificato correttamente come gestire queste crisi.
Di nuovo, una crisi che derivi da un incidente di cyber security non interessa solo i sistemi informativi e la loro capacità di ripristinare il servizio: il fermo dei processi operativi che ne deriva, infatti, comporta anche una capacità di gestire questi fermi e la relativa ripartenza, come anche di valutare gli impatti del fermo, definire delle misure di mitigazione a livello di processo operativo, ma anche coordinare le attività a livello complessivo aziendale, gestendo temi come le comunicazioni verso le autorità, verso gli stakeholder e verso l’esterno, compresi il pubblico e la stampa.
C’è un’ampia casistica di incidenti che, gestiti in modo inefficace in termini di comunicazioni verso l’esterno, hanno causato danni, legati all’immagine aziendale o alla perdita di valore del titolo per società quotate, che sono stati anche paragonabili a quelli causati dall’incidente in sé.
La gestione delle emergenze legate agli incidenti di cyber security, come la gestione di tutte le emergenze, richiede preparazione. In effetti, quando si parla di continuità operativa, molta dell’attività ha proprio lo scopo di arrivare preparati ad un incidente, sapendo chi deve fare cosa e come.
Oltre all’attività di pianificazione, qualsiasi buona pratica di gestione della continuità operativa prevede delle attività di test di incidente come parte importante del processo. La simulazione di crisi comprende sia le attività tecniche di ripristino dei sistemi, sia la gestione dell’emergenza dal punto di vista dei processi di escalation e delle azioni a livello apicale.
Conclusioni
La capacità di gestire la continuità operativa rispetto ad incidenti di cyber security implica, quindi, non solo una capacità di proteggere i propri sistemi IT/OT da possibili attacchi informatici, ma anche di analizzare le dipendenze critiche, di gestire efficacemente le crisi e di pianificare il ripristino dell’operatività in caso di incidenti.
Per fare ciò, è necessario coinvolgere i responsabili dei processi operativi aziendali, oltre ai responsabili IT.
Come per altri requisiti posti dalla direttiva NIS 2, e dalla prevenzione e gestione degli incidenti di cyber security in generale, non è sufficiente agire all’interno della gestione dei sistemi IT/OT, è necessario affrontare il tema a livello di azienda nel suo complesso, e di processi operativi in particolare, dato che è l’interruzione di questi processi che comporta poi un impatto sull’azienda e sui clienti.
