Detection Engineering: Building Detections That Actually Fire

Gue masih ingat betul malam itu. Jam dua lewat, ruang SOC lagi sepi, lampu cuma dari monitor yang kelap-kelip merah dan kuning. Di layar gue ada puluhan alert yang numpuk dari SIEM, kebanyakan cuma noise: someone logged in from a new IP, port scan detected, antivirus updated. Gue sikat semua itu dengan gerakan otomatis, eskalasi yang perlu eskalasi, tutup yang perlu ditutup, dan ngerasa udah kerja dengan bener. Eskalasi terakhir malam itu gue kirim ke tim IR, mereka bilang oke, gue pulang dengan rasa lega.

Tiga hari kemudian, gue dapet kabar kalau server file sharing di kantor baru aja diencrypt ransomware. Pelakunya masuk lewat akun admin yang credentials-nya kecurian dari satu phishing email yang menurut sistem gue "low risk". Gue ngecek balik log-nya. Ternyata ada jejak yang seharusnya bikin alarm berbunyi kenceng: akun itu ngejalankan PowerShell dengan perintah encoded, ngeload DLL aneh lewat rundll32, terus nyalain layanan remote desktop di jam yang nggak wajar. Semua itu ada di log. Tapi nggak ada satu pun deteksi yang nangkep pola itu sebagai satu cerita. SIEM gue cuma liat potongan-potongan kecil dan ngebilang "nothing to see here".

Malam itu ngajarin gue pelajaran yang mahal: punya SIEM, punya log, dan punya ratusan alert itu belum tentu berarti lo punya visibilitas. Yang kurang adalah deteksi yang dirancang dengan sengaja buat nangkep cara kerja musuh, bukan cuma nangkep gejala acak. Itulah titik balik gue masuk ke dunia detection engineering.

Detection Engineering Bukan Cuma "Bikin Alert"

Banyak orang di security menganggap deteksi itu kerjaan pasif. Lo pasang agent, nyalain rule bawaan vendor, terus duduk nunggu alert nyala. Kalau alertnya kebanyakan, ya berarti sistemnya "bagus dan sensitif". Kalau sepi, ya berarti "aman". Dua-duanya salah besar.

Detection engineering itu disiplin aktif. Intinya: seseorang (atau satu tim kecil) yang dengan sengaja merancang, nulis, ngetes, dan nge-tune deteksi supaya sistem keamanan lo bisa mengenali perilaku musuh secara andal. Beda dengan analis SOC yang nerja harian triage alert yang sudah ada, detection engineer justru yang mutusin alert apa yang harus ada di tempat pertama.

Gue suka analogi bikin jaring penangkap ikan. Analis SOC itu yang duduk di pinggir pantai nerika ikan yang kepancing. Detection engineer itu yang desain bentuk jaringnya, nentuin ukuran lubangnya, milih di titik mana jaring harus diturunin, dan ngetes ulang kalau ketahuan jaringnya kegedean (nangkep sampah) atau kekecilan (ikan gede lolos). Tanpa jaring yang bener, analis terbaik sekalipun cuma duduk nunggu apa yang nggak akan dateng.

Di tim kecil, sering gue sendiri yang jadi dua-duanya. Tapi pola pikirnya beda. Pas gue lagi di mode detection engineer, gue nggak nanya "alert apa yang masuk hari ini?", melainkan "teknik serangan apa yang belum gue bisa liat, dan gimana caranya biar besok gue bisa?".

Mulai dari Hipotesis, Bukan dari Log

Kesalahan paling umum pas orang mulai bikin deteksi adalah ngebuka log dulu, terus nyari apa yang "kelihatan aneh". Masalahnya, tanpa arah, lo cuma bakal nemu anomaly yang nggak jelas pentingnya, dan ujung-ujungnya bikin alert yang 90 persen false positive.

Cara yang jauh lebih sehat: mulai dari hipotesis tentang musuh. Gue biasa pakai kerangka MITRE ATT&CK bukan karena itu produk vendor, tapi karena dia ngasih bahasa umum buat ngejelasin langkah serangan. Tiap deteksi gue mulai dari satu kalimat: "kita hipotesis musuh bakal pakai teknik X, dan bukti paling bisa dipercaya ada di sumber telemetry Y."

Contoh nyata. Suatu hari gue mikir, "di lingkungan kita banyak server Windows, dan admin sering remote. Kalau ada musuh yang udah dapet kredensial, dia bakal pengen gerakin dirinya lewat remote service biar nggak kelihatan." Itu hipotesis. Dari situ gue turunin pertanyaan teknis: apa bukti paling dekat dengan momen itu? Biasanya Windows Event ID 4624 (logon sukses) dengan logon type 10 (RemoteInteractive / RDP) di jam yang aneh, dari workstation yang biasanya nggak remote, menuju server kritis. Deteksi lahir dari rantai itu, bukan dari "ah ada logon, kasih alert aja".

