NIS2: ecco le regole ENISA per una corretta gestione degli incidenti di sicurezza

Fornire ulteriori consigli e suggerimenti su cosa considerare quando si è chiamati a implementare il sistema di gestione cyber security in forza dell’attuazione della NIS2: è questo l’obiettivo della guida tecnica (al momento in bozza e sotto consultazione pubblica fino al 9 dicembre 2024) che ENISA ha realizzato in collaborazione con la Commissione europea e gli Stati membri della UE nell’ambito del gruppo di cooperazione NIS.

Una guida arricchita da esempi utilizzabili per valutare se un requisito è stato soddisfatto; oppure tabelle di confronto dei requisiti di sicurezza previsti dal regolamento di esecuzione con gli standard europei e internazionali, nonché alla luce degli atti normativi nazionali.

Linee guida ENISA sulla NIS2: la gestione degli incidenti

Analizziamo ora uno degli aspetti maggiormente significativi, quello relativo alla politica sulla gestione degli incidenti.

Definizione degli obiettivi

In primo luogo, non può mancare una definizione degli obiettivi. Gli obiettivi della politica devono essere anzitutto chiari. Perciò occorre che la politica sia conforme a leggi, regolamenti e standard di settore.

Non a caso sappiamo che ai fini dell’articolo 21, paragrafo 2, lettera b), della direttiva (UE) 2022/2555, i soggetti coinvolti debbono istituire e attuare una politica di gestione degli incidenti che stabilisca ruoli, responsabilità e procedure per l’individuazione, contenere o rispondere, recuperare, documentare e segnalare incidenti in modo tempestivo.

Una politica che deve essere coerente con il piano di continuità operativa (business continuity) e di ripristino in caso di disastro (disaster recovery).

La politica deve comprendere in sostanza:

1. un sistema di categorizzazione degli incidenti coerente con la valutazione e la classificazione degli eventi;
2. piani di comunicazione efficaci, anche per quanto riguarda l’escalation e la segnalazione;
3. assegnazione di ruoli per individuare e rispondere adeguatamente agli incidenti ai dipendenti competenti;
4. documenti da utilizzare nel corso dell’individuazione e della risposta agli incidenti, quali manuali di risposta agli incidenti, Grafici di escalation, elenchi di contatti e modelli.

Monitoraggio e registrazione

Non meno importante è la (seconda) fase di monitoraggio e registrazione delle attività sulla rete e sui sistemi informativi al fine di individuare eventi che potrebbero essere considerati “incidenti, rispondendo per attenuarne l’impatto.

Per tali fini, è opportuno individuare uno o più obiettivi del monitoraggio delle attività sulla rete e sui sistemi informativi dell’ente, tra cui (elenco indicativo, non esaustivo): il rilevamento delle minacce; una garanzia di conformità; un supporto per la risposta agli incidenti; una ottimizzazione delle prestazioni; il rilevamento delle anomalie; una robusta prevenzione della perdita di dati; e infine un monitoraggio costante dello stato di salute della rete.

Di qui, le procedure devono descrivere obiettivi; dati per la raccolta; analisi degli algoritmi di dati; notifica, al personale competente, i meccanismi.

Per tali obiettivi servono degli strumenti che rispondono a specifici criteri come:

1. facilità d’uso;
2. integrazione con la rete e il sistema informativo esistenti;
3. minimizzazione dell’intervento manuale;
4. capacità di raccogliere dati da varie fonti, come ad esempio reti, sistemi, applicazioni;
5. funzionalità di sicurezza come ad esempio crittografia;
6. controllo degli accessi;
7. costi e licenze.

Per quanto possibile, il monitoraggio andrebbe automatizzato ed effettuato in modo continuo o a intervalli periodici, compatibilmente con le capacità economico-commerciali. Grazie alle attività di monitoraggio è possibile se non auspicabilmente probabile che siano ridotti al minimo i cd “falsi positivi e negativi”.

