Analisi dei Log con LogTotal

Cos’è l’analisi dei log?

L’analisi dei log è la pratica di raccogliere, analizzare, normalizzare e interrogare i record di eventi generati da macchine per rispondere a una domanda operativa o di sicurezza. In un SOC, questa domanda è solitamente ristretta: questo account si è autenticato da una fonte inattesa, questo host ha avviato un processo figlio insolito, quali chiamate API hanno preceduto il trasferimento dei dati.

Il materiale grezzo è eterogeneo: canali di sicurezza e Sysmon di Windows in file .evtx, output di auth.log e journald di Linux, eventi di firewall e proxy in CEF, e tracce di audit cloud come AWS CloudTrail o log di accesso di Microsoft Entra ID esportati come JSON.

Una pipeline funzionante di analisi dei log ha quattro fasi:

1. Raccolta. Esporta eventi dalla fonte senza perdere campi o timestamp.
2. Normalizzazione. Mappa src_ip, IpAddress e sourceIPAddress su uno schema comune.
3. Rilevazione. Esegui Sigma o regole del venditore e tagga ogni rilevamento con tecniche MITRE ATT&CK.
4. Correlazione. Raggruppa i rilevamenti correlati in una sequenza temporale o catena di attacco che un analista può convalidare.

Perché l’analisi dei log è importante per il rilevamento e la risposta

I log sono spesso l’unica traccia che sopravvive a un’intrusione. La telemetria degli EDR viene sovrascritta, la memoria si perde al riavvio, e la cattura pacchetti è raramente attiva quando necessario. Gli ID evento di Windows 4624, 4672 e 4688, o le chiamate CloudTrail come ConsoleLogin e CreateAccessKey, sono tipicamente le prove principali per delimitare un incidente.

Tre pressioni fanno dell’analisi dei log una competenza centrale del SOC piuttosto che una funzionalità SIEM:

• Volume. Un singolo incidente può produrre milioni di eventi, e grep trova solo ciò che già sai cercare.
• Vuoti di copertura. Laptop di contrattisti, segmenti OT, e tenant SaaS che nessuno ha collegato non sono nel SIEM, ma i loro log necessitano comunque di analisi.
• Gestione dei dati. I log contengono nomi utente, nomi host, IP, cookie di sessione e token di accesso. Nell’ambito del GDPR molto di ciò è considerato dato personale, e un token trapelato è un percorso di accesso attivo.

Ogni log allegato a un ticket del venditore o incollato in una chat AI allarga il cerchio di persone e giurisdizioni che possono leggere i valori originali. Una buona analisi dei log risponde rapidamente alla domanda senza creare un secondo incidente.

Una breve storia dell’analisi dei log

Syslog, scritto da Eric Allman per Sendmail nei primi anni ’80, fu successivamente standardizzato nelle RFC 3164 (2001) e RFC 5424 (2009). Per due decenni, l’analisi dei log significava grep e awk su un server syslog centrale.

Windows ha adottato una struttura. Windows Vista ha sostituito il formato legacy .evt con il formato .evtx basato su XML e il modello di canale ancora usato oggi, e Sysmon (2014) ha aggiunto telemetria di processo e di rete ad alta fedeltà.

La metà degli anni 2000 ha portato il SIEM. ArcSight, QRadar e successivamente Splunk hanno reso la ricerca centralizzata e la correlazione una categoria di prodotto, e il CEF di ArcSight è ancora emesso dalla maggior parte degli apparecchi di rete. Gli anni 2010 hanno aggiunto stack aperti come ELK e tracce di audit cloud come CloudTrail (2013).

Nel 2017, Sigma ha dato ai difensori un formato di regole neutrale rispetto al fornitore. Lo stesso anno, SOC Prime ha iniziato a taggare le regole Sigma con tecniche MITRE ATT&CK e ha applicato l’approccio all’indagine pubblica su NotPetya. La mappatura ATT&CK è da allora diventata un’aspettativa predefinita per i contenuti di rilevamento.

Verso dove sta andando l’analisi dei log

La rilevazione si muove a monte. I team eseguono regole Sigma su eventi in streaming nella pipeline prima che i dati raggiungano il SIEM, riducendo i costi di archiviazione e riducendo il tempo medio di rilevamento da ore a minuti.