Keuntungan mulai dari hipotesis: lo bisa jelasin ke bos dan ke tim IR kenapa deteksi ini ada. Lo nggak cuma bilang "ini rule penting", tapi "ini nutup celah di technique T1021, dan ini bukti yang kita pakai". Pas deteksinya false positive, lo juga lebih gampang ngetune karena lo paham maksud awalnya.

Studi Kasus: Ngejar LOLBin di Windows

Satu proyek detection engineering favorit gue adalah ngejar apa yang disebut LOLBin, singkatan dari Living Off the Land Binary. Intinya musuh nggak bawa malware baru, tapi pakai alat yang sudah ada di Windows buat jalanin maksud jahat. Rundll32, wmic, certutil, mshta, powershell sendiri, semuanya sah secara sistem tapi bisa dipakai jahat.

Gue ambil contoh certutil. Secara normal, certutil dipakai admin buat ngelola sertifikat. Tapi musuh suka pakai dia buat download file dari internet langsung ke memori atau disk, karena antivirus sering nggak curiga ke binary Microsoft resmi. Di log, ini kelihatan sebagai certutil.exe dengan argumen urlcache atau pingen download dari URL. Masalahnya, admin beneran juga kadang pakai certutil buat hal sah. Jadi deteksi mentah "certutil jalan" bakal banjir false positive.

Gue pecah jadi hipotesis: "musuh pakai certutil buat ngambil file dari luar". Bukti yang dicari: command line yang mengandung argumen download ke atau dari URL eksternal, apalagi kalau filenya berekstensi aneh atau disimpen di folder temp. Sumber telemetry terbaik di sini adalah PowerShell Script Block Logging dan Windows Event ID 4688 (process creation) dengan kolom command line aktif. Gue tulis deteksi yang cuma nyalain alarm kalau certutil dipanggil dengan pola URL + lokasi temp, bukan sekadar certutil jalan. False positive turun drastis, dan pas ada tester internal yang iseng download payload uji, deteksinya langsung bunyi.

Pengalaman ini ngajarin gue satu hal krusial: deteksi yang bagus itu soal konteks, bukan sekadar nama binary. Lo harus ngerti kenapa sebuah tindakan bisa jahat di satu situasi dan sah di situasi lain. Detection engineering itu sebenernya seni ngasih konteks ke mesin yang cuma tau string.

Sigma: Bahasa Deteksi yang Portabel

Pas gue mulai nulis deteksi, gue sadar ada masalah portabilitas. Rule di SIEM kita ditulis dalam query bahasa yang cuma berlaku di produk itu. Kalau besok bos mutusin pindah ke SIEM lain, atau gue mau ngetes deteksi di lab pakai tool beda, semua tulisan gue harus ditulis ulang dari nol. Itu melelahkan dan rawan salah.

Di sinilah Sigma masuk. Sigma itu semacam bahasa umum buat nulis deteksi, mirip cara YAML buat nyatakan "aku lagi nyari event dengan field ini dan nilai itu". Keuntungannya: satu file Sigma bisa diterjemahin ke query SPL buat Splunk, ke KQL buat Sentinel, ke Elasticsearch query, atau ke PySigma buat ngetes lokal. Gue nulis sekali, jalan di mana aja.

Gue kasih contoh bentuknya biar lo kebayang. Bayangin deteksi buat nangkep PowerShell encoded command. Di Sigma, gue nyatain log source-nya adalah produk Windows/Sysmon dengan event id tertentu, terus detection-nya nyari command line yang mengandung pola "-enc" atau "Base64" panjang. File itu readable oleh manusia, bisa di-review lewat pull request kayak kode biasa, dan bisa dites. Pas tim gue pindah sebagian log ke platform lain, gue cuma jalanin converter, nggak nulis ulang logika.

Sigma bukan satu-satunya standar, dan dia punya keterbatasan di detection yang butuh korelasi lintas event. Tapi buat deteksi level satu event, dia ngasih gue kebebasan nggak dikunci sama satu vendor. Buat tim kecil dengan budget pas-pasan, itu berharga banget.

Kalau Deteksinya Salah, Lo Cuma Bikin Noise

Ada candaan kelam di SOC: "alert terbaik adalah yang bisa lo tutup tanpa baca". Itu candaan karena dia menyakitkan. Deteksi yang salah tuning cuma nambah beban analis dan bikin mereka kebal sama alarm. Pas semuanya bunyi kencengap, nggak ada yang beda lagi antara "ini serangan beneran" dan "ini lagi salah lagi".

