Bagaimana Membangun Rencana Respons Insiden yang Efektif?

Sebagian besar organisasi tidak gagal dalam respons insiden karena kurangnya alat. Mereka gagal karena tidak ada kesepakatan sebelumnya tentang siapa yang melakukan apa, dan insiden pertama yang sebenarnya menjadi rapat daripada respons.

Mulai dengan fase, bukan playbook

NIST SP 800-61 menetapkan empat fase: preparation, detection and analysis, containment/eradication/recovery, dan post-incident activity. Urutan itu penting. Tim suka langsung melompat ke containment karena terasa produktif, tetapi jika Anda belum melakukan pekerjaan preparation, Anda tidak tahu jaringan Anda sendiri cukup baik untuk menahan apa pun dengan bersih.

Preparation berarti inventaris aset yang benar-benar terkini, bukan spreadsheet dari 2022. Ini berarti mengetahui jendela retensi log Anda (jika 7 hari dan penyerang memiliki 30 hari dwell time, Anda sudah kehilangan timeline). Ini berarti forensic tooling yang sudah disiapkan sebelumnya — Velociraptor, KAPE, atau bahkan prosedur tar/dd yang didokumentasikan untuk disk image — sehingga tidak ada yang mengunduh alat ke host yang dikompromikan selama insiden aktif.

Tentukan tingkat keparahan sebelum Anda membutuhkannya

SEV1 (data exfiltration aktif, detonasi ransomware, kompromi domain admin) memerlukan respons berbeda dari SEV3 (malware terisolasi di satu workstation unprivileged). Tulis ini dalam bentuk matriks: dampak vs. cakupan vs. keyakinan. Tetapkan untuk setiap tingkat keparahan waktu respons yang diperlukan dan jalur eskalasi. Jika incident commander Anda untuk SEV1 adalah orang yang sama yang harus menyetujui setiap pesanan pembelian $500, Anda telah membangun bottleneck ke dalam proses darurat Anda sendiri.

Peran incident commander bukan opsional

Satu orang menjalankan insiden. Bukan engineer paling senior secara default — orang yang paling cocok untuk mengoordinasikan, mendelegasikan, dan membuat keputusan containment di bawah tekanan. Orang ini tidak harus menyentuh keyboard selama respons; mereka melacak timeline, mengelola komunikasi dengan legal dan leadership, dan memutuskan kapan harus menarik pemicu untuk mengisolasi segmen atau membawa sistem offline.

Tanpa peran ini, Anda mendapatkan lima orang SSH ke box yang sama, tidak ada yang berbicara satu sama lain, dan tidak ada yang menangkap volatile memory sebelum seseorang restart mesin untuk "melihat apakah itu memperbaikinya."

Keputusan containment yang benar-benar penting

Panggilan tersulit dalam sebagian besar insiden adalah: isolasi sekarang, atau amati sedikit lebih lama untuk memahami cakupan? Menarik akses jaringan terlalu cepat memberi tahu penyerang yang masih bergerak secara lateral dan menghancurkan kesempatan Anda untuk melihat langkah berikutnya. Menunggu terlalu lama membiarkan ransomware menyelesaikan enkripsi share.

Jalan tengah yang masuk akal: gunakan network segmentation dan EDR isolation (CrowdStrike, Defender for Endpoint, SentinelOne semuanya mendukung ini) untuk memutus host dari lateral movement sambil mempertahankannya tetap hidup untuk memory capture. Shutdown penuh harus menjadi pilihan terakhir — ini membunuh volatile evidence dan, untuk kasus ransomware, dapat memicu perilaku anti-forensic yang tertanam dalam beberapa payload.

Celah logging yang akan Anda sesali saat terjadi, bukan sebelumnya

Windows Event Log default tidak cukup. Jika Anda tidak memiliki Sysmon yang diterapkan dengan config yang layak (baseline config dari SwiftOnSecurity atau Olaf Hartong adalah starting point yang solid), Anda akan merekonstruksi process trees dari fragmen. Di sisi jaringan, NetFlow atau Zeek logs lebih penting daripada yang disadari sebagian besar org sampai mereka perlu menjawab