SOC Alert Triage and Prioritization Framework

Ringkasan

Alert triage adalah proses memvalidasi, mengelompokkan, dan menentukan prioritas terhadap alert yang masuk ke SOC agar sumber daya investigasi dipakai pada kejadian yang paling penting terlebih dahulu. Triage yang baik bukan sekadar membaca severity dari tool, tetapi menggabungkan sinyal teknis, konteks aset, konteks user, dan potensi dampak bisnis.

Framework ini membantu SOC menjawab tiga hal inti:

1. Apakah alert ini valid?
2. Seberapa berisiko alert ini bagi environment?
3. Apa aksi paling tepat: close, monitor, investigate, atau escalate?

Tujuan Triage

Tujuan triage bukan membuktikan seluruh root cause, tetapi membuat keputusan awal yang cepat dan cukup akurat. Outcome yang diharapkan:

• noise berkurang sebelum masuk ke jalur investigasi mahal
• alert yang benar-benar penting naik prioritas lebih cepat
• kualitas handoff antar shift dan antar level meningkat
• SLA investigasi lebih mudah dipenuhi
• keputusan close lebih dapat dipertanggungjawabkan

Prinsip Dasar

• severity vendor bukan prioritas final
• risiko adalah kombinasi sinyal teknis dan konteks bisnis
• low-confidence alert pada privileged asset bisa lebih penting dari high-severity alert pada low-value asset
• waktu analyst terbatas, jadi enrichment harus berurutan dan bernilai tinggi
• triage harus repeatable agar konsisten antar analyst dan antar shift

Severity, Priority, dan Risk

Istilah ini sering tercampur, padahal berbeda:

Rule praktis:

• severity menjelaskan seberapa serius sinyal awal
• risk menjelaskan seberapa berbahaya kejadian itu bagi organisasi
• priority menentukan siapa yang dikerjakan sekarang

Data Minimum Sebelum Mengambil Keputusan

Minimal kumpulkan konteks berikut sebelum disposition awal:

1. Alert source dan detection logic singkat
2. Entity utama: host, user, IP, process, mailbox, workload, account, atau bucket
3. Asset criticality atau owner sistem
4. Privilege level user/account terkait
5. Satu artefak teknis utama: process tree, auth chain, atau network direction
6. Nearby alerts atau event tetangga dalam window waktu yang sama

Tanpa enam item ini, triage mudah bias atau terlalu vendor-driven.

Workflow Triage End-to-End

1. Intake

Saat alert masuk, baca:

• nama rule atau analytic
• source product
• timestamp dan frequency
• entity yang terpengaruh
• action vendor: detect only, block, quarantine, allow

Tujuan tahap ini hanya memahami bentuk sinyal, bukan mengambil kesimpulan cepat.

2. Validasi Teknis Awal

Tentukan apakah event benar-benar terjadi dan field utamanya masuk akal:

• parser atau field mapping benar
• timestamp konsisten
• entity tidak null atau salah mapping
• event bukan hasil test, lab, scanner internal, atau simulation yang sah

Jika basic validation gagal, alert bisa masuk jalur data-quality issue, bukan incident path.

3. Rapid Enrichment

Ambil enrichment bernilai tertinggi dulu:

• criticality aset
• role dan privilege user
• parent-child process atau login chain
• source IP context
• apakah ada change window atau activity admin resmi

Tahap ini idealnya singkat, terutama untuk L1.

4. Risk Assessment

Tanya pertanyaan berikut:

1. Seberapa berbahaya teknik atau behavior yang terlihat?
2. Seberapa sensitif asset atau akun yang terkena?
3. Seberapa besar peluang alert ini benign?
4. Ada indikasi blast radius atau persistence?
5. Kontrol apa yang sudah menahan aktivitas ini?

5. Correlation

Korelasikan ke source lain jika alert belum jelas:

• endpoint ke network
• identity ke email
• IAM ke cloud activity
• DNS ke EDR process
• proxy ke mailbox click event

Alert yang awalnya lemah sering menjadi kuat setelah cross-source correlation.

6. Disposition

Pilih salah satu hasil berikut:

• false positive
• benign true positive
• suspicious, needs monitoring
• suspicious, needs escalation
• confirmed malicious

Disposition harus ditulis bersama alasan, bukan label saja.

