Punti chiave
- SIEM significa Security Information and Event Management: una piattaforma che raccoglie, normalizza, correla e analizza eventi di sicurezza.
- Il valore non è solo conservare log. Un SIEM trasforma i log in rilevamento, indagine ed evidenza di conformità.
- NIST SP 800-92 tratta la gestione dei log come un processo enterprise, con infrastruttura, operatività e manutenzione.
- Per NIS 2, un SIEM può supportare rilevamento, gestione incidenti, retention delle evidenze e reporting di governance.
- SIEM è diverso da EDR, SOAR e XDR, anche se gli strumenti moderni spesso si sovrappongono.
- Soluzioni SIEM open source come Wazuh possono essere adatte alle PMI quando progettazione, tuning e presidio operativo sono chiari.
Ambito di questo articolo
Questo articolo definisce il SIEM, spiega l'architettura tipica, confronta categorie di strumenti vicine e collega le capacità SIEM alle attese NIS 2 e alle misure di base ACN. È pensato per direzione, IT e compliance.
Cos'è un SIEM
Un SIEM è una piattaforma di sicurezza che raccoglie log ed eventi rilevanti da sistemi, applicazioni, identità, dispositivi di rete e servizi cloud. Normalizza questi eventi, li correla tramite regole o analisi e produce alert, dashboard e report.
L'acronimo significa Security Information and Event Management. La parte information management riguarda raccolta, retention e ricerca. La parte event management riguarda rilevamento, correlazione ed escalation. Servono entrambe: conservare log senza capacità di indagine è archivio; generare alert senza copertura affidabile è fragile.
NIST SP 800-92 descrive la gestione dei log di sicurezza come una disciplina pratica per sviluppare, implementare e mantenere pratiche efficaci di log management a livello enterprise (NIST SP 800-92).
Che problema risolve un SIEM
Un SIEM riduce la distanza tra eventi distribuiti nell'ambiente e capacità di rilevarli, indagarli e provarli. Senza gestione centralizzata, le evidenze restano disperse tra server, endpoint, firewall, console SaaS e sistemi di identità. Questa frammentazione rallenta le indagini e indebolisce l'auditabilità.
- Rilevamento minacce: individua sequenze sospette su più sorgenti.
- Indagine incidenti: permette ricerche per account, host, indirizzo IP o finestra temporale.
- Evidenza di conformità: mostra che monitoraggio e retention funzionano.
- Visibilità operativa: evidenzia attività privilegiate, errori e accessi anomali.
Come funziona un SIEM: architettura tipica
Un'architettura SIEM pratica segue un flusso ripetibile:
- Sorgenti: endpoint, server, identità, firewall, EDR, workload cloud, SaaS e applicazioni critiche.
- Ingestion: agent, syslog, API, connettori cloud o collector inviano eventi al SIEM.
- Normalizzazione: i log grezzi diventano campi coerenti.
- Correlazione: regole e analytics collegano eventi deboli se presi singolarmente.
- Alerting: pattern sospetti generano alert per la triage.
- Indagine: gli analisti cercano, collegano e ricostruiscono timeline.
- Reporting: report di compliance e gestione mostrano copertura e attività.
In una PMI conviene partire dalle sorgenti ad alto valore: identità, firewall, endpoint protection, server critici, log amministrativi cloud, sistemi di backup e applicazioni essenziali. La copertura si amplia poi per priorità di rischio.
SIEM, log management, EDR, SOAR e XDR
| Strumento | Ruolo principale | Output tipico | Differenza dal SIEM |
|---|---|---|---|
| Log management | Raccoglie, conserva e ricerca log | Evidenza consultabile | Può non includere correlazione o alerting avanzato |
| SIEM | Correla eventi e supporta il rilevamento | Alert, dashboard, indagini | È il livello centrale tra molte sorgenti |
| EDR | Monitora e risponde sugli endpoint | Telemetria e azioni endpoint | Vista profonda sull'endpoint, non sempre correlazione enterprise |
| SOAR | Automatizza workflow di risposta | Playbook e gestione casi | Agisce su alert, spesso da SIEM o EDR |
| XDR | Correla telemetria su livelli selezionati | Detection and response integrata | Spesso dipende dall'ecosistema vendor |
Perché un SIEM serve per la conformità NIS 2
NIS 2 e il quadro italiano di attuazione insistono su gestione del rischio, gestione incidenti e monitoraggio della sicurezza. Il decreto NIS italiano recepisce obblighi di governance e incident management, mentre le misure di base ACN traducono alcune attese in controlli più operativi per i soggetti NIS italiani (Decreto Legislativo 138/2024, determinazione ACN sugli obblighi di base).
Un SIEM non rende conforme l'organizzazione da solo. Supporta però esigenze specifiche: centralizzazione log, copertura di monitoraggio, triage degli alert, ricostruzione della timeline di incidente e reporting. Per approfondire, leggi gli articoli Aegister su rilevamento e monitoraggio eventi e registri operativi, log e backup.
SIEM commerciale vs SIEM open source
I SIEM commerciali offrono supporto vendor, connettori pronti, analytics gestiti e procurement più prevedibile. Le opzioni open source possono ridurre vincoli di licenza e aumentare trasparenza, ma richiedono più disciplina implementativa.
Wazuh è una soluzione open source usata per file integrity monitoring, vulnerability detection, endpoint security, analisi log e monitoraggio orientato alla compliance. Parti dalla panoramica Wazuh per la NIS 2, poi leggi la guida al deployment, l'articolo sulla gestione centralizzata dei log e il confronto tra Wazuh e SIEM commerciali.
Quando una PMI italiana ha bisogno di un SIEM
Una PMI dovrebbe valutare un SIEM quando rientra nel perimetro NIS 2, gestisce dati regolati, eroga servizi critici, ha finding ricorrenti sui log, non possiede evidenze di incidente o opera in ambienti cloud ed endpoint frammentati.
La decisione deve includere budget per onboarding sorgenti, retention, tuning regole, proprietà degli alert e workflow di incidente. Un SIEM senza presidio diventa shelfware; una copertura più piccola ma gestita produce più valore di una copertura ampia ma non governata.
Cosa serve per implementare un SIEM
- inventario delle sorgenti e policy di retention;
- responsabilità chiare per onboarding e qualità dei parser;
- regole mappate a minacce realistiche ed evidenze di conformità;
- playbook di triage e soglie di escalation;
- revisione periodica di alert rumorosi e rilevamenti mancati;
- reporting verso il management collegato al rischio business.
Quando conviene un servizio gestito
Molte PMI non devono assumere un SOC completo prima di adottare rilevamento centralizzato. Un approccio gestito può definire l'architettura SIEM, collegare le sorgenti prioritarie, regolare gli alert e trasformare i finding in roadmap di governance. Aegister supporta questo percorso con servizi Virtual CISO e tracciamento operativo nella Cyber Console.
Sorgenti log minime da cui partire
Un progetto SIEM non dovrebbe iniziare importando ogni evento possibile. Questo crea costo, rumore e fatica operativa. Conviene partire dalle sorgenti che spiegano identità, perimetro, sistemi critici e capacità di ripristino.
| Sorgente | Perché conta | Domande tipiche |
|---|---|---|
| Identity provider | Molti attacchi coinvolgono credenziali o privilegi | Chi ha effettuato accesso, da dove e con quale privilegio? |
| Firewall e VPN | Mostrano attività perimetrali e accessi remoti | Quali connessioni sono state consentite, negate o anomale? |
| Endpoint protection | Collega alert a host e utenti | Quale dispositivo ha eseguito l'attività sospetta? |
| Server critici | Proteggono i sistemi che supportano servizi essenziali | Quale servizio è cambiato, fallito o ha generato errori di accesso? |
| Log amministrativi cloud | Catturano eventi ad alto impatto su configurazione e accessi | Chi ha modificato policy, storage, chiavi o esposizione di rete? |
| Piattaforma backup | Supporta readiness ransomware ed evidenze di ripristino | I backup sono completati, testati e protetti? |
Retention, integrità ed evidenze
Per la conformità, la policy di retention è importante quanto l'alerting. L'organizzazione dovrebbe definire per quanto tempo conserva i log, chi può accedervi, come protegge l'integrità e come esporta evidenze durante incidenti o audit.
Le evidenze orientate a NIS 2 e ACN dovrebbero mostrare non solo che esiste un SIEM, ma che i log delle sorgenti definite sono ricevuti, ricercabili e conservati secondo una policy scritta. Il fascicolo dovrebbe includere inventario sorgenti, impostazioni di retention, registri di gestione alert ed esempi di timeline investigative.
Roadmap pratica di implementazione
- Definire i casi di rischio: ransomware, account takeover, abuso privilegi, errore cloud e accesso fornitori.
- Scegliere le prime 5-10 sorgenti log che provano quei casi di rischio.
- Implementare ingestion e verificare qualità dei parser prima di scrivere troppe regole.
- Partire da poche regole collegate a playbook di risposta reali.
- Rivedere settimanalmente alert per rumore, falsi negativi e ownership.
- Riportare mensilmente copertura e finding al responsabile risk o compliance.
Fattori di costo e dimensionamento
Il costo di un SIEM non è solo licenza. I driver principali sono volume eventi, numero di sorgenti, periodo di retention, modello storage, tuning regole, triage alert e reporting. Il software open source può ridurre il costo di licenza, ma non elimina lavoro ingegneristico e operativo.
Per le PMI, il dimensionamento migliore è risk-based. Si parte da sistemi critici, identità, perimetro e amministrazione cloud. Le sorgenti secondarie si aggiungono solo quando producono rilevamento azionabile o evidenza di audit richiesta. Così il SIEM resta utile e non diventa un data lake costoso.
Domande da fare prima di acquistare o installare
- Quali incidenti dobbiamo rilevare per primi?
- Quali sorgenti log dimostrano quegli incidenti?
- Chi gestisce il triage alert in orario lavorativo e fuori orario?
- Per quanto tempo dobbiamo conservare i log per audit e indagine?
- Quali report servono a management, compliance e clienti?
- Come ridurremo falsi positivi e rumore?
Se queste domande non hanno un owner, il progetto dovrebbe fermarsi. Un SIEM funziona quando cambia la capacità di risposta, non quando l'ingestion raggiunge un volume elevato.
FAQ
Cos'è un SIEM in cybersecurity?
È una piattaforma che raccoglie e correla log ed eventi di sicurezza per supportare rilevamento, indagine e reporting.
La NIS 2 obbliga a usare un SIEM?
La NIS 2 non impone un prodotto SIEM specifico, ma monitoraggio, gestione incidenti ed evidenze richiedono spesso capacità simili a quelle di un SIEM.
Posso usare Wazuh come SIEM?
Sì, Wazuh può supportare casi d'uso SIEM e log analysis se deployment, copertura sorgenti e presidio operativo sono adeguati.
Differenza tra SIEM e EDR?
L'EDR si concentra sugli endpoint. Il SIEM centralizza e correla eventi da endpoint, identità, cloud, reti e applicazioni.