Per adeguare i log alla NIS2, una PMI deve centralizzare i log critici, garantire timestamp sincronizzati e definire una policy di retention basata sul rischio. La priorità è inventariare gli asset, raccogliere i log in un unico punto e mantenerli integri e accessibili in tempi rapidi. L’implementazione è realizzabile in 2-3 mesi, con un costo annuo di outsourcing SIEM compreso tra 3.000 e 15.000 euro.
In breve:
- La sincronizzazione temporale tra sistemi è fondamentale per ricostruire correttamente gli eventi di un attacco, per cui è consigliato configurare un server NTP interno affidabile.
- Una policy di retention di almeno 12 mesi, insieme a pratiche di integrità come hash e supporti non modificabili, garantisce la correttezza e l’accessibilità dei log durante un incidente.
- La priorità di raccolta log deve concentrarsi su accessi agli asset critici, modifiche di privilegio e attività di backup, fondamentali per una risposta rapida alle emergenze.
- La responsabilità di pre-notificare un incidente al CSIRT entro 24 ore e di inviare la notifica completa entro 72 dipende dalla disponibilità immediata di log affidabili e ben strutturati.
- Per una PMI, il costo di un outsourcing SIEM con politiche di retention gestita si stimano tra 3.000 e 15.000 euro l’anno, con un’implementazione in 2-3 mesi e focus sulla copertura degli asset più critici.
Indice
- Perché la gestione dei log è centrale per NIS2 e per la risposta agli incidenti
- Quali sono i requisiti tecnici essenziali per i log NIS2
- Retention, integrità e disponibilità: le tre colonne di una policy efficace
- Come i log supportano i tempi di notifica a CSIRT e ACN
- Checklist operativa e stime per le PMI
- Quali tecnologie scegliere: SIEM, server centralizzati, open source o outsourcing
- Come ReportIA aiuta le PMI a strutturare il logging per NIS2
- La nostra prospettiva su compliance e operatività nelle PMI
- Come iniziare con ReportIA per mettere in ordine il logging
- Domande frequenti
- Fonti
Perché la gestione dei log è centrale per NIS2 e per la risposta agli incidenti
I log sono la prova materiale che permette di ricostruire un attacco, capire cosa è stato compromesso e dimostrare agli organi di controllo che le misure di sicurezza erano attive. Senza una registrazione affidabile degli eventi, qualsiasi notifica al CSIRT rischia di restare generica e difficile da sostenere in sede di verifica.
Il vero salto di qualità avviene quando i log non restano isolati per sistema ma vengono correlati:
- i log del firewall rivelano traffico anomalo in ingresso o uscita
- i log degli endpoint segnalano processi sospetti o malware
- i log di Active Directory mostrano tentativi di privilege escalation
- i log applicativi completano il quadro con l’attività a livello di dato
Le indicazioni dell’Agenzia per la Cybersicurezza Nazionale chiariscono che il log management è il nucleo operativo dell’incident response: senza correlazione automatica diventa difficile rispettare i tempi di notifica e dimostrare la conformità richiesta dalla direttiva.
Quali sono i requisiti tecnici essenziali per i log NIS2
Il Regolamento di esecuzione (UE) 2024/2690 definisce con precisione cosa va registrato e come. Le misure 3.2.1-3.2.6 indicano gli asset da monitorare e le modalità di sincronizzazione temporale, un dettaglio che spesso viene sottovalutato ma che è decisivo per ricostruire la sequenza esatta di un attacco su più sistemi.
Gli eventi minimi da registrare, secondo un ordine di priorità pratico, sono:
- accessi riusciti e falliti a sistemi critici e account amministrativi
- modifiche ai privilegi e creazione di nuovi account con diritti elevati
- modifiche alla configurazione di firewall, server e apparati di rete
- alert generati da antivirus ed endpoint protection
- esiti dei job di backup, compresi fallimenti e anomalie
La misura 3.2.6 del regolamento richiede, ove fattibile, la sincronizzazione delle sorgenti temporali: senza un orologio comune tra i sistemi, correlare eventi provenienti da fonti diverse diventa quasi impossibile. Conservazione sicura, cifratura dei log a riposo e controllo rigoroso di chi può accedervi o modificarli completano il quadro tecnico.
Un consiglio: configura un server NTP interno sincronizzato con una fonte affidabile e verifica periodicamente lo scarto temporale tra i sistemi che generano log.
Retention, integrità e disponibilità: le tre colonne di una policy efficace
Una policy di log realmente utile si regge su tre pilastri che vanno definiti insieme, non uno alla volta.
- retention: una finestra di conservazione di almeno 12 mesi è una base prudente per supportare audit e indagini successive a un incidente
- integrità: hashing periodico, esportazione su supporti non riscrivibili (WORM) e firme di timestamping impediscono alterazioni, anche accidentali
- disponibilità: ridondanza dei sistemi di raccolta e una procedura di accesso d’emergenza al SIEM garantiscono che i log siano consultabili anche durante un incidente in corso
Il Garante per la protezione dei dati personali richiede che le registrazioni degli accessi degli amministratori di sistema siano complete, inalterabili e conservate per un periodo non inferiore a sei mesi, con verifiche periodiche della loro attività: un vincolo minimo che molte PMI già devono rispettare indipendentemente dalla NIS2, e che si integra naturalmente con una policy più ampia tarata sul rischio.
Come i log supportano i tempi di notifica a CSIRT e ACN
Le scadenze non lasciano margine di improvvisazione. Secondo le FAQ dell’ACN su misure di sicurezza e notifica degli incidenti, i soggetti NIS devono pre-notificare un incidente significativo entro 24 ore e inviare la notifica completa entro 72 ore: rispettare questi termini dipende quasi interamente dalla disponibilità immediata di log integri e consultabili.
Nelle prime 24 ore, il team tecnico deve poter estrarre rapidamente:
- l’elenco dei sistemi e degli account coinvolti, ricostruito dai log di accesso
- la cronologia delle modifiche di configurazione rilevanti nel periodo sospetto
- gli alert di sicurezza generati da firewall ed endpoint nelle ore precedenti
La responsabilità operativa va assegnata in anticipo: chi nel team IT estrae i log, chi redige la notifica e chi la invia formalmente al CSIRT sono tre ruoli che vanno definiti prima che accada l’emergenza, non durante.
Checklist operativa e stime per le PMI
Mettere in produzione un sistema di log conforme segue una sequenza precisa e non richiede necessariamente un team di sicurezza interno.
- censire gli asset critici (server, firewall, AD, backup) e stabilire quali eventi registrare per ciascuno
- centralizzare i log in un unico repository, con invio automatico da ogni sorgente
- attivare hashing e procedure di esportazione su supporti non modificabili
- definire e documentare per iscritto la policy di retention, collegandola all’analisi del rischio
- pianificare revisioni periodiche degli alert e test di ripristino dei backup
I tempi tipici per centralizzazione e definizione delle policy si attestano su 2-3 mesi, mentre la revisione degli alert diventa un’attività ricorrente mensile o trimestrale. Il costo di un servizio di outsourcing SIEM con retention gestita si colloca tra i 3.000 e i 15.000 euro l’anno, a seconda del numero di sorgenti e del volume di eventi; un’alternativa open source riduce la spesa diretta ma sposta il costo sul tempo del personale interno necessario per manutenzione e aggiornamenti.
Un consiglio: parti dagli asset che generano il rischio più alto (AD, firewall perimetrali, backup) prima di estendere la raccolta log a sistemi secondari.
Quali tecnologie scegliere: SIEM, server centralizzati, open source o outsourcing
Il mercato italiano offre quattro famiglie di soluzioni, ciascuna con un profilo di costo e complessità diverso.
- SIEM gestiti in SaaS: riducono il carico operativo interno e offrono correlazione pronta all’uso, a fronte di un canone ricorrente
- server di log centralizzati on-premise: danno pieno controllo sui dati ma richiedono competenze interne per la manutenzione
- soluzioni open source con log-shipping: abbattono i costi di licenza ma spostano l’onere su configurazione e aggiornamenti
- outsourcing con retention gestita: delega la conservazione e l’integrità a un fornitore terzo, utile quando mancano risorse dedicate alla sicurezza
Nella scelta contano soprattutto tre criteri: la capacità di integrarsi con i sistemi già in uso, il costo totale di gestione nel tempo e il supporto nativo per timestamp sincronizzati e immutabilità dei dati. L’integrazione con l’IAM aziendale, in particolare, è ciò che trasforma un log da semplice traccia tecnica a prova verificabile: associare un evento a un’identità reale, non solo a uno username, rende la tracciabilità difendibile in sede di audit.
Come ReportIA aiuta le PMI a strutturare il logging per NIS2
All’interno della nostra suite, ReportIA mette a disposizione funzioni di audit trail e logging che tracciano ogni accesso e modifica con dettaglio verificabile. La gestione di utenti e ruoli con permessi granulari collega ogni evento a un’identità specifica, un requisito che semplifica la dimostrazione di conformità in sede di audit.
La nostra prospettiva su compliance e operatività nelle PMI
Il principio di proporzionalità esiste proprio perché non tutte le PMI hanno le stesse risorse di un gruppo industriale, e questo va detto chiaramente a chi deve giustificare un budget al management. La priorità non è comprare lo strumento più completo sul mercato, ma coprire per primi gli asset che generano il rischio reale: accessi amministrativi, backup, perimetro di rete. Una policy di log ben fatta non è solo un adempimento: migliora la capacità di individuare anomalie operative prima ancora che diventino incidenti di sicurezza.
— Ufficio
Come iniziare con ReportIA per mettere in ordine il logging
Strutturare un sistema di log conforme alla NIS2 richiede un punto di partenza chiaro, non un progetto infinito. Con ReportIA partiamo da un audit dello stato attuale e costruiamo insieme la configurazione per centralizzare le sorgenti, impostare la retention corretta e collegare ogni log a un’identità verificata tramite i permessi granulari della piattaforma.
Un intervento tipico include:
- analisi degli asset da loggare in base al rischio specifico dell’azienda
- configurazione della raccolta centralizzata e della sincronizzazione temporale
- definizione scritta della policy di retention e delle procedure di accesso d’emergenza
- integrazione con i sistemi di identità già in uso per rendere ogni log attribuibile
Per le aziende che vogliono affrontare la conformità in modo più ampio, la nostra pagina cybersecurity e sicurezza informatica raccoglie i servizi di audit e adeguamento NIS2 disponibili. Possiamo organizzare una valutazione iniziale per capire da dove partire.
Domande frequenti
Qual è la retention minima dei log richiesta dalla NIS2?
Non esiste un numero unico fissato dalla direttiva: la retention va calibrata sul rischio specifico dell’azienda. Una base prudente è una conservazione di almeno 12 mesi per i log critici, mentre il Garante Privacy richiede almeno sei mesi per le registrazioni degli accessi degli amministratori di sistema.
Quali log devono essere raccolti per prima per NIS2?
Gli asset con priorità più alta sono accessi amministrativi, Active Directory, firewall perimetrali e sistemi di backup, perché generano l’evidenza più rilevante in caso di incidente. Il Regolamento di esecuzione (UE) 2024/2690 dettaglia gli eventi minimi da registrare nelle misure 3.2.1-3.2.6.
Chi deve inviare la notifica al CSIRT in caso di incidente?
La responsabilità operativa va assegnata in anticipo all’interno del team IT o di sicurezza, con ruoli distinti per chi estrae i log, chi redige la notifica e chi la invia. Le FAQ dell’ACN chiariscono che la pre-notifica va inviata entro 24 ore e la notifica completa entro 72 ore.
Quanto costa adeguare il log management alla NIS2 per una PMI?
Un servizio di outsourcing SIEM con retention gestita costa indicativamente tra 3.000 e 15.000 euro l’anno, a seconda del numero di sorgenti da monitorare. L’implementazione completa, dalla centralizzazione alla policy di retention, richiede in genere 2-3 mesi.
Fonti
- Regolamento di esecuzione (UE) 2024/2690 — misure tecniche e metodologiche
- Garante per la protezione dei dati personali — Misure e accorgimenti per registrazione accessi
