Bab 6: Menanggulangi Insiden - Incident Response

🎯 Track: Keduanya (K) - Untuk Direksi, Manajer, dan Teknisi

---

"Ketika", Bukan "Jika"

Bab 1 sampai 5 membahas cara membangun pertahanan - Fisik, Jaringan, Perangkat, Proses, dan Regulasi. Semuanya bertujuan mengurangi kemungkinan insiden terjadi. Tapi tidak ada pertahanan yang sempurna, dan Bab 4 sudah menekankan itu: setiap lapis akan gagal suatu saat.

Pertanyaannya bukan "apakah PDAM Anda akan mengalami insiden siber", melainkan "ketika insiden terjadi, apakah PDAM Anda tahu harus melakukan apa dalam lima menit pertama, bukan lima jam pertama." Bab ini membahas persis itu.

---

🎯 Tujuan Bab Ini

Setelah membaca bab ini, Anda akan:

1. Memahami siklus penanggulangan insiden menurut NIST SP 800-61 - kerangka yang sudah teruji luas
2. Punya template SOP yang bisa langsung disesuaikan untuk PDAM Anda
3. Melihat kembali kasus Oldsmar dan PDNS (Bab 1-2) lewat lensa siklus ini - apa yang berjalan, apa yang tidak
4. Tahu cara menjalankan simulasi tanggap insiden tanpa perlu insiden sungguhan

---

Siklus Penanggulangan Insiden (NIST SP 800-61)

NIST membagi penanggulangan insiden menjadi empat fase yang berulang - bukan proses linier sekali jalan, melainkan siklus yang terus disempurnakan setiap kali dijalankan.

Fase 1: Persiapan (Preparation)

Fase ini terjadi sebelum insiden - dan ini yang paling sering diabaikan karena tidak terasa mendesak sampai terlambat.

Kontrol konkret:

• Tim Tanggap Insiden sudah dibentuk (disebut di Bab 4 dan 5) dengan peran jelas: siapa memimpin, siapa menghubungi vendor, siapa menghubungi BSSN
• Daftar kontak darurat tersedia offline - vendor SCADA, ISP, BSSN, manajemen puncak - karena sistem yang terinfeksi mungkin tidak bisa diakses untuk mencari nomor telepon
• Backup offline teruji dan bisa dipulihkan (bukan hanya "ada", tapi pernah dicoba dipulihkan)
• SOP tertulis dan pernah disimulasikan, bukan dokumen yang baru dibuka saat insiden terjadi

Pelajaran dari PDNS (Bab 2): salah satu alasan pemulihan memakan waktu berminggu-minggu adalah keterbatasan kesiapan sebelumnya - bukan semata kecepatan tim yang menangani setelah insiden diketahui.

Fase 2: Deteksi dan Analisis (Detection & Analysis)

Fase ini menjawab: bagaimana Anda tahu sedang diserang, dan seberapa parah?

Kontrol konkret:

• Indikator kompromi (IoC) yang sudah dibahas di Bab 2 dipantau secara aktif, bukan hanya diketahui secara teori
• Ada jalur pelaporan yang jelas dan tidak menghukum - staf yang melihat sesuatu aneh harus merasa aman melapor, bukan takut disalahkan
• Log dari lapis Jaringan dan Proses (Bab 3-4) tersimpan cukup lama untuk ditelusuri saat insiden terjadi

Pelajaran dari Oldsmar (Bab 1): operator sebenarnya melihat mouse bergerak sendiri di 14:15 - tanda deteksi sudah ada. Yang gagal adalah analisis dan eskalasi: sinyal itu diabaikan sampai upaya kedua di jam 15:00. Deteksi tanpa jalur eskalasi yang jelas sama saja dengan tidak mendeteksi.

Fase 3: Penahanan, Pemberantasan, dan Pemulihan (Containment, Eradication & Recovery)

Setelah insiden dikonfirmasi, tiga langkah berurutan:

1. Penahanan (Containment): hentikan penyebaran - putuskan koneksi yang dicurigai, matikan remote access, isolasi segmen jaringan yang terdampak (di sinilah segmentasi Bab 3 membuktikan nilainya: kerusakan terbatas pada satu segmen, bukan seluruh jaringan)
2. Pemberantasan (Eradication): hilangkan akar masalah - hapus malware, tutup celah yang dieksploitasi, ganti kredensial yang mungkin bocor
3. Pemulihan (Recovery): kembalikan sistem ke operasi normal dari backup yang bersih dan sudah diverifikasi, dengan pemantauan ekstra selama masa transisi

Prinsip penting: jangan buru-buru pulihkan sistem sebelum akar masalah benar-benar dihilangkan - memulihkan sistem yang masih terinfeksi hanya mengulang insiden yang sama.

Fase 4: Aktivitas Pasca-Insiden (Post-Incident Activity)

Fase yang paling sering dilewatkan karena semua orang ingin "kembali normal" secepatnya - padahal ini fase yang membuat insiden berikutnya lebih kecil kemungkinannya.

Kontrol konkret:

• Dokumentasikan kronologi insiden selagi masih segar: apa yang terjadi, kapan, siapa merespons, apa yang berhasil dan tidak
• Evaluasi SOP - apakah prosedur yang ada cukup, atau perlu direvisi
• Penuhi kewajiban notifikasi UU PDP (Bab 5) jika insiden melibatkan data pribadi - dalam 3x24 jam, bukan setelah semuanya "aman"
• Bagikan pelajaran ke seluruh organisasi, bukan hanya tim IT

