Un SIEM raccoglie i log, li normalizza, applica regole di correlazione e genera alert per il triage. Segui la pipeline con un esempio che puoi eseguire.
Quando un team di sicurezza dice di aver "visto l'attacco", di solito intende che l'attacco ha lasciato tracce in più punti e che un sistema le ha messe insieme e ha lanciato una segnalazione. Quel sistema, il più delle volte, è un SIEM, sigla di security information and event management. Buona parte del lavoro quotidiano di un SOC parte da lì: un analista apre un alert, controlla gli eventi che ci stanno dietro e decide se qualcuno deve intervenire.
Questo articolo spiega passo per passo che cosa fa un SIEM: da dove arrivano i dati, perché i log vanno rimodellati prima di servire a qualcosa, come le regole di correlazione trasformano gli eventi in alert e che cosa succede dopo che un alert è scattato. Mostra anche dove si colloca un SIEM rispetto agli strumenti EDR e SOAR, e associa un alert di esempio a una tecnica di MITRE ATT&CK, così vedi come un rilevamento si collega al comportamento di chi attacca.
Stavolta non ti serve un laboratorio. La parte pratica è un piccolo script Python che gira su qualsiasi macchina con Python 3.12 e usa log sintetici. Produce un alert vero a partire da righe grezze, e puoi cambiare i dati e guardare come cambia il risultato. Se vuoi uno stack completo, le ultime sezioni indicano due opzioni gratuite che puoi installare da solo.
Un SIEM fa tre lavori su un'unica piattaforma. Raccoglie log ed eventi da molte fonti. Li conserva, così puoi cercarli in seguito. E applica ai dati delle regole che generano un alert quando qualcosa corrisponde a uno schema.
La guida del NIST alla gestione dei log di sicurezza informatica, SP 800-92, dà indicazioni pratiche per sviluppare, implementare e mantenere la gestione dei log in tutta un'organizzazione. La guida la tratta come un'attività continua, che un team deve pianificare e tenere in funzione. Un SIEM è un modo comune di farlo su larga scala, ma ce ne sono altri. Un team piccolo può fare parecchio con un server di log centrale e qualche ricerca scritta bene.
Nel nome, la parola "security" conta meno della parola "event". Di suo, un SIEM non sa che cosa sia un evento pericoloso. Conosce gli eventi che gli mandi e le regole che scrivi. La sua qualità dipende dai dati in ingresso e dai rilevamenti che ci girano sopra.
Chi attacca produce raramente un unico segnale chiaro. Un login fallito, una nuova operazione pianificata e una connessione in uscita verso un host sconosciuto sono, presi uno per uno, fatti normali. Messi insieme possono descrivere un'intrusione. Un SIEM serve perché può mettere quei record fianco a fianco, tra host, account e momenti diversi. Una persona che legge singoli file su singole macchine non può farlo su una scala appena significativa.
L'altro motivo è il volume. Un'organizzazione con qualche centinaio di macchine può generare milioni di righe di log al giorno. Nessun analista le legge. Il compito del SIEM è ridurre quel volume a un elenco breve di cose che una persona deve guardare, con abbastanza contesto per decidere in fretta.
Un SIEM lavora per fasi. Ogni fase può rompersi, e molti problemi di rilevamento nascono da una di queste.
Una fonte di log è qualsiasi cosa scriva un record su un fatto avvenuto. Nella maggior parte degli ambienti le più comuni sono:
Ogni fonte descrive il mondo dal proprio punto di vista. Un firewall vede una connessione. Un host Windows vede un accesso. Nessuno dei due vede tutta la storia.
La raccolta porta i record dalla fonte al SIEM. I metodi abituali sono un agent installato sull'host, un forwarder che legge i file di log, messaggi syslog inviati in rete oppure un'API che preleva gli eventi da un servizio cloud. Gli agent possono catturare più dettagli dall'host. Syslog è semplice e molto diffuso, ma sotto carico può perdere messaggi se nessuno li mette in buffer.
I guasti nella raccolta non fanno rumore. Se un server smette di mandare log, per impostazione predefinita il SIEM non mostra errori. Su quel server non ha niente da dire, e il silenzio può sembrare calma. I team bravi tengono d'occhio il volume di eventi per fonte e generano un alert quando una fonte tace.
Ogni fonte usa il proprio formato. Un sistema scrive il nome utente come user, un altro come account, un terzo come subject.name dentro un JSON annidato. La normalizzazione riporta quei campi su un unico schema condiviso, così una regola può dire "il campo utente" e intendere la stessa cosa per ogni fonte.
La maggior parte dei prodotti SIEM lo fa per te, con parser integrati o uno schema pubblicato. Qualunque sia il prodotto, l'obiettivo è lo stesso: dopo la normalizzazione, una ricerca di accessi falliti ha lo stesso aspetto sia che gli eventi arrivino da Linux, da Windows o da un provider di identità cloud.
Lo script di esempio più avanti fa la stessa cosa in piccolo. Prende una riga SSH grezza e produce un dizionario con i nomi dei campi sempre uguali.
La conservazione è il tempo per cui tieni i log prima di cancellarli. Sembra una questione amministrativa, ma decide che cosa puoi indagare. Un'intrusione scoperta tre mesi dopo ha bisogno dei log di tre mesi prima. Se li conservi per due settimane, le prove spariscono prima che qualcuno le guardi.
Il periodo giusto dipende dalla tua policy, dagli obblighi legali e normativi e dal costo dello spazio. Le indicazioni sulla gestione dei log come NIST SP 800-92 coprono l'intera vita dei dati di log, quindi la conservazione va nel piano fin dall'inizio, e non deve saltare fuori quando il disco si riempie. Metti per iscritto che cosa tieni, per quanto tempo e chi può leggerlo. Poi controlla che la cancellazione avvenga davvero.
I dati recenti di solito stanno su uno storage veloce e costoso. Quelli più vecchi possono passare a uno storage più economico, in cui le ricerche sono più lente. Il compromesso è semplice: più vecchio è l'evento, più tempo ci vuole a trovarlo.
La correlazione è il passaggio in cui il SIEM mette in relazione più eventi invece di guardare dentro uno solo. Una regola di correlazione descrive uno schema: una condizione, una finestra temporale e una chiave di raggruppamento. Quando lo schema compare, la regola crea un alert.
Questa è una regola per il password spraying scritta in linguaggio corrente. La proveremo nella sezione pratica.
Group events by source IP over a 10-minute window.
Count distinct user accounts with a failed login from that source.
If the count is 4 or more, and the same source later has a successful login,
create an alert with the source IP, the accounts and the successful login.Due cose rendono utile una regola così. Usa più di un evento, quindi un singolo login fallito non fa scattare niente. E raggruppa per una chiave adatta all'attacco. Chi indovina le password spesso prova una sola password su molti account da un unico punto, e questo andamento si vede bene quando raggruppi per origine.
Un alert afferma che qualcosa merita attenzione e non stabilisce che un attacco ci sia stato. Il triage è la prima decisione dopo che l'alert è scattato. L'analista si fa quattro domande: l'alert si basa su dati reali, l'account o l'host hanno importanza, che cosa è successo prima e dopo, qual è il passo successivo. Molti alert si chiudono qui come innocui, per esempio una scansione di vulnerabilità che hai lanciato tu o un utente che ha sbagliato a digitare la password dopo averla cambiata.
Il risultato di un buon triage è una decisione con una nota. La nota registra che cosa ha controllato l'analista, così chi viene dopo non rifà il lavoro. I team che saltano la nota finiscono per indagare di nuovo sullo stesso alert innocuo ogni settimana.
Nella maggior parte dei SOC tre termini compaiono insieme, e i loro ambiti si sovrappongono.
Un SIEM raccoglie e correla record da molte fonti in tutto l'ambiente. Il suo punto di forza sono l'ampiezza e lo storico. Il suo limite è che vede solo quello che ogni fonte riporta.
L'EDR, endpoint detection and response, osserva gli endpoint nel dettaglio. Registra attività dei processi, modifiche ai file e connessioni di rete su ogni host, e spesso può isolare una macchina. Il suo punto di forza è la profondità sull'endpoint. Un log del firewall o un audit trail del cloud non li vede, a meno che tu non glieli colleghi.
Il SOAR, security orchestration, automation and response, esegue playbook. Un playbook può arricchire un alert con una verifica di reputazione, aprire un ticket, disabilitare un account dopo un'approvazione o avvisare chi è di turno. Il suo punto di forza è una risposta ripetibile. I risultati dipendono dalla qualità degli alert che riceve.
Questo esercizio richiede Python 3.12 e nient'altro. I log sono sintetici e usano indirizzi di 192.0.2.0/24, un intervallo riservato alla documentazione. Non tocchi nessun sistema. Lo script legge le righe, le normalizza, applica la regola sul password spraying e stampa il risultato.
Salva questo file come siem_demo.py:
# Synthetic logs only. 192.0.2.0/24 is a documentation range (TEST-NET-1).
import re
from collections import defaultdict
RAW = """\
2026-11-07T10:00:01Z sshd[811]: Failed password for alice from 192.0.2.44 port 50111
2026-11-07T10:00:03Z sshd[812]: Failed password for bob from 192.0.2.44 port 50112
2026-11-07T10:00:05Z sshd[813]: Failed password for carol from 192.0.2.44 port 50113
2026-11-07T10:00:07Z sshd[814]: Failed password for dave from 192.0.2.44 port 50114
2026-11-07T10:00:09Z sshd[815]: Failed password for erin from 192.0.2.44 port 50115
2026-11-07T10:00:11Z sshd[816]: Accepted password for erin from 192.0.2.44 port 50116
2026-11-07T10:02:00Z sshd[820]: Accepted password for frank from 192.0.2.10 port 50200
2026-11-07T10:03:00Z sshd[821]: Failed password for frank from 192.0.2.10 port 50201
"""
PATTERN = re.compile(
r"^(?P<ts>\S+) sshd\[\d+\]: (?P<outcome>Failed|Accepted) password for "
r"(?P<user>\S+) from (?P<src>\S+) port \d+$"
)
def normalize(line):
m = PATTERN.match(line)
if not m:
return None
return {
"timestamp": m["ts"],
"event_type": "authentication",
"outcome": "success" if m["outcome"] == "Accepted" else "failure",
"user": m["user"],
"source_ip": m["src"],
}
events = [e for e in (normalize(l) for l in RAW.splitlines()) if e]
print(f"normalized {len(events)} events")
# Rule: one source IP fails against 4+ different accounts, then gets a success from that IP.
fails = defaultdict(set)
successes = defaultdict(list)
for e in events:
if e["outcome"] == "failure":
fails[e["source_ip"]].add(e["user"])
else:
successes[e["source_ip"]].append(e)
for ip, users in fails.items():
if len(users) >= 4 and successes.get(ip):
s = successes[ip][0]
print(f"ALERT src={ip} failed_accounts={len(users)} then_success_user={s['user']} at={s['timestamp']}")
print(" mapped: T1110 Brute Force, sub-technique T1110.003 Password Spraying (candidate)")Eseguilo dalla cartella in cui l'hai salvato:
python -I siem_demo.pyIl flag -I esegue Python in modalità isolata. Ignora le variabili d'ambiente e lascia la cartella dello script fuori dal percorso di importazione. È una buona abitudine quando esegui uno script che non hai scritto tu.
Sulla macchina Windows 11 su cui è stato verificato questo articolo, con Python 3.12.10, l'output è stato:
normalized 8 events
ALERT src=192.0.2.44 failed_accounts=5 then_success_user=erin at=2026-11-07T10:00:11Z
mapped: T1110 Brute Force, sub-technique T1110.003 Password Spraying (candidate)Lo script tiene la regola corta di proposito. Non applica la finestra di 10 minuti della versione in linguaggio corrente e non controlla che il successo sia arrivato dopo i fallimenti. Una regola in produzione farebbe entrambe le cose.
Da un solo indirizzo sono falliti gli accessi a cinque account in una decina di secondi. Poi erin ha fatto l'accesso con successo dallo stesso indirizzo. La regola è scattata perché entrambe le condizioni erano vere: molti account, pochi tentativi ciascuno, e poi un successo. Un errore di battitura o una password salvata di rado hanno questo aspetto.
Ora guarda la seconda origine, 192.0.2.10. Frank ha fatto l'accesso con successo, e più tardi è comparso un fallimento. La regola non è scattata, perché da quell'indirizzo sono falliti gli accessi a un solo account. La chiave di raggruppamento serve proprio a questo. Un login fallito è rumore. Accessi falliti su cinque account diversi da un unico punto sono uno schema.
Cambia i dati per vedere i compromessi. Se cancelli la riga del successo di erin, l'alert sparisce anche se i fallimenti restano, perché la regola ha bisogno di entrambi. Se alzi la soglia a 6, l'alert sparisce comunque, dato che gli account con accessi falliti sono solo cinque. In produzione, una regola più stretta si perde gli attacchi più lenti e una più larga scatta più spesso su comportamenti normali.
MITRE ATT&CK è una base di conoscenza pubblica sul comportamento degli avversari. Ogni tecnica ha un ID, una tattica e una descrizione, e le indicazioni di rilevamento di alcune tecniche elencano le fonti di dati che le rivelano.
L'alert rientra in T1110, Brute Force, sotto la tattica Credential Access. ATT&CK descrive il brute force come una serie di tentativi ripetuti di accedere ad account quando chi attacca non conosce la password. Elenca quattro sotto-tecniche. Password Spraying (T1110.003) significa provare una o poche password su molti account, così nessun singolo account viene bloccato. Password Guessing (T1110.001) prova molte password su un solo account. Credential Stuffing (T1110.004) riusa password trapelate da altri servizi. La pagina rimanda anche a una strategia di rilevamento che correla i fallimenti di autenticazione tra piattaforme diverse, la stessa idea della nostra piccola regola.
Fai caso alla parola "candidate" nell'output. La regola trova uno schema, e lo schema è compatibile con lo spraying. È compatibile anche con un servizio configurato male che prova diverse credenziali salvate, o con un test interno. Sta al triage capire quale dei casi sia. L'associazione ad ATT&CK ti dice dove guardare e quale comportamento collegato controllare dopo, come l'uso di account validi (T1078) dopo un login riuscito. Che l'attacco sia avvenuto, però, non lo dimostra.
Gran parte di queste cose si impara senza comprare niente. Due opzioni aperte coprono il percorso dalla raccolta all'alert. Installane una su una macchina di scorta o in una macchina virtuale.
La documentazione di Wazuh lo descrive come una piattaforma di sicurezza gratuita e open source che unisce funzioni XDR e SIEM. Ha tre componenti centrali, il Wazuh indexer, il Wazuh server e la Wazuh dashboard, più un agent universale da installare sui sistemi che monitori. La guida introduttiva propone un quickstart che installa lo stack in pochi minuti. Documenta anche installazioni passo per passo, macchine virtuali, Docker e Kubernetes. Controlla nella documentazione corrente la versione e i comandi esatti, perché cambiano da una release all'altra.
Per fare pratica, installa un agent su una macchina virtuale Linux. Da una seconda macchina virtuale sotto il tuo controllo fai fallire qualche login SSH, poi guarda gli eventi arrivare nella dashboard. Così copri raccolta, normalizzazione e alert su una pipeline reale.
Elastic Security documenta un SIEM costruito sull'Elastic Stack. La sua panoramica descrive la raccolta dei dati tramite le integrazioni e l'Elastic Agent, il rilevamento con regole predefinite, regole personalizzate e machine learning, il triage degli alert, Timeline per il threat hunting e Cases per registrare le indagini. Quali di queste funzioni include un'installazione self-managed dipende dal livello di licenza, quindi leggi la pagina degli abbonamenti di Elastic prima del deploy. La panoramica non elenca quali funzioni SIEM ottiene gratis un'installazione self-managed, quindi non dare per scontato che un livello gratuito copra una certa funzione di rilevamento.
Comincia dalla guida NIST SP 800-92. È di taglio organizzativo e di alto livello, quindi leggila per le domande che pone, come chi è responsabile di ogni fonte di log e per quanto tempo la conservi. Poi apri la pagina di ATT&CK su T1110 e leggi le note di rilevamento accanto alle sotto-tecniche.
A quel punto installa Wazuh o Elastic su una macchina virtuale e manda i log di una fonte che controlli. Scrivi una regola che corrisponda a uno schema che puoi far scattare di proposito, poi scrivi la nota di triage come se un collega dovesse riprenderla in mano domani.
Il prossimo articolo di questa serie tratta il registro eventi di Windows e gli event ID da cui dipendono molte regole di correlazione, così quelle regole diventano più facili da leggere: log eventi di Windows ed event ID. Se vuoi farti un'idea di come si scrive in pratica un singolo rilevamento, scrivere una regola YARA contro un file di test innocuo mostra la stessa idea: provare una regola su dati noti prima di fidarsene.
Rilevamento e blue team
Leggi il log Security di Windows: policy di audit, Event ID 4624, 4625, 4634, 4672, 4688 e 1102, cosa aggiunge Sysmon e un logon fallito da trovare da solo.
Rilevamento e blue team
Scrivi una regola Sigma per i logon Windows falliti, validala, convertila per Splunk e provala su eventi known-good e known-bad.