Incident Response 101: The First 60 Minutes Matter
Panduan 60 menit pertama insiden response: triage, pembentukan tim, penahanan, komunikasi, dan checklist praktis dari pengalaman lapangan.
Jam pertama setelah insiden terdeteksi adalah jam yang paling menentukan. Gue tahu ini bukan dari buku, tapi dari pengalaman pahit. Satu kali, gue menunda tindakan karena nunggu "data yang lebih lengkap". Dalam 30 menit, penyerang sudah pindah ke tiga server lain. Pelajaran mahal.
Incident response 60 menit pertama bukan tentang menyelesaikan insiden. Itu tentang memperlambat penyerang, mengumpulkan cukup informasi untuk membuat keputusan, dan mencegah kerusakan yang lebih besar. Ini adalah panduan praktis yang gue pakai sendiri.
Menit 0 Sampai 15: Triage dan Konfirmasi
Langkah pertama adalah yang paling penting: pastikan ini insiden nyata, bukan false positive. Banyak tim membuang waktu mengejar hantu. Banyak tim lain malah mengabaikan ancaman nyata karena mengira itu noise.
Pertanyaan pertama: apa yang memicu alert? SIEM? Laporan pengguna? Notifikasi dari pihak ketiga? Identifikasi sumbernya.
Pertanyaan kedua: seberapa bisa dipercaya sumber itu? Alert dari SIEM yang sudah teruji punya keandalan tinggi. Email dari "seseorang di internet" perlu verifikasi lebih lanjut.
Pertanyaan ketiga: apa dampak jika ini benar-benar insiden? Kalau server produksi terancam, prioritasnya paling tinggi. Kalau cuma workstation yang terisolasi, lo bisa bernapas sedikit lebih lega.
Dalam 15 menit pertama, lo harus bisa menjawab: apakah ini nyata, apa yang terpengaruh, dan siapa yang perlu dikumpulkan untuk merespons.
Menit 15 Sampai 30: Pembentukan Tim dan Komunikasi Awal
Begitu lo yakin ini insiden nyata, jangan bekerja sendiri. Kumpulkan tim respons. Minimal, lo butuh tiga peran.
Incident commander adalah orang yang memimpin. Dia membuat keputusan, mengelola komunikasi, dan memastikan semua orang tahu perannya. Dia tidak melakukan pekerjaan teknis — dia mengoordinasikan.
Investigator adalah orang yang menggali secara teknis. Dia memeriksa log, menganalisis bukti, dan mencari tahu apa yang sebenarnya terjadi. Satu investigator bisa cukup untuk insiden kecil.
Communicator adalah orang yang memberi kabar ke stakeholder. Dia menulis update untuk manajemen, memberitahu pengguna yang terkena dampak, dan menyiapkan komunikasi eksternal jika diperlukan.
Komunikasi pertama ke stakeholder tidak perlu panjang. Cukup: apa yang terjadi (singkat), apa yang lo lakukan sekarang, dan kapan update berikutnya. Jangan berspekulasi. Jangan janji. Cukup fakta.
Satu kesalahan yang sering gue lihat: tim teknis terlalu sibuk menyelidiki sampai lupa memberi kabar ke manajemen. Manajemen kemudian panik karena tidak tahu apa yang terjadi, lalu mengambil keputusan buruk. Komunikasi adalah bagian dari respons, bukan hambatan.
Menit 30 Sampai 45: Tindakan Penahanan
Ini saatnya bertindak. Tujuan penahanan adalah membatasi radius kerusakan. Bukan membereskan semuanya, tapi menghentikan pendarahan.
Beberapa tindakan penahanan yang bisa lo ambil:
Isolasi host yang terinfeksi dari jaringan. Cabut kabel jaringan, nonaktifkan interface, atau blokir di switch. Jangan shutdown dulu — memory dan proses yang sedang berjalan adalah bukti forensik yang berharga.
Reset kredensial yang dicurigai bocor. Password korban, API key yang tersimpan di server yang terinfeksi, token akses. Lebih baik reset lebih banyak daripada lebih sedikit.
Blokir indikator kompromi di perimeter. IP address penyerang, domain command-and-control yang terlihat di log, atau hash file malware. Ini tindakan sementara sambil investigasi berlanjut.
Jangan buru-buru mematikan semuanya. Tindakan yang terlalu agresif bisa menghilangkan bukti dan memberi tahu penyerang bahwa mereka terdeteksi. Penahanan adalah keseimbangan antara kecepatan dan kehati-hatian.
Menit 45 Sampai 60: Dokumentasi dan Transisi
Di akhir jam pertama, lo harus sudah punya dokumentasi yang cukup untuk transisi ke fase berikutnya.
Buat timeline sederhana. Kapan alert pertama muncul, kapan tim dibentuk, kapan tindakan diambil. Timeline ini akan jadi fondasi investigasi lanjutan dan laporan akhir.
Kirim update kedua ke stakeholder. Sebutkan apa yang sudah dilakukan, apa yang sedang diselidiki, dan apa rencana jam berikutnya. Manajemen butuh tahu bahwa situasi terkendali — bahkan jika secara teknis masih banyak yang tidak pasti.
Pastikan role untuk jam berikutnya sudah jelas. Siapa yang melanjutkan investigasi forensik, siapa yang memantau alert baru, siapa yang menulis laporan. Kelelahan adalah musuh di fase ini.
Apa yang Tidak Boleh Dilakukan
Menyalahkan. Mencari "siapa yang salah" di jam pertama adalah tindakan yang merusak dan tidak membantu. Fokus ke pemulihan dulu, evaluasi nanti.
Menghancurkan bukti. Jangan format server yang terinfeksi. Jangan hapus log karena panik menyembunyikan jejak. Bukti adalah kunci untuk memahami apa yang terjadi dan mencegah kejadian serupa.
Mendiamkan insiden. Tidak memberitahu siapapun adalah kesalahan fatal. Insiden mungkin memerlukan bantuan dari luar, dan semakin lama lo diam, semakin besar risiko hukum dan reputasi.
Membuat keputusan besar tanpa data. Jangan umumkan ke publik tanpa konfirmasi. Jangan hubungi penyerang. Jangan nego tanpa konsultasi hukum.
Persiapan Sebelum Insiden Terjadi
Jam pertama yang efektif dimulai jauh sebelum insiden terjadi. Lo harus sudah menyiapkan fondasinya saat keadaan tenang.
Buat daftar kontak darurat. Siapa yang harus dihubungi, dalam urutan apa, dan lewat jalur apa. Simpan daftar ini di luar sistem yang mungkin terkena dampak.
Siapkan alat komunikasi darurat. Kalau email perusahaan down, bagaimana tim komunikasi? Group chat terpisah, nomor telepon cadangan, atau frekuensi radio.
Dokumentasikan arsitektur sistem. Lo tidak punya waktu untuk memetakan jaringan saat insiden berlangsung. Diagram jaringan, daftar server kritis, dan dependensi antar sistem harus sudah didokumentasikan sebelumnya.
Latihan tabletop secara berkala. Kumpulkan tim setiap tiga bulan, berikan skenario insiden, dan jalani proses respons tanpa benar-benar menyentuh sistem. Ini membangun memori otot yang akan menyelamatkan lo saat insiden nyata.
Penutup
Insiden adalah bukan soal "jika", tapi "kapan". Suatu hari nanti, sesuatu akan terjadi. Mungkin phishing, mungkin ransomware, mungkin insider threat. Ketika itu terjadi, jam pertama lo adalah perbedaan antara gangguan kecil dan berita utama.
Persiapkan sekarang. Latih sekarang. Jangan tunggu sampai insiden terjadi.
#IncidentResponse #Cybersecurity #DFIR #BlueTeam #InfoSec
Checklist Jam Pertama yang Bisa Lo Cetak
Kalau lo hanya mengingat satu hal dari tulisan ini, ingat checklist ini. Cetak, tempel di dinding, simpan di HP.
- 1Konfirmasi: apakah ini insiden nyata?
- 2Identifikasi: apa yang terpengaruh? Server, akun, data apa?
- 3Kumpulkan tim: incident commander, investigator, communicator.
- 4Kirim update awal ke stakeholder, tanpa spekulasi.
- 5Isolasi: batasi radius kerusakan, jangan shutdown dulu.
- 6Reset kredensial yang dicurigai bocor.
- 7Blokir IoC di perimeter: IP address, domain, hash file.
- 8Buat timeline kronologi selama jam pertama.
- 9Kirim update kedua ke stakeholder.
- 10Dokumentasikan semua langkah, pastikan role untuk jam berikutnya sudah jelas.
Pelajaran dari Insiden Nyata
Gue pernah merespons insiden di mana penyerang sudah berada di dalam selama dua minggu sebelum terdeteksi. Di jam pertama, gue merasa kewalahan. Tapi karena tim punya playbook yang jelas, kami bisa membagi tugas: investigator menelusuri log, gue sebagai commander mengoordinasi, dan satu orang fokus ke komunikasi. Playbook itu menyelamatkan kami.
Playbook bukan menggantikan penilaian manusia, ia mengurangi beban keputusan di saat stres. Lo tidak perlu memikirkan apa yang harus dilakukan selanjutnya, karena sudah ada template-nya.
Siapkan playbook lo sekarang. Uji dengan tabletop. Perbaiki dari hasil latihan. Ketika insiden nyata datang, lo akan berterima kasih pada diri sendiri.
#IncidentResponse #Cybersecurity #DFIR #BlueTeam #InfoSec