Lessons Learned - Pembelajaran Pasca Insiden

Pengantar

Lessons Learned adalah fase paling penting namun paling sering diabaikan dalam Incident Response Lifecycle. Setelah insiden berhasil ditangani dan sistem kembali pulih, organisasi sering kali langsung "move on" tanpa melakukan evaluasi mendalam. Padahal, tanpa Lessons Learned, organisasi akan mengulangi kesalahan yang sama pada insiden berikutnya.

Fase ini dalam NIST SP 800-61 disebut Post-Incident Activity, dan dalam SANS PICERL merupakan fase keenam: Lessons Learned. Tujuannya sederhana: belajar dari pengalaman agar tidak terjadi lagi. Artikel ini membahas Post-Incident Review (PIR), format meeting, action item tracking, root cause analysis, metrics, improvement plan, dan feedback loop ke prevention.

Post-Incident Review (PIR)

Post-Incident Review adalah pertemuan formal yang dilakukan dalam waktu 1 - 2 minggu setelah insiden selesai. PIR bukan ajang mencari siapa yang salah, melainkan forum untuk evaluasi proses secara objektif.

Tujuan PIR

1. Mengidentifikasi apa yang berjalan baik dan perlu dipertahankan.
2. Mengidentifikasi apa yang tidak berjalan baik dan perlu diperbaiki.
3. Menentukan akar penyebab (root cause) insiden.
4. Menghasilkan rekomendasi konkret dan actionable.
5. Memperbarui Incident Response Plan, playbook, dan deteksi rules.
6. Meningkatkan maturity organisasi dalam menangani insiden.

Format Pertemuan PIR

Durasi: 60 - 90 menit Peserta Wajib:

• Incident Manager (fasilitator)
• SOC Analyst yang terlibat (L1, L2, L3)
• Forensic Analyst
• IT Operations (yang melakukan recovery)
• Perwakilan dari tim yang terdampak (misal: Engineering, Finance)
• CISO / Kepala Keamanan Informasi (untuk insiden S1/S2)
• Perwakilan Legal (jika ada implikasi hukum)

Peserta Opsional:

• HR (jika insiden melibatkan insider threat)
• External forensic consultant
• Vendor terkait (misal: EDR vendor, cloud provider)

Agenda PIR

AGENDA POST-INCIDENT REVIEW
Case ID: IR-2025-0042 - Ransomware LockBit 3.0
Tanggal: 30 Juni 2025, 10:00 - 11:30 WIB
Lokasi: Meeting Room 3 / Google Meet

1. Pembukaan (5 menit)
   - Tujuan meeting: evaluasi proses, bukan mencari kesalahan.
   - Ground rules: jujur, terbuka, konstruktif.

2. Ringkasan Insiden (10 menit)
   - Timeline singkat dari Incident Manager.

3. Evaluasi - Apa yang Berjalan Baik? (15 menit)
   - Setiap peserta menyampaikan 1 - 2 hal positif.

4. Evaluasi - Apa yang Perlu Diperbaiki? (20 menit)
   - Identifikasi gaps dan kelemahan proses.

5. Root Cause Analysis (15 menit)
   - Metode 5 Whys atau Fishbone Diagram.

6. Rekomendasi dan Action Items (15 menit)
   - Setiap rekomendasi harus memiliki PIC dan deadline.

7. Penutup (10 menit)
   - Summary, follow-up meeting schedule, distribution of minutes.

Action Item Tracking

Setiap rekomendasi dari PIR harus dicatat sebagai action item yang dilacak hingga selesai. Gunakan format berikut:

ACTION ITEM TRACKER
Insiden: Ransomware LockBit 3.0 - IR-2025-0042

| No | Rekomendasi                         | Tindakan                        | PIC        | Deadline   | Status      |
|----|-------------------------------------|---------------------------------|------------|------------|-------------|
| 1  | Update signature email gateway      | Jadwalkan update otomatis       | IT Ops     | H+7        | Selesai     |
|    | secara terjadwal                   | mingguan via cron               |            |            |             |
| 2  | Implementasi network               | Buat VLAN terpisah untuk        | Network    | H+30       | In Progress |
|    | micro-segmentation                 | setiap tier (web, app, db)      |            |            |             |
| 3  | Security awareness training        | Jadwalkan simulasi phishing     | HR + IT    | H+14       | Selesai     |
|    | bulanan                           | bulanan dengan report hasil     |            |            |             |
| 4  | Update detection rules di SIEM     | Tambah Sigma rules untuk       | SOC L3     | H+5        | Selesai     |
|    | untuk varian ransomware baru       | LockBit 3.0 dan varian terkini  |            |            |             |
| 5  | Implementasi MFA untuk             | Deploy Duo Security untuk       | IT Ops     | H+7        | Selesai     |
|    | semua akses remote                | VPN dan RDP                     |            |            |             |
| 6  | Backup offline (air-gapped)        | Setup backup tape offline       | IT Ops     | H+45       | Not Started |
|    |                                    | dengan rotasi mingguan          |            |            |             |

Tools Action Tracking:

