Home › Monitoraggio eventi di sicurezza NIS2 SIEM: guida pratica

Monitoraggio eventi di sicurezza NIS2 SIEM: guida pratica

Il monitoraggio eventi di sicurezza NIS2 SIEM consiste nel raccogliere e correlare i log dei sistemi per rilevare tempestivamente attività anomale, e nel gestirle con una procedura documentata. La NIS2 non impone uno strumento preciso: chiede capacità di rilevazione adeguate al rischio. Un SIEM è la soluzione più diffusa, ma conta di più la politica che ne definisce scopo, responsabilità e tempi.

In questa guida vediamo cosa scrivere nella politica, quando un SIEM serve davvero e come valutare le alternative prima di acquistare.

Monitoraggio eventi di sicurezza NIS2 SIEM: cosa richiede la direttiva

La direttiva (UE) 2022/2555, recepita in Italia con il D.Lgs. 138/2024, richiede misure tecniche, operative e organizzative proporzionate ai rischi. Tra queste rientrano la gestione degli incidenti e la valutazione dell'efficacia delle misure adottate. Senza visibilità su ciò che accade nei sistemi, nessuna delle due è realistica.

Il testo è neutrale rispetto alla tecnologia. Non dice "installa un SIEM", ma pretende che l'organizzazione sappia accorgersi di un incidente, valutarlo e, se significativo, notificarlo nei tempi previsti. Per i dettagli operativi e le eventuali specifiche tecniche vale la pena consultare i documenti aggiornati dell'Autorità nazionale competente, perché possono precisare requisiti minimi di registrazione e rilevazione.

Perché il monitoraggio è un ponte tra più politiche

Il monitoraggio non vive da solo. Si collega alla gestione degli asset, perché non si può controllare ciò che non si conosce. Si collega alla gestione delle vulnerabilità, alla risposta agli incidenti e al controllo degli accessi. Per questo la politica va scritta in coerenza con le altre, come spiegato nella guida alla redazione di politiche e procedure NIS2.

Chi deve aderire a NIS2 e a chi serve il monitoraggio

La domanda ricorrente è: chi deve aderire a NIS2? Riguarda i soggetti essenziali e importanti che operano nei settori elencati dal decreto, in genere di dimensioni medie o grandi, con alcune eccezioni. Il perimetro va verificato caso per caso, in base a settore, dimensione e servizi erogati.

Se rientrate nel perimetro, il monitoraggio degli eventi vi riguarda a prescindere dalla grandezza. Cambia però la proporzione: una realtà con pochi sistemi può avere un presidio più snello di una con infrastrutture distribuite.

Cosa deve contenere la politica di monitoraggio

Una buona politica è breve, assegna responsabilità e rende verificabili le scelte. Dovrebbe includere almeno questi elementi:

• Scopo e perimetro: quali sistemi, reti e servizi sono monitorati, in raccordo con l'inventario degli asset.
• Fonti di log: autenticazioni, firewall, VPN, posta, endpoint, applicazioni critiche e servizi cloud.
• Ruoli e responsabilità: chi analizza gli avvisi, chi decide l'escalation, chi risponde del processo verso la direzione.
• Casi d'uso di rilevazione: le situazioni da individuare, come accessi anomali, privilegi elevati o disattivazione di protezioni.
• Conservazione e protezione dei log: durata definita dall'analisi del rischio e dagli obblighi applicabili, con controlli contro la manomissione.
• Sincronizzazione oraria: senza orari coerenti, ricostruire un incidente diventa molto difficile.
• Riesame periodico: frequenza di revisione di regole, soglie e copertura.

Ricordate che i log possono contenere dati personali. La politica deve quindi tenere conto anche dei vincoli sulla protezione dei dati, senza sacrificare la capacità di rilevazione.

Quando serve davvero un SIEM

Un SIEM aggrega log da fonti diverse, li normalizza, applica regole di correlazione e genera avvisi. Il valore nasce quando gli eventi sono tanti, eterogenei e distribuiti, e nessuna persona potrebbe leggerli a mano. Nel monitoraggio eventi di sicurezza NIS2 SIEM è spesso la scelta naturale per organizzazioni con più sedi, ambienti ibridi o servizi digitali critici.

