Dasar-Dasar KQL yang Harus Diketahui Setiap Analis SOC

Kusto Query Language (KQL) adalah fondasi dari threat hunting dan triage alert di Microsoft Sentinel dan Microsoft Defender. Jika Anda bekerja di SOC, kelancaran KQL membedakan analis yang dapat dengan cepat menjawab "apa yang terjadi di sini?" dari mereka yang terjebak mengklik melalui dashboard. Ini bukan referensi bahasa lengkap — ini adalah subset praktis yang digunakan terus-menerus selama shift.

Mengapa KQL Penting di SOC

KQL bersifat read-only dan dioptimalkan untuk mengkueri dataset log besar dengan cepat. Sentinel, Defender for Endpoint, Azure Monitor, dan Log Analytics semuanya menggunakannya. Setelah Anda mengenal KQL, Anda dapat berpindah antar produk dengan model mental yang sama: pilih tabel, filter, dan bentuk output. Setiap investigasi — triage phishing, hunt lateral movement, tuning false-positive — dimulai dengan kueri.

Pipe Adalah Segalanya

Kueri KQL dibangun sebagai pipeline. Anda memulai dengan tabel dan meneruskan data melalui serangkaian operator, masing-masing memfilter, mentransformasi, atau merangkum hasil sebelumnya:

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

Baca dari atas ke bawah seperti kalimat: mulai dengan log SecurityEvent, pertahankan hanya failed logon (4625), batasi ke hari terakhir, hitung kegagalan per account/computer, kemudian urutkan. Keterbacaan linear tersebut adalah kekuatan terbesar KQL dibanding SQL untuk hunting ad hoc.

Operator Inti untuk Dihafalkan

• where — filter utama Anda. Gunakan di awal dan sering untuk mengurangi volume data sebelum operasi mahal.
• project — pilih dan ganti nama kolom spesifik, membuang noise yang tidak perlu di output.
• extend — tambahkan kolom terhitung tanpa menghapus yang sudah ada, berguna untuk parsing string atau penandaan kondisi.
• summarize — agregat data dengan count(), sum(), dcount(), atau make_set(), hampir selalu dipasangkan dengan by.
• join — korelasikan antar tabel, misalnya menghubungkan log sign-in dengan inventori perangkat untuk menemukan logon perangkat tak terkelola.
• render — visualisasikan hasil sebagai timechart atau barchart langsung di editor kueri, berguna untuk mendeteksi lonjakan.

Filtering Waktu yang Benar

Selalu filter pada TimeGenerated (atau kolom timestamp yang setara dengan tabel) sedini mungkin di pipeline. Mesin KQL dioptimalkan sangat berat di sekitar filter range waktu, dan menempatkan | where TimeGenerated > ago(7d) di dekat atas daripada di bawah bisa membuat perbedaan antara kueri yang return dalam hitungan detik versus yang timeout di tenant yang sibuk.

SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType != "0"
| where UserPrincipalName has "@yourdomain.com"

String Matching: has vs contains vs ==

Kesalahan umum adalah default ke contains untuk semuanya. has mencocokkan istilah utuh dan menggunakan indeks istilah, membuatnya jauh lebih cepat di tabel besar. Gunakan contains hanya ketika Anda memerlukan pencocokan substring di dalam kata (seperti fragmen domain parsial), dan gunakan == untuk pencocokan tepat pada field terstruktur seperti EventID atau IPAddress. Satu kebiasaan ini terlihat mempercepat hunt di tabel volume tinggi seperti DeviceNetworkEvents atau CommonSecurityLog.

DeviceProcessEvents
| where ProcessCommandLine has "powershell"
| where ProcessCommandLine has_any ("-enc", "-EncodedCommand")

Membangun Logika Deteksi yang Dapat Digunakan Kembali

Setelah kueri terbukti berguna, bungkus sebagai fungsi dengan let, atau simpan sebagai Sentinel Analytics Rule dengan eksekusi terjadwal. Parametrisasi threshold (seperti jumlah failed logon) sehingga logika yang sama dapat diskalakan antar tenant atau disesuaikan tanpa menulis ulang dari awal. Inilah cara kueri hunting satu kali berkembang menjadi deteksi yang berdiri dan secara otomatis melaporkan ke SOC.

Jebakan Umum

• Lupa filter TimeGenerated, menyebabkan full-table scan yang lambat dan mahal.
• Menggunakan summarize sebelum where, memaksa mesin untuk mengagregat data yang tidak difilter.
• Nama kolom yang tidak cocok saat join tabel — selalu periksa schema dengan getschema lebih dulu.
• Overuse contains, yang melewati manfaat indeksing dan memperlambat hunt skala besar.

KQL memberikan penghargaan kepada analis yang berpikir dalam pipeline daripada subkueri bersarang. Mulai setiap investigasi dengan window waktu yang sempit dan tabel spesifik, kemudian perluas hanya sesuai kebutuhan.

Jika ini memberi Anda fondasi yang solid, jelajahi segmen Blue Team dan Digital Forensics di Korra Studio untuk lebih banyak walkthrough kueri SOC praktis dan latihan pembuatan deteksi.