• Jira - issue tracker dengan workflow approval dan SLA.
• TheHive - task management per case.
• Trello / Asana - kanban board untuk tracking.
• Google Sheets - sederhana, cukup untuk tim kecil.

Root Cause Analysis (RCA)

Root Cause Analysis adalah proses sistematis untuk menemukan penyebab fundamental insiden - bukan sekadar gejala permukaan. Dua metode paling populer adalah 5 Whys dan Fishbone Diagram.

Metode 5 Whys

Teknik sederhana dengan bertanya "Mengapa?" secara berulang hingga akar masalah ditemukan.

Contoh 1 - Ransomware via Phishing:

Gejala: Server terenkripsi ransomware.
1. Mengapa? → User membuka lampiran email phishing.
2. Mengapa? → Email lolos dari email gateway.
3. Mengapa? → Signature database email gateway tidak diupdate.
4. Mengapa? → Tidak ada jadwal maintenance security appliances.
5. Mengapa? → Tidak ada SOP IT untuk update berkala.
Root Cause: Tidak adanya SOP pemeliharaan security appliances.

Contoh 2 - Data Breach via API:

Gejala: Data pelanggan bocor melalui API endpoint.
1. Mengapa? → API endpoint tidak memiliki rate limiting.
2. Mengapa? → Developer tidak memasukkan rate limiting saat deployment.
3. Mengapa? → Tidak ada security review dalam CI/CD pipeline.
4. Mengapa? → Security team tidak dilibatkan dalam proses development.
5. Mengapa? → Tidak ada Secure SDLC policy di organisasi.
Root Cause: Tidak adanya kebijakan Secure SDLC dan security review.

Contoh 3 - DDoS Berhasil Melumpuhkan Server:

Gejala: Website tidak bisa diakses selama 3 jam.
1. Mengapa? → Traffic DDoS membanjiri server.
2. Mengapa? → Tidak ada DDoS protection di frontend.
3. Mengapa? → Anggaran untuk CDN/WAF tidak disetujui.
4. Mengapa? → Risiko DDoS tidak diidentifikasi dalam risk assessment.
5. Mengapa? → Tidak ada Business Impact Analysis (BIA) untuk infrastruktur.
Root Cause: Tidak adanya Business Impact Analysis yang komprehensif.

Fishbone Diagram (Ishikawa / Cause-and-Effect)

Diagram ini membantu mengidentifikasi faktor penyebab dari berbagai kategori. Untuk insiden keamanan, kategori yang umum digunakan:

• People (Manusia): Kurang training, human error, phishing victim, insider threat.
• Process (Proses): Tidak ada SOP, patch mgmt buruk, no DR test, no change management.
• Technology (Teknologi): EDR outdated, SIEM rule lama, backup gagal, software vulnerable.
• Policy (Kebijakan): No IR plan, no BCP/DRP, budget tidak memadai, no access control policy.
• Compliance (Kepatuhan): Regulasi tidak dipatuhi, tidak ada audit berkala, no risk assessment.
• Environment (Lingkungan): Network flat (no segmentation), VPN publik, cloud misconfiguration.

Cara menggunakan Fishbone Diagram:

1. Tulis insiden di bagian kanan (efek/kepala ikan).
2. Identifikasi kategori penyebab (tulang besar).
3. Brainstorm penyebab di setiap kategori (tulang kecil).
4. Analisis penyebab yang paling mungkin dan dapat ditindaklanjuti.
5. Validasi dengan data dan bukti dari investigasi.
6. Tetapkan tindakan perbaikan untuk setiap penyebab yang valid.

Metrik Incident Response (KPIs)

Metrik berikut digunakan untuk mengukur efektivitas tim IR dan menjadi bahan evaluasi di Lessons Learned:

1. MTTD - Mean Time to Detect

Waktu rata-rata yang dibutuhkan untuk mendeteksi insiden sejak pertama kali terjadi.

Rumus: MTTD = Jumlah (Detection Time - Occurrence Time) / Jumlah Insiden
Contoh: (32 + 45 + 18 + 60) / 4 = 38,75 menit
Target: Kurang dari 30 menit untuk S1, kurang dari 1 jam untuk S2

2. MTTR - Mean Time to Respond

Waktu rata-rata dari deteksi hingga containment atau eradication.

Rumus: MTTR = Jumlah (Response Time - Detection Time) / Jumlah Insiden
Contoh: (120 + 90 + 45 + 180) / 4 = 108,75 menit
Target: Kurang dari 60 menit (S1), kurang dari 4 jam (S2/S3)

3. MTTC - Mean Time to Contain

Waktu rata-rata untuk menahan insiden agar tidak meluas.

4. Dwell Time

Waktu antara kompromi awal dan deteksi. Semakin pendek semakin baik.

Dwell Time = Detection Time - Initial Compromise Time
Target: Kurang dari 24 jam (ideal), kurang dari 72 jam (acceptable)
Rata-rata industri 2024: 200+ hari (Mandiant M-Trends)

5. MTBF - Mean Time Between Failures

Waktu rata-rata antara satu insiden ke insiden berikutnya. Digunakan untuk mengukur stabilitas dan efektivitas perbaikan.