Non è però sempre il primo passo. Se i log non vengono raccolti con ordine o nessuno è incaricato di leggere gli avvisi, il software resta una spesa senza effetto. Prima conviene stabilire processo e responsabilità, poi scegliere lo strumento.

Criteri per valutare un SIEM

Nel confronto tra offerte, chiedete risposte verificabili e fate una prova su dati reali. Questi sono i punti da esaminare:

• copertura dei connettori per i vostri sistemi effettivi, inclusi cloud e applicazioni specifiche;
• qualità delle regole di rilevazione già disponibili e facilità di personalizzarle;
• gestione del volume dei log e modello di costo, per evitare sorprese con la crescita dei dati;
• funzioni di indagine, ricerca e reportistica utili anche in sede di audit;
• localizzazione dei dati e condizioni contrattuali, in particolare se il servizio è gestito da un fornitore esterno;
• competenze richieste per gestirlo giorno per giorno.

Non fidatevi di confronti generici. Chiedete una dimostrazione con i vostri scenari e verificate quanto lavoro di configurazione ricade su di voi.

SIEM interno o servizio gestito

La differenza vera non è nello strumento ma nelle persone. Un presidio interno dà controllo e conoscenza del contesto, ma richiede competenze e copertura nel tempo. Un servizio gestito, o un SOC esterno, riduce il carico operativo, ma introduce un fornitore critico da governare.

In questo caso entra in gioco la sicurezza della filiera: contratti, livelli di servizio e obblighi di notifica vanno definiti con chiarezza. Approfondite il tema nella guida sulla sicurezza della catena di fornitura nella NIS 2.

La procedura: dall'evento all'incidente

La politica dice cosa fare e perché; la procedura spiega come. Un flusso essenziale può essere questo:

1. Raccolta: i log arrivano in modo continuo e protetto dalle fonti definite.
2. Rilevazione: le regole generano avvisi su comportamenti sospetti.
3. Triage: un analista valuta se l'avviso è un falso positivo o un evento reale, registrando la decisione.
4. Classificazione: si stabilisce se l'evento è un incidente e quanto è grave, con criteri scritti in anticipo.
5. Escalation e notifica: si attiva la risposta agli incidenti. Per gli incidenti significativi la NIS2 prevede obblighi di notifica con tempi stringenti, da verificare nel decreto e nelle indicazioni dell'Autorità.
6. Chiusura e miglioramento: si documentano cause e azioni, e si aggiornano regole e procedure.

Il punto di contatto con la gestione delle vulnerabilità è diretto: un avviso può rivelare lo sfruttamento di una falla non ancora corretta. Vedete come impostare quel processo nella procedura di gestione delle vulnerabilità secondo la NIS 2.

Errori comuni da evitare

Il primo è raccogliere tutto senza criterio. Un volume enorme di dati genera costi e rumore, e finisce per nascondere i segnali importanti. Meglio partire dai sistemi critici e crescere in base al rischio.

Il secondo è non assegnare responsabilità. Se nessuno è tenuto a leggere gli avvisi fuori orario o nei giorni festivi, la capacità di rilevazione esiste solo sulla carta. Decidete in anticipo la copertura e l'escalation.

Il terzo è non produrre evidenze. In un audit servono prove: elenco delle fonti, regole attive, registro degli avvisi trattati, verifiche periodiche. Conservarle in modo ordinato fa risparmiare molto tempo.

Infine, non dimenticate le persone. Molti incidenti iniziano da un messaggio ingannevole, e la formazione aiuta a segnalarli prima che producano effetti: leggete anche il nostro approfondimento sul phishing e sulla formazione del personale richiesta dalla NIS 2.

Conclusione

Il monitoraggio efficace nasce da una politica chiara, da responsabilità definite e da fonti di log scelte in base al rischio. Il SIEM è un ottimo alleato quando c'è un processo che lo sostiene, non un sostituto di quel processo. Prima di scegliere, mappate asset e scenari, poi valutate gli strumenti su casi concreti.

Se volete inserire questo tassello in un percorso di conformità ordinato, scoprite come affrontare l'adeguamento NIS 2 in modo strutturato con DirettivaNIS2.

Domande frequenti