Otomasi SOC: Bagian Mana yang Aman Diotomatisasi dan Mana yang Tetap Membutuhkan Manusia

Pertanyaan yang benar bukan “bisa diotomatisasi?” melainkan “apa dampak bila keputusan salah?”. Enrichment IP hampir selalu reversibel; mengisolasi domain controller tidak.

Matriks keputusan#

Aman untuk diotomatisasi#

• Normalisasi dan deduplikasi alert.
• Enrichment asset, identity, geolocation, dan threat intelligence.
• Pengumpulan event sebelum/sesudah alert.
• Pembuatan case serta evidence bundle.
• Notifikasi dengan template dan owner yang jelas.
• Penutupan alert duplikat jika fingerprint sangat kuat.

Perlu keputusan manusia#

• Attribution dan penentuan intent.
• Containment pada sistem kritis.
• Komunikasi hukum, regulator, atau publik.
• Pengecualian security jangka panjang.
• Keputusan yang bergantung pada konteks bisnis yang tidak ada di telemetry.

Contoh playbook phishing#

1. Ambil message ID dan header.
2. Ekstrak URL serta attachment hash.
3. Cari penerima lain.
4. Cek apakah user mengklik dan apakah proses baru muncul.
5. Jika hash malicious terkonfirmasi dan blast radius jelas, otomatis karantina email yang sama.
6. Jika membutuhkan penghapusan mailbox luas atau reset massal, minta approval incident commander.

{
  "action": "quarantine_matching_messages",
  "confidence": 0.97,
  "reversible": true,
  "scope": 14,
  "approval_required": false,
  "evidence": ["message-id", "sha256", "url"]
}

Guardrail wajib#

• Dry-run dan preview scope.
• Idempotency: playbook dua kali tidak menggandakan dampak.
• Timeout, retry terbatas, dan circuit breaker.
• Least privilege untuk akun otomasi.
• Audit log input, keputusan, versi rule, dan output.
• Rollback yang benar-benar diuji.
• Kill switch dan owner on-call.

Uji sebelum produksi#

Replay alert historis yang sudah dilabeli, lakukan tabletop untuk skenario salah, lalu jalankan mode shadow: otomasi membuat rekomendasi tanpa mengeksekusi. Bandingkan keputusan dengan analis sebelum mengaktifkan tindakan.

Prinsip: otomatisasi mesin untuk pekerjaan deterministik; pertahankan manusia untuk ambiguitas, dampak besar, dan akuntabilitas.

Human-in-the-loop yang benar#

Approval bukan sekadar tombol “yes”. Tampilkan evidence, confidence, scope, affected asset, dampak bisnis, dan rollback. Operator harus memahami apa yang akan terjadi. Batasi masa berlaku approval agar konteks lama tidak digunakan setelah situasi berubah.

Contoh kegagalan otomasi#

Sebuah playbook memblokir domain berdasarkan satu feed. Feed salah menandai CDN yang dipakai aplikasi bisnis; ratusan user terdampak. Guardrail yang seharusnya menghentikan aksi: domain prevalence internal tinggi, scope preview besar, asset bisnis kritis, dan tidak ada sumber intel kedua.

Maturity bertahap#

1. Observe: kumpulkan telemetry.
2. Recommend: hasilkan saran tanpa aksi.
3. Approve: manusia menyetujui tindakan.
4. Auto low-risk: eksekusi hanya aksi reversibel.
5. Adaptive: perluasan scope setelah metric stabil.

Metric otomasi#

Ukur jam analis yang dihemat, error/rollback rate, persentase aksi dibatalkan manusia, coverage playbook, dan mean time to contain. Jumlah playbook bukan metric keberhasilan; playbook yang jarang dipakai tetapi berbahaya justru menambah risiko operasional.