Continuità operativa e gestione delle crisi: cosa prevede NIS2

La Direttiva NIS2 invita le aziende a prestare particolare attenzione al tema della continuità operativa e della gestione delle crisi, fondamentali quando si parla di resilienza e business continuity (temi questi alla base anche del Regolamento DORA).

La misura all’art. 24, comma 2, lettera c) del decreto legislativo del 4 settembre n.138, “Continuità operativa e gestione delle crisi”, si articola in 3 elementi:

• Business Continuity e Disaster Recovery Plan;
• gestione dei backup e ridondanza;
• gestione delle crisi.

Business Continuity e Disaster Recovery Plan: cosa devi sapere

Per un’azienda, sviluppare un piano di continuità operativa (Business Continuity Plan, BCP) e un piano di recupero in caso di disastro (Disaster Recovery Plan, DRP) è di importanza strategica, in quanto permette di rispondere tempestivamente e efficacemente ai danni causati da un incident e al contenimento (e risoluzione) dei danni.

La direttiva NIS2 prevede che le entità interessate stabiliscano e mantengano un piano di continuità aziendale e di ripristino, da applicare in caso di incidenti.

Il piano deve basarsi sui risultati della valutazione del piano di rischio e deve tener conto di:

1. finalità, ambito di applicazione e pubblico;
2. ruoli e responsabilità;
3. contatti principali e canali di comunicazione (interni ed esterni);
4. condizioni per l'attivazione e la disattivazione del piano;
5. ordine di ripristino delle operazioni;
6. piani di ripristino per operazioni specifiche, compresi gli obiettivi di ripristino;
7. risorse necessarie, compresi i backup e le ridondanze;
8. ripristino e ripresa delle attività a partire dalle misure temporanee.

Propedeutico al Business Continuity Plan e al Disaster Recovery Plan c’è, poi, la Business Impact Analisys (BIA), il cui obiettivo è consentire di determinare l’impatto e le ricadute sul business aziendale di eventi, che causano l’interruzione della produzione o dell’erogazione di servizi. In base ai risultati della BIA e della valutazione dei rischi, l'entità dovrebbe stabilire obiettivi di recupero appropriati:

• Recovery Time Objective (RTO): determinano il tempo massimo consentito per il recupero delle risorse e delle funzioni aziendali dopo un disastro;
• Recovery Point Objective (RPO): determinano la quantità di dati che può essere persa da specifiche attività o applicazioni ICT a causa di un'interruzione;
• Service Delivery Objective (SDO): determinano il livello minimo di prestazioni che le funzioni aziendali devono raggiungere durante la modalità di elaborazione alternativa.

È importante documentare il piano di recupero in caso di disastro, tenendo conto degli RTO, RPO e SDO, e garantire la conformità alle normative e leggi applicabili.

E’ importante tener presente, inoltre, che quando si sviluppa un piano di continuità operativa e di recupero in caso di disastro, bisogna affidarsi agli standard riconosciuti.

Il piano dovrebbe contenere:

• un elenco dei disastri naturali e/o maggiori che potrebbero influenzare i servizi;
• un elenco delle capacità di recupero, come backup, test e obiettivi di recupero;
• i registri dell'attivazione e dell'esecuzione del piano di continuità operativa (inclusi decisioni prese, passaggi seguiti e tempo finale di recupero;
• l'ordine di recupero (basato su criteri come: livello di classificazione degli asset, importanza del servizio per l'entità, dipendenze, obiettivi di recupero, disponibilità delle risorse e requisiti normativi.)

Il piano deve essere sostenibile e attuabile, cioè deve poter essere eseguito con successo con le capacità (persone, risorse, tecnologie, processi e procedure) che l’azienda può mettere in campo. Deve, inoltre, essere facilmente accessibile, ma allo stesso tempo protetto da divulgazioni e modifiche non autorizzate.

Il Business Continuity Plan e il Disaster Recovery Plan devono considerare anche i fornitori esterni di servizi, ai quali deve essere richiesto di garantire adeguatamente i piani di recupero, relativamente al servizio fornito, in caso di disastro.

Il ritorno alla “normalità” operativa può, infine, (e in alcuni casi dovrebbe) prevedere siti di failover distanti geograficamente dal sito principale e backup dei dati con alta criticità in località remote.

Test e cultura aziendale: perché sono importanti

I piani di continuità aziendale e di Disaster Recovery devono essere periodicamente testati (almeno una volta l’anno), rivisti e aggiornati, specialmente dopo incidenti significativi o cambiamenti nelle operazioni o nei rischi. È fondamentale che questi piani integrino le lezioni apprese dai test effettuati.

Altrettanto importante è, poi, la diffusione di una cultura del rischio all’interno dell’organizzazione. Il successo di un piano, infatti, dipende dalla sua comprensione da parte di tutti gli attori coinvolti. Ognuno deve aver ben chiaro il proprio ruolo, le azioni da compiere e in che modo, come viene innescato il suo intervento e a chi comunicare l’esito delle proprie azioni.