---

Template SOP Minimal untuk PDAM

SOP tidak harus panjang untuk berguna. Kerangka minimal yang bisa langsung diisi:

Elemen	Isi yang Perlu Ditentukan Sekarang
Pemicu	Kondisi apa yang menghitung sebagai "insiden" dan memicu SOP ini
Eskalasi	Siapa dihubungi pertama, kedua, ketiga - dengan nomor telepon, bukan hanya nama jabatan
Kewenangan	Siapa yang berhak memutuskan memutus jaringan atau menghentikan sistem produksi
Kontak eksternal	Vendor SCADA, ISP, BSSN, dan (jika relevan) penasihat hukum untuk kewajiban UU PDP
Dokumentasi	Format sederhana untuk mencatat kronologi selama insiden berlangsung
Tinjauan	Kapan SOP ini direvisi ulang - idealnya setiap kali dipakai, simulasi maupun sungguhan

---

Simulasi Tabletop: Latihan Tanpa Insiden Sungguhan

Bab 4 dan 5 sudah menyebut pentingnya menguji SOP lewat simulasi. Simulasi tabletop sederhana:

1. Pilih skenario realistis - misalnya "TeamViewer di HMI diakses dari IP tak dikenal jam 2 pagi" (mengingatkan pada Oldsmar)
2. Kumpulkan tim yang relevan (bukan hanya IT - libatkan operasional dan manajemen)
3. Jalankan skenario secara verbal: fasilitator memberi update situasi, tim menjawab "apa yang kami lakukan sekarang" tanpa benar-benar menyentuh sistem produksi
4. Catat titik macet - di mana tim bingung siapa memutuskan, siapa dihubungi, atau prosedur apa yang belum ada
5. Revisi SOP berdasarkan titik macet yang ditemukan

Simulasi 60-90 menit, dua kali setahun, sudah jauh lebih baik daripada SOP yang hanya ada di atas kertas dan tidak pernah diuji siapa pun.

---

🎯 Yang Harus Anda Lakukan

Untuk Direksi:

1. ✅ Sahkan Tim Tanggap Insiden dengan kewenangan jelas untuk mengambil keputusan darurat
2. ✅ Ikut serta dalam simulasi tabletop minimal sekali setahun - bukan cuma tim teknis
3. ✅ Pastikan anggaran darurat tersedia tanpa perlu proses persetujuan panjang saat insiden terjadi

Untuk Manajer IT:

1. ✅ Susun daftar kontak darurat offline dan sebarkan ke tim relevan
2. ✅ Uji pemulihan backup - bukan hanya pastikan backup berjalan, tapi pastikan bisa benar-benar dipulihkan
3. ✅ Jadwalkan simulasi tabletop pertama dalam 90 hari ke depan

Untuk Teknisi:

1. ✅ Kenali indikator kompromi dari Bab 2 dan laporkan tanpa ragu
2. ✅ Ketahui langkah penahanan darurat - port mana yang dicabut, sistem mana yang diisolasi
3. ✅ Catat kronologi secara real-time saat insiden berlangsung, bukan mengandalkan ingatan setelahnya

---

📖 Lanjut ke Bab Berikutnya

Bab ini membahas cara merespons ketika insiden terjadi.

Bab selanjutnya akan membahas teknologi konkret - 10 teknologi kritis (firewall, VPN, SIEM, dan lainnya) yang menopang seluruh lapis pertahanan yang sudah dibahas.

---

📝 Diskusi Refleksi

Setelah membaca bab ini, jawab pertanyaan berikut - satu per fase:

1. Persiapan: Apakah PDAM Anda punya daftar kontak darurat yang bisa diakses tanpa sistem yang mungkin sedang terinfeksi?
2. Deteksi: Jika staf melihat sesuatu yang aneh, apakah mereka tahu harus melapor ke siapa, dan merasa aman melakukannya?
3. Penahanan/Pemulihan: Apakah backup PDAM Anda pernah benar-benar diuji pulihkan, bukan hanya "ada"?
4. Pasca-Insiden: Jika insiden terjadi hari ini, siapa yang bertanggung jawab mendokumentasikan kronologinya?

Jika Anda belum pernah menjalankan simulasi tabletop, itu titik awal yang baik untuk 90 hari ke depan.

---

Selamat membaca! Semoga bab ini membuat PDAM Anda siap merespons, bukan panik, ketika insiden datang. 🛡️💧

---

📚 Referensi

• NIST. (2012). Computer Security Incident Handling Guide (SP 800-61 Rev. 2). National Institute of Standards and Technology.
• WaterISAC. (2022). Ransomware Attacks on Water and Wastewater Systems. Water Information Sharing and Analysis Center.

---

Disclaimer: Tulisan ini adalah pandangan pribadi penulis dan tidak mewakili pandangan organisasi mana pun. Isi bab ini disajikan untuk tujuan edukasi, bukan nasihat keamanan siber, hukum, atau teknis resmi. Penerapan pada sistem yang sedang beroperasi tetap memerlukan verifikasi dan penyesuaian oleh pihak yang berwenang di organisasi masing-masing.