Cosa ci dice l'applicazione iniziale della NIS2 sugli audit trail

La maggior parte degli obblighi di conformità nasce come un esercizio di spunta. Qualcuno verifica che il logging sia attivo, spunta la casella e il team passa oltre. Ma la NIS2 sta cambiando le cose. Le autorità ora pretendono la prova dei tuoi controlli. Chiedono se sei in grado di ricostruire quanto è accaduto e se qualcuno dovrebbe fidarsi dei tuoi registri. Perché se non puoi mostrare chi ha fatto cosa e quando, quei controlli è come se non esistessero.

Le autorità vogliono evidenze

Gli importi delle sanzioni sono difficili da stabilire. Le cifre che circolano online variano a seconda della fonte, e l'UE non ha ancora creato un registro centrale delle sanzioni. Il modello di applicazione emerso di recente, però, dice di più.

Il BSI tedesco ha emesso decine di diffide formali. L'ANSSI francese ha emesso ordini di correzione per problemi nei settori dell'energia e dei trasporti, preferendo la rimediazione alle sanzioni. Nei Paesi Bassi, una verifica sulle aziende di infrastrutture digitali essenziali ha rilevato che più di un terzo aveva procedure deboli di segnalazione degli incidenti e più della metà non aveva agli atti una politica di sicurezza approvata dalla direzione.

Ognuno di questi rilievi si riduce alla mancanza di prove.

Dove si trovano i requisiti reali

Gran parte della copertura si ferma all'articolo 21, la parte della NIS2 che elenca dieci misure di sicurezza generiche. Ma quell'articolo è volutamente generale. I dettagli che ti servono si trovano nel Regolamento di esecuzione (UE) 2024/2690 della Commissione, in vigore da novembre 2024. Trasforma quelle dieci misure in più di 150 controlli specifici. Logging e monitoraggio, i controlli alla base del tuo audit trail, sono trattati nella sezione 3.2 dell'allegato.

Il regolamento si applica direttamente a un gruppo definito di aziende, tra cui fornitori di cloud e data center, fornitori DNS, fornitori di servizi gestiti e marketplace online. Le aziende al di fuori di quell'elenco non sono formalmente vincolate, ma resta il metro che un'autorità ha più probabilità di usare. (La nostra panoramica sulla conformità alla NIS2 illustra i criteri per capire se la NIS2 si applica a te.)

Le norme dicono spesso cose come "ove opportuno" o "nella misura del possibile", il che suona come un margine di manovra. Ma c'è un trucco: se decidi che un requisito non si applica a te, devi mettere per iscritto il perché. Scegliere di non attivare il logging su un sistema va bene se hai documentato la motivazione. Altrimenti è un rilievo.

La prova spesso scompare prima che qualcuno la cerchi

I log di sicurezza di Windows sui domain controller si sovrascrivono per progettazione. Quando un log raggiunge un limite di dimensione, gli eventi più vecchi lasciano spazio ai nuovi. Quel limite, probabilmente fissato anni fa da qualcuno per risparmiare spazio su disco, non tiene conto delle evidenze. Su un server molto attivo, il log può ruotare in pochi minuti.

Ma poiché il logging è attivo e continuano ad arrivare nuovi record, nessuno si accorge della perdita. Quando un'autorità chiede di qualcosa accaduto quattro mesi fa, rispondere che "il logging era attivo" non serve a nulla.

Due cose rapide che puoi fare:

• Verifica oggi per quanto tempo i tuoi domain controller e i server critici conservano i log. L'impostazione reale conta più del documento di policy.
• Scopri quanta parte della finestra di evidenze richiesta la tua piattaforma di audit può cercare direttamente. I dati recenti sono di solito rapidi da cercare, mentre quelli più vecchi stanno in un archivio che può richiedere un ripristino. Prova subito quel recupero. L'articolo 23 della NIS2 ti concede 24 ore per un preallarme. È un pessimo momento per scoprire che recuperare l'attività di sei mesi prima richiede giorni.

I log che un amministratore può modificare non sono evidenze

La NIS2 si aspetta che tu protegga i log da accessi e modifiche non autorizzati.

Pensa a chi staresti indagando: di solito è un account con diritti di amministratore. Se i tuoi dati di audit risiedono su sistemi controllati da quell'account, una delle prime mosse può essere cancellare i log. E sebbene Windows registri che un log è stato cancellato, scrive quella voce nel log appena svuotato. Scopri che la cronologia è stata cancellata, ma non cosa conteneva.

