Nei prossimi mesi si attendono le pubblicazioni delle liste di inclusione per quelle aziende che sono interessate dalla NIS2. Nel frattempo, però, lungi dal rimanere in immobile attesa, le imprese si stanno mobilitando per non farsi trovare impreparate e porre in atto tutte le misure necessarie ad essere compliant alla nuova Direttiva Europea.
In loro aiuto viene sicuramente l’Agenzia dell’Unione Europea per la Cybersecurity (ENISA) che ha condiviso le linee guida tecniche per la gestione delle misure di sicurezza informatica, con riferimento all’articolo 24 del legislativo italiano del 4 settembre 2024, n. 138.
Tra le dieci misure riportate dall’ENISA, la “gestione degli incidenti, ivi incluse le procedure e gli strumenti per eseguire le notifiche” è particolarmente strategica per le organizzazioni che devono intraprendere la propria roadmap per la compliance.
Quando si parla di “incidenti” o “incident” si intendono interruzioni non pianificate o riduzioni della qualità dei servizi IT di un’organizzazione.
L'articolo 23 della direttiva 2022/2555 (NIS2) prevede che gli incidenti significativi (ovvero in grado di causare danni finanziari, commerciali, alla persona o interruzioni del servizio di business e dell’operatività) vengano segnalati alle autorità competenti tramite i CSIRT nazionali, team dedicati alla risposta agli incidenti di sicurezza informatica.
Il regolamento 2024/2690, inoltre, stabilisce quali siano gli incidenti che si possono considerare significativi e altre tipologie di incidenti rilevanti per l’implementazione della Direttiva NIS2;
Di seguito troverai maggiori dettagli sull’argomento, se invece vuoi approfondire le Policy di analisi dei rischi e di sicurezza dei sistemi informativi e di rete, clicca qui.
La misura “Gestione degli incidenti, ivi incluse le procedure e gli strumenti per eseguire le notifiche” all’art. 24, comma 2, lettera b) del decreto legislativo si articola in 6 elementi:
Ognuno di questi è fondamentale al mantenimento di livelli adeguati di cybersecurity e incident management previsti dalla Direttiva NIS2.
Per garantire una gestione degli incidenti efficace ed efficiente, le aziende devono, innanzitutto, definire obiettivi chiari e coerenti con le strategie di Risk Management, che vanno condivisi con tutti gli stakeholder.
È, inoltre, fondamentale individuare ruoli, responsabilità e procedure per rilevare, analizzare, contenere, rispondere, ripristinare, documentare e segnalare gli incidenti in modo tempestivo.
Una buona politica di gestione degli incidenti deve:
I ruoli, le responsabilità e le procedure stabiliti nella politica devono essere periodicamente testati, rivisti e aggiornati, specialmente dopo incidenti o cambiamenti significativi nelle operazioni o nei rischi.
Ma come ci si assicura che la politica di gestione degli incidenti funzioni?
Questa va testata periodicamente attraverso esercitazioni teoriche, simulazioni di incidenti basate sugli scenari di attacco identificati, esercitazioni con l’aiuto di red team/blue team, analisi dei log e walkthrough di incidenti passati. In tali occasioni vengono valutate la prontezza del personale e l'adeguatezza di procedure, piani o programmi di test della politica di gestione degli incidenti e piani o programmi di revisione della politica.
Eventuali modifiche alla politica di gestione degli incidenti (derivante da un adeguamento del piano di gestione dei rischi) comportano un aggiornamento del piano di comunicazione, delle procedure, dei processi e della documentazione a supporto.
Nonostante, però, questo sia un processo oneroso per l’azienda, un sistema strutturato, organizzato e aggiornato è il miglior modo per ridurre al minimo l’impatto di un incident sull’erogazione dei servizi di business. Ciò non significa bloccare l'azienda in un complesso rigido di procedure e documentazione da aggiornare e modificare costantemente, ma creare un modello snello, sostenibile, calibrato sul piano dei rischi, facilmente utilizzabile, in linea con le capacità e le esigenze di business dell'azienda.
Le attività di monitoraggio svolgono un ruolo fondamentale nella roadmap verso la compliance alla NIS2. Le entità competenti sono, infatti, chiamate a stabilire procedure e utilizzare strumenti adeguati a monitorare e registrare (logging) le attività sul proprio impianto informatico, al fine di rilevare eventi che potrebbero essere considerati incidenti e rispondere di conseguenza.
Il monitoraggio, così come l'attuazione del piano degli incidenti, deve essere sostenibile per l'azienda e va svolto in modo continuativo o a intervalli periodici. Pertanto, è consigliato l'uso di sistemi adeguati, che limitino l'intervento manuale degli operatori e i falsi positivi e negativi. In particolare, sono da preferire sistemi che utilizzano algoritmi di analisi e apprendimento automatico, caratterizzati dalla capacità di aggiornamento continuo. Ciò consente di adattarsi alle nuove minacce e ai cambiamenti nell'ambiente, basandosi sui dati e feedback più recenti.
Il monitoring e logging non può, poi, prescindere dalla valutazione dei rischi. Quest’ultima, infatti, produce un insieme di asset (tracciati in appositi registri o sistemi software) che contribuiscono a supportare l’erogazione del servizio di business. Tali asset generano degli eventi (log, metriche, misure) che vengono raccolti dal sistema di monitoraggio.
Lo strumento di monitoring utilizzato deve essere in grado di rilevare incidenti di carattere intenzionale o casuali che compromettono gli asset e quindi il servizio di business, in modo che le entità aziendali coinvolte riescano tempestivamente ad individuare l’incident, analizzarlo, identificarne la causa, limitarne gli impatti e a produrre tutta la documentazione necessaria ai fini normativi.
Ai fini di poter produrre evidenze al Normatore o per successive indagini forensi, gli eventi devono essere conservati e sottoposti a backup per un periodo predefinito dal piano degli incident e devono essere protetti da accessi o modifiche non autorizzati. Le evidenze prodotte dovrebbero essere, poi, usate come input del processo di revisione del piano dei rischi.
Infine, la disponibilità dei sistemi di monitoraggio deve essere monitorata in modo indipendente dai sistemi che stanno monitorando. E tutto l’impianto di monitoraggio, compreso e l'elenco delle risorse che vengono monitorate (asset), deve essere riesaminato e, ove opportuno, aggiornato a intervalli regolari e dopo incidenti significativi.
Le aziende interessate dalla NI2 hanno l’obbligo e la responsabilità di segnalare gli incidenti significativi. Esiste l’obbligo di segnalare gli incidenti significatici agli organi di controllo competenti entro 24 ore dalla scoperta, con follow-up entro 72 ore, e redigere una relazione finale. Proprio per questo, è molto importante essere in possesso di un sistema software per la tracciatura e la gestione degli incident e mantenere un registro di tutti gli eventi accaduti e segnalati.
Si tratta di un’attività delicata, che necessita una comunicazione chiara e univoca tra tutti gli attori coinvolti.
Al fine di svolgerla al meglio, è essenziale sviluppare linee guida chiare e concise su quali informazioni includere in un report, a seguito di un incidente, allineandole con quelle che potrebbero essere inviate al CSIRT.
Come buona pratica, il rapporto dovrebbe includere:
È, inoltre, consigliato:
Le entità competenti devono valutare gli eventi sospetti per determinare se costituiscono incidenti e, in caso affermativo, determinarne la natura e la gravità.
Per avere un risultato ottimale dal processo di valutazione dell’evento, secondo normativa, bisogna seguire un processo in 5 step:
Ma come si fa a capire se un evento è sospetto e, dunque, costituisce un “incidente?
Di questo se ne occupa il Security Operation Center. Tra le sue mansioni ci sono:
La corretta valutazione dell’impatto da parte del SOC e il suo intervento tempestivo sono possibili solo se è in possesso delle informazioni e delle procedure stilate e condivise nel piano di gestione degli incident.
Per valutare se un evento sospetto è un incidente, sono, dunque, necessari:
È, inoltre, utile implementare playbook o runbook per guidare la valutazione iniziale e le azioni di risposta per tipi comuni di incidenti, come ransomware, phishing, perdita di dati o dispositivi, o ad esempio incendi o anche incidenti ricorrenti.
Infine, quando si correlano e analizzano i file di log, occorre tenere conto della riservatezza dei dati memorizzati, minimizzando la raccolta dei dati, anonimizzando i dati raccolti o nascondendoli attraverso pseudonimi (quando possibile), applicando buone pratiche di sicurezza (controllo degli accessi, crittografia, audit regolari, monitoraggio) e una politica di conservazione dei dati in conformità con i requisiti del GDPR.
Dopo aver intercettato, classificato e segnalato gli incidenti, le entità competenti devo attuare una risposta adeguata e tempestiva, in conformità con le procedure documentate.
Le procedure di risposta agli incidenti devono comprendere le seguenti fasi:
All’interno del Security Operation Center devono esserci le competenze tecniche, le informazioni e le procedure necessarie per identificare un incident, classificarlo, collaborare con le altre entità aziendali per contenerne l’impatto e provvedere alla successiva eliminazione della causa.
Affinché tutto funzioni secondo le attese, è importante definire ruoli e responsabilità all'interno del team, inclusi coordinatori degli incidenti, analisti e responsabili delle comunicazioni.
Dopo il recupero da un incidente, le entità rilevanti devono effettuare revisioni post-incidente. Queste revisioni hanno lo scopo di identificare la causa principale dell'incidente e documentare le lezioni apprese per ridurre il verificarsi di futuri incidenti e le loro conseguenze. Gli attori coinvolti (es: il team di revisione) devono garantire che tali revisioni contribuiscano a migliorare l’approccio alla sicurezza delle reti e delle informazioni, alle misure di trattamento del rischio e alle procedure di gestione, rilevamento e risposta agli incidenti.
Il team di revisione deve includere i membri dei dipartimenti rilevanti come IT, Sicurezza, Legal e Governance.
Anche in questo caso, è consigliato definire un processo per condurre revisioni post-incidente, all’interno del piano di gestione degli incident. Questo processo dovrebbe includere l'identificazione delle cause principali, dei fattori contributivi e delle aree di miglioramento nei processi di rilevamento, la risposta e recupero dagli incidenti, gli incidenti significativi, le azioni intraprese e le raccomandazioni per mitigare il verificarsi futuro di tali incidenti.
Le revisioni post-incidente devono essere analizzate per identificare lacune e debolezze nella sicurezza della rete e delle informazioni dell’Azienda. E quest’ultime devono essere integrate nella valutazione del rischio e nel piano di trattamento del rischio.
Quello della gestione degli incidenti dovrebbe essere un processo solido all’interno di qualunque azienda, indipendentemente dalla conformità a NIS2. Riuscire a intercettare, classificare e gestire degli incident che potrebbero avere impatti sul business è fondamentale al fine di garantire all’azienda e ai propri stakeholder sicurezza, resilienza e business continuity.