Per questo le esercitazioni sono fondamentali .

Gestione dei backup

Al fine di assicurare la continuità del business e una ripresa veloce in caso di incidenti, il backup dei dati è indispensabile. La NIS2 prevede, infatti, che le entità competenti conservino copie di backup dei dati e forniscano sufficienti risorse, tra cui strutture, sistemi di rete e informativi e personale, per garantire un livello appropriato di ridondanza.

Sulla base dei risultati della valutazione dei rischi e del piano di continuità operativa, le organizzazioni che recepiscono la Direttiva devono stabilire piani di backup che comprendono:

1. tempi di ripristino;
2. assicurazione della completezza e correttezza delle copie di backup, compresi i dati di configurazione e i dati conservati nell'ambiente di servizi di cloud computing;
3. conservazione di copie di backup (online o offline) in uno o più luoghi sicuri, che non si trovino nella medesima rete del sistema e che si trovino a una distanza sufficiente da sfuggire a qualsiasi danno causato da un disastro presso il sito principale. I backup devono avere un livello di protezione adeguato, inclusa la crittografia;
4. controlli adeguati degli accessi fisici e logici alle copie di backup, in modo conforme al livello di classificazione delle risorse;
5. ripristino dei dati da copie di backup;
6. periodi di conservazione basati su obblighi commerciali e normativi. Sulla durata di tale periodo non esiste una regola fissa, ma è importante considerare le necessità di business, gli obblighi legali e i regolamenti, e in generale quanto definito nel piano dei rischi.

L’impianto di backup deve essere progettato per rispettare i parametri di RTO, RDO e SDO, definiti nel Business Continuity Plan e, nel caso in cui il servizio sia offerto da una terza parte, è buona norma regolare propriamente il livello di servizio (SLA) rispetto al BCP, concordando, se possibile, il pagamento di eventuali penali.

La normative prevede, inoltre, che le entità competenti effettuino controlli regolari di integrità sulle copie di backup. In tale contesto, le best practice includono: l'uso di checksum o algoritmi di hashing per verificare che i dati nei backup corrispondano ai dati originali; l'implementazione di script automatizzati per eseguire questi controlli regolarmente, riducendo il rischio di errore umano; la pianificazione di test regolari, per ripristinare i dati dai backup e garantire che siano completi e funzionali

È, poi, consigliabile testare vari scenari di recupero, inclusi i ripristini completi del sistema e i recuperi di singoli file, per garantire che tutti gli aspetti del sistema di backup siano affidabili. Infine, bisognerebbe considerare l'uso di soluzioni di archiviazione cloud per i backup fuori sede, che spesso includono controlli di integrità integrati e ridondanza.

Gestione delle ridondanze e test

Sulla base dei risultati della valutazione dei rischi e del piano di continuità operativa, i soggetti pertinenti devono assicurare la disponibilità di risorse sufficienti, mediante una ridondanza quanto meno parziale di:

• sistemi informativi e di rete:

• risorse, compresi impianti, attrezzature e forniture:

• canali di comunicazione adeguati:

Va sottolineato che il processo di Capacity Plan, per essere efficace, deve tenere conto dalle necessità di backup e ridondanza.

A tal fine, le entità competenti dovrebbero prendere in considerazione almeno:

• la definizione delle priorità delle risorse in base ai risultati dell'analisi dei rischi;
• la ridondanza parziale;
• le diverse locazioni di backup;
• il monitoraggio continuo delle risorse in cui è necessaria la ridondanza.

I soggetti pertinenti devono testare regolarmente il ripristino delle copie di backup e le ridondanze per garantire la loro affidabilità e l'efficacia dei processi. È essenziale documentare i risultati dei test e adottare misure correttive, se necessario.

La frequenza dei controlli dei backup deve essere adattata alla criticità dei dati in base alla valutazione del rischio. Ad esempio, i dati ad alta criticità potrebbero essere controllati settimanalmente, mentre quelli a criticità moderata e bassa potrebbero essere controllati mensilmente. Inoltre, è consigliabile coinvolgere fornitori e altre terze parti nei test.

Una buona pratica è seguire la regola del backup 3-2-1: mantenere tre copie dei dati (l'originale più due backup), su due diversi tipi di supporti di archiviazione (ad esempio, dischi rigidi e archiviazione cloud), con una copia conservata fuori sede.

Gestione delle crisi

La misura all’art. 24, comma 2, lettera c) del decreto legislativo del 4 settembre n.138, “Continuità operativa e gestione delle crisi”, contempla, infine, la gestione delle crisi. Una crisi informatica indica una situazione di emergenza generata da un incidente significativo, che compromette gravemente la continuità operativa, la sicurezza dei dati, la reputazione aziendale o la conformità normativa. Per questo richiede una risposta immediata e coordinata, al fine di mitigare i danni e ripristinare la normale operatività.

