Bagaimana SOC Analyst Melakukan Alert Triage Tanpa Tenggelam dalam False Positive

Alert bukan insiden. Alert adalah klaim sensor bahwa sesuatu memenuhi kondisi tertentu. Triage menguji klaim tersebut secara cepat, konsisten, dan terdokumentasi.

Lima langkah triage#

1. Validate: event ada dan parser benar?
2. Contextualize: siapa user, asset, owner, dan baseline?
3. Correlate: adakah event sebelum/sesudah yang berhubungan?
4. Scope: satu endpoint atau banyak?
5. Decide: close, monitor, atau escalate dengan alasan.

Contoh: impossible travel#

SIEM memberi alert login Jakarta lalu Singapura dalam 20 menit. Jangan langsung menyimpulkan account takeover. Periksa:

• Apakah alamat IP adalah exit node VPN perusahaan?
• Apakah token/session sama atau login baru?
• Apakah device ID dan user agent berubah?
• Apakah ada MFA fatigue, reset password, atau mailbox rule?
• Apakah user memang bepergian?

Jika IP kedua milik VPN resmi, device sama, dan tidak ada perilaku lanjutan, alert dapat ditutup sebagai expected behavior dengan evidence. Jika device baru, MFA ditolak berulang, lalu ada mailbox forwarding, eskalasi menjadi insiden.

Risk score yang dapat dijelaskan#

score = severity_sensor (0-30)
      + asset_criticality (0-25)
      + identity_risk (0-20)
      + correlation (0-20)
      + novelty (0-5)

Skor bukan kebenaran. Ia alat antrean. Simpan alasan setiap komponen agar analis dapat mengoreksi.

Minimum evidence untuk eskalasi#

Mengurangi false positive dengan benar#

Jangan membuat allowlist terlalu lebar. Tuning harus spesifik pada identitas, asset group, waktu, atau pola yang tervalidasi. Setiap pengecualian memiliki owner, alasan, tanggal kedaluwarsa, dan metrik sebelum/sesudah.

Metrik SOC yang sehat#

• Alerts per analyst-hour.
• Persentase closed dengan evidence memadai.
• Escalation precision.
• Median time to acknowledge dan decide.
• Jumlah exception yang kedaluwarsa.
• Insiden yang sebelumnya ditutup sebagai benign.

Latihan: ambil satu rule paling bising. Sampel 30 alert, kelompokkan penyebab, lalu ubah satu kondisi rule. Bandingkan volume dan jumlah true positive selama periode yang sama.

Query sebelum dan sesudah#

Untuk setiap alert, tentukan jendela waktu yang konsisten—misalnya 30 menit sebelum dan 60 menit sesudah. Cari identity event, process execution, DNS, proxy, endpoint, dan perubahan privilege. Jendela terlalu sempit kehilangan rangkaian; terlalu lebar menambah noise. Sesuaikan teknik: password spray mungkin butuh jam, process injection mungkin menit.

Decision record#

Disposition: benign-positive
Reason: VPN corporate egress tervalidasi; device dan session sama
Evidence: sign-in IDs 8812, 8819; asset CMDB-771
Checked: MFA, mailbox rule, endpoint process, peer users
Exception: none
Reviewer: analyst-02

False positive vs benign positive#

False positive berarti rule salah mendeteksi kondisi. Benign positive berarti kondisi memang terjadi tetapi aktivitas sah. Bedakan keduanya: false positive mendorong perbaikan logic; benign positive mungkin membutuhkan baseline atau pengecualian terbatas.

Tanda triage berkualitas#

Keputusan dapat direproduksi, scope disebut, bukti ditautkan, dan tuning tidak menghapus kemampuan deteksi. Kecepatan penting, tetapi penutupan cepat tanpa jejak hanya memindahkan risiko ke insiden berikutnya.