Guida del Responsabile della sicurezza delle informazioni (CISO) alla preparazione forense pronta per l’audit: integrare NIS2, DORA, ISO 27001 e GDPR

Maria, Responsabile della sicurezza delle informazioni (CISO) di una società fintech di medie dimensioni, avvertì una familiare stretta allo stomaco. Il rapporto dell’audit esterno per la certificazione ISO/IEC 27001:2022 era sulla sua scrivania, con una conclusione netta e inequivocabile: una non conformità maggiore.

Tre settimane prima, uno sviluppatore junior aveva esposto accidentalmente a Internet, per 72 minuti, un data store di non produzione. Dal punto di vista operativo, la risposta agli incidenti era stata efficace. Il team era intervenuto rapidamente, aveva messo in sicurezza il sistema e aveva confermato che non erano coinvolti dati sensibili dei clienti.

Dal punto di vista della conformità, invece, era stato un disastro.

Quando l’auditor chiese le evidenze per dimostrare esattamente che cosa fosse accaduto in quei 72 minuti, il team non riuscì a fornirle. I log del provider cloud erano generici ed erano stati sovrascritti dopo 24 ore. I log del firewall mostravano connessioni, ma non contenevano dettagli a livello di pacchetto. I log applicativi interni non erano stati configurati per registrare le specifiche chiamate API effettuate. Non era quindi possibile dimostrare in modo definitivo che nessuna parte non autorizzata avesse tentato di elevare i privilegi o di spostarsi lateralmente verso altri sistemi.

La risultanza dell’auditor fu severa: “L’organizzazione non è in grado di fornire evidenze sufficienti e affidabili per ricostruire la cronologia di un evento di sicurezza, dimostrando una carenza di preparazione forense. Ciò solleva criticità significative in merito alla conformità ai requisiti NIS2 di gestione degli incidenti, all’obbligo DORA di tracciamento dettagliato degli incidenti e al principio di responsabilizzazione previsto dal GDPR.”

Il problema di Maria non era un fallimento della risposta agli incidenti, ma una mancanza di visione preventiva. Il suo team era eccellente nel contenere le emergenze, ma non aveva costruito la capacità di indagare sull’origine dell’incendio. È in questo divario critico che si colloca la preparazione forense: una capacità che non è più un elemento opzionale, ma un requisito imprescindibile nell’attuale quadro normativo.

Dalla registrazione reattiva alla preparazione forense proattiva

Molte organizzazioni, come quella di Maria, ritengono erroneamente che “avere log” equivalga a essere pronte per un’indagine. Non è così. La preparazione forense è una capacità strategica, non un sottoprodotto accidentale delle operazioni IT. Come inquadrato dallo standard internazionale ISO/IEC 27043, le organizzazioni devono istituire processi per garantire che le evidenze digitali siano predisposte, accessibili ed efficienti sotto il profilo dei costi in previsione di potenziali incidenti di sicurezza.

Nel contesto di NIS2, DORA, ISO 27001:2022 e GDPR, questo significa essere in grado di:

• Rilevare gli eventi rilevanti con rapidità sufficiente a rispettare scadenze di segnalazione stringenti.
• Ricostruire una sequenza attendibile degli eventi a partire da log resistenti alla manomissione.
• Dimostrare ad auditor e autorità di regolamentazione che i controlli di registrazione e monitoraggio sono basati sul rischio, rispettosi della privacy ed efficaci.

La guida di implementazione di Clarysec in Clarysec’s Zenith Controls: The Cross-Compliance Guide Zenith Controls lo sintetizza così:

Una preparazione forense efficace in contesti di conformità richiede di minimizzare la raccolta dei dati di log a quanto strettamente necessario, evitando l’archiviazione eccessiva di dati personali o sensibili e, ove possibile, anonimizzando o pseudonimizzando i dati. Ulteriori buone pratiche includono l’applicazione di misure di sicurezza robuste, come controlli degli accessi, cifratura, audit frequenti e monitoraggio continuo, insieme all’applicazione di politiche di conservazione dei dati allineate al GDPR e alla rimozione periodica delle informazioni non più necessarie.

