Firewall, backup, MFA, sistemi di monitoraggio e procedure di sicurezza possono indicare che un’azienda ha lavorato sulla conformità alla NIS2. Durante un audit, tuttavia, l’elenco delle misure adottate rappresenta soltanto il punto di partenza.
La verifica entra nel merito di ciò che è accaduto: chi ha avuto accesso a un sistema critico, quale controllo ha rilevato un’anomalia, quando è partito l’allarme e quali azioni hanno seguito l’evento. La sicurezza deve quindi produrre evidenze attendibili, capaci di dimostrare nel tempo il funzionamento delle misure adottate.
Il Decreto legislativo 138/2024 richiede ai soggetti essenziali e importanti misure tecniche, operative e organizzative adeguate e proporzionate al rischio. L’articolo 21 della Direttiva NIS2 comprende anche politiche e procedure per valutarne l’efficacia.
Una policy approvata dimostra l’esistenza di una regola. Per verificarne l’applicazione occorrono anche registrazioni degli accessi, log, ticket, report degli incidenti e risultati dei test. Questi elementi devono descrivere una sequenza coerente tra l’evento rilevato, la decisione presa e l’intervento eseguito.
La conformità assume così una dimensione probatoria. Ogni misura deve avere un responsabile, un processo di verifica e una traccia del proprio funzionamento.
Le richieste cambiano in base al tipo di verifica e al contesto dell’organizzazione. Alcuni elementi, però, ricorrono con particolare frequenza:
Il log isolato fornisce un’informazione tecnica. L’evidenza nasce quando quell’informazione trova corrispondenza in un’identità, un orario affidabile e un processo aziendale.
Anche la retention richiede una scelta motivata. La NIS2 non stabilisce un unico periodo di conservazione valido per qualsiasi log: durata e granularità devono riflettere criticità dei sistemi, finalità del monitoraggio e ulteriori obblighi applicabili.
Un foglio Excel rimane utile per associare requisiti, responsabili e stato di avanzamento. Può descrivere la struttura del percorso di conformità, ma non documenta automaticamente ciò che avviene nell’infrastruttura.
Non rileva l’interruzione di una sorgente, non protegge le registrazioni dalle modifiche e non correla eventi distribuiti tra identità, endpoint, server, applicazioni e ambienti cloud. Soprattutto, riporta ciò che qualcuno ha inserito manualmente, mentre un audit deve poter ricostruire ciò che i sistemi hanno effettivamente registrato.
Quando la quantità di eventi cresce, la gestione manuale lascia inevitabilmente zone prive di visibilità e rende più lenta qualsiasi attività di verifica.
Una piattaforma di Log Management raccoglie gli eventi prodotti dalle diverse componenti IT, li centralizza e li conserva secondo criteri definiti. La normalizzazione rende inoltre confrontabili informazioni provenienti da tecnologie differenti.
Il SIEM aggiunge capacità di analisi e correlazione: combina più eventi, applica regole di rilevamento e genera alert quando riconosce comportamenti potenzialmente anomali. La sua efficacia dipende però dalla qualità dei dati ricevuti, dai casi d’uso configurati e dalla presenza di un processo di risposta.
Raccogliere qualsiasi evento senza una strategia produce volume e rumore. Occorre partire dai sistemi più critici, individuare gli eventi utili e collegare ogni alert a responsabilità e tempi di intervento. Un controllo periodico deve inoltre verificare che tutte le sorgenti previste continuino a trasmettere dati corretti.
Un assessment sulla maturità del monitoraggio log può aiutare a individuare fonti mancanti, retention incoerenti e dipendenze ancora affidate a verifiche manuali. Il suo valore sta nella fotografia iniziale, dalla quale costruire un sistema di evidenze sostenibile nel tempo.
La NIS2 porta quindi in primo piano una differenza sostanziale: una misura descritta in una policy esprime un’intenzione; una misura tracciata, monitorata e verificata dimostra la capacità dell’organizzazione di applicarla.