Segui Un ambiente aziendale emette eventi a milioni ogni ora. Durante un incidente, il responsabile raramente ha bisogno di tutti. Serve i pochi centinaia che raccontano la storia: l’ondata 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 di passare dal primo numero al secondo abbastanza velocemente da fare la differenza.
Quel lavoro è diventato più difficile in due direzioni contemporaneamente. Gli attaccanti che utilizzano strumenti AI generano prove a velocità macchina e compensano le azioni reali con attività dall’aspetto benigno. Nel frattempo, la scorciatoia ovvia di inserire i log in un LLM si scontra con barriere di protezione, limiti delle finestre contestuali e obblighi di protezione dei dati. I responsabili di Hugging Face hanno incontrato esattamente questo muro a luglio 2026, quando circa 17.000 eventi sono stati rifiutati dai modelli di frontiera e hanno dovuto essere processati invece con un modello locale.
Di seguito, trattiamo l’analisi dei log end-to-end, quindi esaminiamo LogTotal, la risposta gratuita di SOC Prime alla versione del problema al momento dell’incidente.
Quali sono i Fondamentali dell’Analisi dei Log?
Ogni flusso di lavoro di analisi dei log, che si esegua in un SIEM, in un data lake o sul laptop di un risponditore, si basa sugli stessi cinque fasi. Saltarne una di solito si traduce in un mancato rilevamento o in un falso positivo che nessuno può spiegare.
- Raccolta. Agenti, reindirizzatori syslog, interrogatori API ed esportatori nativi del cloud spostano eventi dalla fonte. Le lacune qui sono silenziose: una configurazione Sysmon che elimina l’ID evento 10 (accesso a processi) significa che il dump delle credenziali tramite LSASS non appare mai a valle.
- Parsing e normalizzazione. Le righe grezze diventano campi. Un IP di origine dovrebbe essere lo stesso campo che provenga da un firewall, un IdP o un EDR, motivo per cui esistono schemi come ECS e OCSF.
- Arricchimento. Criticità degli asset, ruolo dell’utente, GeoIP e intelligence sulle minacce trasformano un indirizzo IP in un contesto su cui un analista può agire.
- Correlazione. I singoli eventi raramente provano qualcosa. Collegarli tramite host, utente, GUID del processo o ID della sessione è ciò che produce un racconto dell’attacco.
- Conservazione e integrità. Archiviazione a caldo per la ricerca, archiviazione a freddo per le analisi forensi e prove di manomissione in modo che il record si mantenga valido.
Cos’è l’Analisi dei Log?
L’analisi dei log è il processo di esame dei record generati da macchine per ricostruire ciò che è avvenuto su un sistema, decidere se è rilevante 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 è l’idraulica: acquisizione, archiviazione, conservazione, controllo dell’accesso. L’analisi è interpretazione. Un team può avere una pipeline di log ben gestita e comunque mancare un’intrusione perché nessuno, umano o macchina, sta facendo le domande giuste ai dati.
In pratica, l’analisi dei log funziona in tre modalità:
- Rilevamento. Regole e modelli valutano gli eventi continuamente e generano avvisi quando appare un comportamento noto come malevolo.
- Investigazione. Dopo un avviso o una segnalazione, gli analisti esaminano gli eventi correlati per delimitare l’incidente e trovare la causa principale.
- Caccia alle minacce. Gli analisti partono da un’ipotesi, come l’abuso di uno specifico LOLBin, e cercano proattivamente prove che il livello di rilevamento ha mancato.
Di tutti i team che utilizzano i log, la sicurezza ha lo spazio minore per le lacune.
Perché l’Analisi dei Log è Così Importante?
Perché il tempo guida il costo della violazione, e i log sono dove il tempo si guadagna o si perde. Il rapporto 2026 sul costo di una violazione dei dati di IBM pone 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 superiore ai 200 giorni hanno avuto una media di $ 5,65 milioni, contro i $ 4,32 milioni per quelle contenute più velocemente.
Oltre al costo, l’analisi dei log sostiene quattro obblighi che ogni programma di sicurezza deve affrontare:
- Rilevamento. EDR e NDR vedono porzioni di attività. I log dai provider di identità, le tracce di audit SaaS e i piani di controllo del cloud riempiono gli spazi vuoti tra di loro.
- Definizione del perimetro e causa principale. Senza prove a livello di evento, i responsabili non possono dire quali account sono stati toccati o come l’attaccante è entrato, quindi la remediation diventa un’ipotesi.
- Report regolatorio. Il requisito 10 della PCI DSS 4.0 obbliga alla revisione dei log di audit e a 12 mesi di conservazione. L’Item 1.05 del Modulo 8-K della SEC dà alle società quotate quattro giorni lavorativi dopo una determinazione di materialità, il che è impossibile senza una rapida definizione del perimetro.
- Ingegneria del rilevamento. La telemetria reale è il modo in cui le regole vengono testate e ottimizzate.
C’è un problema. Gli stessi log che rendono tutto ciò possibile trasportano nomi utente, indirizzi IP, cookie di sessione e token di accesso. Analizzarli bene significa sempre di più analizzarli in sicurezza.
Quali Sono i Tipi di Dati dei Log?
I log rilevanti per la sicurezza ricadono in sei famiglie. Ognuna risponde a una domanda diversa, e un’indagine che si basa solo su una o due di loro avrà punti ciechi in cui un attaccante può restare.
| Famiglia di log | Fonti tipiche | Cosa rivela all’analista |
| Endpoint e OS | Windows Security (4624, 4688, 7045), Sysmon, auditd Linux, journald | Quale processo è stato eseguito, sotto quale account, con quale padre 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 MFA |
| Rete | Firewall, DNS, proxy web, Zeek, NetFlow | Chi ha parlato con chi, quanta logistica dati è stata spostata, quali dominî sono stati risolti |
| Piano di controllo del cloud | AWS CloudTrail, Azure Activity Log, GCP Audit Logs, audit di Kubernetes | Quali chiamate API hanno modificato l’infrastruttura, i ruoli o le politiche |
| Applicazioni e SaaS | Log degli accessi al server web, Microsoft 365 Unified Audit Log, Google Workspace | Cosa hanno fatto gli utenti all’interno delle applicazioni aziendali e dei magazzini di dati |
| Controlli di sicurezza | EDR, IDS/IPS (Suricata), WAF, gateway di posta elettronica | Cosa hanno già segnalato altri strumenti e perché |
I risultati di maggior valore solitamente si trovano nelle cuciture. Un tentativo di Kerberoasting appare come un cluster di richieste 4769 con crittografia RC4 nei log di identità. Provare cosa ha fatto l’attaccante con l’account di servizio decodificato richiede poi dati endpoint e cloud.
Quali Sono i Formati e le Strutture Comuni dei File di Log?
I log vanno da completamente strutturati a testo libero, e il carico di parsing aumenta di conseguenza. Quattro formati coprono la maggior parte di ciò che un SOC gestisce giorno per giorno.
Syslog. Ancora la lingua franca per dispositivi di rete e host Unix. L’RFC 3164 (BSD syslog) è vagamente definita e povera 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 fornitore.
CEF. Il Common Event Format di ArcSight avvolge gli eventi in un’intestazione delimitata da pipe seguita da estensioni chiave=valore:
CEF:0|Acme|FW|7.2|4625|Logon fallito|5|src=10.1.4.22 suser=jdoe dst=10.1.0.5
È facile da analizzare ma superficiale, e i fornitori mappano i campi in modo incoerente. LEEF, utilizzato da QRadar, segue la stessa idea.
JSON e NDJSON. Il default per i log di audit del cloud e SaaS. Un oggetto per linea rende NDJSON trasmissibile in stream, mentre il nesting profondo e gli array complicano l’appiattimento in uno schema fisso.
Windows EVTX. Un formato binario di record suddivisi che contengono dati degli eventi XML. Non puoi cercarlo con grep; necessita di un parser dedicato, e i campi utili si trovano in EventData.
Un test pratico per qualsiasi strumento di analisi è se è in grado di ingerire tutti e quattro i formati nativamente, senza che un analista debba scrivere script di conversione nel mezzo di un incidente.
Monitoraggio in Tempo Reale dei Log
Il monitoraggio in tempo reale significa valutare gli eventi mentre arrivano piuttosto che su una pianificazione di ricerca. Una query SIEM programmata che esegue ogni 15 minuti una finestra di ritardo di 20 minuti, dietro diversi minuti di latenza di inserimento e indicizzazione, può facilmente mettere mezz’ora tra l’azione di un attaccante e il primo avviso.
Le architetture di streaming chiudono 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 sono valutate al volo con finestre con stato per conteggi e sequenze. Solo gli eventi arricchiti, etichettati e gli avvisi continuano al SIEM, il che riduce anche il costo di inserimento.
Ci sono tre problemi di ingegneria con esso:
- Eventi tardivi e fuori ordine. Le finestre necessitano di segnaletiche di tempo o periodi di tolleranza, altrimenti una sequenza suddivisa tra un batch ritardato non si completa mai.
- Gestione dello stato. Monitorare 10.000 host su una finestra di 30 minuti è un problema di memoria, non un problema di query.
- Volume di avvisi. Il rilevamento più rapido di regole rumorose produce solo rumore più rapidamente.
Le pipeline in tempo reale hanno anche un punto cieco per design. Vedono solo ciò che è cablato in esse. I log estratti da un server isolato, un laptop di un appaltatore o una consociata appena acquisita necessitano ancora di un’analisi autonoma veloce.
Quali Sono le Principali Tecniche di Riconoscimento di Pattern nei Log?
Il riconoscimento di pattern nei log funziona a strati, da eventi singoli fino a catene di attacchi intere.
- Corrispondenza atomica. Un evento, una condizione: un hash noto-malevolo, rundll32.exe caricato da un percorso scrivibile dall’utente, una regola Sigma su una riga di comando sospetta. Rapido e preciso, ma cieco a qualsiasi cosa sia malevola solo nel contesto.
- Aggregazione e soglie. Conteggio su una finestra. Venti tentativi falliti di accesso allo stesso account suggeriscono forza bruta; un tentativo fallito ciascuno contro venti account dalla stessa fonte suggerisce spruzzatura di password. Stesso ID evento, pattern diverso.
- Correlazione di sequenza. Eventi ordinati all’interno di una finestra temporale, come l’introduzione di un nuovo amministratore locale e quindi utilizzato per un accesso RDP entro dieci minuti.
- Baselining e rilevamento anomalie. Coppie di processi genitore-figlio viste per la prima volta, stringhe degli user-agent rare, accessi al di fuori delle ore normali di un utente.
- Correlazione di ordine superiore. Regole che operano su rilevamenti anziché eventi grezzi, cucendo insieme singoli colpi in una catena mappata alle tattiche MITRE ATT&CK. Questo è lo strato che trasforma 400 avvisi in un incidente.
Quali Sono gli Strumenti Essenziali per l’Analisi dei Log?
Nessun prodotto copre l’intero lavoro. I team maturi combinano strumenti di analisi dei log in quattro categorie.
| Categoria | Esempi | Eccelle in |
| SIEM | Splunk, Microsoft Sentinel, Google SecOps, Elastic Security | Rilevamento centralizzato, triage degli avvisi, gestione dei casi |
| Pipeline di dati di sicurezza | Cribl Stream, Vector, Fluent Bit | Routing, filtraggio, normalizzazione e controllo dei costi prima dello stoccaggio |
| Data lake | Amazon Security Lake (OCSF), Snowflake, ClickHouse | Conservazione a lungo termine a basso costo e ricerca su larga scala |
| Utility DFIR | Hayabusa, Chainsaw, EvtxECmd, Velociraptor | Triage rapido degli artefatti raccolti, soprattutto EVTX |
La lacuna si manifesta durante la risposta agli incidenti. I SIEM presumono che i dati siano già a bordo. Le utility DFIR sono rapide ma eseguono un set di regole limitato e lasciano la correlazione all’analista. Gli LLM generali raggiungono i limiti del contesto e rifiutano il contenuto di sicurezza. Uno strumento costruito per la prima ora di un incidente necessita di una lista breve di proprietà:
- acquisizione nativa di EVTX, syslog, CEF e JSON
- una grande libreria di rilevamento che viene mantenuta, non poche centinaia di regole
- correlazione in catene di attacco, non una lista piatta di colpi
- risultati in minuti su infrastruttura comune
- un modello di privacy che sopravvive alla revisione di un IPO
Perché LogTotal è Uno dei Migliori?
LogTotal spunta ogni elemento di quella lista, e lo fa gratuitamente. SOC Prime lo ha aperto come una anteprima pubblica il 26 agosto 2026 e ha annunciato il rilascio generale il 15 ottobre. Il flusso di lavoro è semplice: carica, sanitizza, ricevi un’indagine di ritorno.
| Requisito | Come LogTotal lo soddisfa |
| Formati nativi | Rileva automaticamente EVTX, JSON/NDJSON e syslog, senza un passaggio di conversione |
| Profondità di rilevamento | Confronta gli eventi con circa 1.000.000 di regole di rilevamento e 13.000 etichette di minacce |
| Correlazione | Regole Sigma Ordine Superiore più correlazione AI agentica assemblano catene di attacco mappate alle 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 GPU. Il ragionamento su come appare ciascun attacco è stato fatto in anticipo e compilato nel contenuto di rilevamento, quindi il motore corrisponde e correla piuttosto che generare token.
Il modello di privacy è ciò che fa superare LogTotal al controllo legale. L’open-source @socprime/logtotal-sanitizer (Apache-2.0) scambia credenziali, IP, nomi host e nomi utente con token HMAC stabili, quindi un utente su tre host rimane un’entità dopo la redazione. Tieni tu la chiave. Ogni analisi viene eseguita su un’istanza monouso, immutabile, che viene cancellata successivamente.
I risultati arrivano sotto forma di catene di attacco classificate, con bandiere per tecniche di stealth e i picchi di attività benigna tipici delle intrusioni guidate dall’AI.
Principali Tendenze per l’Analisi dei Log nel 2026
Cinque cambiamenti stanno rimodellando il modo in cui i team analizzano i log quest’anno.
- Gli attacchi a velocità AI cambiano ciò che appare “sospetto”. IBM riferisce che più di un’organizzazione su quattro ha affrontato un attacco guidato dall’AI, in aumento del 56% anno su anno. Le anomalie di volume in classi di eventi benigni stanno diventando un segnale di rilevamento di per sé.
- Il SIEM si sta dividendo. Il Ciclo di Iperattese di Gartner per le Operazioni di Sicurezza 2026 mostra il mercato dividersi in piattaforme SOC integrate e data lake di sicurezza, con agenti SOC AI al picco delle aspettative inflazionate. L’analisi avviene sempre più dove i dati risiedono.
- Il rilevamento si sposta nella pipeline. Eseguire regole sul flusso, prima dell’indicizzazione, riduce sia il tempo medio di rilevamento che la spesa di inserzione.
- L’OCSF diventa lo schema condiviso. I dati normalizzati sono ciò che consente alla stessa detection, o allo stesso agente AI, di funzionare tra i vari fornitori.
- L’analisi che preserva la privacy diventa prassi standard. IBM ha contato il coinvolgimento dell’AI ombra nel 43% degli incidenti, in aumento rispetto al 20%. Incollare log grezzi in un chatbot è esattamente questo. La pseudonimizzazione con chiave prima che i log escano dall’organizzazione si sta trasformando da buona pratica a un’aspettativa.
Il filo comune è velocità senza esposizione. Questo è il problema che LogTotal è stato costruito per risolvere, e non costa nulla testarlo sui tuoi log.