Questo comporta un cambio di mentalità fondamentale:

• Dall’accumulo di dati alla raccolta mirata: invece di raccogliere tutto, si definiscono le evidenze necessarie per rispondere alle domande critiche: chi ha fatto cosa? Quando e dove è accaduto? Qual è stato l’impatto?
• Dai log isolati alle cronologie correlate: i log di firewall, applicazioni e cloud sono singoli pezzi di un puzzle. La preparazione forense è la capacità di assemblarli in un quadro coerente.
• Da strumento operativo ad asset probatorio: i log non servono solo al debugging. Sono evidenze legali e regolamentari che devono essere protette, conservate e gestite con una catena di custodia chiara.

L’incapacità di dimostrare che cosa sia accaduto durante una violazione è oggi considerata un fallimento del controllo in sé, a prescindere dall’impatto iniziale dell’incidente.

Le fondamenta: dove governance e politiche diventano pratica

Prima ancora di configurare un singolo log, un programma di preparazione forense deve partire da una governance chiara. La prima domanda di un auditor non sarà “Mostratemi il vostro SIEM”, ma “Mostratemi la vostra politica”. È qui che un approccio strutturato produce valore immediato e difendibile.

In The Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, lo Step 14 della fase ‘Risk & Implementation’ è dedicato a questo lavoro fondativo. L’obiettivo è esplicito:

“Sviluppare o perfezionare politiche e procedure specifiche, come richiesto dai trattamenti del rischio selezionati (e dai controlli dell’Annex A), e garantire l’allineamento a regolamenti quali GDPR, NIS2 e DORA.”

Questo passaggio impone alle organizzazioni di tradurre le decisioni sul rischio in regole documentate e applicabili. Per un Responsabile della sicurezza delle informazioni (CISO) come Maria, significa creare un insieme di politiche interconnesse che definiscano la capacità forense dell’organizzazione. I modelli di policy di Clarysec forniscono l’architettura per questa struttura. L’elemento chiave è stabilire collegamenti espliciti tra le politiche, così da creare un quadro di governance coerente.

Definendo prima questo quadro di politiche, si crea una posizione difendibile. Ad esempio, la nostra Politica per la raccolta delle evidenze e l’analisi forense dichiara la propria dipendenza dalla P22 – Politica di registrazione e monitoraggio per garantire la “disponibilità di log degli eventi e telemetria per la raccolta delle evidenze e la correlazione forense”. Questa singola frase crea un mandato forte: lo scopo della registrazione non è solo operativo, ma anche a supporto dell’analisi forense.

Per le organizzazioni più piccole, i principi sono identici. La nostra Politica per la raccolta delle evidenze e l’analisi forense per le PMI richiama la propria politica di registrazione fondativa: “P22S – Politica di registrazione e monitoraggio: fornisce i dati grezzi utilizzati come evidenza forense e stabilisce i requisiti di conservazione, controllo degli accessi e registrazione.”

Questa strategia documentata comunica ad auditor, autorità di regolamentazione e team interni che esiste un approccio definito e intenzionale alla gestione delle evidenze.

Il motore tecnico: abilitare la preparazione con il monitoraggio strategico

Con una solida base di policy, il passo successivo è costruire il motore tecnico. Questo si fonda su due controlli chiave di ISO/IEC 27001:2022: 8.15 Registrazione e 8.16 Attività di monitoraggio. Sebbene siano spesso discussi insieme, rispondono a finalità distinte. Il controllo 8.15 riguarda la registrazione degli eventi. Il controllo 8.16 riguarda la loro analisi attiva per rilevare anomalie ed eventi di sicurezza. È il battito cardiaco della preparazione forense.

