Logging e monitoraggio NIS 2 ai sensi dell'articolo 21(2)(b)
Il logging è lo strato di visibilità della gestione degli incidenti. L'articolo 21(2)(b) è dove risiede il dovere, il CIR §3.2 nomina i dodici tipi di eventi e le regole operative, e la Germania inserisce la stessa regola nel §30(2)(2) BSIG.
La versione breve
Il logging e il monitoraggio non sono un dovere separato ai sensi di NIS 2. Si collocano all'interno della misura di gestione degli incidenti dell'articolo 21(2)(b). La logica è semplice: se non potete vedere cosa accade sulla vostra rete, non potete rilevare un incidente di sicurezza e non potete contenerlo.
Il CIR (UE) 2024/2690 §3.2 riempie il dettaglio. Nomina dodici tipi di eventi che dovete registrare, fissa le regole per gli allarmi e la risposta qualificata, stabilisce un periodo di conservazione definito e richiede sistemi con sincronizzazione temporale più un monitoraggio ridondante. Questo è il livello minimo per i settori nominati nell'Annex del CIR.
La Germania inserisce la stessa regola nel §30(2)(2) BSIG. La base pratica è IT-Grundschutz OPS.1.1.5 'Protokollierung' e DER.1 'Detektion'. Questa pagina percorre la direttiva, il regolamento attuativo dell'UE e la trasposizione tedesca in quest'ordine.
Articolo 21(2)(b) della direttiva NIS 2 (2022/2555)
Gestione degli incidenti.
Questo è il punto (b) nell'elenco delle dieci misure di cibersicurezza che ogni soggetto essenziale e importante deve attuare. Il CIR §3 lo rende poi operativo. Il logging e il monitoraggio si collocano all'interno del §3.2.
CIR (UE) 2024/2690, Annex §3.2.1
I soggetti interessati stabiliscono procedure e utilizzano strumenti per monitorare e registrare le attività sui loro sistemi informatici e di rete affinché gli eventi che potrebbero essere considerati incidenti di sicurezza possano essere rilevati e affrontati per contenerne l'impatto.
Poiché si tratta di un regolamento (non di una direttiva), è diritto dell'UE direttamente vincolante. Il §3.2 si articola poi in sette sottopunti che coprono i tipi di eventi da registrare, gli allarmi, la conservazione, la sincronizzazione temporale e la ridondanza. Non occorre alcuna trasposizione nazionale.
§30(2)(2) BSIG (Germania)
Gestione degli incidenti.
La Germania copia il testo dell'UE parola per parola. Il 'come' pratico arriva attraverso IT-Grundschutz: OPS.1.1.5 'Protokollierung' per la progettazione del logging, e DER.1 'Detektion' per il lato allarmi e risposta.
Registrare i dodici tipi di eventi
Costruite l'elenco rispetto al vostro inventario degli asset. Ove appropriato, acquisite: traffico di rete in entrata e in uscita, modifiche di utenti e privilegi, accessi a sistemi e applicazioni, eventi di autenticazione, tutte le attività privilegiate e di amministrazione, accessi a file critici di configurazione o backup, log degli strumenti di sicurezza (AV, IDS, firewall), uso delle risorse di sistema, accessi fisici, uso delle apparecchiature di rete, attivazione o sospensione dei log stessi ed eventi ambientali.
Revisione, allarme, risposta qualificata
Raccogliere i log non basta. Esaminateli con cadenza regolare alla ricerca di tendenze insolite o indesiderate. Ove appropriato, fissate delle soglie. Quando una soglia viene superata, fate scattare un allarme automatico. E assicuratevi che qualcuno di qualificato risponda effettivamente in tempo. L'archiviazione senza revisione non costituisce logging ai sensi del §3.2.
Proteggere, conservare, sincronizzare nel tempo, rendere ridondante
I log stessi sono prove. Conservateli per un periodo di conservazione definito, proteggeteli da accessi e modifiche non autorizzati, sincronizzate nel tempo tutti i sistemi affinché gli eventi possano essere correlati e fate funzionare il sistema di monitoraggio in modo ridondante. Il monitoraggio del sistema di monitoraggio è esso stesso indipendente dai sistemi che monitora.
I log sono un asset, non un sottoprodotto
Il §3.2.5 tratta i log come dati critici. Periodo di conservazione definito, protezione dalla manomissione, protezione dagli accessi non autorizzati. Se un attaccante può cancellare i log che mostrano cosa ha fatto, il dovere di logging non è soddisfatto. È anche il motivo per cui il §3.2.3(k) elenca esplicitamente 'attivazione, disattivazione o sospensione' dei log come un evento che dovete registrare.
Esaminare i log è un dovere, non un optional
Il §3.2.4 richiede controlli regolari per le tendenze insolite, soglie ove appropriato, allarmi automatici al superamento delle soglie e una risposta qualificata tempestiva. Un SIEM che nessuno guarda non soddisfa questo. Un auditor chiederà chi ha esaminato quali allarmi, quando e cosa ha fatto al riguardo.
BSI / IT-Grundschutz OPS.1.1.5 + DER.1
Il BSI indica IT-Grundschutz come via pratica. OPS.1.1.5 'Protokollierung' è dove risiede la progettazione del logging (cosa registrare, conservazione, protezione). DER.1 'Detektion' copre il lato allarmi e risposta (cadenza di revisione, regole SIEM, gestione qualificata). I due insieme si mappano sul CIR §3.2.
ENISA Technical Implementation Guidance
La TIG di ENISA fornisce esempi concreti di prove per il §3.2: modelli di politica di logging, soglie di allarme di esempio, valori predefiniti di conservazione e una mappatura sull'Annex A della ISO/IEC 27001:2022 (A.8.15 Logging, A.8.16 Monitoring activities). Se già usate la ISO 27001, riutilizzate la maggior parte dei controlli.
Leggi nazionali di trasposizione
Ogni Stato membro ha la propria trasposizione (Paesi Bassi: Cyberbeveiligingswet, Austria: NISG, Belgio: NIS2-Wet). Il dovere del §3.2 è lo stesso perché il CIR è direttamente applicabile. Ciò che differisce: con quale autorità nazionale parlate e come vengono gestiti localmente i canali di notifica e le cadenze di audit.
Conserviamo tutti i log per sempre, quindi siamo a posto.
Il §3.2.5 richiede un periodo di conservazione definito, non uno infinito. Conservare tutto per sempre è un problema di protezione dei dati (Art. 5(1)(e) GDPR, limitazione della conservazione) e un problema di costi. Decidete una finestra di conservazione per tipo di log, scrivetela, giustificatela rispetto al vostro quadro di rischio e attenetevi a essa.
Il SIEM ce l'ha, quindi siamo a posto.
Vicino, ma non del tutto. Il §3.2.4 non richiede solo l'archiviazione. Richiede revisione regolare, soglie ove appropriato, allarmi automatici al superamento e una persona qualificata che risponda effettivamente. Un SIEM che funziona senza regole, o con regole che nessuno calibra, non soddisfa il §3.2.4.
Registriamo l'attività degli utenti ma non quella degli amministratori.
Il §3.2.3(e) è esplicito: tutti gli accessi privilegiati a sistemi e applicazioni più le attività degli account amministrativi. Gli amministratori sono gli utenti a maggiore impatto sulla vostra rete. Non registrarli è la lacuna che un auditor trova per prima.
Quello che vediamo nella pratica: la maggior parte delle aziende del Mittelstand ha i log del firewall e i log di Active Directory. Raramente hanno coperti sistematicamente i dodici tipi di eventi del §3.2.3. Accessi privilegiati, modifiche ai file di configurazione e accessi fisici sono le tre lacune ricorrenti.
La correzione più economica: costruite l'elenco del §3.2.3 rispetto al vostro inventario degli asset (RSK 2.2), convogliate tutto in un unico punto (un archivio centrale di log o un piccolo SIEM), fissate soglie sugli eventi di alto valore ed esaminate settimanalmente. Non vi serve un SOC gestito fin dal primo giorno. Vi serve qualcuno che guardi gli allarmi e sappia cosa fare.
Il modulo INC copre la strategia di logging del §3.2: quali tipi di eventi registrate, rispetto a quali asset, con quale finestra di conservazione. La scrivete una volta, la firmate e diventa la vostra politica di logging pronta per l'audit.
Il modulo EFF copre il lato revisione del §3.2.4: soglie di allarme, cadenza di revisione, prove di risposta qualificata. Le firme e la traccia di audit mostrano a un auditor che qualcuno ha guardato gli allarmi e vi ha agito. Nessuna pila di fogli di calcolo. Nessun secondo strumento.
- Direttiva (UE) 2022/2555 (NIS 2), articolo 21(2)(b) — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Regolamento di esecuzione (UE) 2024/2690 della Commissione (CIR), Annex §3.2 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- Legge sul BSI (BSIG), §30(2)(2) come modificata dalla legge di attuazione di NIS2 e di rafforzamento della cibersicurezza
- IT-Grundschutz Kompendium, OPS.1.1.5 'Protokollierung' e DER.1 'Detektion' — bsi.bund.de/grundschutz
- ENISA Technical Implementation Guidance per il CIR (UE) 2024/2690 (al maggio 2026)