KQL-basiskennis voor elke SOC-analist

Kusto Query Language (KQL) is de basis van threat hunting en alert triage in Microsoft Sentinel en Microsoft Defender. Als je in een SOC werkt, bepaalt KQL-vaardigheid het verschil tussen analisten die snel "wat is hier gebeurd?" kunnen beantwoorden en degenen die vastzitten aan het doorklikken van dashboards. Dit is geen volledige taalreferentie — het is de praktische subset die constant tijdens diensten wordt gebruikt.

Waarom KQL in de SOC uitmaakt

KQL is alleen-lezen en geoptimaliseerd voor het snel bevragen van enorme logbestanden. Sentinel, Defender for Endpoint, Azure Monitor en Log Analytics spreken het allemaal. Als je het eenmaal kent, kun je tussen producten schakelen met hetzelfde mentale model: kies een tabel, filter deze, vorm de output. Elk onderzoek — phishing-triage, lateral movement hunts, false-positive tuning — begint met een query.

De Pipe Is Alles

KQL-queries zijn opgebouwd als een pijplijn. Je begint met een tabel en geeft gegevens door een reeks operators, die elk het vorige resultaat filteren, transformeren of samenvatten:

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

Lees het van boven naar beneden als een zin: begin met SecurityEvent-logboeken, hou alleen mislukte aanmeldingen (4625), beperk tot de afgelopen dag, tel mislukkingen per account/computer, sorteer vervolgens. Die lineaire leesbaarheid is KQL's grootste sterkte ten opzichte van SQL voor ad hoc hunting.

Kernoperators om te onthouden

• where — je primaire filter. Gebruik het vroeg en vaak om gegevensvolume te verminderen voordat dure operaties worden uitgevoerd.
• project — selecteer en hernoem specifieke kolommen, verwijder ruis die je niet in de uitvoer nodig hebt.
• extend — voeg berekende kolommen toe zonder bestaande kolommen te verwijderen, handig voor het parseren van strings of het markeren van voorwaarden.
• summarize — aggregeer gegevens met count(), sum(), dcount() of make_set(), bijna altijd gekoppeld aan by.
• join — correleer tussen tabellen, bijvoorbeeld koppel aanmeldingslogboeken aan apparaatinventaris om aanmeldingen van onbeheerde apparaten op te sporen.
• render — visualiseer resultaten als timechart of barchart rechtstreeks in de query-editor, handig voor het opspotten van pieken.

Tijdsfiltering correct doen

Filter altijd op TimeGenerated (of de equivalente tijdstempelkolom van de tabel) zo vroeg mogelijk in de pijplijn. KQL-engines optimaliseren zwaar rond tijdbereikfilters, en het plaatsen van | where TimeGenerated > ago(7d) aan de bovenkant in plaats van aan de onderkant kan het verschil betekenen tussen een query die in seconden terugkeert en een query die een time-out krijgt op een drukke tenant.```kql SigninLogs | where TimeGenerated > ago(1h) | where ResultType != "0" | where UserPrincipalName has "@yourdomain.com"

## Stringovereenkomsten: has vs contains vs ==

Een veelgebruikte fout is standaard `contains` voor alles gebruiken. `has` komt overeen met hele termen en gebruikt een term-index, waardoor het aanzienlijk sneller is op grote tabellen. Gebruik `contains` alleen wanneer je substring-overeenkomsten in een woord nodig hebt (zoals een gedeeltelijk domeingedeelte), en gebruik `==` voor exacte overeenkomsten op gestructureerde velden zoals EventID of IPAddress. Deze ene gewoonte versnelt hunts merkbaar in high-volume tabellen zoals `DeviceNetworkEvents` of `CommonSecurityLog`.```kql
DeviceProcessEvents
| where ProcessCommandLine has "powershell"
| where ProcessCommandLine has_any ("-enc", "-EncodedCommand")

Herbruikbare detectielogica opbouwen

Zodra een query nuttig blijkt, verpak deze als een functie met let, of sla deze op als een Sentinel Analytics Rule met geplande uitvoering. Parametriseer drempels (zoals aantal mislukte aanmeldingen) zodat dezelfde logica over tenants schaalt of zonder opnieuw te schrijven kan worden aangepast. Dit is hoe ad-hoc hunting-queries zich ontwikkelen tot staande detecties die de SOC automatisch activeren.

Veelgebruikte valkuilen

• Vergeten TimeGenerated filters toe te voegen, wat leidt tot trage, dure full-table scans.
• summarize gebruiken voordat where, wat forceert dat de engine ongefilterde gegevens aggregeert.
• Niet-overeenkomende kolomnamen bij het samenvoegen van tabellen — controleer eerst het schema met getschema.
• contains overmatig gebruiken, wat indexeringsvoordelen omzeilt en large-scale hunts vertraagt.

KQL beloont analisten die in pijplijnen denken in plaats van geneste subquery's. Begin elk onderzoek met een smal tijdvenster en een specifieke tabel, verbreed dan alleen als nodig.

Als dit je een solide basis gaf, verken dan de Blue Team en Digital Forensics segmenten op Korra Studio voor meer hands-on SOC query walkthroughs en detection-building exercises.