Fondamenti di KQL che Ogni Analista SOC Dovrebbe Conoscere

Kusto Query Language (KQL) è la base della threat hunting e della triage degli alert in Microsoft Sentinel e Microsoft Defender. Se lavori in un SOC, la fluidità in KQL distingue gli analisti che riescono a rispondere rapidamente a "cosa è successo qui?" da quelli bloccati a cliccare sui dashboard. Questo non è un riferimento completo del linguaggio — è il sottoinsieme pratico che viene usato costantemente durante i turni.

Perché KQL Conta nel SOC

KQL è read-only e ottimizzato per interrogare enormi dataset di log velocemente. Sentinel, Defender for Endpoint, Azure Monitor e Log Analytics lo parlano tutti. Una volta che lo conosci, puoi passare tra i prodotti con lo stesso modello mentale: scegli una tabella, filtrala, dai forma all'output. Ogni investigazione — triage del phishing, hunt del movimento laterale, tuning dei falsi positivi — inizia con una query.

La Pipe È Tutto

Le query KQL sono costruite come una pipeline. Inizi con una tabella e passi i dati attraverso una serie di operatori, ognuno filtrando, trasformando o riepilogando il risultato precedente:

SecurityEvent
| where EventID == 4625
| where TimeGenerated > ago(24h)
| summarize FailedLogons = count() by Account, Computer
| sort by FailedLogons desc

Leggilo da cima a fondo come una frase: inizia con i log di SecurityEvent, mantieni solo i failed logons (4625), ristringa all'ultimo giorno, conta i fallimenti per account/computer, poi ordina. Quella leggibilità lineare è il punto di forza più grande di KQL rispetto a SQL per la hunting ad hoc.

Operatori Principali da Memorizzare

• where — il tuo filtro primario. Usalo presto e spesso per ridurre il volume di dati prima delle operazioni costose.
• project — seleziona e rinomina colonne specifiche, scartando il rumore che non ti serve nell'output.
• extend — aggiungi colonne calcolate senza eliminare quelle esistenti, utile per analizzare stringhe o contrassegnare condizioni.
• summarize — aggrega dati con count(), sum(), dcount(), o make_set(), quasi sempre abbinato a by.
• join — correla tra tabelle, ad esempio collegando i log di sign-in all'inventario dei dispositivi per individuare sign-on da dispositivi non gestiti.
• render — visualizza i risultati come un timechart o barchart direttamente nell'editor di query, utile per individuare picchi.

Time Filtering Fatto Bene

Filtra sempre su TimeGenerated (o la colonna timestamp equivalente della tabella) il più presto possibile nella pipeline. I motori KQL si ottimizzano pesantemente intorno ai filtri di intervallo di tempo, e mettere | where TimeGenerated > ago(7d) vicino all'inizio invece che alla fine può fare la differenza tra una query che ritorna in secondi e una che va in timeout su un tenant occupato.```kql SigninLogs | where TimeGenerated > ago(1h) | where ResultType != "0" | where UserPrincipalName has "@yourdomain.com"

## String Matching: has vs contains vs ==

Un errore comune è usare `contains` per tutto. `has` corrisponde a termini interi e usa un indice di termini, rendendolo drammaticamente più veloce su tabelle grandi. Usa `contains` solo quando hai bisogno di corrispondenze di substring all'interno di una parola (come un frammento di dominio parziale), e usa `==` per le corrispondenze esatte su campi strutturati come EventID o IPAddress. Questa abitudine da sola accelera notevolmente le hunt su tabelle ad alto volume come `DeviceNetworkEvents` o `CommonSecurityLog`.```kql
DeviceProcessEvents
| where ProcessCommandLine has "powershell"
| where ProcessCommandLine has_any ("-enc", "-EncodedCommand")

Costruire Logica di Rilevamento Riutilizzabile

Una volta che una query si rivela utile, racchiudila come funzione con let, o salvala come Sentinel Analytics Rule con esecuzione pianificata. Parametrizza le soglie (come i conteggi di failed logon) in modo che la stessa logica si ridimensioni su più tenant o venga tuning senza riscrivere da zero. Così le query di hunting occasionali si evolvono in rilevamenti permanenti che avvisano il SOC automaticamente.

Errori Comuni

• Dimenticare i filtri TimeGenerated, causando scansioni lente e costose di intera tabella.
• Usare summarize prima di where, che forza il motore ad aggregare dati non filtrati.
• Nomi di colonna non corrispondenti quando unisci tabelle — controlla sempre lo schema con getschema prima.
• Overusing di contains, che salta i vantaggi dell'indicizzazione e rallenta le hunt su larga scala.

KQL ricompensa gli analisti che pensano in pipeline piuttosto che in subquery nidificate. Inizia ogni investigazione con una finestra di tempo stretta e una tabella specifica, poi allarga solo se necessario.

Se questo ti ha dato una solida base, esplora i segmenti Blue Team e Digital Forensics su Korra Studio per altre procedure dettagliate di query SOC e esercizi di costruzione di rilevamenti.