Per ridurla al minimo tale ipotesi per quanto possibile, occorre considerare fattori come gli algoritmi di analisi e machine learning; l’aggiornamento continuo degli strumenti di monitoraggio automatizzato per adattarsi alle nuove minacce e ai cambiamenti dell’ambiente, ottimizzando i parametri e le soglie in base ai dati e ai feedback più recenti.

Il registro delle attività

Sulla base di quanto sopra, i soggetti coinvolti dovrebbero conservare, documentare e rivedere i registri, redigendo un elenco delle attività da sottoporre a monitoraggio sulla base dei risultati della valutazione del rischio effettuata.

I registri ove presenti debbono avere:

1. traffico di rete in uscita e in entrata pertinente;
2. una sezione che preveda la creazione, modifica o cancellazione di utenti della rete e dei sistemi informativi degli enti coinvolti ed estensione delle autorizzazioni;
3. accesso a sistemi e applicazioni con tutto ciò che ne consegue ai fini relativi all’autenticazione;
4. tutti gli accessi privilegiati ai sistemi e alle applicazioni e le attività svolte dagli account amministrativi;
5. accesso o modifiche ai file critici di configurazione e backup;
6. registri degli eventi e registri di strumenti di sicurezza, come antivirus, sistemi di rilevamento delle intrusioni o firewall;
7. utilizzo delle risorse di sistema, nonché delle loro prestazioni; l’accesso fisico alle strutture;
8. l’accesso e l’utilizzo delle loro apparecchiature e dispositivi di rete;
9. attivazione, arresto e pausa dei vari log; eventi ambientali.

Per esempio, immaginiamo un accesso a sistemi e app, tre o più blocchi dell’account entro 15 minuti. ENISA, tra gli esempi di evidenze, suggerisce nella guida (in bozza) in parola di “assicurarsi che le procedure implementate siano in grado di rilevare gli attacchi basati sulla rete modelli anomali di traffico in entrata e in uscita e/o attacchi Denial of Service (DoS) in modo tempestivo”.

Ancora, i registri devono essere esaminati regolarmente per individuare eventuali tendenze insolite o indesiderate. Se del caso, i soggetti pertinenti stabiliscono valori appropriati per le soglie di allarme. Se i valori stabiliti per la soglia di allarme sono superati, deve essere attivato automaticamente un allarme, ove opportuno. I soggetti coinvolti provvedono affinché, in caso di allarme, sia avviata tempestivamente una risposta qualificata e adeguata.

Tra gli esempi di evidenze ci sono i “report periodici che riassumono i dati di log ed evidenziano le anomalie rilevate”.

I soggetti interessati è bene che conservino ed eseguano backup delle registrazioni per un periodo predefinito e li proteggano da accessi o modifiche non autorizzate.

Infine, le procedure e l’elenco dei beni registrati sono riesaminati e, se del caso, aggiornati a intervalli regolari e vieppiù dopo che si verificano incidenti cd significativi.

Determinare la frequenza delle revisioni in base ai risultati della valutazione del rischio relativi alla criticità delle risorse, assicurandosi che le revisioni siano condotte almeno una volta all’anno.

Segnalazione di eventi

I soggetti pertinenti devono mettere in atto un meccanismo semplice che consenta ai propri dipendenti, fornitori e clienti di segnalare eventi sospetti.

Definire cosa costituisce un evento sospetto in base a criteri (elenco indicativo, non esaustivo):

1. la riservatezza, l’integrità o la disponibilità della rete o del sistema informativo è stata compromessa;
2. persistenza, ovvero se l’evento è in corso o non più;
3. impatto, ad esempio, sul numero di attività (potenzialmente) interessate, sull’impatto economico per le organizzazioni ecc.;
4. mancata compliance.

Ma non è tutto. Occorre anche predisporre o implementare delle linee guida chiare e concise circa quali informazioni dovrebbero essere incluse, allineandole con quelle da trasmesse al CSIRT o all’Autorità competente, nel caso in cui l’evento dovesse essere notificato conformemente agli artt. 23, 30 della Direttiva NIS2.

