Post-Incident Review — Belajar dari Kegagalan untuk Jadi Lebih Kuat

Akhirnya. Insiden selesai.

Sistem udah pulih. Backup udah direstore. Malware udah diberantas. Manajemen udah di-brief. Regulator udah dilaporin. Pelanggan udah dinotifikasi. Lo akhirnya bisa tidur setelah 72 jam begadang.

Tapi... ada satu langkah terakhir yang paling penting — dan paling sering di-skip: post-incident review.

Ini bagian yang membedakan tim CSIRT profesional dari tim amatir. Tim amatir selesai di "udah selesai, move on." Tim profesional selesai di "oke, kenapa ini bisa terjadi? Gimana caranya biar nggak terjadi lagi? Apa yang bisa kita lakukan lebih baik?"

Di artikel ini, kita bakal bahas tuntas bagaimana melakukan post-incident review yang efektif. Bukan sekadar meeting basa-basi yang akhirnya cuma jadi notulensi berdebu. Tapi proses yang beneran bikin tim dan organisasi lo jadi lebih kuat setelah kena insiden.

Kenapa Post-Incident Review Itu Penting?

Coba lo bayangin: lo baru aja melewati insiden ransomware. 3 hari chaos. Lo berhasil pulihkan sistem. Tapi lo nggak pernah melakukan review setelahnya. 6 bulan kemudian... kena lagi. Dengan penyebab yang SAMA PERSIS.

Kenapa? Karena lo nggak pernah belajar dari insiden pertama.

Post-incident review adalah mekanisme untuk mengkonversi pengalaman pahit menjadi perbaikan nyata. Tanpa review:

• Root cause nggak ketemu → celah yang sama masih terbuka → attacker bisa masuk lagi.
• Prosedur yang salah nggak diperbaiki → next time, tim yang sama bakal bikin kesalahan yang sama.
• Tools yang kurang nggak dianggarkan → "udah cukup kok" → padahal harusnya upgrade.
• Karyawan nggak belajar → training yang dibutuhkan nggak diidentifikasi.

Dengan review yang baik, satu insiden bisa jadi katalis untuk perbaikan besar-besaran. Ini paradigm shift: dari "insiden adalah bencana" menjadi "insiden adalah pelajaran mahal" — dan lo harus memastikan uang sekolahnya nggak terbuang percuma.

Kapan Post-Incident Review Dilakukan?

Timing itu penting. Jangan terlalu cepat (orang masih capek dan emosional), jangan terlalu lambat (detail mulai lupa).

Rule of thumb:

• Untuk insiden besar (severity high/critical): lakukan review dalam 1 minggu setelah insiden selesai.
• Untuk insiden kecil-menengah: bisa dalam 2 minggu setelah selesai.
• Hot wash / immediate debrief: segera setelah fase response selesai — ini bukan review formal, tapi diskusi singkat "apa yang berjalan baik, apa yang nggak" yang hasilnya jadi input untuk review formal.

Siapa yang Harus Hadir?

Jangan cuma tim teknis. Ajak semua pihak yang terlibat:

• Incident Manager — yang memimpin diskusi.
• Technical Lead & Analyst — yang paling ngerti detail teknis.
• Communications Lead — evaluasi komunikasi internal dan eksternal.
• Legal & Compliance — evaluasi aspek regulasi.
• Perwakilan dari tim yang terdampak — misalnya developer yang aplikasinya kena, atau IT operations yang server-nya down.
• Executive Sponsor (opsional) — kalau ada keputusan strategis yang perlu dibahas.

Format Post-Incident Review

Gue rekomendasiin format terstruktur berikut:

Bagian 1: Ringkasan Insiden (5-10 menit)

Incident Manager mempresentasikan ringkasan kronologi:

• Kapan insiden terdeteksi?
• Sistem apa yang terdampak?
• Apa tindakan yang diambil?
• Kapan dinyatakan selesai?

Ini untuk menyamakan persepsi. Semua yang hadir harus punya pemahaman yang sama tentang apa yang terjadi.

Bagian 2: Timeline Detail (15-20 menit)

Technical Lead mempresentasikan timeline teknis:

Timeline ini penting untuk melihat:

• Dwell time: berapa lama dari first access ke detection?
• Response time: berapa lama dari detection ke containment?
• Recovery time: berapa lama dari containment ke full recovery?

Bagian 3: Analisis Root Cause (30-45 menit)

Ini bagian paling penting. Tanyakan "mengapa" berulang kali (teknik 5 Whys):

Contoh:

• Kenapa ransomware bisa masuk? → Karena attacker berhasil RDP login.
• Kenapa attacker bisa RDP login? → Karena password lemah dan nggak ada MFA.
• Kenapa nggak ada MFA? → Karena belum pernah diimplementasikan.
• Kenapa belum diimplementasikan? → Karena belum ada kebijakan yang mewajibkan.
• Kenapa belum ada kebijakan? → Karena manajemen belum sadar pentingnya MFA.

