Di episode #1 saya memuat Confidentiality, Integrity, Availability sebagai pengukur setiap keputusan keamanan. Waktu itu saya masih berpikir tugas utama programmer adalah mencegah serangan supaya tidak pernah terjadi. Hari ini saya belajar sisi lain yang menurut saya justru lebih realistis: mencegah 100% itu mustahil, jadi yang membedakan insiden kecil dan bencana adalah bagaimana kita merespons begitu alarm berbunyi. Ini catatan belajar saya tentang incident response.
Kenapa ini bukan cuma urusan tim SOC besar
Saya sempat mengira incident response hanya relevan untuk perusahaan dengan ruangan monitor kaca. Ternyata tidak. Di episode #2 saya mencatat bahwa ransomware, phishing, dan supply chain attack menyerang organisasi segala ukuran, termasuk developer lepas dan blog kecil seperti milik saya. Analogi yang paling menempel di kepala saya: pemadam kebakaran tidak pernah berharap rumahnya terbakar, tapi mereka tetap latihan setiap bulan dan tahu persis pintu mana yang dibuka lebih dulu. Incident response adalah latihan itu — sebuah runbook, bukan keberanian.
PICERL: enam langkah dari SANS
Model yang paling banyak dipakai praktisi adalah PICERL dari SANS Incident Handler’s Handbook. Enam langkahnya berurutan dan membentuk siklus, bukan garis lurus:
- Persiapan — rencana, playbook per skenario, log yang benar-benar aktif, backup yang pernah diuji restore, dan pembagian peran. Ini satu-satunya tahap yang dikerjakan saat jam tidak berjalan, jadi paling sering ditunda.
- Identifikasi — memastikan alert itu insiden nyata, bukan false positive, lalu memetakan cakupannya: host mana, akun mana, data apa.
- Penahanan — menghentikan penyebaran: isolasi host, blokir akun/IP, tanpa menghapus bukti yang dibutuhkan analisis.
- Pembersihan (eradication) — menghapus malware, mematikan persistence, menutup celah masuk awal, dan mereset kredensial yang tersentuh.
- Pemulihan — mengembalikan layanan dari backup yang bersih, memvalidasi, lalu memantau tanda kambuh.
- Pelajaran — review tanpa mencari kambing hitam, paling lambat dua minggu setelah insiden selesai, hasilnya berupa aksi konkret dengan pemilik dan tenggat.
Yang baru saya sadari: urutannya menentukan hasil. Pembersihan yang terburu-buru menghapus bukti, pemulihan yang terlalu cepat membuat insiden terbuka kembali berhari-hati kemudian.
Aturan yang paling saya ingat: bukti dulu, bersih-bersih kemudian
Ini bagian yang paling menahan tangan saya sebagai programmer. Kebiasaan saya kalau server terasa aneh langsung restart atau reinstall — ternyata reboot membuang isi RAM (proses mencurigakan, koneksi yang masih terbuka), dan reinstall menimpa jejak di disk. Karena itu penahanan selalu diawali pekerjaan dokumenter kecil: catat waktu, simpan log, baru ubah sistem.
# jejak awal dicatat SEBELUM menyentuh service apa pun date -u # patokan waktu (UTC) untuk timeline who; last -n 20 # siapa saja yang login belakangan ss -tulpn # port & proses yang mendengarkan journalctl --since "24 hours ago" > /tmp/bukti-jurnal.txt # salin keluar, jangan hanya dilihat di layar: scp /tmp/bukti-jurnal.txt user@mesin-analisis:/tmp/
Perintah di atas bukan mantra pengusir hantu — nilainya ada pada kebiasaan menyimpan salinan dengan stempel waktu. Bukti yang integritasnya terjaga adalah syarat kalau nanti insiden perlu dibawa ke ranah hukum; di Indonesia, pengujian sistem harus tetap berada di aset sendiri atau mendapat izin tertulis, karena UU ITE mengatur akses ilegal terhadap sistem elektronik. Catatan: justru syarat inilah yang membuat pemulihan dari backup lebih aman daripada “memperbaiki langsung”.
NIST SP 800-61 Rev. 3: kerangkanya berubah April 2025
Selama ini saya membaca referensi lama yang membagi penanganan insiden jadi empat fase (persiapan; deteksi & analisis; penahanan, pembersihan & pemulihan; aktivitas pasca-insiden). Ternyata pada 3 April 2025 NIST menerbitkan SP 800-61 Rev. 3 dan menarik Rev. 2. Perubahan besarnya: anjuran incident response kini dipetakan ke fungsi-fungsi NIST Cybersecurity Framework 2.0 — Govern, Identify, Protect, Detect, Respond, Recover — bukan diagram fase yang berdiri sendiri. Pekerjaannya sama, hanya pengelompokannya yang berubah. Bagi saya poin pentingnya justru kedisiplinan yang ditekankan: klasifikasi & prioritas insiden (RS.MA-02/03), akar masalah dianalisis sampai tuntas (RS.AN-03), dan rekaman tindakan penyelidikan wajib dijaga integritasnya (RS.AN-06).
Kesalahan yang saya catat supaya tidak saya ulangi
- Langsung wipe atau reinstall tanpa menyimpan log dan citra — penyelidikan berhenti sebelum dimulai.
- Menganggap satu host yang tertangkap adalah satu-satunya yang terinfeksi, padahal penyerang biasanya sudah berpindah.
- Menyalakan kembali layanan karena tekanan bisnis sebelum pembersihan diverifikasi.
- Lewat tahap pelajaran, lalu insiden yang sama terulang dengan biaya penuh.
- Ternyata log tidak pernah disimpan cukup lama — ini yang membuat saya ingat kembali materi episode #14 tentang audit log; tanpa log, identifikasi hanya menebak.
Checklist yang bisa saya siapkan minggu ini
Sederhana, tapi sudah mengubah cara saya bekerja: uji restore backup (backup yang belum pernah dipulihkan bukan backup), tulis definisi “apa yang dianggap insiden” beserta tingkat keparahannya, tentukan siapa yang berwenang mengisolasi server tanpa menunggu rapat, siapkan playbook untuk tiga skenario paling mungkin (phishing ke akun admin, ransomware, kebocoran kredensial — lihat materi episode #18), dan pastikan log disimpan cukup lama. Di banyak yurisdiksi ada kewajiban pemberitahuan pelanggaran data dengan tenggat ketat — di Uni Eropa misalnya 72 jam (GDPR Pasal 33) — sehingga keputusan “lapor atau tidak” sebaiknya sudah dipikirkan sebelum insiden, bukan saat panik.
Sumber
- NIST SP 800-61 Rev. 3 — Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile (final 3 April 2025)
- NIST news: NIST Revises SP 800-61 (April 2025)
- NIST CSRC — Incident Response project page
- SANS — Incident Handler’s Handbook (Patrick Kral, 21 Feb 2012), dasar model PICERL
- SANS SEC504 — Incident Response Cycle cheat sheet (PICERL)
- CISA — Federal Government Cybersecurity Incident and Vulnerability Response Playbooks (template playbook yang bisa disesuaikan)
Komentar Terbaru