Incident Response: Tahapan Menangani Insiden Keamanan

Incident response adalah pendekatan terstruktur untuk mendeteksi, menangani, dan memulihkan diri dari insiden keamanan siber agar kerugian bagi bisnis dan data bisa ditekan seminimal mungkin. Organisasi yang tidak punya rencana tertulis cenderung bereaksi dengan panik, sehingga bukti hilang dan kerusakan meluas. Artikel ini menjelaskan tahapan, peran tim, kewajiban pelaporan, dan hal yang perlu disiapkan sebelum insiden terjadi.

Apa Itu Incident Response dan Mengapa Organisasi Membutuhkannya?

Insiden keamanan adalah kejadian yang mengancam kerahasiaan, integritas, atau ketersediaan sistem dan data. Contohnya akun karyawan yang diambil alih, ransomware yang mengunci server, atau database pelanggan yang terekspos. Tidak semua kejadian yang tercatat di log adalah insiden. Ribuan percobaan login gagal setiap hari termasuk kejadian biasa, sedangkan satu login berhasil dari negara yang tidak pernah dipakai karyawan layak diselidiki.

Incident response (IR) menjawab pertanyaan yang pasti muncul saat insiden terjadi: siapa yang memutuskan, sistem mana yang dipisahkan lebih dulu, kapan manajemen dan pihak luar diberi tahu, dan bagaimana layanan dipulihkan. Menjawab semuanya di tengah krisis jauh lebih mahal daripada menyusunnya saat situasi tenang.

Tahapan Incident Response Menurut NIST

Acuan yang paling sering dipakai adalah NIST SP 800-61. Revisi 2 membagi penanganan insiden menjadi empat fase: persiapan, deteksi dan analisis, containment-eradication-recovery, serta aktivitas pasca-insiden. Pada April 2025, NIST menerbitkan Revisi 3 yang menggantikan Revisi 2. Panduan baru ini disusun sebagai profil komunitas untuk NIST Cybersecurity Framework 2.0 dan menegaskan bahwa keenam fungsi CSF 2.0 berperan dalam penanganan insiden. Fungsi Govern, Identify, dan Protect mewakili persiapan, sedangkan Detect, Respond, dan Recover membentuk inti penanganan. Pelajaran dari setiap insiden dikembalikan ke kategori Improvement. Revisi 3 tidak lagi memberi prosedur langkah demi langkah, tetapi menekankan integrasi IR ke dalam manajemen risiko.

Untuk praktik sehari-hari, alur klasik empat fase tetap berguna sebagai kerangka berpikir.

1. Persiapan

Ini tahap terpenting dan terjadi sebelum ada insiden. Isinya kebijakan dan rencana IR tertulis, daftar kontak internal dan eksternal, inventaris aset, pencatatan log yang memadai, backup yang teruji, serta latihan berkala. Tanpa persiapan, tahap lain berjalan lambat.

2. Deteksi dan analisis

Tim menerima sinyal dari alat pemantauan, laporan pengguna, atau pihak luar, lalu menilai apakah itu insiden sungguhan, seberapa luas dampaknya, dan seberapa mendesak. Platform seperti SIEM membantu mengumpulkan log dan memberi peringatan, tetapi analis tetap perlu mengambil keputusan. Setiap langkah dan temuan dicatat dengan waktu yang jelas.

3. Containment, eradication, dan recovery

Containment membatasi penyebaran, misalnya dengan mengisolasi perangkat atau menonaktifkan akun yang disusupi. Eradication menghilangkan penyebab, seperti kredensial yang bocor, celah yang dieksploitasi, atau malware yang tertanam. Recovery mengembalikan layanan dari sumber yang bersih dan memantau agar masalah tidak kembali. Bukti perlu diamankan sebelum sistem dibersihkan, sesuai prinsip forensik digital.

4. Pasca-insiden

Setelah situasi stabil, tim menggelar tinjauan tanpa mencari kambing hitam: apa yang terjadi, apa yang berjalan baik, apa yang terlambat, dan perbaikan apa yang harus dikerjakan. Hasilnya masuk ke kebijakan, konfigurasi, dan materi pelatihan.

Siapa Saja yang Terlibat dalam Tim Incident Response?

Insiden bukan hanya urusan tim IT. Susunan tim umumnya mencakup:

