Noțiuni Elementare de KQL pe Care Ar Trebui Să Le Cunoască Orice Analist SOC

Kusto Query Language (KQL) este fundamentul vânării amenințărilor și triajului alertelor în Microsoft Sentinel și Microsoft Defender. Dacă lucrezi într-un SOC, cunoașterea fluentă a KQL diferențiază analiștii care pot răspunde rapid la "ce s-a întâmplat aici?" de cei blocați să deschidă dashboard-uri. Aceasta nu este o referință completă a limbajului — este subsetul practic care se folosește constant în timpul serviciului.

De Ce Contează KQL în SOC

KQL este read-only și optimizat pentru interogarea rapidă a seturilor masive de jurnale. Sentinel, Defender for Endpoint, Azure Monitor și Log Analytics vorbesc toți KQL. Odată ce îl cunoști, poți naviga între produse cu același model mental: alege un tabel, filtrează-l, dă forma ieșirii. Fiecare investigație — triajul phishing-ului, vânări de mișcare laterală, reglarea fals-pozitivelor — începe cu o interogare.

Pipe-ul Este Totul

Interogările KQL sunt construite ca o conductă. Începi cu un tabel și treci datele printr-o serie de operatori, fiecare filtrând, transformând sau agregând rezultatul anterior:

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

Citește-o de sus în jos ca o propoziție: începe cu jurnalele SecurityEvent, păstrează doar eșecurile de logare (4625), restricționează la ultima zi, numără eșecurile pe cont/calculator, apoi sortează. Această lizibilitate liniară este cel mai mare avantaj al KQL peste SQL pentru vânări ad hoc.

Operatori de Bază de Memorat

• where — filtrul tău principal. Folosește-l devreme și des pentru a reduce volumul de date înainte de operații costisitoare.
• project — selectează și redenumește coloane specifice, eliminând zgomotul pe care nu-l ai nevoie în ieșire.
• extend — adaugă coloane calculate fără a elimina pe cele existente, util pentru analiza șirurilor sau marcarea condițiilor.
• summarize — agregrează date cu count(), sum(), dcount() sau make_set(), aproape întotdeauna pereche cu by.
• join — corelează între tabele, de ex., legând jurnalele de logare cu inventarul dispozitivelor pentru a identifica logări de pe dispozitive neadministrate.
• render — vizualizează rezultatele ca timechart sau barchart direct în editorul de interogări, util pentru a identifica vârfuri.

Filtrarea Timpului Făcută Corect

Mereu filtrează pe TimeGenerated (sau coloana de marcă de timp echivalentă a tabelului) cât mai devreme posibil în conductă. Motoarele KQL se optimizează greu în jurul filtrelor de interval de timp, iar plasarea | where TimeGenerated > ago(7d) aproape de vârf în loc de fund poate face diferența între o interogare care se returnează în secunde și una care expiră pe un chiriar ocupat.```kql SigninLogs | where TimeGenerated > ago(1h) | where ResultType != "0" | where UserPrincipalName has "@yourdomain.com"

## Potrivirea Șirurilor: has vs contains vs ==

O greșeală frecventă este implicita la `contains` pentru totul. `has` potrivește termeni întregi și folosește un index de termeni, făcând-o dramatic mai rapidă pe tabele mari. Folosește `contains` doar când ai nevoie de potriviri de subșiruri în interiorul unui cuvânt (cum ar fi un fragment de domeniu parțial), și folosește `==` pentru potriviri exacte pe câmpuri structurate cum ar fi EventID sau IPAddress. Această singură obicei accelerează notabil vânările pe tabele cu volum ridicat cum ar fi `DeviceNetworkEvents` sau `CommonSecurityLog`.```kql
DeviceProcessEvents
| where ProcessCommandLine has "powershell"
| where ProcessCommandLine has_any ("-enc", "-EncodedCommand")

Construirea Logicii de Detecție Reutilizabilă

Odată ce o interogare se dovedește utilă, înfășoarc-o ca o funcție cu let, sau salvează-o ca Sentinel Analytics Rule cu execuție programată. Parametrizează pragurile (cum ar fi numărarea eșecurilor de logare) pentru ca aceeași logică să se scaleze între chiriile sau să se regleze fără rescrierea de la zero. Iată cum interogările de vânare care au fost o singură dată evoluează în detecții permanente care declanșează automat SOC-ul.

Capcane Frecvente

• Uitarea filtrelor TimeGenerated, cauzând scanări lente și costisitoare ale tabelului complet.
• Folosirea summarize înainte de where, ceea ce forțează motorul să agrege date nefiltrare.
• Numiri necorespunzătoare de coloane la unire între tabele — întotdeauna verifică schema cu getschema mai întâi.
• Overusing contains, care omite beneficiile indexării și încetinește vânările la scară largă.

KQL răsplătește analiștii care gândesc în conducte mai degrabă decât subinterogări imbricate. Începe fiecare investigație cu o fereastră de timp restrânsă și un tabel specific, apoi lărgește doar după cum este nevoie.

Dacă aceasta ți-a dat o bază solidă, explorează segmentele Blue Team și Digital Forensics pe Korra Studio pentru mai multe proceduri de interogare SOC hands-on și exerciții de construire a detecțiilor.