Gue belajar ngetune lewat tiga langkah praktis. Pertama, baseline. Sebelum deteksi gue nyalain alarm ke SOC, gue jalanin dia dalam mode observasi dulu seminggu, ngumpulin berapa kali dia nyala dan kenapa. Kalau seminggu dia nyala seratus kali dan semuanya sah, berarti threshold atau kondisinya salah, bukan dunianya yang jahat. Kedua, kurasi context. Tambahin pengecualian buat akun service yang emang kerjanya mirip musuh, tapi catat pengecualian itu di dokumentasi biar nggak jadi lubang yang lupa ditutup. Ketiga, ukur signal-to-noise. Gue catat berapa deteksi yang berujung insiden beneran vs yang ditutup sebagai false positive. Kalau rasio jelek, deteksi itu balik ke meja gue, bukan ke SOC.

Hal yang sering dilupakan: false positive itu bukan cuma nyebelin, dia juga biaya. Tiap alert yang di-triage butuh waktu analis yang bisa dipakai buat ngejar ancaman beneran. Jadi detection engineer punya utang moral ke tim SOC: jangan kirim alert kalau lo sendiri nggak yakin itu penting.

Detection-as-Code: Bikin Deteksi Kayak Software

Pas jumlah deteksi gue mulai puluhan, gue sadar ngelola rule lewat klik-klik di UI SIEM itu rese. Nggak ada history, nggak ada review, dan pas orang lain ubah rule, gue nggak tau apa yang berubah. Solusinya: perlakukan deteksi sebagai kode.

Gue pindahin semua rule ke repository. Tiap deteksi jadi satu file, lengkap dengan komentar yang ngejelasin hipotesis, sumber telemetry, dan referensi ATT&CK-nya. Kalau ada yang mau nambah atau ngubah deteksi, dia buka pull request. Gue dan minimal satu orang lain nge-review: apakah logikanya bener? Apakah ada false positive yang kelihatan? Apakah dia ngetes di lab? Baru setelah itu di-merge.

Lebih jauh, gue nambahin testing otomatis. Tiap deteksi gue punya sampel event uji, baik event jahat (harus ketahuan) maupun event sah (harus lolos). Pas ada perubahan, pipeline kecil jalanin tes itu. Kalau deteksi baru malah nge-block event sah yang penting, pipeline nolak merge-nya. Ini ngasih gue tidur tenang pas ada perubahan besar di infrastruktur, karena gue tau deteksi nggak tiba-tiba buta.

Bagi tim yang belum sanggup bikin pipeline rumit, jangan takut. Mulai dari hal kecil: simpan rule di git, wajibin review dua mata, tulis dokumentasi singkat. Itu sudut naik yang gede dibanding nyimpen rule di otak seseorang atau di spreadsheet yang gak ada yang buka.

Penutup: Deteksi itu Kerajinan, Bukan Checklist

Kalo lo tanya gue apa inti detection engineering setelah setahun lebih main di situ, jawabannya simpel tapi dalam: deteksi itu kerajinan, bukan checklist compliance. Lo bisa beli alat paling mahal, pasang seribu rule bawaan, dan tetep buta kalau lo nggak paham musuh yang lo hadapin dan nggak peduli apa yang beneran kejadian di jaringan lo sendiri.

Gue gak jadi ahli dalam semalam. Banyak deteksi gue di awal sampah, banyak false positive yang bikin temen SOC ngomel, dan banyak juga celah yang baru ketahuan pas incident beneran. Tapi tiap deteksi yang gue bikin dari hipotesis yang jelas, yang gue tes, yang gue tune, dan yang gue review, itu nambah lapisan penglihatan buat tim. Perlahan tapi pasti, jaringnya makin rapet.

Buat lo yang baru mulai di Blue Team dan merasa kalah sama merahnya alert tiap pagi, coba ubah kacamata lo. Jangan cuma jadi yang nerika alarm orang lain. Mulai tanya, "teknik apa yang belum gue liat?", terus bangun deteksinya dari sana. Nulis deteksi pertama lo bakal berantakan, tapi itu wajar. Yang penting lo mulai, lo ukur, dan lo perbaiki. SOC yang bagus bukan yang paling banyak alatnya, tapi yang paling paham apa yang dia cari dan kenapa.

Gue masih ingat malam server diencrypt itu. Sekarang, kalau kejadian serupa coba lewat, certutil yang narik file aneh, rundll32 yang load DLL asing, RDP yang nyala jam dua lewat dari workstation aneh, semuanya bakal bunyi sebagai satu cerita, bukan potongan sunyi. Dan itu, buat gue, adalah bedanya antara ngerasa aman dan beneran bisa liat.