Dashboard Metrik

INCIDENT RESPONSE METRICS - Q2 2025
+----------------------------+----------+----------+----------+----------+
| Metrik                     | Target   | Q1 2025  | Q2 2025  | Trend    |
+----------------------------+----------+----------+----------+----------+
| MTTD (menit)               |          |          |          |          |
| Dwell Time (jam)           |          |          |          |          |
+----------------------------+----------+----------+----------+----------+
| Rata-rata MTTD             |          |          |          |          |
| Rata-rata Dwell Time       |          |          |          |          |
+----------------------------+----------+----------+----------+----------+

Tools Monitoring Metrik:

• TheHive / IRIS - dashboard metrik built-in dengan SLA tracking.
• Grafana + Prometheus - kustom dashboard untuk visualisasi metrik.
• Elastic Stack (Kibana) - aggregasi log dan metrik dari SIEM.
• Jira Dashboard - gadget untuk SLA dan MTTR tracking.

Improvement Plan

Berdasarkan hasil PIR dan RCA, buat Improvement Plan yang konkret dan terukur:

1. Short-Term (0 - 30 Hari)

Tindakan cepat untuk menutup celah kritis:

2. Mid-Term (30 - 90 Hari)

Perbaikan infrastruktur dan proses:

3. Long-Term (3 - 12 Bulan)

Program perbaikan jangka panjang:

Feedback Loop ke Prevention

Fungsi paling krusial dari Lessons Learned adalah menutup siklus - hasil evaluasi harus kembali ke fase Prevention/Preparation agar insiden serupa tidak terulang. Berikut adalah feedback loop yang ideal:

┌─────────────────────────────────────────────────────┐
│                   INSIDEN TERJADI                    │
└──────────────────┬──────────────────────────────────┘
                   │
                   ▼
┌─────────────────────────────────────────────────────┐
│               INCIDENT HANDLING                      │
│  (Triage → Containment → Eradication → Recovery)    │
└──────────────────┬──────────────────────────────────┘
                   │
                   ▼
┌─────────────────────────────────────────────────────┐
│              LESSONS LEARNED (PIR + RCA)             │
│  • Apa yang berjalan baik?                          │
│  • Apa yang perlu diperbaiki?                       │
│  • Metrics: MTTD, MTTR, Dwell Time                 │
└──────┬──────────────────────────────┬───────────────┘
       │                              │
       ▼                              ▼
┌──────────────────┐    ┌──────────────────────────────┐
│ UPDATE PREVENTION │    │    UPDATE PREPARATION         │
│ • Patch kerentanan│    │ • Update IR Plan & Playbook   │
│ • Tambah kontrol   │    │ • Update deteksi rules       │
│ • Training user   │    │ • Tambah alat (SOAR/EDR)      │
│ • Kebijakan baru  │    │ • Update SLA dan metrik       │
└──────────────────┘    └──────────────────────────────┘
       │                              │
       └──────────────┬───────────────┘
                      │
                      ▼
┌─────────────────────────────────────────────────────┐
│              PREVENTION (lebih kuat)                 │
│  • Security controls ditingkatkan                    │
│  • Detection capability diperkuat                    │
│  • Tim lebih siap menghadapi insiden berikutnya      │
│  • MTTD dan MTTR terus menurun                      │
└─────────────────────────────────────────────────────┘

Contoh Feedback Loop Nyata:

1. Insiden: Ransomware masuk via phishing.
2. Lessons Learned: Email gateway signature tidak update.
3. Feedback to Prevention:
   • Automatisasi update signature email gateway (cron job mingguan).
   • Tambah email security layer (DMARC, SPF, DKIM enforcement).
   • Training phishing simulasi bulanan untuk semua karyawan.
4. Hasil: 6 bulan kemudian, tingkat karyawan yang terjebak phishing turun dari 25% menjadi

Kesimpulan

Lessons Learned bukan sekadar formalitas - ia adalah motor perbaikan berkelanjutan dalam keamanan siber organisasi. Tanpa fase ini, setiap insiden hanyalah kejadian yang berlalu tanpa menghasilkan perbaikan berarti.

Kunci sukses implementasi Lessons Learned:

1. Lakukan PIR dalam 1 - 2 minggu - semakin cepat, semakin akurat ingatan semua pihak.
2. Blame-free culture - fokus pada proses, bukan individu.
3. Action item yang konkret - setiap rekomendasi harus measurable dan memiliki PIC.
4. Tracking hingga selesai - action item tanpa follow-up tidak ada artinya.
5. Metrics-driven - gunakan data (MTTD, MTTR, dwell time) untuk mengukur perbaikan.
6. Feedback loop ke prevention - pastikan hasil PIR benar-benar mengubah kebijakan, prosedur, dan alat.

Organisasi yang matang dalam Incident Response tidak hanya cepat merespons, tetapi juga terus belajar dan menjadi lebih tangguh setiap kali menghadapi insiden. Ingatlah motto tim IR profesional:

"Setiap insiden adalah guru. Jika Anda tidak belajar darinya, Anda akan mengulangi ujian yang sama."