La guida Zenith Controls, proprietà intellettuale di Clarysec che mappa i controlli ISO sugli standard globali e sulle pratiche di audit, illustra come 8.16 Attività di monitoraggio sia l’elemento cardine che collega i dati grezzi a informazioni utilizzabili. Non opera in isolamento: fa parte di un ecosistema di sicurezza profondamente interconnesso:

• Collegato a 8.15 Registrazione: un monitoraggio efficace è impossibile senza una registrazione robusta. Il controllo 8.15 garantisce l’esistenza dei dati grezzi. Il controllo 8.16 fornisce il motore di analisi per interpretarli. Senza monitoraggio, i log sono solo un archivio silenzioso e non esaminato.
• Alimenta 5.25 Valutazione e decisione sugli eventi di sicurezza delle informazioni: le allerte e le anomalie segnalate dal monitoraggio (8.16) sono gli input principali del processo di valutazione degli eventi (5.25). Come evidenzia la guida Zenith Controls, è così che si distingue un’anomalia minore da un incidente pienamente sviluppato che richiede escalation.
• Informato da 5.7 Threat intelligence: il monitoraggio non deve essere statico. La threat intelligence (5.7) fornisce nuovi indicatori di compromissione e schemi di attacco, che devono essere utilizzati per aggiornare le regole e le ricerche di monitoraggio, creando un ciclo di feedback proattivo.
• Esteso a 5.22 Monitoraggio dei servizi dei fornitori: la visibilità non può fermarsi al perimetro interno. Per i servizi cloud e gli altri fornitori, è necessario assicurare che le loro capacità di monitoraggio e registrazione soddisfino i requisiti forensi dell’organizzazione, un aspetto essenziale per NIS2 e DORA.

Una strategia di registrazione e monitoraggio pronta per l’analisi forense parte dallo scopo. Le soglie di allarme devono basarsi sulla valutazione del rischio, includendo ad esempio il monitoraggio di picchi nel traffico di rete in uscita, blocchi rapidi degli account, eventi di elevazione dei privilegi, rilevazioni di malware e installazioni di software non autorizzato.

Allo stesso modo, la conservazione dei log deve essere una decisione deliberata. La guida Zenith Controls raccomanda:

La conservazione e il backup dei log devono essere gestiti per un periodo predefinito, con protezioni contro accessi e modifiche non autorizzati. I periodi di conservazione dei log devono essere determinati in base alle esigenze aziendali, alle valutazioni del rischio, alle buone pratiche e ai requisiti legali…

Ciò significa definire periodi di conservazione per ciascun sistema (ad esempio, 12 mesi online, 3-5 anni archiviati per i sistemi critici ai fini DORA) e assicurare che le copie di backup siano conservate almeno per tutto il periodo in cui i log vengono riesaminati regolarmente.

L’equilibrio della conformità: raccogliere evidenze senza violare il GDPR

Una reazione istintiva a un fallimento di audit come quello di Maria potrebbe essere registrare tutto, ovunque. Questo crea però un problema nuovo e altrettanto pericoloso: la violazione dei principi di protezione dei dati previsti dal GDPR. Preparazione forense e privacy sono spesso percepite come forze contrapposte, ma devono essere conciliate.

È qui che il controllo ISO 27001:2022 5.34 Privacy e protezione delle PII diventa critico. Rappresenta il ponte tra il programma di sicurezza e gli obblighi in materia di privacy. Come illustrato in Zenith Controls, l’implementazione del controllo 5.34 costituisce evidenza diretta della capacità di soddisfare l’Article 25 del GDPR (Data protection by design and by default) e l’Article 32 (Security of processing).

Per raggiungere questo equilibrio, il programma forense deve integrare controlli chiave a tutela della privacy:

