Ketika membahas ransomware, banyak perusahaan merasa lebih aman karena sudah memiliki backup. Itu langkah penting, tetapi backup saja tidak menjamin bisnis dapat pulih dengan cepat.
Pertanyaan yang lebih relevan bagi management adalah: jika sistem utama terenkripsi atau tidak dapat digunakan besok pagi, layanan mana yang harus kembali lebih dulu, siapa yang mengambil keputusan, dan berapa lama perusahaan dapat beroperasi tanpa sistem tersebut?
Inilah perbedaan antara memiliki backup dan memiliki cyber resilience.
Backup Adalah Komponen Recovery, Bukan Recovery Plan
Backup menyimpan salinan data. Recovery plan menentukan bagaimana data, aplikasi, identity, infrastructure, dan proses bisnis dipulihkan dalam urutan yang benar.
Dalam serangan ransomware, organisasi dapat menghadapi beberapa masalah sekaligus:
- server atau endpoint terenkripsi;
- credential administrator dicuri;
- backup online ikut terhapus atau terenkripsi;
- network harus diisolasi;
- application dependency tidak dapat digunakan;
- tim belum mengetahui sistem mana yang harus diprioritaskan;
- proses restore memakan waktu lebih lama dari yang diasumsikan.
Karena itu, backup yang “berhasil dibuat” belum tentu berarti backup tersebut siap dipakai saat incident.
NIST 2026: Ransomware Risk Management Harus Terhubung dengan Resilience
Pada Juni 2026, NIST NCCoE merilis versi final NIST IR 8374 Revision 1, Ransomware Risk Management: A Cybersecurity Framework 2.0 Community Profile.
Dokumen tersebut memperbarui pendekatan ransomware agar selaras dengan NIST Cybersecurity Framework 2.0 dan dapat digunakan organisasi untuk mengevaluasi defense serta menentukan tindakan prioritas.
Pesan pentingnya bagi bisnis adalah bahwa ransomware bukan hanya isu antivirus atau endpoint. Ia menyentuh governance, identify, protect, detect, respond, dan recover.
Backup Harus Diuji, Bukan Sekadar Dipantau
NIST juga menerbitkan OT Backup Quick Start Guide pada Juni 2026. Walaupun fokusnya pada operational technology, prinsip backup yang disampaikan sangat relevan secara lebih luas: backup perlu dibuat secara teratur, diintegrasikan ke change management, diuji, dan direview dalam recovery exercise.
Artinya, indikator “backup job success” tidak cukup. Organisasi perlu membuktikan bahwa:
- file benar-benar dapat direstore;
- application dapat dijalankan kembali;
- dependency tersedia;
- credential untuk recovery masih dapat digunakan;
- tim mengetahui prosedurnya;
- waktu recovery sesuai target bisnis.
RPO dan RTO Harus Dimulai dari Bisnis
Dua istilah yang sering muncul dalam business continuity adalah RPO dan RTO.
Recovery Point Objective (RPO) menjawab seberapa banyak data yang dapat diterima untuk hilang.
Recovery Time Objective (RTO) menjawab berapa lama layanan dapat tidak tersedia sebelum dampaknya menjadi tidak dapat diterima.
Nilainya tidak seharusnya ditentukan hanya oleh tim IT. Management dan process owner perlu menentukan berdasarkan dampak bisnis.
Sistem payroll, ERP, website marketing, production system, email, dan internal file server tidak selalu memiliki prioritas recovery yang sama.
Lima Lapisan Cyber Resilience yang Perlu Diperiksa
1. Backup Isolation
CISA dalam #StopRansomware Guide merekomendasikan offline, encrypted backups untuk data kritis dan pengujian availability serta integrity secara berkala.
Backup yang selalu dapat diakses menggunakan credential administrator yang sama dengan production dapat memperbesar risiko ketika account tersebut dikompromikan.
2. Identity Recovery
Banyak recovery plan berfokus pada server tetapi melupakan identity. Jika identity provider, Active Directory, privileged account, atau MFA infrastructure bermasalah, tim bisa memiliki data backup tetapi kesulitan mengakses atau mengoperasikan environment recovery.
3. Application Dependency
Aplikasi tidak berdiri sendiri. ERP mungkin membutuhkan database, identity, DNS, storage, network, integration service, dan API lain.
Recovery sequence perlu memperhitungkan dependency tersebut.
4. Clean Recovery Environment
Restore seharusnya tidak mengembalikan malware atau compromised configuration ke environment baru.
Organisasi perlu menentukan bagaimana memastikan system image, credentials, software package, dan backup yang dipakai untuk recovery dapat dipercaya.
5. Human Decision and Communication
Incident besar menciptakan tekanan tinggi. Perusahaan perlu mengetahui siapa yang memiliki authority untuk mengisolasi sistem, memutus koneksi, menjalankan disaster recovery, berkomunikasi dengan customer, atau melibatkan pihak eksternal.
Tanpa decision matrix, waktu berharga akan habis untuk mencari persetujuan.
Recovery Exercise Lebih Penting daripada Dokumen yang Sempurna
Banyak perusahaan memiliki Business Continuity Plan atau Disaster Recovery Plan yang terlihat lengkap. Namun dokumen tersebut belum tentu mencerminkan architecture saat ini.
Perusahaan berubah. Aplikasi baru ditambahkan. Vendor berganti. Data berpindah ke cloud. API bertambah. Personel berubah.
Karena itu, resilience perlu diuji melalui exercise.
Mulailah dari skenario sederhana:
- Pilih satu business service kritis.
- Asumsikan primary environment tidak dapat digunakan.
- Tentukan siapa yang menerima alert dan mengambil keputusan.
- Restore pada environment terkontrol.
- Ukur waktu aktual.
- Catat dependency yang terlewat.
- Perbarui runbook.
Exercise seperti ini sering menghasilkan insight yang lebih berguna daripada menambah puluhan halaman policy.
Recovery Harus Dimulai dari Business Service, Bukan dari Server
Dalam incident besar, organisasi sering berpikir dalam daftar perangkat: server A, database B, storage C. Padahal management merasakan dampaknya sebagai hilangnya business service: order tidak bisa diproses, pembayaran berhenti, customer service tidak dapat melihat data, produksi terganggu, atau karyawan tidak dapat login.
Karena itu, business continuity sebaiknya memetakan service secara end-to-end. Satu layanan bisnis dapat bergantung pada identity provider, DNS, network, database, API, application server, storage, vendor SaaS, dan external integration sekaligus.
Jika satu dependency tertinggal, aplikasi mungkin technically “up” tetapi service tetap tidak dapat digunakan.
Buat Dependency Map untuk Sistem Kritis
Dependency map tidak harus berupa diagram architecture yang sangat detail. Yang dibutuhkan adalah daftar komponen yang menentukan apakah satu business service benar-benar berfungsi.
Untuk setiap service, dokumentasikan:
- business owner dan technical owner;
- RTO dan RPO;
- application dan database utama;
- identity dan authentication dependency;
- network/DNS dependency;
- integration/API penting;
- backup location;
- external vendor;
- recovery sequence;
- validation step setelah restore.
Dokumen ini menjadi jauh lebih berguna saat incident daripada inventaris server yang tidak menunjukkan hubungan antar-komponen.
Tabletop Exercise dan Technical Recovery Test Memiliki Tujuan Berbeda
Tabletop exercise menguji keputusan. Tim mensimulasikan scenario: ransomware ditemukan pada pukul tertentu, beberapa sistem tidak dapat digunakan, dan attacker diduga memiliki credential administrator. Peserta kemudian menentukan siapa yang mengisolasi network, siapa yang menghubungi management, kapan disaster recovery dijalankan, dan bagaimana komunikasi eksternal dilakukan.
Technical recovery test menguji kemampuan nyata untuk restore system. Backup benar-benar digunakan, environment recovery dibangun, application dijalankan, integration diuji, dan waktu aktual dicatat.
Keduanya diperlukan. Tabletop yang bagus dapat menemukan gap authority dan komunikasi, tetapi tidak membuktikan bahwa restore akan berhasil. Technical test dapat membuktikan sistem pulih, tetapi tidak selalu menguji keputusan organisasi di bawah tekanan.
Ukur Recovery dengan Evidence, Bukan Asumsi
Beberapa metrik yang berguna antara lain:
- Actual Recovery Time: waktu nyata dari mulai recovery sampai service usable.
- Restore Success Rate: persentase backup kritis yang berhasil direstore saat test.
- Recovery Data Loss: berapa banyak data yang hilang dibanding target RPO.
- Dependency Failure: berapa banyak recovery yang tertunda karena komponen lain belum tersedia.
- Manual Intervention: berapa banyak langkah membutuhkan individu tertentu atau knowledge yang belum terdokumentasi.
Data ini membantu management membedakan antara resilience yang diasumsikan dan resilience yang sudah dibuktikan.
SaaS dan Cloud Tidak Menghilangkan Kebutuhan Recovery Planning
Menggunakan SaaS atau cloud mengubah pembagian tanggung jawab, tetapi tidak menghilangkan risiko business interruption.
Vendor mungkin bertanggung jawab terhadap availability platform, tetapi perusahaan tetap bertanggung jawab terhadap configuration, identity, access, data retention, integration, dan continuity process mereka sendiri.
Perusahaan juga perlu memahami skenario ketika vendor mengalami outage, credential internal disalahgunakan, data dihapus secara sah tetapi salah, atau integration critical gagal meskipun platform utama masih tersedia.
Karena itu, recovery strategy perlu memasukkan vendor dependency dan alternatif manual process ketika external service tidak tersedia.
Cyber Resilience Juga Membutuhkan Operational Fallback
Tidak semua proses dapat dipulihkan dalam hitungan menit. Untuk service tertentu, perusahaan sebaiknya menyiapkan degraded-mode operation: cara bisnis tetap berjalan secara terbatas ketika sistem digital belum tersedia.
Contohnya dapat berupa prosedur penerimaan order sementara, approval manual dengan threshold tertentu, jalur komunikasi alternatif, atau pencatatan transaksi offline yang nantinya direkonsiliasi.
Fallback seperti ini harus dirancang sebelumnya. Membuat proses manual ketika incident sedang berlangsung biasanya menghasilkan keputusan yang tidak konsisten dan meningkatkan risiko error.
Recovery Readiness Harus Menjadi Agenda Management
Cyber resilience bukan hanya KPI tim infrastructure. Ketika incident menghentikan revenue, customer service, supply chain, atau production, dampaknya adalah business issue.
Management perlu secara periodik menerima ringkasan service kritis, RTO/RPO, hasil test terakhir, gap dependency, dan remediation plan. Dengan begitu, keputusan investasi dapat didasarkan pada risiko aktual, bukan asumsi bahwa “backup kita aman”.
Recovery Prioritization Perlu Memperhitungkan Dampak Antar-Layanan
Prioritas recovery juga tidak selalu identik dengan urutan sistem yang paling mahal atau paling besar. Sebuah service kecil dapat menjadi dependency untuk banyak proses lain. Identity service, DNS, message queue, API gateway, atau integration platform mungkin tidak terlihat langsung oleh customer, tetapi kegagalannya dapat menahan pemulihan banyak aplikasi sekaligus.
Karena itu, perusahaan perlu menggabungkan Business Impact Analysis dengan dependency map. Management dapat menentukan mana service yang harus pulih pertama, mana yang dapat berjalan dalam degraded mode, dan mana yang aman ditunda. Pendekatan ini membantu tim menggunakan resource recovery secara lebih rasional ketika kapasitas, personel, atau waktu sangat terbatas.
Hasil akhirnya bukan sekadar daftar RTO, tetapi recovery sequence yang dapat dieksekusi: siapa melakukan apa, dependency apa yang harus tersedia lebih dulu, bagaimana service divalidasi, dan kapan business owner menyatakan layanan benar-benar usable.
Bagaimana SIDIK CYBER Dapat Membantu?
Cyber resilience membutuhkan kombinasi cybersecurity, infrastructure, cloud, backup, monitoring, IAM, incident response, dan business continuity.
Melalui Cybersecurity Solutions, SIDIK CYBER dapat membantu perusahaan melakukan assessment terhadap critical system, dependency, backup architecture, recovery target, security control, monitoring, dan incident workflow.
Pendekatan ini bertujuan memastikan perusahaan tidak hanya memiliki data cadangan, tetapi juga memiliki kemampuan operasional untuk memulihkan layanan ketika kondisi terburuk terjadi.
Tujuan Backup Bukan Menyimpan Data, tetapi Mengembalikan Bisnis ke Kondisi Operasional
Backup tetap merupakan salah satu kontrol terpenting menghadapi ransomware. Namun nilai backup baru terbukti ketika organisasi dapat menggunakannya untuk memulihkan layanan secara aman, dalam urutan yang benar, dan dalam waktu yang dapat diterima bisnis.
Cyber resilience berarti menggabungkan backup, identity, architecture, security, people, dan decision process menjadi satu kemampuan recovery yang benar-benar diuji.
Sumber:
NIST — Ransomware Risk Management: CSF 2.0 Community Profile, IR 8374 Revision 1, 11 Juni 2026.
NIST — OT Backup Quick Start Guide, SP 1339, 17 Juni 2026.
CISA — #StopRansomware Guide.