Checklist Assessment Ketahanan terhadap Ransomware
Ketahanan ransomware adalah kemampuan membatasi penyalahgunaan identitas, menghambat penyebaran, memulihkan layanan prioritas, dan membuat keputusan yang dapat dipertanggungjawabkan saat tertekan. Job backup berstatus sukses bukan bukti pemulihan. CISA merekomendasikan backup offline terenkripsi, pengujian ketersediaan serta integritas berkala, golden image, rencana insiden, dan akses least privilege. Panduan NIST tentang respons insiden menempatkan pemulihan serta lessons learned sebagai pekerjaan yang direncanakan.
Tetapkan asumsi pemulihan dahulu
Inventarisasi layanan berdasarkan konsekuensi bisnis, dependensi, sumber data, owner pemulihan, dan pemeriksaan pemulihan yang dapat diterima. Berikan recovery point objective dan recovery time objective hanya bila owner bisnis telah menyetujuinya. Perlakukan target sebagai masukan perencanaan, bukan janji. Simpan daftar kontak offline, runbook pemulihan, proses kredensial, dan dependensi arsitektur tanpa bergantung pada sistem identitas yang mungkin terdampak.
Peta bukti ketahanan
| Area | Contoh selesai | Bukti | Owner | Lulus/gagal | Pengecualian atau remediasi |
|---|---|---|---|---|---|
| Isolasi backup | database keuangan memiliki salinan terenkripsi pada batas akses terpisah | kebijakan backup, review akun pemulihan | owner backup | Lulus | restore triwulanan jatuh tempo |
| Restore backup | salinan 2026-07-29 dipulihkan ke lingkungan terisolasi; query integritas lulus | ID job, checksum, log tes | owner pemulihan | Lulus | restore produksi tidak diuji |
| Identitas privileged | 14 akun admin direview; dua akun usang dinonaktifkan | ekspor akses, catatan disable | owner identitas | Lulus | uji break-glass terbuka |
| Segmentasi | VLAN workstation tidak dapat mencapai jaringan manajemen backup | rule firewall dan tes flow ditolak | owner jaringan | Lulus | review jump host supplier jatuh tempo |
| Pemulihan layanan | invoicing menerima transaksi sintetis setelah rebuild | cek bisnis disetujui keuangan | owner layanan | Gagal | dependency queue belum pulih |
Lulus berarti bukti observasi memenuhi kriteria tes yang direncanakan. Ini tidak berarti penyerang tidak dapat mencapai lingkungan. Gagal menghasilkan remediasi terbatas: tentukan dependensi gagal, owner, tanggal tes target, dan bukti yang dibutuhkan untuk mengubah status. Jangan menghapus tes gagal setelah tes berikutnya lulus; simpan urutannya.
Backup: verifikasi restore, bukan penyimpanan
Simpan salinan di luar jangkauan administrator rutin dan uji apakah petugas pemulihan berwenang dapat menemukan, mendekripsi, memulihkan, serta memvalidasinya. Uji data dan dependensi: key, image, template infrastruktur, media software, konfigurasi, DNS, dan proses kredensial. Ukur waktu pengambilan, restore, validasi, serta handoff bisnis secara terpisah. Checksum valid mengonfirmasi integritas salinan, bukan kegunaan aplikasi.
Gunakan lingkungan pemulihan terisolasi. Jangan hubungkan sistem pulih ke jaringan produksi tepercaya sebelum review malware, keputusan identitas, dan otorisasi. Catat waktu backup sumber, lingkungan target, operator, versi command atau runbook, sanitasi data, hasil validasi, serta cleanup. Bila pemulihan bergantung pada pengetahuan orang yang tidak tersedia, itu adalah gap ketahanan.
Tes identitas dan segmentasi
Uji pencabutan darurat untuk akun privileged serta service account, invalidasi sesi, proses break-glass, dan prosedur saat identity provider tidak tersedia. Pisahkan identitas pengguna harian dari identitas administrator. Pastikan akun lama, akses eksternal, API token, dan service principal dorman teridentifikasi; jangan mempublikasikan data akun dalam catatan latihan.
Segmentasi memerlukan jalur yang diamati. Uji bahwa flow bisnis yang dibutuhkan berjalan dan jalur lateral terlarang gagal antara jaringan pengguna, server, manajemen backup, infrastruktur identitas, serta lingkungan pemulihan. Catat sumber tes, tujuan, protokol, versi rule, dan hasil. Diagram jaringan adalah niat desain, bukan bukti.
Drill pemulihan dan keputusan
Jalankan skenario tanpa menyentuh produksi: dugaan enkripsi, kompromi akun, tool kolaborasi tidak tersedia, dan permintaan restore layanan prioritas. Putuskan siapa mengotorisasi isolasi, rotasi kredensial, urutan restore, dan kembali beroperasi. Simpan log serta keputusan. Setelah drill, bandingkan waktu nyata dan blocker dengan asumsi; revisi runbook, bukan riwayat.
Uji penutupan pemulihan
Baris pemulihan ditutup hanya setelah owner layanan menjalankan cek bisnis disetujui pada layanan pulih terisolasi. Untuk invoicing, catat versi queue dipulihkan, ID invoice sintetis, hasil ledger, waktu pengambilan/restore/validasi, dan konfirmasi cleanup. Jika database pulih tetapi replay queue gagal, tandai pemulihan layanan gagal walau checksum backup lulus; identifikasi owner queue dan ulangi tahap yang terblokir. Keputusan kembali beroperasi tetap milik operations berwenang, bukan fasilitator drill atau operator backup.
Frekuensi review
Jalankan tes restore, identitas, segmentasi, dan keputusan pada frekuensi yang direncanakan serta setelah perubahan material pada arsitektur, identity provider, backup, atau supplier. Catat cakupan tes agar perubahan kecil tetap dapat dibandingkan. Review pengecualian terbuka pada setiap latihan. Eskalasi bukti pemulihan yang terlewat kepada owner bisnis; tes terlewat adalah informasi operasional, bukan kebisingan administratif.
Batas
Checklist ini adalah panduan perencanaan bukti, bukan jaminan pencegahan ransomware, sertifikasi, nasihat hukum, atau penentuan kepatuhan regulasi. Gunakan review berwenang untuk keputusan hukum, kontrak, keselamatan, dan notifikasi.
Prioritas saat pemulihan
Urutan pemulihan harus mengikuti layanan yang paling penting bagi operasi, bukan urutan server yang paling mudah dipulihkan. Pemilik bisnis menyetujui pemeriksaan hasil yang dapat diterima, sedangkan pemilik teknis membuktikan dependensi, identitas, dan data yang diperlukan. Bila prioritas berubah selama insiden, keputusan dan alasannya harus dicatat agar latihan berikutnya menguji asumsi yang baru.
Sumber
Validasi pemulihan ransomware
Untuk pemulihan sistem penggajian, buktikan titik pemulihan, urutan ketergantungan, waktu pemulihan, dan integritas hasil restore. Catat siapa yang dapat menghapus cadangan, mengubah retensi, atau memakai kunci pemulihan. Jika uji restore hanya memulihkan data tanpa membuat aplikasi berfungsi, status ketahanan tetap terbuka sampai pemilik layanan memvalidasi proses bisnisnya.
Catat pula siapa yang dapat menghapus backup, mengubah retensi, atau menggunakan kunci pemulihan. Hak akses tersebut sering menentukan apakah salinan benar-benar berguna saat insiden. Bila restore mengembalikan data tetapi aplikasi gagal karena dependensi eksternal, hasilnya parsial. Uji akhir: owner menyetujui daftar celah pemulihan dan tanggal latihan berikutnya.