• pemimpin insiden yang mengoordinasikan keputusan dan jalur komunikasi;
• analis keamanan atau anggota Security Operations Center yang menyelidiki sinyal;
• administrator sistem dan jaringan yang menjalankan isolasi serta pemulihan;
• perwakilan hukum, kepatuhan, atau pejabat pelindungan data untuk urusan pelaporan;
• perwakilan komunikasi atau humas yang mengatur pernyataan ke pelanggan dan media;
• pimpinan bisnis yang berwenang mengambil keputusan berdampak besar, seperti menghentikan layanan.

Pada organisasi kecil satu orang bisa memegang beberapa peran. Yang penting, peran dan penggantinya sudah ditetapkan sebelum insiden.

Kewajiban Pelaporan Insiden yang Melibatkan Data Pribadi

Jika insiden menyebabkan kegagalan pelindungan data pribadi, UU Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi mewajibkan pengendali data menyampaikan pemberitahuan tertulis paling lambat 3 x 24 jam kepada subjek data dan lembaga yang berwenang, sebagaimana tercantum pada Pasal 46 ayat (1). Rencana IR yang baik karenanya memuat template pemberitahuan dan alur persetujuannya. Isi minimal pemberitahuan mencakup data pribadi yang terungkap, kapan dan bagaimana terungkapnya, serta upaya penanganan dan pemulihan. Kewajiban perusahaan lainnya dibahas di artikel tentang UU PDP. Teks resmi undang-undang dapat dibaca di JDIH Komdigi.

Pelajaran dari Insiden PDNS 2 Tahun 2024

Serangan ransomware pada Pusat Data Nasional Sementara di Surabaya pada Juni 2024 memberi contoh nyata betapa persiapan menentukan hasil. Menurut kronologi Kompas, peretas mulai beraksi sejak 17 Juni 2024, layanan imigrasi di bandara terganggu pada 20 Juni, dan pelaku menuntut tebusan 8 juta dolar AS yang ditolak pemerintah. Dari 282 instansi terdampak, hanya 44 yang memiliki data cadangan, dan BSSN menyebut tata kelola operasional pusat data sebagai kelemahan. Kronologi lengkapnya ada di liputan Kompas. Pelajaran umumnya: backup yang teruji dan terpisah, tata kelola yang jelas, dan rencana pemulihan yang pernah dilatih. Pembahasan jenis serangannya ada di artikel ransomware.

Cara Menguji Kesiapan Incident Response

Rencana yang hanya tersimpan di folder bersama belum bisa dikatakan siap. Latihan meja (tabletop exercise) mempertemukan semua peran untuk membahas skenario fiktif, misalnya ransomware di jam kerja, tanpa mengganggu sistem produksi. Dari sana biasanya terlihat kontak yang kedaluwarsa, wewenang yang tidak jelas, atau backup yang belum pernah dipulihkan. Ukur juga waktu dari deteksi sampai containment dan catat kemajuannya dari latihan ke latihan. Organisasi yang ingin melatih timnya secara terstruktur dapat melihat program pelatihan tim.

Pertanyaan yang Sering Diajukan

Apa bedanya kejadian keamanan dan insiden keamanan?

Kejadian (event) adalah apa pun yang tercatat di sistem, termasuk yang tidak berbahaya. Insiden adalah kejadian yang benar-benar mengancam atau merugikan kerahasiaan, integritas, atau ketersediaan data dan layanan.

Apakah usaha kecil perlu rencana incident response?

Perlu, meski bentuknya sederhana. Satu halaman yang berisi siapa yang dihubungi, akun mana yang dikunci lebih dulu, di mana backup berada, dan siapa yang berbicara ke pelanggan sudah jauh lebih baik daripada tidak ada rencana.

Apa yang harus dilakukan pertama kali saat curiga ada insiden?

Catat apa yang terlihat, laporkan segera ke jalur yang sudah ditetapkan, dan jangan menghapus atau mematikan sistem tanpa arahan karena bisa menghilangkan bukti. Isolasi perangkat dilakukan sesuai prosedur tim.

Berapa lama batas waktu memberi tahu pihak terkait?

Untuk kegagalan pelindungan data pribadi, UU PDP menetapkan paling lambat 3 x 24 jam. Sektor tertentu bisa punya aturan tambahan dari regulatornya, jadi periksa juga regulasi industri Anda.

Kesimpulan

Incident response bukan alat atau produk, melainkan kemampuan organisasi untuk bertindak cepat dan terkoordinasi. Siapkan rencana, tetapkan peran, jaga backup, latih tim, dan pelajari setiap insiden. Linuxhackingid menyediakan kursus dan pelatihan keamanan siber yang dapat membantu tim Anda membangun kemampuan tersebut.