Per questo "per quanto tempo lo conserviamo?" è la prima domanda sbagliata. Un archivio di sette anni che un amministratore può modificare è più debole di un archivio di sei mesi che non può toccare. Una registrazione affidabile richiede tre cose:

1. Un sistema esterno all'ambiente monitorato raccoglie e conserva i dati.
2. Le persone che gestiscono quei sistemi non possono modificare la cronologia archiviata.
3. L'archivio di audit registra ogni modifica che subisce.

È il secondo requisito quello su cui le aziende falliscono di più. L'account che raccoglie i dati di audit è spesso un domain admin perché era il più semplice da configurare. Così un attaccante che prende il controllo di un accesso amministrativo raggiunge anche le evidenze. Verifica oggi chi ha accesso in scrittura al tuo database e al tuo archivio di audit.

Il terzo requisito è il più facile da trascurare. La tua piattaforma dovrebbe dirti quando i log di audit sono stati cancellati, quando le impostazioni di audit sono cambiate e chi ha consultato l'archivio. Se non può, le tue evidenze non hanno nulla che le sostenga.

Sei test da eseguire prima che lo faccia un'autorità

Riserva due ore, prendi un cronometro e prova a produrre la prova per ciascuno di questi casi nel tuo ambiente reale:

1. Un account privilegiato viene compromesso. Riesci a vedere tutto ciò che ha fatto, su ogni sistema, in ordine?
2. Qualcuno ottiene permessi che non dovrebbe avere. Riesci a capire chi li ha concessi e quando, anche attraverso gruppi annidati?
3. Cambia un'impostazione critica. Riesci a mostrare com'era prima e com'è ora?
4. Compare un account sospetto. Riesci a capire chi lo ha creato e cosa ha fatto subito dopo?
5. Un incidente coinvolge più sistemi. Riesci a costruire una cronologia chiara abbastanza in fretta da sostenere il preallarme di 24 ore dell'articolo 23?
6. Martedì scorso qualcuno ha cancellato un log di sicurezza. Lo sapresti e potresti dimostrare come lo sai?

Valuta te stesso e annota l'intervallo di date che testi. I team spesso superano il test per la settimana scorsa ma lo falliscono per lo scorso trimestre. Questa differenza è ciò che l'esercizio ti mostra. E "sì, ma ci sono voluti tre giorni e cinque team" è un fallimento. L'orologio delle 24 ore non si cura di quante persone ti siano servite.

Dove si inserisce Netwrix Auditor

Tutti e sei i test si riducono a un'unica capacità: una cronologia affidabile di chi ha modificato cosa, quando e com'era prima, conservata in un luogo che l'ambiente monitorato non possa riscrivere di nascosto.

Netwrix Auditor raccoglie l'attività di modifica, accesso e amministrazione da Active Directory, Entra ID, Microsoft 365, file server, SQL Server e altro in un proprio archivio di audit. La tua cronologia non dipende più da quanto a lungo un domain controller conserva i suoi log.

Esiste anche un pacchetto di report NIS2 che si allinea strettamente ai sei test. Ad esempio, Administrative Group Membership Changes copre il test 1 e Account Permissions Reports copre il test 2. Audit Log Clearing e Local Audit Policy Changes coprono il test 6, mentre Access to Archive Data mostra chi ha letto le evidenze stesse. Una guida di mappatura dei requisiti NIS2 ti aiuta a mostrare a un'autorità il collegamento tra ogni requisito e un report.

Nessuno strumento di audit ti rende conforme alla NIS2 da solo. L'articolo 21 copre molto più del monitoraggio, ma ogni sua misura deve prima o poi essere dimostrata, e la prova nasce dalle evidenze di audit. Senza di esse, un controllo funzionante e uno mancante appaiono uguali a un'autorità.

Le conclusioni

L'applicazione iniziale è un segnale di dove si stanno dirigendo le autorità europee. La conformità passa da ciò che dice la tua policy a ciò che sei in grado di dimostrare.

Quindi esegui i sei test puntandoli a una data di quattro mesi fa. Se qualcuno fallisce, rendi la correzione la priorità di questa settimana, prima che un'autorità renda quella stessa correzione più costosa.