Come le organizzazioni dovrebbero sviluppare piani di Business Continuity (BC) e di Disaster Recovery (DR) in caso di disastro ai sensi della Direttiva NIS2, inclusi passaggi dettagliati e misure tecniche.

Continuità operativa e pianificazione del recupero in caso di disastri secondo la Direttiva NIS2

La Direttiva NIS2, come oramai noto, mira ad innalzare gli standard di cybersecurity e a rafforzare la resilienza informatica dei settori critici in tutta l’UE, imponendo obblighi significativi riguardo alla gestione del rischio informatico e alla risposta agli incidenti.

Di fatto, NIS2 richiede esplicitamente alle organizzazioni di implementare misure di continuità robuste – inclusa la gestione dei backup, il recupero in caso di disastri e capacità di risposta alle crisi – per garantire che entità essenziali e importanti possano mantenere le operazioni durante incidenti informatici dirompenti. Per molte organizzazioni, questo significa:

• Rivalutazione e colmare potenziali lacune di resilienza
• Rafforzamento delle capacità di recupero
• Dimostrazione della responsabilità esecutiva

Inoltre, uno dei pilastri di NIS2 è la Business Continuity (BC) e la pianificazione del Disaster Recovery (DR). Le organizzazioni che rientrano per perimetro della NIS2 sono sempre più consapevoli che i piani di BC e di DR sono critici ai sensi della Direttiva NIS2 e devono essere sviluppati adeguatamente “in tempo di pace” per essere attivati “in tempo di guerra”, i.e. quando un evento dirompente si verifica.

La Direttiva NIS2 e l’importanza della resilienza informatica

La Direttiva NIS2 è stata varata per garantire la continuazione ininterrotta dei servizi e delle attività critiche di fronte alla crescente frequenza e complessità degli incidenti informatici.

È doveroso evidenziare che la direttiva non si concentra solo sulla prevenzione degli attacchi informatici, ma sottolinea anche la rapidità con cui le organizzazioni possono recuperare e ripristinare i propri servizi una volta che si verifica un incidente. Inoltre, la BC ed il DR sono componenti fondamentali della resilienza informatica.

La direttiva si caratterizza per un approccio multi-risk, i.e. vari fattori come attacchi informatici, disastri naturali, guasti hardware o errori umani possono creare interruzioni delle operazioni di un’organizzazione che possono causare perdite finanziarie, danni alla reputazione, perdita di dati e persino interruzioni dei servizi pubblici.

A fronte di ciò la NIS2 impone alle organizzazioni di adottare misure proattive per minimizzare questi rischi e mitigare l’impatto delle interruzioni.

Obblighi chiave per le organizzazioni ai sensi del NIS2

La Direttiva NIS2 impone misure specifiche di gestione del rischio, in particolare per le organizzazioni classificate come “Entità Essenziali” e “Entità Importanti”. La BC ed il DR, in caso di eventi dirompenti, sono centrali in queste misure. Di fatto, la direttiva prevede che le organizzazioni adottino politiche e procedure efficaci nelle seguenti aree:

• Analisi del rischio e politiche di sicurezza dei sistemi informativi
• Gestione degli incidenti
• Continuità aziendale, recupero in caso di disastri e gestione delle crisi
• Sicurezza della catena di approvvigionamento
• Sicurezza nell’acquisizione e nello sviluppo di sistemi di rete e informazione
• Test e audit della cybersecurity
• Formazione dei dipendenti

Si tratta di obblighi che dimostrano che la pianificazione della BC e del DR non sono solo un requisito tecnico, ma una parte integrante della strategia di governance aziendale e di cybersecurity.

Differenza tra Business Continuity (BC) e Disaster Recovery (DR)

Sebbene questi due termini siano spesso usati in modo intercambiabile, hanno punti focali differenti e, precisamente:

• Piano di Business Continuity (BCP) – Si tratta di una strategia completa che descrive come le operazioni aziendali continueranno con minime interruzioni durante un disastro o un’interruzione. Il focus è il mantenimento del funzionamento delle funzioni aziendali critiche. Ciò comprende non solo i sistemi IT, ma tutte le risorse aziendali, incluse le risorse umane, le strutture, la catena di approvvigionamento e le comunicazioni.
• Piano di Disaster Recovery (DRP) – Si tratta del piano che dettaglia principalmente come i sistemi e i dati di tecnologia dell’informazione (IT) verranno recuperati e ripristinati allo stato operativo dopo un disastro. Il suo obiettivo è riparare l’infrastruttura IT, ripristinare i dati e rimettere in funzione i sistemi.

La Direttiva NIS2 prevede che entrambi i tipi di piani siano solidi ed efficaci. Le organizzazioni devono adottare un approccio integrato per garantire la continuità sia dei processi aziendali che dell’infrastruttura tecnica.

Quando si sviluppa un BCP ai sensi della Direttiva NIS2, dovrebbero essere considerati i seguenti componenti chiave:

1. Business Impact Analysis (BIA)

La BIA è uno studio sistematico condotto per identificare i processi aziendali critici di un’organizzazione, i sistemi che li supportano e i potenziali impatti derivanti da un’interruzione. Pertanto, di tratta di:

• Identificare i processi aziendali critici – È necessario identificare quali servizi od operazioni dell’organizzazione sono classificati come “essenziali” o “importanti” per i cittadini dell’UE, l’economia o il pubblico e quali sarebbero gli impatti maggiori se questi servizi venissero interrotti.
• Stabilire il Return Time Objective (RTO – Obiettivo del Tempo di Recupero) – Si ratta di determinarela durata massima tollerabile di un’interruzione, entro cui un processo aziendale o un sistema venga ripristinato a un livello di prestazioni accettabile dopo un’interruzione. NIS2 potrebbe prevedere RTOs brevi, specialmente per i servizi critici.
• Stabilire il Return Point Objective (RPO – Obiettivo del Punto di Recupero- Si riferisce alla quantità massima di dati che può essere persa in caso di disastro. Ad esempio, un RPO di 1 ora significa che puoi tollerare un massimo di 1 ora di perdita di dati. Ciò influisce direttamente sulla frequenza di backup e sulle strategie di sincronizzazione dei dati.
• Eseguire l’analisi delle dipendenze – Si tratta di identificare da quali sistemi IT, infrastrutture, personale e fornitori dipendono i processi aziendali critici.

2. Valutazione del rischio

Identificare, analizzare e dare priorità ai rischi di cybersecurity costituisce la base della pianificazione della BC conforme a NIS2. Ciò dovrebbe includere non solo minacce tecniche, ma anche rischi operativi, ambientali e indotti dall’uomo. Pertanto, si tratta di:

• Identificare delle minacce – Minacce potenziali come attacchi informatici (ransomware, DDoS), disastri naturali (alluvioni, terremoti), guasti hardware, bug software, interruzioni di corrente.
• Eseguire l’analisi della vulnerabilità – Evidenziare falle di sicurezza nei sistemi esistenti, configurazioni deboli, software obsoleto.
• Svolgere la valutazione del rischio – Dare priorità ai rischi valutando la probabilità e il potenziale impatto di ogni minaccia e vulnerabilità.

3. Sviluppo della strategia

Sulla base dei risultati della BIA e della valutazione del rischio, dovrebbero essere sviluppate strategie appropriate per raggiungere gli obiettivi di BC e di DR. E, precisamente:

• Backup e ripristino dei dati- Backup regolari, criptati e geograficamente diversificati sono fondamentali. L’integrità e la recuperabilità dei dati devono essere testate regolarmente.
• Soluzioni ad alta disponibilità – Utilizzo di ridondanza, bilanciamento del carico e meccanismi di failover per sistemi critici.
• Sedi secondarie/Data Center – Luoghi alternativi che possono prendere il controllo delle operazioni se la struttura principale diventa inutilizzabile in caso di disastro. Questi possono essere luoghi caldi, caldi o freddi. NIS2 può incoraggiare configurazioni attive/attiva o attiva/passiva per i servizi critici.
• Protezione DDoS – Dovrebbero essere implementati meccanismi adeguati di mitigazione DDoS, specialmente per le organizzazioni ad alto rischio di attacchi informatici diretti.
• Gestione dell’identità e degli accessi (IAM) – Garantire un accesso autorizzato sicuro anche in situazioni di disaster recovery.
• Accesso remoto sicuro – VPN, MFA e soluzioni simili per permettere al personale di lavorare in sicurezza da remoto durante le crisi.

4. Sviluppo e documentazione del piano

Tutte le strategie dovrebbero essere dettagliate in un documento chiaro, comprensibile e pratico per l’azione. Questo documento deve essere verificabile per la conformità al NIS2.

• Procedure di Gestione degli Incidenti – Processi per rilevare, analizzare, contenere, eradicare, recuperare e apprendere dagli incidenti informatici. NIS2 specifica chiaramente i periodi e i formati di notifica degli incidenti.
• Piano di comunicazione – Come comunicare con stakeholder interni ed esterni (dipendenti, clienti, enti regolatori, media) durante una crisi.
• Squadre di Risposta alle Emergenze – Team con ruoli e responsabilità chiaramente definiti.
• Procedure di recupero – Processi dettagliati di recupero tecnico e operativo passo dopo passo.
• Gestione dei fornitori – Specificare i requisiti di BC e DR nei contratti con i fornitori e verificare regolarmente i piani fornitori. NIS2 pone particolare enfasi sulla sicurezza della catena di approvvigionamento.

5. Test, manutenzione e revisione

L’unico modo per garantire l’efficacia di un piano è testarlo regolarmente e aggiornarlo in base ai risultati. Questo è anche un requisito fondamentale previsto dalla Direttiva NIS2.

• Esercizi e test regolari – Testare gli aspetti tecnici e operativi del piano con scenari realistici (ad esempio, esercitazioni da tavolo, simulazioni, test di recupero dal vivo).
• Metriche di prestazione –Valutare se gli obiettivi RTO e RPO sono stati raggiunti.
• Meccanismi di aggiornamento – Aggiornare periodicamente il piano in base a cambiamenti nei processi aziendali, nei sistemi o nelle minacce.
• Formazione e sensibilizzazione – Formare tutto il personale rilevante sui piani di continuità operativa e recupero in caso di disastri e aumentare la loro consapevolezza.

Misure tecniche e lista di controllo per il DRP

Sebbene la Direttiva NIS2 non elenchi in dettaglio i requisiti delle misure tecniche, implica che alcuni controlli tecnici debbano essere implementati per una posizione efficace di cybersecurity. Alcune misure tecniche e una checklist che dovrebbero essere incluse in un DRP, quali:

Checklist Tecnico DRP

Di seguito si fornisce una check-list requisiti tecnici (esplicativa ma non esaustiva) che un DR deve includere.

• Backup e ripristino dei dati
  • Backup regolare dei dati critici (completi, incrementali, differenziali).
  • Crittografia dei backup e protezione con controlli di accesso.
  • Archiviare i backup in diverse località geografiche (archiviazione off-site).
  • Testando periodicamente l’integrità e la recuperabilità dei backup.
  • Valutazione di soluzioni di backup basate su cloud.

• Sicurezza di rete
  • Implementazione della segmentazione e micro-segmentazione della rete.
  • Monitoraggio e controllo del traffico di rete con firewall e sistemi di rilevamento/prevenzione delle intrusioni (IDS/IPS).
  • Accesso remoto sicuro con protocolli di crittografia come VPN e SSL/TLS.
  • Utilizzo dei servizi di mitigazione DDoS.

• Protezione degli endpoint
  • Soluzioni antivirus e di rilevamento e risposta agli endpoint (EDR).
  • Mantenere tutto il software aggiornato con la gestione delle patch.
  • Configurazione dei sistemi secondo standard di induramento.

• Identity and Access Management (IAM)
  • Utilizzo di Multi-Factor Authentication (MFA).
  • Applica del principio del minimo privilegio.
  • Soluzioni Privileged Access Management (PAM).
  • Soluzioni di Role-Based Access Control (RBAC).

Logging and Monitoring

1. Raccolta dei log degli eventi da tutti i sistemi critici e i dispositivi di rete.

• Gestione centralizzata dei log e sistemi di Security Information and Event Management (SIEM).
• Rilevamento di attività anomale e incidenti di sicurezza in real time.

• Application Security
  • Integrazione dei controlli di sicurezza nel ciclo di vita dello sviluppo software (Software Development Life Cycle – SDLC).
  • Vulnerability scanning and penetration testing.
  • Uso del firewall per applicazioni web (Web Application Firewall – WAF).

• Sicurezza fisica
  • Accesso controllato ai data center e alle server room.
  • Sistemi di monitoraggio ambientale (temperatura, umidità, incendi).

• Sicurezza dei fornitori e terze parti
  • Specificare i requisiti di sicurezza conformi a NIS2 nei contratti con i fornitori.
  • Revisionare e valutare regolarmente la postura di cybersecurity dei fornitori.

• Formazione e sensibilizzazione del personale
  • Formazione sulla consapevolezza della cybersecurity.
  • Simulazioni di phishing.
  • Formazione sulle procedure di emergenza e recupero in caso di disastri.

NIS2: cambio di paradigma e focus sul ruolo degli organi direttivi in termini di responsabilità gestionali e governance

La Direttiva NIS2 dichiara esplicitamente la responsabilità e la responsabilità degli organi dirigenziali (membri del consiglio) per la cybersecurity. La direzione è direttamente responsabile della creazione, implementazione e supervisione dei piani di BC e DR.

DI fatto, la direttiva NIS2 e il relativo recepimento nazionale (D.Lgs. 138/2024) introducono un radicale cambio di paradigma. Gli organi direttivi e di amministrazione (CdA, AD, legali rappresentanti) dei soggetti essenziali e importanti sono considerati direttamente responsabili (accountable) della conformità cyber. La sicurezza informatica non è più delegabile interamente al comparto IT.

Ma vediamo di che si tratta.

1. Obblighi e responsabilità diretta

I membri degli organi di direzione hanno doveri precisi e non delegabili in termini di:

• Approvazione – Devono approvare formalmente le misure di gestione dei rischi di cibersicurezza.
• Supervisione – Sono tenuti a monitorare costantemente l’attuazione delle misure di sicurezza aziendali.
• Formazione – Hanno l’obbligo di seguire regolarmente una formazione specifica in materia di cybersecurity per comprendere e valutare i rischi e le pratiche di gestione.

2. Formazione obbligatoria del personale

I vertici aziendali devono assicurare che anche i propri dipendenti frequentino corsi di formazione periodica sui rischi e le best practice di sicurezza. Le figure apicali, per prime, devono possedere e mantenere aggiornate le competenze necessarie.

3. Sanzioni e responsabilità personale

Il mancato rispetto di questi obblighi espone l’organizzazione a sanzioni amministrative molto severe, e i membri dell’organo di gestione possono essere ritenuti personalmente responsabili per le violazioni. In caso di inottemperanza grave, la normativa prevede la possibilità di interdire temporaneamente i soggetti apicali dall’esercizio delle funzioni di rappresentanza o direzione.

Conclusione

La Direttiva NIS2 impone un approccio olistico e proattivo risk-based e resilience-based alla cybersecurity, ponendo i piani di BC e DR al centro. Ne consegue che le organizzazioni devono non solo prevenire attacchi informatici, ma anche avere piani solidi che dimostrino come mantenere e recuperare i loro servizi critici con il minor impatto possibile e nel minor tempo possibile durante un’interruzione o un disastro.

Inoltre, l’integrazione completa di tecnologia, processi e, soprattutto, di persone in questi piani, è fondamentale per la compliance alla NIS2 e la resilienza cyber aziendale.

Inoltre, il coinvolgimento della direzione e audit regolari dovrà garantire che questi piani non rimangano non siano delle cosiddetta “tigri di carta”, ma diventino strumenti continuamente sviluppati e funzionali.

Concludendo, la compliance alla Direttiva NIS2 è più di un semplice requisito, bensì un investimento strategico che garantisce un futuro digitale sicuro delle organizzazioni.

Si è da poco conclusa la terza edizione della CYBSEC EXPO a Piacenza. Guarda il recap finale della fiera!