• Integrare con 5.12 Classificazione delle informazioni: assicurare che i log provenienti da sistemi che trattano PII siano classificati come altamente sensibili e ricevano le protezioni più rigorose.
• Implementare 8.11 Mascheramento dei dati: utilizzare attivamente la pseudonimizzazione o il mascheramento per oscurare gli identificativi personali nei log quando i valori grezzi non sono necessari ai fini dell’indagine. Si tratta di un’applicazione diretta della minimizzazione dei dati.
• Applicare 5.15 e 5.16 (controllo degli accessi e gestione delle identità): limitare l’accesso ai log grezzi secondo un rigoroso principio di necessità di conoscere, soprattutto per gli eventi relativi a dipendenti o clienti.
• Mappare il programma sui framework privacy: supportare il programma con standard quali ISO/IEC 27701 (per PIMS), ISO/IEC 27018 (per PII nel cloud) e ISO/IEC 29100 (per i principi privacy).

Integrando questi controlli, è possibile progettare una strategia di registrazione e monitoraggio solida sotto il profilo forense e consapevole della privacy, soddisfacendo contemporaneamente le esigenze dei team di sicurezza e dei responsabili della protezione dei dati.

Dalla teoria all’audit: che cosa cercano davvero auditor diversi

Superare un audit richiede di presentare le evidenze corrette in modo coerente con la metodologia specifica dell’auditor. Un auditor ISO 27001 ragiona in modo diverso da un auditor COBIT, ed entrambi hanno un focus diverso rispetto a un’autorità NIS2.

La sezione audit_methodology della nostra guida Zenith Controls relativa a 8.16 Attività di monitoraggio offre ai Responsabili della sicurezza delle informazioni (CISO) una tabella di marcia di grande valore, traducendo l’obiettivo del controllo in evidenze concrete per diverse prospettive di audit.

Ecco come prepararsi al riesame da diverse angolazioni:

Comprendere queste diverse prospettive è essenziale. Per un auditor ISO, un processo ben documentato per la gestione di un falso allarme è un’eccellente evidenza di un sistema funzionante. Per un auditor NIST, un test live che mostri l’attivazione di un’allerta in tempo reale è più convincente. Per un’autorità NIS2 o DORA, la prova di rilevazione ed escalation tempestive è fondamentale. Il team di Maria ha fallito perché non è stato in grado di fornire evidenze idonee a soddisfare nessuna di queste prospettive.

Scenario pratico: costruire un pacchetto di evidenze pronto per l’audit

Applichiamo questi principi a uno scenario reale: una campagna malware colpisce diversi endpoint nelle operazioni UE, alcuni dei quali trattano PII dei clienti. È necessario soddisfare GDPR, NIS2, DORA e l’auditor ISO 27001.

Il pacchetto di evidenze deve essere una narrazione strutturata, non un semplice scarico di dati. Deve includere:

1. Cronologia tecnica e artefatti:

   • Allerte SIEM che mostrino la rilevazione iniziale, collegate a 8.16 Attività di monitoraggio.
   • Log EDR con hash dei file, alberi dei processi e azioni di contenimento.
   • Log firewall e di rete che mostrino tentativi di comunicazione C2.
   • Log di autenticazione che mostrino eventuali tentativi di movimento laterale.
   • Hash di tutti i file di log raccolti per dimostrarne l’integrità, in coerenza con 8.24 Uso della crittografia.

2. Evidenze di governance e procedurali:

   • Una copia della Politica per la raccolta delle evidenze e l’analisi forense.
   • Una copia della Politica di registrazione e monitoraggio, che dimostri il mandato alla raccolta di questi dati.
   • L’estratto rilevante della Politica di conservazione ed eliminazione dei dati Politica di conservazione ed eliminazione dei dati, che mostri i periodi di conservazione applicabili a questi log specifici.

3. Collegamento con la gestione degli incidenti:

   • Il ticket di risposta agli incidenti che mostri classificazione, valutazione di gravità ed escalation, collegando il monitoraggio (8.16) alla valutazione dell’incidente (5.25).
   • Registrazioni del processo decisionale relativo alla notifica alle autorità ai sensi di NIS2 Article 23 o GDPR Article 33.