→ Root cause: kurangnya kebijakan keamanan yang mewajibkan MFA untuk akses remote.

Jangan berhenti di "password lemah". Gali terus sampai ke akar manajemen dan proses.

Bagian 4: Apa yang Berjalan Baik (10 menit)

Ini penting untuk menjaga moral tim. Catat semua yang positif:

• "Backup berhasil direstore dalam 4 jam — lebih cepat dari perkiraan."
• "Komunikasi dengan regulator berjalan lancar — template notifikasi sudah siap."
• "EDR berhasil mendeteksi dan auto-blokir beberapa C2 connection."

Positive reinforcement penting supaya tim nggak merasa review ini cuma buat nyari kesalahan.

Bagian 5: Apa yang Perlu Diperbaiki (20-30 menit)

Ini bagian yang agak sensitif. Aturan mainnya: blameless. Kita nggak nyari siapa yang salah. Kita nyari apa yang bisa diperbaiki.

Contoh perbaikan:

• "Response time 45 menit terlalu lambat — perlu tambahan alert rules yang lebih sensitif."
• "Ada kebingungan siapa yang bertanggung jawab untuk komunikasi eksternal — perlu SOP yang lebih jelas."
• "Beberapa log ternyata nggak dikumpulin karena agent SIEM belum diinstal di semua server."

Bagian 6: Action Items (15 menit)

Setiap perbaikan harus jadi action item konkret:

PENTING: Action items harus:

• Spesifik (bukan "perbaiki keamanan" — itu terlalu vague).
• Ada penanggung jawab (SATU nama, bukan "tim" — nanti nggak ada yang ngerjain).
• Ada deadline (bukan "secepatnya" — itu nggak pernah terjadi).
• Ada tracking (review di meeting berikutnya — statusnya apa?).

Root Cause Analysis: Tools dan Teknik

Selain 5 Whys di atas, ada beberapa teknik lain untuk root cause analysis (RCA):

Fishbone Diagram (Ishikawa)

Cocok untuk insiden kompleks dengan banyak faktor. Kategorikan penyebab ke dalam:

• People (manusia)
• Process (prosedur)
• Technology (teknologi)
• Environment (lingkungan)

Contoh ransomware:

• People: User ketipu phishing, admin nggak pasang patch.
• Process: Nggak ada policy MFA, nggak ada audit berkala.
• Technology: RDP terbuka ke internet, EDR nggak terinstall.
• Environment: Third party vendor punya akses tanpa pengawasan.

Timeline Analysis

Bikin timeline detail dan identifikasi di mana delay atau kegagalan terjadi:

• 02:15 Alert muncul → 02:30 baru ada yang lihat (delay: 15 menit — kenapa?)
• 02:30 Investigasi mulai → 02:50 baru isolasi (delay: 20 menit — bisa dipercepat?)

Blameless Postmortem

Ini konsep dari Google. Prinsipnya:

• Fokus ke sistem dan proses, bukan individu.
• Asumsikan semua orang bertindak dengan niat baik dengan informasi yang mereka punya saat itu.
• Cari "bagaimana sistem kita membiarkan ini terjadi" — bukan "siapa yang melakukan kesalahan".

Output Post-Incident Review: Final Report

Hasil review harus didokumentasikan dalam laporan formal. Strukturnya:

1. Executive Summary — 1 halaman untuk manajemen.
2. Incident Overview — apa, kapan, dampak.
3. Timeline — kronologi detail.
4. Root Cause Analysis — 5 Whys, fishbone, atau metode lain.
5. What Went Well — positive findings.
6. What Needs Improvement — gap dan kelemahan.
7. Action Items — tabel dengan PIC, deadline, status.
8. Appendix — log, screenshot, chain of custody, data pendukung.

Simpan laporan ini dengan baik. Ini bukan cuma untuk keperluan internal — bisa juga diperlukan untuk:

• Audit eksternal
• Sertifikasi (ISO 27001, dll)
• Klaim asuransi siber
• Proses hukum (kalau kasusnya berlanjut)

Update Incident Response Plan

Setelah review, wajib update IRP lo:

1. Playbook yang nggak akurat → diperbaiki. (Misalnya: playbook ransomware bilang "isolasi dalam 15 menit" — ternyata di lapangan butuh 45 menit karena prosedurnya terlalu kompleks. Sederhanakan!)

2. Kontak yang out-of-date → diupdate. (Incident Manager yang resign belum diganti di contact list? Bahaya!)

3. Tools yang kurang → dianggarkan. (Write blocker cuma 1, padahal sering dipakai bersamaan? Harus beli lagi.)