Altra buona pratica, è opportuno indicare come minimo la data e ora dell’evento; una descrizione dell’evento; eventuali screenshot, registri o altre prove pertinenti; informazioni di contatto per il follow-up, se necessario.

Occorrono poi procedure documentate per la comunicazione degli eventi, che descrivano (a titolo indicativo, elenco non esaustivo):

1. motivi/motivazioni per la comunicazione o la segnalazione (motivi commerciali, motivi legali ecc.);
2. il tipo di eventi nell’ambito;
3. il contenuto richiesto delle comunicazioni;
4. notifiche o rapporti;
5. i canali da utilizzare;
6. i ruoli responsabili della comunicazione, della notifica e della rendicontazione.

Insomma, l’ENISA dice alle Organizzazioni come fare.

Misure tecniche più robuste

I soggetti pertinenti valutano gli eventi sospetti per determinare se costituiscano incidenti e, in caso affermativo, determinarne la natura e la gravità.

Per valutare se un evento sospetto è un incidente o meno (la sezione 3.1.1 di questa linea guida fornisce un elenco indicativo e non esaustivo di tali criteri) occorre determinare la natura e la gravità dell’evento sulla base di un sistema di categorizzazione ai fini del quale i soggetti coinvolti agiscono nel modo che segue e in particolare:

1. effettuare la valutazione sulla base di criteri predefiniti stabiliti in anticipo e su un triage per determinare le priorità di contenimento ed eliminazione degli incidenti;
2. valutare l’esistenza di incidenti ricorrenti di cui all’articolo 4 del presente regolamento su base trimestrale;
3. esaminare i registri appropriati ai fini della valutazione e della classificazione degli eventi;
4. mettere in atto un processo per la correlazione e l’analisi dei log, nonché rivalutare e riclassificare gli eventi nel caso in cui si rendano disponibili nuove informazioni o dopo l’analisi di informazioni precedentemente disponibili.

Revisioni periodiche della valutazione e classificazione degli eventi passati per migliorare processi, potenziale impatto.

Tenere conto della riservatezza dei dati memorizzati, in particolare quando si correlano e analizzano i file di log per (elenco indicativo, non esaustivo):

1. ridurre al minimo i dati raccolti, il che significa raccogliere e analizzare solo i log che si adattano allo scopo;
2. evitare di conservare dati personali o sensibili non necessari;
3. anonimizzare o pseudonimizzare, quando possibile, i dati raccolti;
4. prendere in considerazione l’implementazione di uno strumento di gestione delle informazioni e degli eventi di sicurezza (SIEM) o di sistemi simili che consentirà e faciliterà la correlazione e l’analisi dei dati.

Risposta agli incidenti

I soggetti pertinenti rispondono agli incidenti secondo procedure documentate e in modo/maniera tempestivo.

Per fare ciò tendenzialmente occorre da un lato istituire un team dedicato alla risposta agli incidenti composto da dipendenti con le necessarie competenza e autorità per rispondere efficacemente agli incidenti; e dall’altro definire ruoli e responsabilità all’interno del team di risposta agli incidenti, compresi i coordinatori degli incidenti, analisti e collegamenti di comunicazione.

Revisioni post-incidente

Se del caso, i soggetti coinvolti effettuano revisioni successive all’incidente dopo la ripresa dagli eventi. Le revisioni successive all’incidente devono individuare, ove possibile, la causa principale dell’incidente e tradursi in insegnamenti documentati tratti per ridurre il verificarsi e le conseguenze di incidenti futuri.

Di qui, è bene definire un processo per condurre revisioni post-incidente dopo gli incidenti di sicurezza, identificandone le cause principali, i fattori che contribuiscono e le aree di miglioramento nei processi di rilevamento, risposta e ripristino degli incidenti.

