Segui Un ambiente aziendale genera eventi a milioni ogni ora. Durante un incidente, il responsabile raramente ha bisogno di tutti. Necessita dei pochi centinaia che raccontano la storia: l’esplosione di errori 4625 seguiti da un singolo successo 4624, il PowerShell codificato generato da winword.exe, il nuovo servizio installato alle 03:12 su un controller di dominio. L’analisi dei log è la disciplina che permette di passare dal primo numero al secondo abbastanza velocemente da contare.
Quel lavoro è diventato più difficile in due direzioni contemporaneamente. Gli attaccanti che utilizzano strumenti AI generano prove alla velocità delle macchine e riempiono le azioni reali con attività dall’aspetto innocuo. Nel frattempo, la scorciatoia ovvia di inserire i log in un LLM si scontra con guardrail, limiti della finestra di contesto e obblighi di protezione dei dati. I rispondenti di Hugging Face hanno colpito proprio quel muro a luglio 2026, quando circa 17.000 eventi sono stati rifiutati dai modelli di frontiera e hanno dovuto essere elaborati su un modello locale.
Di seguito, copriamo l’analisi dei log dall’inizio alla fine, poi diamo un’occhiata a LogTotal, la risposta gratuita di SOC Prime alla versione del problema legata al momento dell’incidente.
Quali sono i fondamenti dell’analisi dei log?
Ogni flusso di lavoro di analisi dei log, che avvenga in un SIEM, in un data lake o sul laptop di un rispondente, si basa sugli stessi cinque stadi. Saltarne uno di solito si presenta più tardi come un rilevamento mancato o un falso positivo che nessuno può spiegare.
- Raccolta. Agenti, forwarder syslog, poller API ed esportatori cloud-native spostano gli eventi fuori dalla fonte. Le lacune qui sono silenziose: una configurazione Sysmon che elimina l’ID Evento 10 (accesso ai processi) significa che il dump delle credenziali tramite LSASS non appare mai a valle.
- Parsing e normalizzazione. Le linee grezze diventano campi. Un IP di origine dovrebbe essere lo stesso campo, che provenga da un firewall, un IdP o un EDR, ecco perché esistono schemi come ECS e OCSF.
- Arricchimento. La criticità degli asset, il ruolo utente, il GeoIP e le informazioni sulle minacce trasformano un indirizzo IP in un contesto su cui un analista può agire.
- Correlazione. Gli eventi singoli raramente provano qualcosa. Collegarli per host, utente, GUID di processo o ID sessione è ciò che produce una narrazione di attacco.
- Conservazione e integrità. Archiviazione hot per la ricerca, archiviazione cold per la forense, e prove di manomissione affinché il record regga nel tempo.
Cos’è l’analisi dei log?
L’analisi dei log è il processo di esaminare registrazioni generate dalle macchine per ricostruire cosa è successo su un sistema, decidere se è importante e determinare cosa fare successivamente. Nelle operazioni di sicurezza, risponde a cinque domande su qualsiasi attività sospetta: chi ha agito, su quale asset, quando, da dove e con quale meccanismo.
È distinta dalla gestione dei log. La gestione è idraulica: ingestione, archiviazione, conservazione, controllo degli accessi. L’analisi è interpretazione. Una squadra può avere una pipeline di log ben gestita e comunque mancare un’intrusione perché nessuno, umano o macchina, sta ponendo le giuste domande ai dati.
In pratica, l’analisi dei log funziona in tre modalità:
- Rilevamento. Regole e modelli valutano gli eventi continuamente e alzano allarmi quando appare un comportamento noto malevolo.
- Indagine. Dopo un allarme o una segnalazione, gli analisti passano attraverso eventi correlati per delimitare l’incidente e trovare la causa radice.
- Caccia alle minacce. Gli analisti partono da un’ipotesi, come l’abuso di un determinato LOLBin, e cercano proattivamente prove che lo strato di rilevamento ha mancato.
Di tutti i team che utilizzano log, la sicurezza ha il minor margine per le lacune.
Perché l’analisi dei log è così importante?
Perché il tempo determina il costo della violazione, e i log sono dove il tempo si guadagna o si perde. Il rapporto del 2026 di IBM sul costo di una violazione dei dati stabilisce il tempo medio per identificare e contenere una violazione a 247 giorni, il primo aumento in cinque anni. Le violazioni con un ciclo di vita di oltre 200 giorni hanno avuto un costo medio di 5,65 milioni di dollari, contro 4,32 milioni di dollari per quelle contenute più rapidamente.
Oltre al costo, l’analisi dei log sostiene quattro obblighi che ogni programma di sicurezza deve soddisfare:
- Rilevamento. EDR e NDR vedono segmenti di attività. I log dai provider di identità, i registri di audit SaaS e i piani di controllo cloud riempiono le lacune tra di loro.
- Scoping e causa radice. Senza prove a livello di evento, i rispondenti non possono dire quali account sono stati toccati o come l’attaccante è entrato, quindi la remediation diventa congettura.
- Segnalazione regolamentare. Il requisito 10 del PCI DSS 4.0 obbliga la revisione dei log di audit e la conservazione per 12 mesi. L’Item 1.05 del modulo 8-K della SEC dà alle aziende quotate quattro giorni lavorativi dopo una determinazione di materialità, cosa impossibile senza un rapido scoping.
- Ingegneria di rilevamento. La telemetria reale è come le regole vengono testate e messe a punto.
C’è un problema. Gli stessi log che rendono tutto ciò possibile portano con sé nomi utente, indirizzi IP, cookie di sessione e token di autorizzazione. Analizzarli bene significa sempre più analizzarli in sicurezza.
Quali sono i tipi di dati di log?
I log rilevanti per la sicurezza si suddividono in sei famiglie. Ognuna risponde a una domanda diversa, e un’indagine che si basa solo su uno o due di essi avrà zone cieche in cui un attaccante può muoversi.
| Famiglia di log | Fonti tipiche | Cosa dice all’analista |
| Endpoint e OS | Windows Security (4624, 4688, 7045), Sysmon, Linux auditd, journal | Quale processo è stato eseguito, sotto quale account, con quale genitore e riga di comando |
| Identità | Active Directory (4768, 4769), accessi Entra ID, Okta System Log | Chi ha autenticato, da dove, con quale protocollo e risultato dell’MFA |
| Rete | Firewall, DNS, proxy web, Zeek, NetFlow | Chi ha parlato con chi, quanta dati si sono spostati, quali domini sono stati risolti |
| Piano di controllo cloud | AWS CloudTrail, Registro Attività Azure, GCP Audit Logs, audit di Kubernetes | Quali chiamate API hanno cambiato infrastrutture, ruoli o politiche |
| Applicazione e SaaS | Registri di accesso al server web, Unified Audit Log di Microsoft 365, Google Workspace | Cosa hanno fatto gli utenti all’interno di applicazioni aziendali e archivi dati |
| Controlli di sicurezza | EDR, IDS/IPS (Suricata), WAF, gateway email | Cosa altri strumenti hanno già segnalato e perché |
Le scoperte di maggior valore di solito si trovano nei punti di contatto. Un tentativo di Kerberoasting appare come un gruppo di richieste 4769 con crittografia RC4 nei log di identità. Dimostrare cosa ha fatto l’attaccante con l’account di servizio violato richiede poi dati di endpoint e cloud.
Quali sono i formati e le strutture comuni dei file di log?
I log variano da completamente strutturati a testo libero, e il carico della gestione del parsing scala di conseguenza. Quattro formati coprono la maggior parte di ciò che un SOC gestisce quotidianamente.
Syslog. Ancora la lingua franca per i dispositivi di rete e gli host Unix. L’RFC 3164 (BSD syslog) è definito in modo approssimativo e povero di timestamp. L’RFC 5424 aggiunge un campo di versione, timestamp ISO 8601, MSGID e un blocco STRUCTURED-DATA, ma il corpo del messaggio stesso è spesso testo libero specifico del vendor.
CEF. Il formato comune di eventi di ArcSight avvolge gli eventi in un’intestazione delimitata da pipe seguita da estensioni chiave=valore:
CEF:0|Acme|FW|7.2|4625|Logon failure|5|src=10.1.4.22 suser=jdoe dst=10.1.0.5
È facile da gestire ma superficiale, e i vendor mappano i campi in modo incoerente. LEEF, usato da QRadar, segue la stessa idea.
JSON e NDJSON. Il formato predefinito per i registri di audit cloud e SaaS. Un oggetto per linea rende NDJSON trasmissibile, mentre un annidamento profondo e gli array complicano l’appiattimento in uno schema fisso.
Windows EVTX. Un formato binario di record a blocchi che contengono dati evento XML. Non puoi eseguire il grep su di esso; ha bisogno di un parser dedicato, e i campi utili si trovano in EventData.
Un test pratico per qualsiasi strumento di analisi è se ingurgita nativamente tutti e quattro, senza che un analista debba scrivere script di conversione nel mezzo di un incidente.
Monitoraggio dei log in tempo reale
Il monitoraggio in tempo reale significa valutare gli eventi non appena arrivano piuttosto che in base a un programma di ricerca. Una query programmata del SIEM che viene eseguita ogni 15 minuti su una finestra di lookback di 20 minuti, con diversi minuti di ritardo nell’ingestione e nell’indicizzazione, può facilmente mettere mezz’ora tra l’azione di un attaccante e il primo allarme.
Le architetture in streaming colmano quel divario spostando la logica di rilevamento a monte. Gli eventi fluiscono attraverso un bus come Kafka o una pipeline come Cribl Stream, e le regole vengono valutate in tempo reale con finestre stateful per conteggi e sequenze. Solo eventi etichettati arricchiti e avvisi continuano al SIEM, il che riduce anche il costo di ingestione.
Tre problemi di ingegneria vengono con esso:
- Eventi in ritardo o fuori ordine. Le finestre hanno bisogno di watermark o periodi di grazia, altrimenti una sequenza suddivisa in un batch ritardato non viene mai completata.
- Gestione dello stato. Monitorare 10.000 host su una finestra di 30 minuti è un problema di memoria, non di query.
- Volume di allarme. Un rilevamento più veloce delle regole rumorose produce solo rumore più velocemente.
I pipeline in tempo reale hanno anche un punto cieco per design. Vedono solo ciò che è collegato a loro. I log estratti da un server isolato, un laptop di un contraente o una nuova filiale acquisita necessitano comunque di un’analisi rapida e autonoma.
Quali sono le principali tecniche di riconoscimento dei pattern nei log?
Il riconoscimento dei pattern nei log funziona a strati, dai singoli eventi a intere catene di attacco.
- Matching atomico. Un evento, una condizione: un hash noto malevolo, rundll32.exe che si carica da un percorso scrivibile dall’utente, una regola Sigma su una riga di comando sospetta. Veloce e preciso, ma cieco a tutto ciò che è solo malevolo nel contesto.
- Aggregazione e soglie. Conteggio su una finestra. Venti accessi falliti su un account suggeriscono un attacco brute force; un fallimento ciascuno su venti account dalla stessa fonte suggerisce uno spray di password. Stesso ID evento, pattern diverso.
- Correlazione di sequenza. Eventi ordinati in una finestra temporale, come un nuovo admin locale creato e poi usato per un login RDP entro dieci minuti.
- Baseline e rilevazione anomalie. Coppie processo genitore-figlio mai viste prima, stringhe user-agent rare, login al di fuori delle ore normali di un utente.
- Correlazione di ordine superiore. Regole che funzionano su rilevamenti piuttosto che su eventi grezzi, unendo colpi individuali in una catena mappata a tattiche MITRE ATT&CK. Questo è lo strato che trasforma 400 allarmi in un incidente.
Quali sono gli strumenti essenziali per l’analisi dei log?
Nessun prodotto singolo copre tutto il lavoro. I team maturi combinano strumenti di analisi dei log da quattro categorie.
| Categoria | Esempi | Meglio in |
| SIEM | Splunk, Microsoft Sentinel, Google SecOps, Elastic Security | Rilevamento centralizzato, triage degli allarmi, gestione dei casi |
| Pipeline di dati di sicurezza | Cribl Stream, Vector, Fluent Bit | Instradamento, filtraggio, normalizzazione e controllo dei costi prima dell’archiviazione |
| Data lakes | Amazon Security Lake (OCSF), Snowflake, ClickHouse | Conservazione a lungo termine economica e caccia su larga scala |
| Utilità DFIR | Hayabusa, Chainsaw, EvtxECmd, Velociraptor | Triage rapido degli artefatti raccolti, in particolare EVTX |
Il divario emerge durante la risposta agli incidenti. I SIEM presuppongono che i dati siano già stati acquisiti. Le utilità DFIR sono veloci ma eseguono un set di regole limitato e lasciano la correlazione all’analista. Gli LLM generali raggiungono limiti di contesto e rifiutano i contenuti relativi alla sicurezza. Un tool costruito per la prima ora di un incidente ha bisogno di una breve lista di proprietà:
- ingestione nativa di EVTX, syslog, CEF e JSON
- una libreria di rilevamento grande e mantenuta, non solo poche centinaia di regole
- correlazione in catene di attacco, non un elenco piatto di colpi
- risultati in minuti su infrastruttura comune
- un modello di privacy che superi la revisione di un DPO
Perché LogTotal è uno dei migliori?
LogTotal controlla ogni voce su quella lista, e lo fa gratuitamente. SOC Prime lo ha aperto come anteprima pubblica il 26 agosto 2026 e ha annunciato il rilascio generale il 15 ottobre. Il flusso di lavoro è semplice: carica, sanifica, ottieni un’indagine indietro.
| Requisito | Come LogTotal lo soddisfa |
| Formati nativi | Rileva automaticamente EVTX, JSON/NDJSON e syslog, senza passaggi di conversione |
| Profondità di rilevamento | Confronta gli eventi con circa 1.000.000 di regole di rilevamento e 13.000 etichette di minacce |
| Correlazione | Higher Order Sigma Rules e correlazione AI agenziali assemblano catene di attacco mappate a MITRE ATT&CK |
| Velocità | Fino a 1,7 milioni di eventi in meno di un minuto, circa 100 volte il set di log di Hugging Face |
| Privacy | La sanitizzazione avviene nel browser, nulla viene memorizzato e i dati del cliente non vengono utilizzati per l’addestramento |
La velocità non è un trucco della GPU. Il ragionamento su cosa ogni attacco sembri è stato fatto in anticipo e compilato nel contenuto di rilevamento, quindi il motore abbina e correla invece di generare token.
Il modello di privacy è ciò che fa superare a LogTotal la revisione legale. L’open-source @socprime/logtotal-sanitizer (Apache-2.0) sostituisce credenziali, IP, hostname e nomi utente con token HMAC stabili, così un utente su tre host rimane un’entità dopo redazione. Tu conservi la chiave. Ogni analisi viene eseguita su un’istanza usa e getta, immutabile, che viene eliminata successivamente.
Le scoperte arrivano come catene di attacco classificate, con bandiere per tecniche di stealth e i picchi di attività benigni tipici delle intrusioni guidate da AI.
Principali tendenze per l’analisi dei log nel 2026
Cinque cambiamenti stanno rimodellando come i team analizzano i log quest’anno.
- Gli attacchi alla velocità dell’AI cambiano l’aspetto del ‘sospetto’. IBM riferisce che più di una organizzazione su quattro ha affrontato un attacco guidato da AI, in aumento del 56% anno su anno. Le anomalie volumetriche nelle classi di eventi benigni stanno diventando un segnale di rilevamento a sé stante.
- Il SIEM si sta dividendo. Il ciclo delle aspettative di Gartner per le operazioni di sicurezza del 2026 mostra il mercato dividersi in piattaforme SOC integrate e data lakes di sicurezza, con agenti SOC AI al picco delle aspettative gonfiate. L’analisi avviene sempre più dove risiedono i dati.
- Il rilevamento si sposta nel pipeline. Eseguire regole sullo stream, prima dell’indicizzazione, riduce sia il tempo medio di rilevamento sia la spesa di ingestione.
- OCSF diventa lo schema condiviso. Dati normalizzati sono ciò che permette allo stesso rilevamento, o allo stesso agente AI, di funzionare tra i vendor.
- L’analisi che preserva la privacy diventa una pratica standard. IBM ha contato l’inclusione dell’AI ombra nel 43% degli incidenti, in aumento dal 20%. Incollare log grezzi in un chatbot è esattamente questo. La pseudonimizzazione a chiave prima che i log lascino l’organizzazione si sta trasformando da buona pratica in aspettativa.
Il filo comune è la velocità senza esposizione. Questo è il problema che LogTotal è stato costruito per risolvere, e non costa nulla testarlo sui propri log.
