Nel panorama odierno della sicurezza delle informazioni, l’audit assume un ruolo fondamentale come misura di risposta agli incidenti, poiché può trasformare le vulnerabilità in occasioni di crescita.
La direttiva NIS 2 e il decreto attuativo D.lgs. 138/2024 spingono le organizzazioni a formalizzare processi di audit a seguito di eventi di sicurezza e più in generale in fase di monitoraggio dei sistemi creando un sistema di verifica strutturato e indipendente.
Analizziamo, di seguito, le diverse tipologie di audit richieste, dal post-incidente alla valutazione proattiva e periodica, per rafforzare i controlli di sicurezza e prevenire future violazioni.
Indice degli argomenti
Audit di sicurezza NIS 2: comparazione con gli standard ISO
L’audit è definito all’art. 2 del D.lgs. 138/2022 come una “attività di verifica, a distanza o in loco, sistematica, documentata e indipendente, volta a valutare la conformità agli obblighi del capo IV del presente decreto, condotta da un organismo indipendente qualificato o dall’Autorità nazionale competente NIS”.
Questa definizione rispecchia sostanzialmente quella fornita dalla norma UNI EN ISO 19011:2018, la quale sottolinea analogamente il requisito dell’indipendenza. Tuttavia, la ISO 19011 distingue tra l’audit di seconda e terza parte, eseguito da organismi indipendenti esterni, e quello di prima parte, effettuato da soggetti che, seppur indipendenti, sono incaricati dalla Direzione nel ruolo di committente dell’audit.
A differenza del GDPR, che all’art. 43 individua con chiarezza i soggetti autorizzati all’attività di audit, il D.lgs. 138/2022 non specifica in modo dettagliato cosa si intenda per “organismo indipendente”.
In una prospettiva conservativa, è ragionevole considerare tali organismi come terze parti, analoghe agli enti di certificazione (accreditati dall’ente nazionale di accreditamento – in Italia, Accredia, riconosciuto a livello internazionale dall’IAF).
Questo approccio evidenzia ulteriormente il legame tra la NIS 2 e lo standard ISO/IEC 27001:2022, che richiede, ai fini della certificazione, l’intervento di organismi indipendenti per l’audit.
Una prospettiva meno conservativa, con un minore impatto economico, opta per soggetti esterni all’organizzazione qualificati ma non necessariamente accreditati dall’ente nazionale. La questione, tuttavia, rimane ad oggi non completamente chiarita.
Quanto previsto dalla NIS 2 e dal decreto di recepimento come misura conclusiva in caso di incidente di sicurezza informatica rappresenta un valore aggiunto significativo. Tale misura, sebbene non obbligatoria nel GDPR, è invece contemplata nella norma ISO/IEC 27001, che nel controllo 5.27 introduce il concetto di “lesson learned” (“apprendimento dagli incidenti relativi alla sicurezza delle informazioni”).
Questo controllo richiede la formalizzazione delle lezioni apprese in seguito a un incidente e la loro condivisione all’interno dell’organizzazione, con l’obiettivo di sensibilizzare i collaboratori e migliorare la consapevolezza, offrendo casi esemplari su cui riflettere e affinare le procedure interne.
Le caratteristiche distintive di questo tipo di audit, che può essere condotto utilizzando le tecniche dettagliate nella linea guida UNI EN ISO 19011:2018 per il loro riconosciuto valore, costituiscono un pilastro essenziale nella gestione del sistema.
In questo contesto, è indispensabile considerare attentamente i diversi aspetti, dalla pianificazione fino alla consuntivazione delle attività, per garantire una corretta applicazione e l’efficacia del processo di audit, secondo quanto suggerito dalle suddette linee guida.
Doppio audit per la sicurezza NIS 2: modello di resilienza e prevenzione
Un primo ambito in cui è richiesta l’attività di audit, come indicato, è a valle di un incidente sulla sicurezza delle informazioni.
In tale ambito, la prima decisione strategica riguarda la tempistica per l’attività di audit in risposta a un incidente di sicurezza delle informazioni. Per garantire un approccio completo ed efficiente, si consiglia di pianificare due audit distinti come parte della gestione dell’incidente.
Il primo audit dovrebbe essere condotto immediatamente dopo la risoluzione del problema ed a valle della comunicazione agli enti preposti. Questo audit mira a verificare l’efficacia delle misure di trattamento, assicurando che la criticità sia stata gestita nei limiti del possibile. L’audit è anche l’occasione per verificare la correttezza e la completezza delle comunicazioni, quando previste, effettuate al Computer Security Incident Response Team (CSIRT) e, se necessario, al Garante della Privacy in base alle disposizioni del GDPR nel caso di incidente che coinvolge i dati personali.
Il secondo audit, da effettuarsi dopo un adeguato lasso di tempo dall’implementazione delle azioni correttive, ha l’obiettivo di valutare la capacità di tali misure nel rimuovere le cause dell’incidente. Questo audit può essere svolto a distanza di mesi dal primo, poiché è essenziale non solo implementare le azioni ma anche verificarne l’efficacia a lungo termine.
In tal modo, è possibile pianificare due fasi di audit specifiche, tenendo presente che i format di segnalazione al CSIRT e al Garante non richiedono esplicitamente la documentazione delle azioni correttive né delle “lesson learned”, limitandosi a richiedere le misure adottate per risolvere l’evento.
A differenza degli standard ISO, che prevedono un’analisi delle cause e la loro eventuale rimozione come parte integrante della conformità, questa procedura di audit post-incidente estende la prevenzione oltre il singolo evento, includendo la verifica se il problema possa emergere anche in altri processi o ambiti e nel caso le azioni poste in atto.
In sintesi, il modello di audit richiesto dal D.lgs. 138/2024 è articolato e va ben oltre una semplice verifica di conformità, integrando misure preventive e proattive anche per potenziali incidenti. Questa metodologia rafforza la resilienza dell’organizzazione e amplia il perimetro di prevenzione, consolidando l’efficacia delle misure di sicurezza nel lungo periodo.
Un esempio pratico di audit post-incidente
Incidente
Un collaboratore, abilitato all’accesso, cancella involontariamente un archivio di un gestionale sviluppato internamente. L’evento non viene rilevato immediatamente ma solo dopo alcune settimane. A causa del tempo trascorso, non è più possibile recuperare le informazioni tramite il backup.
Trattamento:
- Recuperare i dati cancellati tramite ridigitazione degli stessi.
- Verificare se anche altri archivi sono stati involontariamente cancellati.
Causa
- La modalità di cancellazione nel gestionale non richiede una “conferma di cancellazione,” che è necessaria per prevenire cancellazioni accidentali e assicurare che l’azione sia effettivamente intenzionale.
- Il periodo di conservazione del backup è troppo limitato.
Azione correttiva
- Modificare il gestionale introducendo la funzionalità di “conferma di cancellazione”.
- Valutare se questa modifica debba essere estesa anche agli altri gestionali utilizzati in azienda.
- Aumentare tramite azioni di formazione e di sensibilizzazione il personale sulle cautele da porre in fase di cancellazione e sulle nuove funzioni di “conferma di cancellazione”.
- Valutare la possibilità di estendere l’intervallo di conservazione dei dati di backup.
Lesson Learned
- Aggiornare la procedura di sviluppo interno prevedendo sempre un test che verifichi la presenza della “conferma di cancellazione” in ogni applicativo sviluppato.
Inoltre, qualora l’incidente debba essere comunicato al CSIRT e/o al Garante per la protezione dei dati mediante i moduli online predisposti da tali enti, è necessario fornire una descrizione dettagliata dell’incidente e indicare il trattamento previsto.
Audit periodici e mirati nella sicurezza NIS 2: requisiti e obblighi
L’art. 34 del D.lgs. 138/2024 prescrive anche l’obbligo di condurre audit di sicurezza periodici e mirati, nonché scansioni di sicurezza, da parte di organismi indipendenti, sulla base di valutazioni del rischio condotte dall’Autorità nazionale competente NIS o dal soggetto auditato.
L’Autorità può richiedere di acquisire gli esiti di tali verifiche, e i costi sono generalmente a carico dell’organizzazione, salvo eccezioni motivate dall’Autorità stessa e legate al piano di risposta agli incidenti su vasta scala previsto dall’art. 13, comma 3.
L’art. 34 implica che le organizzazioni debbano eseguire audit periodici, per:
- rispondere alle richieste dell’Autorità nazionale competente NIS – L’art. 37, comma 2, consente all’Autorità di richiedere dati che dimostrino l’attuazione delle politiche di sicurezza, inclusi i risultati degli audit;
- prepararsi agli audit disposti dall’Autorità – Secondo l’art. 35, comma 3b), l’Autorità può richiedere audit mirati o periodici, specialmente in caso di incidente significativo o violazione del decreto.
Questi requisiti sono in linea con la ISO/IEC 27001:2022 e altri standard che si basano sull’Annex SL, promuovendo un controllo costante e strutturato dei sistemi di gestione della sicurezza.
Il programma di audit, usualmente definito durante il riesame della Direzione, deve includere:
- audit di sistema di gestione (MONIS), secondo l’art. 23, per verificare la conformità ai requisiti gestionali della sicurezza;
- audit di conformità legislativa per assicurare l’aderenza al decreto;
- audit di commessa, se richiesti da terze parti o clienti, focalizzati sulla cybersecurity.
Infine, l’art. 37, comma 3, chiarisce che l’Autorità nazionale competente NIS non può richiedere audit di sicurezza periodici ai soggetti considerati “importanti,” limitando la portata di tale obbligo a specifiche categorie di organizzazioni.
Conclusione
Abbiamo cercato di evidenziare come l’audit previsto dalla NIS 2 a seguito di un incidente di sicurezza non sia solo una misura di conformità, ma un’opportunità per rafforzare la struttura difensiva dell’organizzazione, migliorando le procedure e integrando una cultura della sicurezza.
La suddivisione in audit post-incidente e audit periodici permette di creare un sistema di controllo dinamico, in grado di rispondere efficacemente alle minacce attuali e future.
Tale approccio multidimensionale, basato sulle best practice e sulle normative di riferimento, consente di trasformare gli obblighi normativi in un vantaggio competitivo, favorendo la resilienza e l’efficacia dei sistemi di sicurezza.