Ancora, occorre indagare sugli incidenti significativi e redigere rapporti finali sugli incidenti, comprese le azioni intraprese, e stilare delle raccomandazioni volte a mitigare il verificarsi futuro di questo tipo di incidente.

I soggetti coinvolti garantiscono che le revisioni successive all’incidente contribuiscano a migliorare il loro approccio alla sicurezza delle reti e dell’informazione, alle misure di trattamento dei rischi e alle procedure di gestione, individuazione e risposta agli incidenti.

Tra gli “esempi di evidenze” si annoverano:

1. i rapporti di revisione post-incidente descrivono in dettaglio i risultati, le lezioni apprese e le raccomandazioni per il miglioramento a seguito di incidenti di sicurezza;
2. l’analisi, la risoluzione e le misure di mitigazione adottate sono comunicate a tutto il personale interessato.

NIS2 e il ritardo delle organizzazioni: l’opinione dell’esperta

Come abbiamo visto, le linee guida ENISA sulla NIS2 risultano essere molto utili alle aziende anche (e forse soprattutto) per aiutarle a colmare il ritardo nell’implementazione della direttiva europea.

Abbiamo chiesto a Federica M.R. Livelli, Business Continuity & Risk Management Consultant/Membro Comitato Scientifico CLUSIT ed ENIA, BCI SIG Cyber Resilience Committee, un’opinione nel merito.

“La Nis2 avanza sempre più e le organizzazioni sembrano ancora indugiare a prendere atto della direttiva. Pertanto, ben venga una linea guida di implementazione come quella di ENISA che possa convertirsi in un vecchio magister, i.e. colui che indica la via per rispondere ai requisiti e progettare strategie di cybersecurity e relative procedure necessarie. Senza dimenticare che si tratta di un “viaggio sine die” e che può richiedere tempi significativi.

Attualmente, numerose organizzazioni non sono ancora dotate di un adeguato sistema di gestione della cybersecurity, non raccolgono dati critici per gli indicatori di performance né effettuano audit di sicurezza. Aspetti che assumono sempre più importanza nel processo di conformità alla NIS2 e, purtroppo, sono ancora poche le organizzazioni che hanno avviato il maturity assessment e la gap analysis vs. i requisiti della direttiva.

È doveroso sottolineare che le PMI e tutte quelle organizzazioni che rientrano nella catena di fornitura delle entità essenziali e importanti dovranno quanto prima conformarsi ai dettami della NIS2, altrimenti rischiano di compromettere le proprie relazioni commerciali. La Direttiva NIS2 sottolinea, infatti, che le misure di sicurezza devono essere estese non solo all’entità stessa, ma anche ai suoi fornitori e subappaltatori che giocano un ruolo essenziale nel garantirne l’operatività e la resilienza. Di conseguenza, qualora un fornitore presenti lacune significative che influenzano la supply chain, l’ente soggetto alla NIS2 sarà costretto a sostituirlo per preservare la sua resilienza operativa. Inoltre, molte aziende decideranno di interrompere le relazioni con quei fornitori che non dimostrano di poter garantire un adeguato livello di protezione contro gli attacchi informatici.

La NIS2 si sta rivelando un vero e proprio tsunami e “travolgerà” sia le piccole e medie imprese sia le grandi imprese e gli enti pubblici, specialmente per coloro che desiderano tutelare non solo i propri dati, ma anche la loro stabilità economica.

Per concludere, come dice giustamente Federica M.R. Livelli, “Tempus fugit ed è quanto mai fondamentale avviare il processo di conformità alla direttiva. La guida di ENISA può convertirsi in un supporto strategico. Tuttavia, è necessario che le organizzazioni coinvolte, nell’implementare la Direttiva NIS2, prendano coscienza non si può più indugiare nell’adottare un approccio risk-based e resilience-based e multi-risk atto a garantire la necessaria cyber resilience, quale intersezione dei principi di Risk Management, Business Continuity e Cybersecurity”.

Non possiamo che essere d’accordo.