La correlazione batte gli avvisi singoli. Corrispondenze isolate e a bassa fedeltà sono rumore. Una logica di ordine superiore che collega tecniche attraverso host e finestre temporali in catene di attacco offre agli analisti qualcosa da confermare o chiudere.

La triage AI incontra i limiti di gestione dei dati. I modelli LLM spiegano bene gli alberi di processo e riassumono le timeline, ma inviare telemetria grezza a un fornitore di modelli solleva questioni di privacy e contrattuali, e i modelli avanzati possono rifiutare i contenuti di sicurezza del tutto. Durante la risposta all’incidente HuggingFace di luglio 2026, un tentativo di inviare circa 17.000 eventi a modelli di frontiera è stato bloccato da protezioni.

La pseudonimizzazione diventa una fase della pipeline. La mascheratura statica distrugge la correlazione, e gli hash semplici possono essere invertiti con il dizionario. I token HMAC con chiave mantengono intatte le relazioni mentre rimuovono i valori. Aspettati questo passaggio davanti a ogni destinazione esterna: servizi AI, supporto del venditore, MSSP, e data lake condivisi.

Benefici dell’analisi dei log

• Scoping più veloce per i soccorritori di incidenti. Una timeline correlata risponde “quali host, quali account, da quando” in pochi minuti, il che accelera il contenimento e riduce il tempo di permanenza.
• Rilevazioni convalidate per ingegneri. Il replay dei log contro la logica delle regole mostra quali regole Sigma si attivano, quali sono rumorose e quali tecniche ATT&CK non hanno copertura.
• Evidenza di conformità. Il requisito 10 del PCI DSS, il controllo A.8.15 della ISO/IEC 27001 e il NIS2 si aspettano che gli eventi di sicurezza vengano registrati e rivisti.
• Causa principale per gli amministratori. L’output di journalctl che spiega un servizio fallito spesso rivela una configurazione errata che un attaccante potrebbe sfruttare.
• Costi di SIEM inferiori. È possibile analizzare una fonte di breve durata una sola volta senza integrarla.
• Collaborazione più sicura. I log pseudonimizzati permettono a un abbonato, MSSP o TAC di vendor di raggruppare host e utenti senza vedere le identità reali.

Casi d’uso per l’analisi dei log

Triage degli host non gestiti. Il laptop di un contrattista senza EDR è sospettato di compromissione. Esporta i log di Security, Sysmon e PowerShell e verifica i risultati di LogTotal per accesso alle credenziali (T1003), esecuzione di PowerShell (T1059.001), e task pianificati (T1053.005) prima di reimaging.

Compromissione di account cloud. Dopo un ConsoleLogin sconosciuto, estrai 72 ore di CloudTrail e accessi Entra ID e cerca nuove chiavi di accesso, modifiche MFA, e modifiche alle politiche IAM.

Ritenuta IR esterna e TAC del venditore. Sanifica le prove con una chiave che conservi. La terza parte clusterizza ancora host e utenti per token, e tu mappi i token internamente.

Ingegneria della rilevazione. Ripeti i log Atomic Red Team o Caldera per confermare quali regole si attivano, quindi sanifica i risultati prima che raggiungano Git o CI artifacts.

Revisioni sulla privacy. La pseudonimizzazione con chiave è una misura tecnica documentabile ai sensi dell’Articolo 32 del GDPR: cosa è stato sostituito, come sono stati generati i token, chi detiene la chiave.

Come effettuare l’analisi dei log: individua ed esporta i log per piattaforma

Ogni procedura sotto termina in un formato che LogTotal legge nativamente: EVTX, CEF, JSON/NDJSON, o syslog. Fissa la finestra di tempo UTC e l’intervallo prima, e hash ogni esportazione (Get-FileHash o sha256sum) per la catena di custodia.

Windows (EVTX). Richiede una shell elevata come amministratore locale. I file .evtx live sotto %SystemRoot%System32winevtLogs sono bloccati dal servizio Log eventi, quindi esportali con wevtutil:

wevtutil epl Security C:IRSecurity.evtx

wevtutil epl “Microsoft-Windows-Sysmon/Operational” C:IRSysmon.evtx

Aggiungi /q:”*[System[TimeCreated[timediff(@SystemTime) <= 86400000]]]” per limitare l’esportazione a 24 ore. Percorso GUI: eventvwr.msc → Log di Windows → Sicurezza → Salva tutti gli eventi come…