4. Evidenze di conformità privacy:

   • Una nota del DPO che confermi l’esecuzione di un riesame privacy sul pacchetto di evidenze.
   • Dimostrazione che eventuali PII presenti nei log sono state gestite secondo la politica (ad esempio, con accesso limitato), in coerenza con il controllo 5.34 Privacy e protezione delle PII.

5. Comunicazioni regolamentari:

   • Una registrazione di eventuale corrispondenza con l’autorità di protezione dei dati o con l’autorità nazionale di cibersicurezza, come raccomandato dalla nostra guida in Zenith Controls.

Questo pacchetto strutturato trasforma un evento caotico in una dimostrazione di controllo, processo e due diligence.

Costruire il proprio archivio delle evidenze: un piano operativo

Come può un Responsabile della sicurezza delle informazioni (CISO) passare da una postura reattiva a uno stato di preparazione forense continua e pronta per l’audit? La chiave è costruire sistematicamente un “archivio delle evidenze” contenente le prove di cui gli auditor avranno bisogno prima che le richiedano.

1. Documentare la strategia:

• Finalizzare le politiche: approvare e pubblicare la Politica di registrazione e monitoraggio, la Politica per la raccolta delle evidenze e la Politica di conservazione dei dati, utilizzando lo Step 14 di The Zenith Blueprint come guida.
• Mappare il flusso dei dati: mantenere un diagramma che mostri da dove vengono raccolti i log, dove vengono aggregati (ad esempio, nel SIEM) e come vengono protetti.

2. Configurare e convalidare gli strumenti:

• Impostare soglie basate sul rischio: documentare le soglie per le allerte chiave e giustificarle in base alla valutazione del rischio.
• Convalidare le impostazioni di conservazione: acquisire screenshot dalla piattaforma di gestione dei log o dalla console cloud che mostrino chiaramente i periodi di conservazione configurati per i diversi tipi di dati.
• Dimostrare l’integrità: istituire un processo per calcolare hash crittografici dei file di evidenza critici al momento della raccolta e conservare gli hash separatamente.

3. Dimostrare l’efficacia operativa:

• Mantenere registrazioni dettagliate: conservare registrazioni di come sono stati gestiti almeno tre eventi di sicurezza recenti, anche falsi allarmi. Mostrare l’allerta iniziale, le note di triage, le azioni intraprese e la risoluzione finale con marcature temporali.
• Registrare l’accesso ai log: essere pronti a mostrare chi ha accesso alla visualizzazione dei log grezzi e a fornire tracce di audit dei relativi accessi.
• Testare e registrare: mantenere registrazioni che dimostrino lo stato di salute dei sistemi di monitoraggio e l’esecuzione e registrazione di test periodici (ad esempio, test degli allarmi).

Il fallimento di audit di Maria non era tecnico, ma strategico. Ha imparato nel modo più difficile che, nell’attuale panorama regolamentare, un incidente non indagabile è quasi grave quanto l’incidente stesso. I log non sono più un semplice sottoprodotto dell’IT: sono un asset critico per governance, gestione del rischio e conformità.

Non aspettare che una non conformità esponga le lacune. Costruendo una vera capacità di preparazione forense, i dati di sicurezza si trasformano da potenziale responsabilità nel principale asset per dimostrare due diligence e resilienza.

Vuoi costruire una capacità forense pronta per l’audit? Esplora The Zenith Blueprint: An Auditor’s 30-Step Roadmap di Clarysec per costruire il tuo SGSI documentato dalle fondamenta e approfondisci Zenith Controls per comprendere le evidenze precise richieste dagli auditor per ogni controllo. Prenota oggi una consulenza per scoprire come i nostri toolkit integrati possono accelerare il percorso verso una conformità dimostrabile.