Executive summary
Quando un'organizzazione gestisce centinaia di sistemi, applicazioni e dispositivi di rete, ogni componente genera registri di attività che, presi singolarmente, dicono poco, ma che combinati possono rivelare tentativi di intrusione, comportamenti anomali o violazioni in corso. Questo articolo analizza le piattaforme progettate per raccogliere, normalizzare e mettere in relazione questi registri, trasformando un volume altrimenti ingestibile di dati grezzi in segnalazioni utili per i responsabili della sicurezza. L'analisi mostra che i sistemi più efficaci non si limitano a confrontare gli eventi con schemi di attacco noti, ma costruiscono un profilo del comportamento normale di ogni utente e dispositivo per identificare deviazioni sospette, anche quando non corrispondono a minacce già catalogate. Emerge inoltre che l'integrazione tra la capacità di rilevamento e meccanismi automatizzati di risposta rappresenta la direzione su cui converge l'intera industria, con implicazioni significative sulla riduzione dei tempi di contenimento delle minacce.
Background
I sistemi SIEM (Security Information and Event Management) nascono dalla convergenza di due discipline distinte che, fino alla metà degli anni 2000, operavano in modo indipendente: il Security Information Management (SIM), focalizzato sulla raccolta e archiviazione a lungo termine dei log per finalità di compliance e analisi forense, e il Security Event Management (SEM), orientato al monitoraggio in tempo reale e alla correlazione degli eventi di sicurezza. Il termine SIEM è stato introdotto da Gartner nel 2005 per descrivere soluzioni che integrassero entrambe le funzionalità in un'unica piattaforma [1]. Questa convergenza non è stata un esercizio tassonomico: rispondeva a un'esigenza operativa concreta, poiché i team di sicurezza necessitavano sia della visibilità storica per le indagini post-incidente sia della capacità di rilevamento in tempo reale per la risposta immediata.
L'architettura di un SIEM contemporaneo si articola attorno a quattro componenti funzionali interconnessi. Il primo è il sottosistema di raccolta e normalizzazione dei log, che acquisisce dati eterogenei da fonti diverse, firewall, sistemi IDS/IPS, endpoint, server, applicazioni, servizi cloud, e li trasforma in un formato uniforme per consentirne l'analisi. Il secondo è il motore di correlazione, che applica regole logiche e algoritmi statistici per identificare pattern sospetti emergenti dalla combinazione di eventi che, presi singolarmente, apparirebbero innocui. Il terzo è il sottosistema di analisi comportamentale (User and Entity Behavior Analytics, UEBA), che costruisce modelli del comportamento normale per rilevare anomalie. Il quarto è il livello di risposta, che nei sistemi più avanzati include funzionalità di orchestrazione e automazione (Security Orchestration, Automation and Response, SOAR) [2].
Il contesto operativo in cui i SIEM operano è radicalmente cambiato rispetto alle origini. La superficie di attacco si è espansa con l'adozione del cloud computing, del lavoro remoto e delle architetture distribuite. Il volume di dati da elaborare è cresciuto esponenzialmente: un'organizzazione enterprise di medie dimensioni genera tipicamente decine di migliaia di eventi di sicurezza al secondo, con picchi nell'ordine dei milioni durante attacchi attivi o periodi di elevata attività [3]. La sofisticazione delle minacce è aumentata, con attacchi multi-stadio che si sviluppano su archi temporali di settimane o mesi, rendendo inadeguati i modelli di rilevamento basati su singoli eventi isolati. Queste pressioni hanno spinto l'evoluzione del SIEM da strumento di log management a piattaforma di security analytics, un'evoluzione che il Gartner Magic Quadrant for SIEM documenta annualmente e che nel 2025 vede tra i leader piattaforme cloud-native come Microsoft Sentinel, Google Security Operations e Splunk [4].
Architettura di raccolta e normalizzazione dei log
Il problema dell'eterogeneità delle fonti
La raccolta dei log rappresenta il fondamento tecnico su cui si costruisce ogni capacità analitica di un SIEM. La sfida principale non è la quantità di dati, per quanto significativa, ma la loro eterogeneità. Un firewall Palo Alto genera log in formato strutturato proprietario con campi specifici per applicazione identificata, zona sorgente e zona destinazione. Un server Linux produce messaggi syslog con formato semi-strutturato e contenuto variabile in funzione del demone che li genera. Un servizio AWS CloudTrail emette eventi in formato JSON con uno schema distinto per ciascun tipo di chiamata API. Un sistema di autenticazione Active Directory registra eventi Windows in formato EVTX con codici evento numerici il cui significato dipende dal contesto [5].
Senza normalizzazione, l'analista di sicurezza sarebbe costretto a conoscere il formato specifico di ogni sorgente per formulare anche la più semplice delle query. Il processo di normalizzazione trasforma questa eterogeneità in un modello dati unificato in cui concetti equivalenti, un indirizzo IP sorgente, un nome utente, un'azione compiuta, sono rappresentati con la stessa struttura indipendentemente dalla fonte. L'Elastic Common Schema (ECS) rappresenta uno degli sforzi più maturi in questa direzione: definisce un catalogo di campi standardizzati organizzati per categoria (source, destination, user, process, file, network) che consente di scrivere query e regole di correlazione indipendenti dalla sorgente dati [6].
Pipeline di ingestione e trasformazione
L'architettura della pipeline di ingestione determina la scalabilità e la resilienza dell'intero sistema. Nei SIEM di prima generazione, gli agenti di raccolta inviavano i log direttamente al motore di analisi, creando un accoppiamento stretto tra produzione e consumo dei dati. L'introduzione di broker di messaggi come Apache Kafka ha trasformato questa architettura, disaccoppiando la raccolta dall'analisi attraverso un layer intermedio di buffering e distribuzione [7]. In questa architettura, i log vengono prodotti verso topic Kafka partizionati, consentendo a molteplici consumatori, il motore di correlazione, il sistema di archiviazione, i moduli di analisi comportamentale, di leggere gli stessi dati indipendentemente e al proprio ritmo.
La pipeline tipica si articola in quattro fasi sequenziali. La fase di raccolta (collection) acquisisce i dati dalle sorgenti attraverso protocolli eterogenei: syslog su TCP/UDP, agent installati sugli endpoint, API REST per servizi cloud, log forwarder per ambienti containerizzati. La fase di parsing estrae i campi strutturati dal formato nativo di ciascuna sorgente. La fase di normalizzazione mappa i campi estratti nello schema comune del SIEM. La fase di arricchimento (enrichment) aggiunge contesto ai dati grezzi: risoluzione DNS inversa, geolocalizzazione degli indirizzi IP, lookup su threat intelligence feed, correlazione con l'inventario degli asset per determinare la criticità del sistema coinvolto [7]. Quest'ultima fase è particolarmente rilevante per l'efficacia del rilevamento: un evento di autenticazione fallita ha un significato radicalmente diverso se proviene da un laptop utente o da un server di produzione che ospita dati finanziari.
Sfide di scalabilità e costo
Il volume di dati è il fattore che domina l'economia operativa di un SIEM. Le piattaforme commerciali adottano modelli di pricing basati sul volume ingerito (misurato in GB/giorno o eventi al secondo), creando un incentivo perverso a ridurre la visibilità per contenere i costi. Zuech et al. [3] documentano come, nei sistemi tradizionali, la latenza delle query cresca in modo non lineare con il volume archiviato: un'analisi retrospettiva su un mese di dati poteva richiedere da venti minuti a un'ora, rendendo impraticabile l'analisi forense iterativa. L'adozione di architetture basate su data lake e motori di ricerca distribuiti (Elasticsearch, Apache Spark, ClickHouse) ha mitigato questa limitazione, consentendo query su petabyte di dati con latenze nell'ordine dei secondi.
Le architetture cloud-native hanno introdotto un ulteriore paradigma: la separazione tra storage e compute. In queste architetture, i log vengono archiviati in object storage a basso costo (Amazon S3, Google Cloud Storage) e analizzati on-demand attraverso risorse di calcolo effimere. Questo modello consente di mantenere anni di dati storici a costi marginali, eliminando il compromesso tradizionale tra profondità temporale e budget operativo. Manzoor et al. [5] documentano come soluzioni open-source come Wazuh e Elastic Security consentano alle organizzazioni di piccole e medie dimensioni di implementare capacità SIEM con costi infrastrutturali significativamente inferiori rispetto alle piattaforme commerciali, sebbene con un investimento maggiore in competenze operative.
Motore di correlazione e regole di rilevamento
Principi della correlazione degli eventi
Il motore di correlazione è il componente che trasforma un archivio di log in un sistema di rilevamento delle minacce. La sua funzione è identificare relazioni significative tra eventi che, considerati individualmente, non costituirebbero indicatori di compromissione. Un singolo tentativo di autenticazione fallita è un evento ordinario. Cinquanta tentativi di autenticazione fallita sullo stesso account in cinque minuti, seguiti da un'autenticazione riuscita e da un accesso a una risorsa mai utilizzata da quell'utente, costituiscono un pattern che richiede indagine immediata.
La correlazione opera attraverso due paradigmi complementari. Il primo è la correlazione basata su regole (rule-based): l'analista definisce condizioni logiche che, quando soddisfatte, generano un alert. Queste regole codificano la conoscenza esplicita del team di sicurezza sugli scenari di attacco noti. Il secondo paradigma è la correlazione statistica e algoritmica, che utilizza tecniche di machine learning per identificare pattern non anticipati dalle regole statiche. Sheeraz et al. [8] propongono un motore di correlazione ottimizzato che sostituisce il modulo di matching regex tradizionale con la libreria Hyperscan per la scansione parallela dei log, ottenendo miglioramenti significativi nelle prestazioni di correlazione multi-layer.
Sigma: uno standard aperto per le regole di rilevamento
Uno dei problemi strutturali della correlazione basata su regole è stata storicamente la dipendenza dal vendor: una regola scritta per Splunk non funziona in Elastic Security, e viceversa. Il formato Sigma, introdotto nel 2017 da Florian Roth e Thomas Patzke [9], affronta questo problema definendo un linguaggio dichiarativo YAML-based indipendente dalla piattaforma per la descrizione delle regole di rilevamento. Sigma si posiziona nel panorama della sicurezza come equivalente di Snort per il traffico di rete e di YARA per i file: un formato universale che consente la condivisione di logica di rilevamento tra organizzazioni e strumenti diversi.
Una regola Sigma specifica quattro elementi fondamentali: il logsource, che identifica il tipo di log su cui opera (prodotto, servizio, categoria); la detection, che definisce le condizioni logiche da soddisfare attraverso combinazioni di operatori booleani su campi e valori; il level, che classifica la criticità dell'alert su una scala da informational a critical; e i tags, che mappano la regola al framework MITRE ATT&CK per contestualizzare la tecnica di attacco rilevata [9]. Il repository SigmaHQ su GitHub raccoglie oltre 3.000 regole mantenute dalla comunità, coprendo scenari che spaziano dall'esecuzione di comandi PowerShell malevoli al lateral movement via PsExec, dalla credential dumping tramite Mimikatz al rilevamento di ransomware [10].
Il workflow operativo prevede la scrittura della regola in formato Sigma e la sua conversione nel linguaggio di query nativo del SIEM di destinazione attraverso un compilatore (sigma-cli o pySigma). Questo approccio consente ai team di sicurezza di investire nella logica di rilevamento indipendentemente dalla piattaforma, riducendo il costo di migrazione tra SIEM e favorendo la collaborazione inter-organizzativa. I tipi di correlazione supportati da Sigma includono event_count (regole a soglia), value_count (soglie su valori distinti), temporal (regole cluster) e ordered_temporal (regole a catena), coprendo la maggior parte degli scenari di correlazione richiesti in un Security Operations Center [9].
MITRE ATT&CK come framework di riferimento
Il framework MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) fornisce la tassonomia di riferimento per classificare le capacità di rilevamento di un SIEM rispetto ai comportamenti avversari osservati nel mondo reale [11]. Organizzato in 14 tattiche, dalla reconnaissance iniziale all'esfiltrazione dei dati, e oltre 200 tecniche specifiche, il framework consente di mappare ciascuna regola di correlazione a una o più tecniche di attacco note, producendo una matrice di copertura che evidenzia le aree protette e i gap nel rilevamento.
Questa mappatura ha implicazioni operative concrete. Un'organizzazione che scopre di avere copertura robusta sulle tattiche di Initial Access e Execution ma nessuna regola per le tecniche di Lateral Movement e Defense Evasion ha una postura di sicurezza strutturalmente sbilanciata: è in grado di rilevare il primo ingresso dell'attaccante ma non il suo movimento successivo attraverso la rete. Piattaforme come Elastic Security integrano nativamente una vista della copertura MITRE ATT&CK nel proprio modulo di gestione delle regole, consentendo un assessment continuo e data-driven delle lacune di rilevamento [6]. La guida congiunta pubblicata nel 2025 da NSA, Australian Cyber Security Centre (ACSC), CISA e altre agenzie internazionali raccomanda esplicitamente la mappatura ATT&CK come best practice per l'implementazione di piattaforme SIEM e SOAR [2].
User and Entity Behavior Analytics (UEBA)
Limiti intrinseci del rilevamento basato su regole
Il rilevamento basato su regole, per quanto essenziale, presenta un limite strutturale: può identificare solo ciò che è stato esplicitamente codificato. Ogni regola rappresenta un'ipotesi specifica su un pattern di attacco, e la sua efficacia dipende dalla capacità dell'analista di anticipare i comportamenti dell'avversario. Questa limitazione diventa critica di fronte a due classi di minacce. La prima è costituita dagli attacchi zero-day e dalle tecniche di evasione che non corrispondono a pattern noti. La seconda, e spesso più insidiosa, è rappresentata dalle minacce interne (insider threat), in cui un utente legittimo utilizza credenziali e permessi autorizzati per compiere azioni malevole. In entrambi i casi, l'attacco non viola alcuna regola predefinita: utilizza strumenti e percorsi legittimi per scopi illegittimi [12].
L'User and Entity Behavior Analytics (UEBA) affronta questa limitazione invertendo la logica di rilevamento. Invece di definire a priori i pattern malevoli, il sistema costruisce un modello del comportamento normale di ciascun utente e di ciascuna entità (server, applicazione, dispositivo di rete) e segnala le deviazioni statisticamente significative da tale baseline. Se un utente che accede tipicamente a tre applicazioni durante l'orario lavorativo inizia ad accedere a dieci sistemi diversi alle tre di notte, il sistema genera un alert anche se ogni singolo accesso è tecnicamente autorizzato.
Architettura dei modelli comportamentali
L'architettura di un sistema UEBA si articola in tre stadi computazionali. Il primo stadio è la costruzione della baseline: il sistema osserva il comportamento di ciascuna entità per un periodo di apprendimento (tipicamente 14-30 giorni) e costruisce un profilo multidimensionale che cattura i pattern ricorrenti, orari di attività, risorse accedute, volumi di dati trasferiti, indirizzi IP di connessione, comandi eseguiti. Il secondo stadio è il rilevamento delle anomalie: ogni nuovo evento viene confrontato con la baseline e valutato in base alla sua deviazione dal comportamento atteso. Il terzo stadio è l'assegnazione del risk score: le anomalie rilevate vengono aggregate in un punteggio di rischio complessivo per ciascuna entità, consentendo al team di sicurezza di concentrare le indagini sulle entità con il profilo di rischio più elevato [12].
I modelli di machine learning impiegati variano per complessità e finalità. Le tecniche di clustering non supervisionato (K-means, DBSCAN) identificano gruppi di utenti con comportamenti simili e segnalano i soggetti che si discostano dal proprio cluster. Le tecniche di isolamento delle anomalie (Isolation Forest) individuano eventi rari in spazi ad alta dimensionalità. Le reti neurali ricorrenti e gli autoencoder LSTM catturano le dipendenze temporali nel comportamento, risultando particolarmente efficaci nel rilevare sequenze di azioni anomale che singolarmente apparirebbero normali [13]. La ricerca recente mostra una crescente adozione di approcci ibridi che combinano apprendimento supervisionato su minacce note con apprendimento non supervisionato per la scoperta di pattern inediti. Kim et al. [12] documentano come l'integrazione di algoritmi supervisionati e non supervisionati migliori significativamente la precisione del rilevamento, con riduzioni dei falsi positivi nell'ordine del 50-60% rispetto ai sistemi puramente basati su regole.
Sfide operative e falsi positivi
L'efficacia di un sistema UEBA è condizionata da diversi fattori operativi. Il primo è la qualità dei dati di input: modelli costruiti su log incompleti o mal normalizzati producono baseline inaccurate e, di conseguenza, tassi elevati di falsi positivi. Il secondo è il problema del concept drift: il comportamento degli utenti cambia nel tempo, nuovi progetti, riorganizzazioni aziendali, cambiamenti di ruolo, e il modello deve adattarsi senza perdere la sensibilità ai cambiamenti genuinamente sospetti. Il terzo è il cold start problem: per gli utenti nuovi o per le entità appena aggiunte all'infrastruttura, il sistema non dispone di una baseline sufficiente per valutare le anomalie.
Un aspetto critico è il rapporto tra volume di alert e capacità investigativa del SOC (Security Operations Center). Un sistema UEBA mal calibrato che genera centinaia di alert quotidiani con tassi di falsi positivi elevati non riduce il carico operativo degli analisti: lo aumenta, generando alert fatigue e, paradossalmente, peggiorando la postura di sicurezza perché gli analisti iniziano a ignorare sistematicamente gli alert [1]. La calibrazione delle soglie di rischio e l'aggregazione contestuale, raggruppare le anomalie per entità e per arco temporale piuttosto che presentare ogni anomalia isolata, sono quindi essenziali per l'operatività del sistema in produzione.
Integrazione SOAR: dall'alert alla risposta automatizzata
Il problema del gap tra rilevamento e risposta
L'identificazione di una minaccia è solo metà del problema. Il tempo che intercorre tra il rilevamento di un evento sospetto e il contenimento effettivo dell'attacco, noto come Mean Time to Respond (MTTR), è il fattore che determina l'entità del danno. Un sistema SIEM che rileva un'esfiltrazione di dati in corso ma richiede 45 minuti di intervento manuale per isolare il sistema compromesso consente all'attaccante di completare l'operazione. L'integrazione con piattaforme SOAR (Security Orchestration, Automation and Response) affronta questa limitazione automatizzando le fasi di risposta che non richiedono giudizio umano e orchestrando i workflow che ne richiedono.
L'architettura SOAR si fonda su tre capacità distinte. L'orchestrazione integra gli strumenti di sicurezza dell'organizzazione, SIEM, firewall, endpoint detection and response (EDR), identity provider, sistemi di ticketing, attraverso API, consentendo di eseguire azioni coordinate su piattaforme eterogenee da un'unica interfaccia. L'automazione codifica le procedure di risposta (playbook) in workflow eseguibili che il sistema può attivare senza intervento umano: ad esempio, bloccare un indirizzo IP al firewall, disabilitare un account compromesso, isolare un endpoint dalla rete. La gestione dei casi (case management) fornisce il contesto investigativo, tracciando ogni alert dall'apertura alla chiusura con la cronologia delle azioni intraprese [2, 14].
Playbook e tassonomia delle risposte
Un playbook SOAR è un grafo aciclico diretto (DAG) di azioni condizionate che codifica una procedura operativa standard. La struttura tipica prevede un trigger (l'alert SIEM che attiva il playbook), una fase di arricchimento (raccolta automatica di contesto: reputazione dell'IP sorgente, storico dell'utente coinvolto, vulnerabilità del sistema affetto), una fase decisionale (che può includere soglie automatiche o punti di approvazione umana), e una fase di azione (le operazioni di contenimento o remediation).
La guida congiunta NSA-ACSC del 2025 [2] classifica le risposte automatizzabili in tre livelli di rischio. Le azioni a basso rischio, come l'arricchimento contestuale, la creazione di un ticket, l'invio di una notifica, possono essere automatizzate senza approvazione umana (full automation). Le azioni a rischio moderato, come il blocco di un IP esterno o la quarantena di un file, possono essere automatizzate con approvazione post-hoc (semi-automation). Le azioni ad alto rischio, come la disabilitazione di un account utente, l'isolamento di un server di produzione, il reset di credenziali, richiedono approvazione esplicita prima dell'esecuzione (human-in-the-loop). Questa tassonomia riflette un principio fondamentale: l'automazione deve ridurre il tempo di risposta senza introdurre il rischio di azioni distruttive attivate da falsi positivi.
Metriche di efficacia e maturità
L'impatto dell'integrazione SOAR è misurabile attraverso indicatori operativi concreti. Il MTTR (Mean Time to Respond) quantifica il tempo medio dalla rilevazione alla mitigazione. Il MTTD (Mean Time to Detect) misura il tempo medio dalla compromissione alla sua identificazione. Il tasso di automazione indica la percentuale di alert gestiti senza intervento umano. L'efficacia si valuta anche attraverso il rapporto tra alert generati e incidenti confermati (precision), e la capacità di rilevare gli incidenti effettivi (recall). Le organizzazioni che implementano con successo l'integrazione SIEM-SOAR riportano riduzioni del MTTR nell'ordine di grandezza, da ore a minuti, rispetto ai processi interamente manuali, a condizione che i playbook siano progettati e calibrati con rigore operativo [2, 14].
SIEM cloud-native: architetture di nuova generazione
Dalla migrazione al ripensamento architetturale
La transizione al cloud ha imposto un ripensamento fondamentale dell'architettura SIEM. I sistemi tradizionali sono stati progettati per ambienti on-premises con un numero relativamente stabile di sorgenti dati e volumi prevedibili. L'adozione di infrastrutture cloud, con la loro natura elastica, il modello di responsabilità condivisa e la proliferazione di servizi generatori di log, ha reso questi presupposti obsoleti. Un'organizzazione che opera su AWS, Azure e GCP simultaneamente deve raccogliere log da centinaia di servizi distinti, ciascuno con il proprio formato, il proprio meccanismo di delivery e la propria semantica degli eventi.
Le architetture SIEM cloud-native si distinguono dai SIEM tradizionali migrati al cloud per tre caratteristiche strutturali. La prima è la separazione tra storage e compute: i dati vengono archiviati in object storage scalabile e analizzati da risorse di calcolo allocate dinamicamente, eliminando il vincolo di capacità fissa. La seconda è l'elasticità: la capacità di ingestione e di analisi scala automaticamente in funzione del volume dei dati, senza intervento manuale e senza degrado delle prestazioni durante i picchi. La terza è l'integrazione nativa con i servizi cloud: i connettori per le sorgenti cloud non sono add-on ma componenti di prima classe dell'architettura, con supporto per formati nativi e aggiornamenti automatici al variare delle API dei provider [15].
Architetture di riferimento
L'architettura di un SIEM cloud-native si organizza tipicamente in tre layer. Il data layer gestisce l'ingestione, la normalizzazione e l'archiviazione dei dati. L'ingestione avviene attraverso connettori nativi per le sorgenti cloud e collector per le sorgenti on-premises, con un message broker (tipicamente Apache Kafka o un servizio equivalente gestito come Amazon Kinesis o Google Pub/Sub) che disaccoppia produttori e consumatori [7]. Lo storage utilizza un modello tiered: uno strato caldo (hot tier) con indici di ricerca per i dati recenti (tipicamente 30-90 giorni) e uno strato freddo (cold tier) su object storage per la conservazione a lungo termine.
Il detection layer implementa la logica di correlazione e analisi. Nelle architetture più avanzate, questo layer opera in modalità streaming: le regole di correlazione vengono applicate agli eventi in transito attraverso la pipeline, producendo alert con latenze sub-secondarie anziché richiedere query periodiche su dati archiviati. Google Security Operations (ex Chronicle) implementa questo modello attraverso il linguaggio YARA-L per la definizione di regole di detection su flussi di eventi in tempo reale. Il response layer integra le capacità SOAR descritte nella sezione precedente, con playbook eseguiti come funzioni serverless attivate dagli alert del detection layer.
Implicazioni di costo e modelli di pricing
Il modello economico dei SIEM cloud-native introduce un cambiamento strutturale rispetto ai sistemi on-premises. I SIEM tradizionali richiedono investimenti in hardware, licenze e personale operativo (modello CapEx). I SIEM cloud-native adottano modelli OpEx con pricing basato sul volume ingerito, sulle query eseguite o sulla capacità di calcolo utilizzata. Questo spostamento ha implicazioni sulla progettazione della pipeline: filtrare, aggregare e comprimere i dati prima dell'ingestione nel SIEM diventa un'ottimizzazione economica oltre che tecnica.
Manzoor et al. [5] documentano come le soluzioni open-source (Wazuh, Elastic Security) consentano di ridurre i costi di licenza ma richiedano competenze operative significative per la gestione dell'infrastruttura. L'analisi comparativa mostra che il costo totale di possesso (TCO) dipende criticamente dal rapporto tra il volume di dati ingeriti e la percentuale effettivamente analizzata: organizzazioni che ingeriscono grandi volumi di log senza una strategia di filtering e tiering pagano costi sproporzionati rispetto al valore analitico ottenuto.
Limiti strutturali e problemi aperti
Il paradosso della copertura
Un SIEM è efficace nella misura in cui riceve i dati giusti. Ogni sorgente non configurata, ogni tipo di log escluso per ragioni di costo, ogni endpoint non coperto da un agent rappresenta un punto cieco nel rilevamento. La mappatura della copertura rispetto al framework MITRE ATT&CK [11] rende espliciti questi gap, ma non li elimina. La tensione tra copertura completa e sostenibilità economica è un problema strutturale che nessuna architettura risolve interamente: aumentare la copertura incrementa i costi e il volume di dati da analizzare, aumentando potenzialmente il rumore e degradando il rapporto segnale-rumore.
Il costo della complessità
L'implementazione e la manutenzione di un SIEM richiedono competenze specialistiche significative. La scrittura di regole di correlazione efficaci presuppone una conoscenza approfondita sia delle tecniche di attacco sia dell'infrastruttura specifica dell'organizzazione. La calibrazione dei modelli UEBA richiede un periodo di tuning prolungato e iterativo. La progettazione dei playbook SOAR impone una formalizzazione rigorosa delle procedure operative che molte organizzazioni non hanno mai documentato. González-Granadillo et al. [1] identificano la complessità operativa come uno dei fattori principali che limitano l'efficacia dei SIEM nelle infrastrutture critiche, osservando che la tecnologia è spesso più matura della capacità organizzativa di utilizzarla.
Evasione e attacchi al SIEM stesso
Un SIEM è, per definizione, un bersaglio di alto valore per un avversario sofisticato. Le tecniche di evasione includono la manipolazione dei log alla sorgente (log tampering), l'utilizzo di canali di comunicazione non monitorati, la frammentazione temporale delle attività malevole per rimanere sotto le soglie di correlazione, e l'abuso di strumenti legittimi di amministrazione (living-off-the-land) che generano eventi indistinguibili dal comportamento normale [11]. L'integrità della pipeline di raccolta, autenticazione dei log forwarder, cifratura in transito, immutabilità dell'archivio, è un prerequisito spesso sottovalutato per l'affidabilità dell'intero sistema.
Verso la convergenza SIEM-XDR
Una traiettoria evolutiva significativa è la convergenza tra SIEM e Extended Detection and Response (XDR). Mentre il SIEM tradizionale raccoglie e correla log eterogenei, l'XDR integra nativamente telemetria da endpoint, rete e cloud in un modello dati unificato con capacità di risposta integrate. La differenza non è solo funzionale ma architetturale: l'XDR nasce come piattaforma integrata, mentre il SIEM opera tipicamente come aggregatore di dati provenienti da prodotti di terze parti. Il Gartner Magic Quadrant 2025 [4] riflette questa convergenza, con i leader del mercato che offrono piattaforme ibride SIEM-XDR in cui il confine tra le due categorie diventa progressivamente sfumato. González-Granadillo et al. [1] avevano anticipato questa tendenza nel 2021, identificando tra i potenziali miglioramenti dei SIEM di nuova generazione l'integrazione nativa di telemetria endpoint e la capacità di risposta automatizzata, funzionalità che oggi definiscono l'XDR come categoria distinta.
Riferimenti
[1] G. González-Granadillo, S. González-Zarzosa, R. Díaz, "Security Information and Event Management (SIEM): Analysis, Trends, and Usage in Critical Infrastructures," Sensors, vol. 21, no. 14, art. 4759, 2021. https://doi.org/10.3390/s21144759
[2] NSA, ASD's ACSC, CISA et al., "Implementing SIEM and SOAR Platforms: Practitioner Guidance," 2025. https://www.cyber.gov.au/business-government/detecting-responding-to-threats/event-logging/implementing-siem-soar-platforms/implementing-siem-and-soar-platforms-practitioner-guidance
[3] R. Zuech, T. M. Khoshgoftaar, R. Wald, "Intrusion Detection and Big Heterogeneous Data: A Survey," Journal of Big Data, vol. 2, no. 3, 2015. https://doi.org/10.1186/s40537-015-0013-4
[4] Gartner, "Magic Quadrant for Security Information and Event Management," 2025. https://www.gartner.com/en/documents/5415763
[5] J. Manzoor, A. Waleed, A. F. Jamali, A. Masood, "Cybersecurity on a Budget: Evaluating Security and Performance of Open-Source SIEM Solutions for SMEs," PLoS ONE, vol. 19, no. 3, e0301183, 2024. https://doi.org/10.1371/journal.pone.0301183
[6] Elastic, "Elastic Common Schema (ECS) Reference," 2024. https://www.elastic.co/guide/en/ecs/current/index.html
[7] Confluent, "Enhanced Cybersecurity with Real-Time Log Aggregation and Analysis," 2024. https://www.confluent.io/blog/log-aggregation-analysis-cybersecurity/
[8] M. Sheeraz, M. H. Durad, M. A. Paracha, S. M. Mohsin, S. N. Kazmi, C. Maple, "Revolutionizing SIEM Security: An Innovative Correlation Engine Design for Multi-Layered Attack Detection," Sensors, vol. 24, no. 15, art. 4901, 2024. https://doi.org/10.3390/s24154901
[9] SigmaHQ, "Sigma Specification," GitHub repository, 2024. https://github.com/SigmaHQ/sigma-specification
[10] SigmaHQ, "Sigma — Main Rule Repository," GitHub repository, 2024. https://github.com/SigmaHQ/sigma
[11] MITRE Corporation, "MITRE ATT&CK," 2024. https://attack.mitre.org/
[12] S. Kim, J. Park, K. Lee, "Insider Threat Detection Model Enhancement Using Hybrid Algorithms Between Unsupervised and Supervised Learning," Electronics, vol. 13, no. 5, art. 973, 2024. https://doi.org/10.3390/electronics13050973
[13] A. Tuor, S. Kaplan, B. Hutchinson, N. Nichols, S. Robinson, "Deep Learning for Unsupervised Insider Threat Detection in Structured Cybersecurity Data Streams," in Proc. AAAI Workshop on AI for Cyber Security, 2017. https://arxiv.org/abs/1710.00811
[14] M. R. Rahman, I. Arif, "Integrating Automation and Orchestration in Security Incident Handling: A Review of SOAR Frameworks and Platforms," in Proc. International Conference on Cyber Warfare and Security, Springer, 2026. https://link.springer.com/chapter/10.1007/978-3-031-95963-9_38
[15] Elastic, "SIEM Platform — Security Information and Event Management," 2025. https://www.elastic.co/security/siem