SOC Detection Engineering and Use Case Lifecycle

Ringkasan

Detection engineering adalah disiplin membangun logika deteksi yang berguna secara operasional, bukan sekadar membuat rule yang berbunyi. Detection yang baik harus relevan terhadap ancaman, didukung telemetry yang benar, menghasilkan alert yang dapat ditindaklanjuti, dan memiliki lifecycle tuning yang terus berjalan.

Use case detection yang matang menjawab pertanyaan berikut:

1. teknik atau risiko apa yang ingin dideteksi?
2. data apa yang dibutuhkan untuk melihatnya?
3. logika seperti apa yang memberi signal-to-noise ratio sehat?
4. bagaimana rule diuji, dipantau, dan ditune setelah live?

Kenapa Banyak Detection Gagal Secara Operasional

Detection sering gagal bukan karena rule syntax salah, tetapi karena:

• dibuat tanpa threat hypothesis yang jelas
• tidak memperhitungkan kualitas telemetry
• tidak punya ownership setelah deployment
• tidak dievaluasi dengan feedback incident nyata
• tidak dibedakan antara high-fidelity detection dan broad hunting analytic

Hasilnya adalah dua ekstrem yang sama-sama buruk:

• terlalu noisy sehingga diabaikan analyst
• terlalu ketat sehingga blind terhadap aktivitas nyata

Detection Use Case vs Rule vs Analytic

Satu use case bisa memiliki beberapa analytic pada berbagai data source.

Lifecycle Detection Engineering

1. Threat Selection

Pilih ancaman berdasarkan:

• threat landscape organisasi
• incident historis internal
• ATT&CK techniques yang relevan
• crown jewel dan identity risk
• compliance atau control requirement

Prioritasi terbaik lahir dari gabungan threat relevance dan business impact.

2. Hypothesis Definition

Tulis hipotesis secara jelas. Contoh:

• attacker akan menggunakan w3wp.exe -> powershell.exe pada web server untuk post-exploitation
• compromised M365 account akan membuat mailbox rule atau OAuth consent setelah login anomali
• AWS IAM abuse akan terlihat sebagai kombinasi login tidak biasa, enumeration, lalu credential creation

Hipotesis yang baik membantu memilih telemetry dan logic yang tepat.

3. Telemetry Mapping

Petakan data source yang diperlukan:

• endpoint telemetry
• auth and identity logs
• email audit logs
• DNS, proxy, firewall, NDR
• cloud audit logs
• asset inventory dan identity enrichment

Pertanyaan wajib:

1. Apakah data source ini benar-benar ada?
2. Apakah field penting lengkap dan konsisten?
3. Berapa latency ingest-nya?
4. Adakah blind spot karena parser atau retention?

Detection logic yang bagus tidak akan berguna jika datanya rapuh.

4. Logic Design

Bangun analytic dengan mempertimbangkan:

• event selection
• threshold dan time window
• correlation antar event
• inclusion criteria
• exclusion criteria
• output entities dan context fields

Komponen logic yang baik:

• cukup sempit untuk actionable
• cukup luas untuk melihat variasi technique
• memiliki enrichment yang membantu triage
• tidak bergantung pada satu IOC yang rapuh kecuali memang IOC-specific use case

5. Test dan Validation

Sebelum production, lakukan:

• syntax validation
• unit-like validation terhadap sample log
• replay historical data bila memungkinkan
• adversary emulation atau lab simulation
• peer review oleh analyst atau engineer lain

Tujuan testing bukan hanya memastikan rule jalan, tetapi memastikan output-nya masuk akal secara operasional.

6. Deployment

Saat deploy, tetapkan:

• owner rule
• severity awal
• expected frequency
• runbook triage
• dashboard pemantauan alert volume

Rule tanpa owner biasanya cepat menjadi technical debt.

7. Monitoring

Setelah live, pantau:

• jumlah alert harian
• top entities
• false positive trend
• missed detection feedback
• alert-to-case conversion rate

Rule yang jarang berbunyi belum tentu bagus. Bisa jadi tidak pernah firing karena bug atau blind spot data.

8. Tuning

Tuning adalah bagian normal dari lifecycle. Trigger tuning biasanya datang dari:

• volume terlalu tinggi
• analyst feedback bahwa alert tidak actionable
• incident nyata lolos tanpa terdeteksi
• perubahan environment atau application behavior
• telemetry field baru yang bisa meningkatkan fidelity

9. Retirement atau Redesign

Detection perlu dipensiunkan atau didesain ulang bila:

• data source tidak lagi relevan
• technique sudah tertutup kontrol lain yang lebih efektif
• logic usang terhadap tradecraft baru
• maintenance cost lebih tinggi dari nilai operasionalnya

Komponen Use Case

Setiap use case sebaiknya punya elemen berikut:

Detection Types yang Perlu Dibedakan

Atomic Detection

Deteksi satu event atau pola tunggal. Contoh: powershell.exe -enc.

Kelebihan:

• cepat dibuat
• latency rendah