Linux (syslog o NDJSON). Richiede root o appartenenza a adm / systemd-journal. Copia /var/log/auth.log (Debian/Ubuntu) o /var/log/secure (RHEL). Per journald:

sudo journalctl –since “2026-10-20” –until “2026-10-21” –utc -o json > host01.ndjson

AWS CloudTrail (JSON). Richiede cloudtrail:LookupEvents. CloudTrail → Cronologia eventi → Scarica eventi → Scarica JSON copre 90 giorni di eventi di gestione. Da un bucket tracciato (s3:GetObject, kms:Decrypt), appiattisci i record in NDJSON:

zcat ./ct/*.json.gz | jq -c ‘.Records[]’ > cloudtrail.ndjson

Microsoft Entra ID e Microsoft 365 (JSON). Centro amministrativo di Entra → Identità → Monitoraggio & salute → Log di accesso → Download → JSON (ruolo Lettore dei rapporti). Per i dati di audit Purview, salta l’esportazione CSV e recupera direttamente il JSON (ruolo Log di audit):

Search-UnifiedAuditLog -StartDate 2026-10-20 -EndDate 2026-10-21 -ResultSize 5000 |

  Select-Object -ExpandProperty AuditData | Out-File .m365.ndjson -Encoding utf8

Dispositivi di rete (CEF). Passa il dispositivo a CEF (su FortiGate: config log syslogd setting → set format cef) ed esporta le righe contenenti CEF:0| dal collettore syslog.

Offerte SOC Prime per l’analisi dei log

• Threat Detection Marketplace: oltre 1.000.000 di regole di rilevazione native Sigma, tradotte in lingue SIEM, EDR e data lake e taggate con ATT&CK.
• Prime Hunt: esamina dati storici SIEM, EDR e di data lake con regole pertinenti e deduce Catene di Attacco dai risultati.
• Prime Detect: esegue regole Sigma su eventi in streaming prima del SIEM e le correla in catene di attacco in tempo reale.
• Uncoder.IO: traduce regole Sigma e Roota in query native.
• LogTotal: analisi gratuita senza registrazione di file di log esportati con sanificazione nel browser.
• logtotal-sanitizer: il motore Apache 2.0 dietro LogTotal, come libreria Node.js e CLI per uso on-premise o in aree isolate.

LogTotal copre il caso di cui si occupa questa guida: un file da una fonte esterna al tuo SIEM, o che non puoi condividere grezzo. Ogni analisi viene eseguita su un’istanza dedicata e usa e getta del motore DetectFlow di SOC Prime e viene eliminata successivamente.

Come funziona l’analisi dei log con LogTotal

LogTotal è gratuito, non richiede account e sanifica i file nel tuo browser prima che qualcosa venga caricato. SOC Prime non conserva i log dopo l’analisi né si addestra su di essi.

1. Apri logtotal.com in una versione recente di Chromium, Firefox o Safari.
2. Carica l’esportazione. Trascina il file .evtx, .log, .json o .ndjson. Il formato viene rilevato automaticamente.
3. Rivedi la sanificazione. Segreti, cookie, ID di pagamento, IP, nomi host, nomi utente e percorsi di home directory diventano token HMAC-SHA-256 con chiave come <USER:…> o <IP:…>. I valori identici ottengono token identici, così dieci account sparsi sembrano ancora dieci utenti.
4. Scarica la copia sanificata per il tuo fascicolo del caso. È esattamente ciò che è stato analizzato.
5. Esegui l’analisi. Gli eventi vengono controllati contro circa 1.000.000 di regole di rilevamento e 13.000 etichette, quindi correlati con regole Sigma di ordine superiore e AI agentica. SOC Prime cita fino a 1,7 milioni di eventi in meno di un minuto.
6. Leggi i risultati. Le rilevazioni sono mappate su ATT&CK, raggruppate in catene di attacco, e spiegate dall’AI. Un token che appare sia nelle rilevazioni di accesso alle credenziali che di movimento laterale è il tuo account da resettare.

Per diversi host, o quando i caricamenti nel browser sono proibiti, sanifica localmente con il CLI open-source (Node.js 20+) e riutilizza una chiave in modo che i token corrispondano tra i file:

npm install -g @socprime/logtotal-sanitizer

logtotal-sanitize ./dc01.log -o ./dc01.sanitized.log –print-key

logtotal-sanitize ./ws17.log -o ./ws17.sanitized.log –key “$KEY”