4. Training gap → direncanakan. (Technical analyst belum bisa pakai Volatility? Daftarkan training!)

IRP adalah dokumen hidup. Harus direview dan diupdate secara berkala — terutama setelah insiden besar.

Membangun Budaya "Blameless"

Ini tantangan terbesar dalam post-incident review — terutama di budaya kerja Indonesia yang kadang masih hierarkis dan "takut salah".

Tips membangun budaya blameless:

1. Mulai dari pimpinan. Kalau CISO atau Incident Manager bilang "Saya yang salah, saya nggak pastikan backup di-test berkala" — itu ngasih contoh bahwa ngaku salah itu aman.

2. Fokus ke perbaikan sistem, bukan hukuman individu. "Ke depan, semua deployment harus ada approval kedua sebelum ke production" — bukan "Ahmad ceroboh, dia yang salah deploy."

3. Rayakan kejujuran. Tim yang berani ngaku "tadi gue salah baca log, makanya response lambat" harus diapresiasi — bukan dimarahi. Kejujuran memperbaiki sistem; ketakutan menyembunyikan masalah.

4. Tindak lanjuti action items. Kalau setiap review ujungnya nggak ada perubahan, orang bakal sinis dan males ikut. "Ah, palingan cuma meeting doang, nggak ada hasilnya."

Checklist Post-Incident Review

• Jadwalkan review dalam 1-2 minggu setelah insiden selesai
• Undang semua pihak yang terlibat (teknis, komunikasi, legal, manajemen)
• Siapkan timeline detail insiden
• Lakukan root cause analysis (5 Whys atau fishbone)
• Identifikasi apa yang berjalan baik
• Identifikasi apa yang perlu diperbaiki
• Buat action items dengan PIC dan deadline yang spesifik
• Tulis laporan formal
• Update Incident Response Plan
• Update playbook
• Jadwalkan follow-up meeting (30-60 hari kemudian) untuk cek status action items
• Simpan laporan dengan baik untuk keperluan audit

Penutup

Post-incident review bukanlah formalitas. Ini adalah investasi. Setiap jam yang lo habiskan untuk melakukan review yang baik, lo menghemat puluhan jam — atau jutaan rupiah — di insiden berikutnya.

Ingat:

• Incident + No Review = Kegagalan Terulang
• Incident + Good Review = Perbaikan Nyata
• Incident + Great Review + Action = Tim yang Anti-Rapuh

Tim CSIRT yang jago bukan tim yang nggak pernah kena insiden. Tim yang jago adalah tim yang setiap kali kena, mereka bangkit lebih kuat.

Ini artikel terakhir di seri Respons Insiden. Dari sini, lo udah punya fondasi:

• Membangun tim CSIRT
• Playbook ransomware
• Deteksi insiden dini
• Komunikasi krisis
• Post-incident review

Sekarang tinggal praktik. Bikin IRP. Setup tools. Latihan. Dan kalau suatu hari insiden terjadi — lo udah siap.

Ada pertanyaan? Kontak. Mau baca ulang? Cek Respons Insiden.

Stay resilient!

Gue mau tutup artikel ini dengan satu refleksi. Selama bertahun-tahun di dunia DFIR, gue udah lihat banyak tim yang melewati insiden besar. Yang menarik: tim yang paling sukses jangka panjang bukan yang nggak pernah kena insiden. Justru mereka yang pernah kena — tapi setiap kali kena, mereka belajar, beradaptasi, dan jadi lebih kuat. Ada satu tim CSIRT di perusahaan telekomunikasi yang gue kenal. Tahun pertama, mereka kena ransomware dan response-nya kacau — 3 hari downtime, pelanggan marah, regulator turun tangan. Tapi mereka nggak putus asa. Mereka lakukan post-incident review yang brutal-honest, benerin semua kelemahan, invest di tools dan training. Dua tahun kemudian, mereka kena lagi — tapi kali ini response time 4 jam, nol data bocor, pelanggan bahkan nggak sadar ada insiden. Itu hasil dari post-incident review yang serius. Jadi, jangan takut kena insiden. Takutlah kalau lo kena insiden lalu nggak belajar apa-apa darinya.

Dan satu pesan terakhir buat lo yang mungkin baru pertama kali memimpin post-incident review: jadilah pemimpin yang menciptakan ruang aman. Tim lo harus merasa nyaman untuk jujur — termasuk mengakui kesalahan. Kalau lo merespons pengakuan dengan kemarahan, next time mereka akan menyembunyikan kesalahan sampai terlambat. Tapi kalau lo merespons dengan "terima kasih sudah jujur, sekarang kita perbaiki bersama" — lo sedang membangun tim yang tangguh. Tim yang tidak takut gagal, karena mereka tahu setiap kegagalan adalah batu loncatan menuju perbaikan. Itu budaya yang langka. Dan langka artinya berharga.