Kekurangan:

• sering noisy
• konteks operasional lemah bila berdiri sendiri

Behavioral Detection

Deteksi perilaku atau urutan aksi. Contoh: web server process -> shell -> outbound network.

Kelebihan:

• lebih tahan terhadap IOC churn
• biasanya lebih relevan terhadap TTP

Kekurangan:

• implementasi lebih sulit
• perlu correlation dan telemetry yang baik

Risk-Based Correlation

Menggabungkan beberapa sinyal kecil menjadi satu prioritas lebih tinggi. Contoh: login anomali + mailbox rule + download spike.

Kelebihan:

• cocok untuk SOC modern
• mengurangi ketergantungan pada satu analytic tunggal

Kekurangan:

• perlu entity normalization dan data quality yang kuat

Relationship antara Detection dan Triage

Detection yang baik memudahkan triage. Minimal output alert harus membawa:

• entity utama
• field konteks utama
• ringkasan logic
• severity awal
• deep link ke log atau evidence pendukung

Jika alert memaksa analyst mencari semua konteks dari nol, use case masih kurang matang.

Sumber Ide Use Case

• incident internal sebelumnya
• purple team atau red team findings
• vendor report dan CTI
• ATT&CK coverage gap review
• hunt findings
• change pada teknologi atau exposure baru organisasi

Urutan prioritas terbaik biasanya:

1. incident nyata yang pernah terjadi
2. privileged identity abuse
3. crown jewel asset abuse
4. internet-facing exploit path
5. common attacker tradecraft dengan telemetry kuat

Tuning Strategy yang Sehat

Saat rule noisy, jangan langsung menambah suppression sembarangan. Evaluasi:

1. apakah event selection terlalu luas?
2. apakah entity normalization salah?
3. apakah threshold tidak cocok dengan baseline?
4. apakah exclusion bisa dibuat berbasis konteks yang stabil?
5. apakah rule ini sebenarnya lebih cocok dijadikan hunting analytic daripada production alert?

Suppression yang baik harus spesifik, terukur, dan tidak menutup jalur attack yang penting.

Coverage dan Gap Analysis

Coverage bukan berarti punya banyak rule. Coverage berarti mampu melihat teknik penting pada aset penting dengan telemetry yang memadai.

Gunakan lensa berikut:

• ATT&CK tactic/technique relevan
• asset class penting
• identity abuse paths
• cloud abuse paths
• post-exploitation behaviors
• data exfiltration indicators

Tanyakan:

• teknik mana yang sudah ada deteksinya?
• mana yang hanya punya hunting, belum alerting?
• mana yang belum punya telemetry memadai?
• mana yang terlalu noisy untuk dipakai produksi?

Metrics Detection Engineering

• true positive rate
• false positive rate
• mean time to tune
• alert-to-case conversion rate
• coverage on priority techniques
• number of incidents that led to rule improvement
• stale rules without review in defined period

Template Ringkas Use Case

Use case: Suspicious Web Server Post-Exploitation Chain
Objective:
- Detect likely post-exploitation on internet-facing web servers.
Threat hypothesis:
- Adversary uses web worker process to spawn shell or PowerShell, followed by outbound network activity.
Data sources:
- EDR process creation
- Network connection telemetry
- Asset inventory
Core logic:
- Parent process in {w3wp, httpd, nginx worker} spawns shell or scripting engine
- Followed by rare outbound connection within 5 minutes
Expected benign:
- Approved deployment automation on designated maintenance windows
Triage guidance:
- Check host criticality, maintenance ticket, command line, outbound destination, persistence artifacts
Escalation trigger:
- Production host with no approved change and persistence or callback observed
Owner:
- Detection Engineering

Feedback Loop dari Incident ke Detection

Setelah incident, selalu tanyakan:

1. sinyal apa yang pertama muncul?
2. rule apa yang firing atau justru tidak firing?
3. konteks apa yang seharusnya ditambahkan ke analytic?
4. apakah playbook triage perlu diubah?
5. apakah ada use case baru yang harus dibuat?

SOC yang belajar dari incident akan memperkuat detection lebih cepat daripada SOC yang hanya mengumpulkan alert volume.

Kesalahan Umum

• membuat rule dari blog atau Sigma tanpa validasi environment sendiri
• menganggap ATT&CK coverage spreadsheet sama dengan detection capability nyata
• tidak memberi owner dan review cycle pada rule
• menumpuk suppression sampai analytic tidak berguna
• tidak membedakan hunting query dan production detection
• mengukur keberhasilan rule hanya dari jumlah firing

Kesimpulan

Detection engineering bukan aktivitas sekali jadi. Ini adalah lifecycle berulang: pilih ancaman yang relevan, petakan telemetry, bangun logic yang actionable, uji, deploy, monitor, tune, lalu ulangi berdasarkan feedback nyata.

Prinsip terpenting: detection yang bagus bukan yang paling canggih di atas kertas, tetapi yang paling membantu SOC menemukan ancaman nyata dengan biaya operasional yang sehat.