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 e la Germania lo recepisce nel §30(2)(2) BSIG. Per i fornitori digitali che copre, il punto 3.2 del CIR nomina dodici tipi di eventi e le regole operative.
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 punto 3.2 riempie il dettaglio per i fornitori digitali elencati nell'art. 1 CIR (DNS, TLD, cloud, data center, CDN, MSP, MSSP, marketplace online, motori di ricerca, social network, servizi fiduciari). Ove appropriato, i log coprono dodici tipi di eventi; il soggetto fissa le soglie di allarme e il proprio periodo di conservazione, mantiene sincronizzate le fonti di tempo e gestisce il monitoraggio in modo ridondante. Per gli altri soggetti questo dettaglio non è un obbligo di legge; in Germania solo i gestori di impianti critici devono gestire sistemi di rilevamento degli attacchi (§ 31 Abs. 2 BSIG).
La Germania recepisce la misura nel §30(2)(2) BSIG. IT-Grundschutz offre OPS.1.1.5 'Protokollierung' e DER.1 'Detektion' come elementi di base; sono raccomandazioni, non un livello minimo di legge. 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 pertinenti devono stabilire procedure e utilizzare strumenti per monitorare e registrare le attività sui loro sistemi informativi e di rete al fine di individuare eventi che potrebbero essere considerati incidenti e rispondervi di conseguenza per attenuarne l'impatto.
Poiché si tratta di un regolamento (non di una direttiva), è diritto dell'UE direttamente vincolante per i tipi di soggetto elencati nel suo art. 1 (DNS, TLD, cloud, data center, CDN, MSP, MSSP, marketplace online, motori di ricerca, social network, servizi fiduciari). Il punto 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. IT-Grundschutz offre OPS.1.1.5 'Protokollierung' e DER.1 'Detektion von sicherheitsrelevanten Ereignissen' come elementi di base; sono raccomandazioni, non un livello minimo di legge.
Registrare i dodici tipi di eventi
Costruite l'elenco degli asset da registrare a partire dalla vostra valutazione del rischio. 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 punto 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 punto 3.2.3(k) elenca 'attivazione, arresto e sospensione dei vari log' come qualcosa da registrare.
Esaminare i log è il punto, non un optional
Per i fornitori digitali coperti dal CIR, il punto 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. Tenete traccia di chi ha esaminato quali allarmi, quando e cosa ha fatto al riguardo.
BSI / IT-Grundschutz OPS.1.1.5 + DER.1
IT-Grundschutz offre OPS.1.1.5 'Protokollierung' (cosa registrare, conservazione, protezione) e DER.1 'Detektion von sicherheitsrelevanten Ereignissen' (allarmi e risposta) come elementi di base; sono raccomandazioni, non un livello minimo di legge.
ENISA Technical Implementation Guidance
La TIG di ENISA fornisce indicazioni ed esempi di prove per il punto 3.2, compresi esempi di soglie di allarme, e indica che il periodo di conservazione si fissa in base alle esigenze aziendali, alla valutazione del rischio e ai requisiti di legge. La sua tabella di mappatura collega il 3.2 a ISO/IEC 27001:2022 A.5.28, A.8.15, A.8.16 e A.8.17; ENISA precisa che la mappatura non è una misura di equivalenza.
Leggi nazionali di trasposizione
Ogni Stato membro ha la propria trasposizione (Paesi Bassi: Cyberbeveiligingswet; Austria: NISG 2026; Belgio: la sua legge NIS2). Il punto 3.2 CIR si applica direttamente in ogni Stato membro, ma solo ai fornitori digitali elencati nell'art. 1 CIR. Ciò che differisce: con quale autorità nazionale parlate e come vengono gestiti localmente notifica e vigilanza.
Conserviamo tutti i log per sempre, quindi siamo a posto.
Per i fornitori digitali coperti dal CIR, il punto 3.2.5 richiede un periodo di conservazione predefinito, non uno infinito. Per tutti, 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. Per i fornitori digitali coperti dal CIR, il punto 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 punto 3.2.4.
Registriamo l'attività degli utenti ma non quella degli amministratori.
Per i fornitori digitali coperti dal CIR, il punto 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, quindi la loro attività va nei log.
L'inizio più economico: costruite l'elenco degli asset da registrare a partire dalla vostra valutazione del rischio, convogliate i log in un unico punto (un archivio centrale di log o un piccolo SIEM), fissate soglie sugli eventi più importanti ed esaminateli regolarmente. Non vi serve un SOC gestito fin dal primo giorno. Vi serve qualcuno che guardi gli allarmi e sappia cosa fare.
- 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 (versione 1.0, giugno 2025)
Ti hanno affidato NIS2?
Ti guidiamo passo dopo passo. Tu compili, noi spieghiamo ogni punto con parole semplici, e alla fine firma la direzione.