Secondo quanto stabilito dalla NIS2, i soggetti pertinenti delle imprese coinvolte devono mettere in atto un processo di crisis management che comprenda almeno:

1. ruoli e responsabilità del personale e, se opportuno, dei fornitori e dei fornitori di servizi, specificando l'assegnazione dei ruoli in situazioni di crisi, comprese le misure specifiche da seguire;
2. mezzi di comunicazione adeguati tra i soggetti pertinenti e le autorità competenti pertinenti;
3. applicazione di misure adeguate, per garantire il mantenimento della sicurezza dei sistemi informativi e di rete in situazioni di crisi.

Ma cosa trasforma un “incident” in una “crisi”?

Questo dipende dalla propensione al rischio e dalle capacità di gestione degli incidenti di un’organizzazione. Le imprese dovrebbero, infatti, definire i propri criteri per dichiarare una crisi, basati, ad esempio, sugli impatti sul business e sulle attività o sul superamento di una certa soglia di tolleranza.

A questo proposito, il Regolamento di Esecuzione (Ue) 2024/2690 della Commissione Europea del 17 ottobre 2024  stabilisce una serie di criteri per stabilire se un incidente è significativo o meno, e quindi verosimilmente in grado di innescare una gestione della crisi, non fosse altro che per gli obblighi di notifica che ne scaturiscono, e dei quali parleremo più avanti.

Senza entrare troppo nei dettagli del Regolamento di Esecuzione, un incidente è considerato significativo se l’incidente ha causato o è in grado di causare, ad esempio:

1. una perdita finanziaria diretta superiore a 500 000 EUR o, se tale importo è inferiore, al 5 % del suo fatturato totale annuo dell’esercizio precedente;
2. l’esfiltrazione di segreti commerciali;
3. il decesso di una persona fisica;
4. danni considerevoli alla salute di una persona fisica;
5. gravi perturbazioni operative a seguito di un accesso non autorizzato ai sistemi informativi e di rete, che si sospetta essere malevolo

Inoltre, si applicano alcuni criteri relativi al numero degli utenti coinvolti, al caso di incidenti ricorrenti e alle fattispecie di alcuni specifici fornitori di servizi (servizi gestiti di sicurezza IT e Cloud Service Provider, per esempio).

La Direttiva prevede che, in caso di incidente significativo, l’azienda ne faccia immediata comunicazione al CSIRT (Computer Security Incident Response Team), un team specializzato che ha il compito di monitorare, prevenire e rispondere a minacce e attacchi informatici, supportando le organizzazioni nella protezione dei propri sistemi IT.

In Italia, il CSIRT Italia è gestito dall'Agenzia per la Cybersicurezza Nazionale (ACN), coordina la gestione degli incidenti su larga scala e collabora con i CSIRT di altri Stati membri dell’Unione Europea per affrontare minacce transfrontaliere.

Innanzitutto, i soggetti pertinenti devono attuare un processo per gestire e utilizzare le informazioni ricevute dai CSIRT, se applicabile, dalle autorità competenti in merito a incidenti, vulnerabilità, minacce o possibili misure di mitigazione.

La comunicazione verso il CSIRT dovrebbe descrivere:

• come le informazioni saranno diffuse alle parti interessate durante una crisi;
• i modelli per la comunicazione;
• le informazioni di contatto aggiornate per le parti interessate interne ed esterne, inclusi dipendenti, clienti, fornitori e servizi di emergenza.

Affinché il processo di comunicazione con il CSIRT sia efficace occorre designare un punto di contatto, con sufficiente competenza.

Il punto di contatto designato dall’azienda dovrebbe:

• rivedere le informazioni ricevute dal CSIRT per rilevanza e urgenza;
• validare le informazioni ricevute con le informazioni in proprio possesso, le politiche aziendali e normative esistenti.
• collaborare con i team pertinenti (IT, Sicurezza, Operazioni) per applicare o sviluppare una strategia di mitigazione, in caso di vulnerabilità o minacce rilevanti;
• condividere approfondimenti e feedback sugli incidenti e sulle mitigazioni con il CSIRT per contribuire alle conoscenze della comunità più ampia della cybersecurity.

Le informazioni in arrivo dal CSIRT devono essere classificate in categorie come incidenti, vulnerabilità, minacce e misure di mitigazione, e devono essere assegnati livelli di priorità basati sulla gravità e sul potenziale impatto sull'entità.

Anche nel caso del crisis management, i soggetti pertinenti devono sottoporre a test, riesaminare e, se opportuno, aggiornare il piano periodicamente o a seguito di incidenti significativi o di cambiamenti significativi delle operazioni o dei rischi.

Nello specifico, il processo di gestione delle crisi deve essere testato in base all'ambito del test: su larga scala ogni sei mesi e con test di stress e componenti del processo di gestione delle crisi annualmente.