7. Documentation dan Handoff

Setelah keputusan dibuat, tulis:

• apa alert-nya
• konteks apa yang dicek
• apa yang ditemukan
• apa yang belum diketahui
• mengapa alert ditutup atau dieskalasi

Risk Scoring Sederhana untuk Triage

Jika butuh model cepat, gunakan tiga komponen:

Interpretasi sederhana:

• total rendah -> close atau monitor
• total sedang -> enrich lebih lanjut atau escalate ke L2
• total tinggi -> prioritize dan escalate cepat

Decision Matrix Praktis

Perbedaan False Positive vs Benign True Positive

Ini salah satu sumber misklasifikasi paling umum.

Contoh:

• rule mendeteksi powershell.exe karena parser salah membaca field -> false positive
• rule mendeteksi PowerShell encoded command saat tim deployment menjalankan automation yang tervalidasi -> benign true positive

Perbedaan ini penting untuk tuning detection di tahap berikutnya.

Alert Family dan Fokus Triage

Endpoint Alerts

Periksa:

• process tree
• command line
• signer/path/hash
• file creation atau persistence
• outbound connection setelah execution

Identity Alerts

Periksa:

• login source dan geolocation
• MFA behavior
• device ID dan user agent
• privilege changes
• mailbox atau SaaS follow-on activity

Email Alerts

Periksa:

• apakah email delivered, clicked, replied, atau quarantined
• siapa penerimanya dan role bisnisnya
• attachment/hash/URL reputation
• apakah ada rule inbox atau token abuse setelahnya

Cloud Alerts

Periksa:

• console vs API access
• source IP dan ASN
• role assumption chain
• perubahan policy, key, secret, atau logging
• apakah actor adalah human account atau automation

Network Alerts

Periksa:

• arah trafik
• protocol dan port
• asset role di kedua sisi
• rarity destination
• keterkaitan dengan process atau auth event

Kapan Harus Escalate Cepat

Escalate cepat jika salah satu berikut muncul:

• account privileged, dormant, atau break-glass terlibat
• asset adalah crown jewel, production, atau internet-facing
• ada tanda persistence, credential access, atau lateral movement
• ada multi-source confirmation
• tool mendeteksi tapi gagal block
• ada potensi data access atau business impact langsung

Kapan Alert Boleh Ditutup

Alert boleh ditutup bila:

• aktivitas tervalidasi sebagai bagian dari workflow resmi
• behavior konsisten dengan baseline historis
• tidak ada source lain yang mendukung malicious interpretation
• dampak dan blast radius minimum sudah diperiksa
• alasan close terdokumentasi jelas

Template Triage Note

Alert: Impossible Travel for finance.user@corp
Source: Microsoft Entra ID
Initial severity: Medium
Current priority: High
Entities:
- User: finance.user@corp
- Source IP 1: 203.0.113.14
- Source IP 2: 198.51.100.32
Context checked:
- User role: Finance staff with access to payment workflow
- VPN exception: none found
- MFA: success observed after travel anomaly
- Nearby alerts: mailbox rule created 6 minutes later
Assessment:
- Alert risk increased due to role sensitivity and supporting mailbox activity
Disposition:
- Escalate to L2 for account compromise investigation

KPI yang Layak Dipantau

• alert-to-disposition time
• false positive rate setelah enrichment L1
• escalation acceptance rate oleh L2
• repeat noise per use case
• persentase triage note yang lengkap konteksnya
• jumlah missed escalations yang ditemukan belakangan

Anti-Pattern yang Harus Dihindari

• close alert hanya karena analyst pernah melihat alert serupa sebelumnya
• percaya penuh pada severity tool tanpa cek context
• menahan escalation hanya karena belum 100 persen pasti
• tidak membedakan false positive dan benign true positive
• tidak mendokumentasikan unknowns
• fokus hanya pada IOC tanpa melihat behavior

Kesimpulan

Triage yang matang adalah filter kualitas pertama SOC. Jika triage kuat, beban investigasi turun dan incident nyata lebih cepat terlihat. Jika triage lemah, SOC akan tenggelam dalam noise atau justru terlambat merespons kejadian penting.

Prinsip sederhana yang harus diingat: triage bukan soal membaca alert, tetapi soal menilai makna alert dalam konteks risiko organisasi.