Mempelajari false positive/negative, severity assessment, prioritization techniques, dan cara mengelola triage queue secara efektif di SOC

Setelah di episode 13 kita mempelajari playbooks & runbooks, pada episode ini kita dalami triage & alert prioritization — keterampilan harian paling kritis SOC analyst. Triage adalah gatekeeper: alert yang ditangani dengan benar mengarah ke respons yang efektif; alert yang salah ditangani membuang waktu atau melewatkan serangan.
Mengapa triage penting? Karena SOC menerima ratusan hingga ribuan alert per hari. Semua alert tidak bisa ditangani bersamaan — ada yang kritis, ada yang noise. Kemampuan memilah dengan cepat dan akurat adalah what makes or breaks a SOC.
| Tipe | Arti | Dampak |
|---|---|---|
| False Positive | Alert salah — tidak ada ancaman nyata | Membuang waktu, alert fatigue |
| False Negative | Serangan lolos tanpa alert | Kerusakan tidak terdeteksi |
| True Positive | Alert benar — ada ancaman nyata | Harus ditangani |
| True Negative | Tidak ada alert, tidak ada ancaman | Normal |
Alert fatigue terjadi ketika terlalu banyak false positive sehingga analyst menjadi desensitized — mulai mengabaikan alert, termasuk yang benar-benar berbahaya.
| Faktor | Pertimbangan |
|---|---|
| Asset Criticality | Server production vs workstation dev |
| Data Sensitivity | PII, financial, public |
| Attack Stage | Reconnaissance vs active exploitation |
| Lateral Movement | Isolated vs spreading |
| Business Impact | Operational disruption vs minor |
| Kombinasi | Severity |
|---|---|
| Critical asset + Active exploitation | Critical |
| Critical asset + Reconnaissance | High |
| Normal asset + Active exploitation | High |
| Normal asset + Suspicious activity | Medium |
| Low-value asset + Policy violation | Low |
Sebelum memutuskan, enrich alert dengan konteks:
# Lookup IP reputation
curl "https://api.abuseipdb.com/api/v2/check?ipAddress=192.168.1.100" -H "Key: YOUR_KEY"
# Cek apakah IP internal
whois 192.168.1.100 | grep -i "netname"
# Cek historical alerts dari IP yang sama
grep "192.168.1.100" /var/log/alerts/*.log | wc -l| Korelasi | Arti |
|---|---|
| Alert sama dari banyak host | Serangan terkoordinasi |
| Alert dari host berbeda | Potensi worm/lateral movement |
| Alert dengan waktu berdekatan | Campaign serangan |
| Alert dengan source IP sama | Attacker spesifik |
| Cek | Tool |
|---|---|
| Scheduled maintenance? | CMDB, change management |
| Approved scan activity? | Vulnerability scanner schedule |
| Known application behavior? | Baseline documentation |
Tip
Selalu tanyakan: "Apakah ini pernah terjadi sebelumnya dalam konteks yang sama?" Jika ya dan sebelumnya benign, escalation mungkin berlebihan. Jika baru, layak ditelusuri lebih dalam.
| Technique | Fungsi |
|---|---|
| Batching | Kelompokkan alert serupa untuk diproses bersama |
| Prioritization | Critical/High dulu, batch Low di akhir shift |
| Delegation | L1 handle Low/Medium, escalate High/Critical |
| Documentation | Setiap keputusan harus tercatat |
□ Apa jenis alert ini?
□ Apa asset yang terpengaruh?
□ Apakah ada korelasi dengan alert lain?
□ Apakah ini known good activity?
□ Severity: Critical/High/Medium/Low?
□ Tindakan: Investigate/Escalate/Close/Tune?
□ Documented di ticket system?Warning
Jangan pernah menutup alert tanpa dokumentasi — bahkan false positive. Catatan tentang mengapa alert ini false positive akan membantu tuning rules dan membantu analyst berikutnya yang menghadapi alert serupa.
Inti yang harus dibawa pulang:
Di episode 15 selanjutnya kita akan membahas forensics dasar & evidence handling — chain of custody, imaging, dan prosedur evidence yang benar. Ketika insiden berubah menjadi kasus hukum, evidence handling menjadi kritis.