Il punto di vista di Cyber Academy
Un SIEM aggrega i log, normalizza gli eventi ed esegue regole di rilevamento sull'intero stack. È il livello di visibilità da cui dipende il SOC. I principali vendor SIEM (Splunk, Sentinel, Elastic, Sumo) integrano sempre più spesso funzionalità SOAR e UEBA. La parte difficile non è acquistare il SIEM; è il data engineering e la pipeline di detection-as-code che ne consegue.
Cosa fa realmente un SIEM
Un SIEM si colloca al centro delle operazioni di sicurezza come motore di raccolta e correlazione. Acquisisce log ed eventi da tutto il parco: firewall, endpoint, provider di identità, piattaforme cloud, server, applicazioni e dispositivi di rete. Normalizza poi quegli eventi in uno schema comune, così che un errore di autenticazione Windows, un accesso VPN e una chiamata a un'API cloud possano essere analizzati insieme, ed esegue regole di rilevamento su quel flusso unificato per generare allarmi. Il punto è la visibilità. Senza un SIEM, i segnali di sicurezza restano intrappolati in decine di console che nessuno correla, e un attacco che tocca cinque sistemi appare come cinque eventi non correlati.
Due funzioni rendono un SIEM molto più di uno strumento di ricerca nei log. La prima è la correlazione: regole che si attivano solo quando si verifica una sequenza, per esempio un tentativo di forza bruta seguito da un accesso riuscito e poi da un'escalation di privilegi, qualcosa che nessuna singola fonte segnalerebbe da sola. La seconda è la conservazione e la ricerca, che trasformano il SIEM nel sistema di riferimento per le indagini e nel luogo a cui un analista si rivolge per ricostruire ciò che è accaduto. Come nota la shortDefinition, le piattaforme moderne come Splunk, Microsoft Sentinel, Elastic e Sumo Logic integrano sempre più il SOAR per la risposta automatizzata e l'UEBA per l'analisi comportamentale, così che i confini tra queste categorie si sfumano.
SIEM, SOC, SOAR ed EDR: chi fa cosa
Questi termini viaggiano spesso insieme ed è facile confonderli, ma descrivono cose diverse: uno strumento, un team, un livello di automazione e un sensore.
| Termine | Che cos'è | Relazione con il SIEM |
|---|---|---|
| SIEM | La piattaforma di aggregazione, normalizzazione e rilevamento | Il livello di visibilità stesso. |
| SOC | Il team e il processo che monitorano e rispondono | Consuma gli allarmi del SIEM; il SIEM è la sua console principale. |
| SOAR | Orchestrazione e playbook di risposta automatizzata | Agisce sugli allarmi del SIEM per arricchirli, classificarli e contenerli. |
| EDR | Sensore su endpoint con telemetria approfondita dell'host | Una fonte ad alta fedeltà che alimenta il SIEM. |
La lettura pratica: il SIEM è la tecnologia che vede tutto, il SOC è l'insieme delle persone che lavorano gli allarmi, il SOAR è l'automazione che riduce il loro lavoro manuale, e l'EDR è una delle fonti di dati più ricche che vi affluiscono. Un SIEM senza un SOC alle spalle genera allarmi che nessuno legge. Un SOC senza un SIEM è cieco. Si acquistano separatamente ma offrono valore solo insieme.
Perché il SIEM è la parte difficile
Acquistare un SIEM è un esercizio di approvvigionamento. Renderlo utile è ingegneria dei dati. Il lavoro che determina davvero il successo consiste nel collegare le giuste fonti di log con una copertura completa, nell'analizzare correttamente ogni fonte affinché i campi finiscano nel posto giusto, e nel mettere a punto i contenuti di rilevamento affinché gli analisti ottengano veri positivi anziché un diluvio di rumore che li abitua a ignorare gli allarmi.
È per questo che i team maturi trattano i rilevamenti come codice: le regole vivono in un controllo di versione, sono testate, sono riviste tra pari e vengono distribuite tramite una pipeline, esattamente come il software applicativo. La shortDefinition è netta in proposito. Il lavoro difficile non è acquistare il SIEM; è la pipeline di detection-as-code che ne consegue.
Dal punto di vista della governance, il SIEM è ciò che impedisce a diversi obiettivi di controllo di restare aspirazioni. Nell'ambito di un SGSI ISO/IEC 27001 sostiene i controlli su registrazione, monitoraggio e sul versante di rilevamento della gestione degli incidenti, e produce le evidenze che un auditor si aspetta di vedere a dimostrazione che gli eventi vengono effettivamente acquisiti ed esaminati. Operativizza inoltre la capacità di rilevamento e risposta che il NIST Cybersecurity Framework presuppone, e che normative come NIS2 e DORA si aspettano che le organizzazioni mantengano e siano in grado di dimostrare durante un incidente.
Frequently asked questions
01Qual è la differenza tra un SIEM e un SOC?
Un SIEM è la piattaforma tecnologica che aggrega i log e genera gli allarmi. Un SOC è il team e il processo che monitorano quegli allarmi e rispondono. Il SIEM è lo strumento principale da cui lavora il SOC; si può possedere l'uno senza l'altro, ma nessuno dei due offre molto valore da solo.
02In cosa un SIEM differisce da un EDR?
L'EDR è un sensore incentrato sulla telemetria approfondita degli endpoint. Un SIEM è più ampio: acquisisce i dati EDR insieme ai log di firewall, identità, cloud e applicazioni, poi li correla tutti. L'EDR è una fonte ricca; il SIEM è dove le fonti convergono.
03SOAR e UEBA sostituiscono un SIEM?
No, lo estendono. Il SOAR automatizza la risposta agli allarmi e l'UEBA aggiunge l'analisi comportamentale al rilevamento, e i fornitori moderni integrano sempre più entrambi nella piattaforma SIEM. Si basano sulla correlazione fornita dal SIEM anziché sostituirla.
04Perché i progetti SIEM falliscono?
Di solito perché si sottovaluta l'ingegneria dei dati. Una copertura incompleta dei log, un'analisi difettosa e regole non messe a punto producono rumore anziché segnale, così gli analisti smettono di fidarsi degli allarmi. Il successo deriva da una pipeline deliberata di detection-as-code, non dall'acquisto in sé.
05Un SIEM è obbligatorio per la conformità?
Nessuno standard nomina specificamente il SIEM, ma le sue capacità di registrazione, monitoraggio e rilevamento corrispondono direttamente agli obiettivi di controllo della ISO/IEC 27001 e alle aspettative del NIST CSF e di normative come NIS2 e DORA. In pratica è il modo standard per dimostrare che gli eventi vengono acquisiti ed esaminati.