Cybersecurity sering dibangun dengan satu asumsi utama: bagaimana mencegah attacker masuk. Enterprise kemudian berinvestasi pada firewall, endpoint protection, identity security, vulnerability management, monitoring, penetration testing, dan berbagai preventive controls. Seluruhnya penting. Namun tidak ada architecture yang dapat menjamin bahwa setiap serangan akan selalu berhasil dicegah. Credential dapat dicuri, vulnerability baru dapat muncul, third-party provider dapat compromised, ransomware dapat melewati perimeter, atau human error dapat membuka jalur yang sebelumnya tidak terlihat.<\/p>\n\n\n\n
Karena itu, pertanyaan cybersecurity di level enterprise tidak cukup berhenti pada \u201cbagaimana mencegah serangan?\u201d<\/strong>. Management juga perlu mampu menjawab pertanyaan yang lebih sulit: \u201cjika sebagian system benar-benar compromised besok, process bisnis apa yang masih dapat berjalan, process mana yang harus dipulihkan lebih dahulu, dan berapa lama perusahaan dapat beroperasi sebelum dampaknya menjadi material?\u201d<\/strong><\/p>\n\n\n\n Di sinilah Cyber Resilience<\/strong> berbeda dari pendekatan security yang hanya berorientasi prevention. NIST melalui Developing Cyber-Resilient Systems<\/em> mendefinisikan cyber resiliency sebagai kemampuan system untuk menghadapi kondisi buruk dengan cara mengantisipasi, bertahan, pulih, dan beradaptasi terhadap serangan atau compromise. Tujuannya bukan mengasumsikan intrusion tidak pernah terjadi, tetapi mengurangi risiko terhadap mission dan business ketika organisasi bergantung pada cyber resources. NIST SP 800-160 Vol. 2 Rev. 1 NIST CSRC<\/a><\/p>\n\n\n\n Dari perspektif bisnis, prinsip tersebut mengubah objective cybersecurity. Keberhasilan bukan hanya tidak terkena serangan<\/strong>, tetapi juga kemampuan perusahaan untuk membatasi blast radius, mempertahankan critical operation, memulihkan capability berdasarkan business priority, dan belajar dari incident agar exposure berikutnya semakin kecil<\/strong>.<\/p>\n\n\n\n Prevention tetap merupakan bagian penting cybersecurity. Enterprise perlu mengurangi attack surface, memperkuat authentication, menjaga software tetap secure, mengelola privilege, melakukan segmentation, mendeteksi vulnerability, dan memastikan security control bekerja. Namun prevention hanya menjawab bagian sebelum atau ketika attacker mencoba memperoleh akses.<\/p>\n\n\n\n Cyber resilience mulai menjadi sangat penting ketika asumsi berubah menjadi: sebagian control dapat gagal<\/strong>.<\/p>\n\n\n\n Jika satu credential privileged compromised, apakah attacker langsung mendapat akses luas atau movement-nya dapat dibatasi? Jika production database terenkripsi ransomware, apakah company masih mempunyai recovery copy yang dapat dipercaya? Jika identity provider tidak tersedia, apakah administrator masih mempunyai controlled mechanism untuk recovery? Jika SaaS provider mengalami disruption, apakah critical business process masih dapat berjalan sementara? Jika primary environment harus diisolasi, apakah terdapat alternative process agar customer atau operation tidak sepenuhnya berhenti?<\/p>\n\n\n\n NIST Cybersecurity Framework 2.0 juga tidak berhenti pada fungsi Protect dan Detect. Framework tersebut memasukkan Respond<\/strong> serta Recover<\/strong>, di mana Recover berfokus pada restoration terhadap asset dan operation yang terdampak agar normal operation dapat dikembalikan secara tepat waktu. NIST menempatkan seluruh fungsi tersebut sebagai bagian yang saling berhubungan dalam cybersecurity risk management, bukan sebagai aktivitas terpisah setelah security gagal. NIST Cybersecurity Framework 2.0 NIST<\/a><\/p>\n\n\n\n Artinya, enterprise security architecture perlu dirancang bukan hanya untuk stop the attack<\/strong>, tetapi juga untuk survive the attack<\/strong>.<\/p>\n\n\n\n Dalam working framework Crocodic, Cyber Resilience dapat dipetakan melalui chain berikut:<\/p>\n\n\n\n Critical Business Process \u2192 Technology Dependency \u2192 Incident Scenario \u2192 Operational Impact \u2192 Recovery Priority \u2192 Recovery Capability \u2192 Continuity Mode \u2192 Restoration \u2192 Learning<\/strong><\/p>\n\n\n\n Framework dimulai dari Critical Business Process<\/strong>, bukan dari daftar server. Enterprise perlu menentukan process apa yang tidak boleh berhenti terlalu lama karena berkaitan dengan revenue, payment, customer service, production, safety, supply chain, regulatory obligation, atau operational continuity.<\/p>\n\n\n\n Setelah itu, identifikasi Technology Dependency<\/strong> yang membuat process tersebut dapat berjalan. Dependency tidak selalu hanya application utama. Business process dapat bergantung pada identity provider, database, API, network connection, third-party SaaS, cloud service, shared storage, integration middleware, endpoint, dan bahkan satu administrative credential tertentu.<\/p>\n\n\n\n Kemudian enterprise perlu membangun Incident Scenario<\/strong>. Apa yang terjadi jika application unavailable? Bagaimana jika datanya corrupted? Bagaimana jika identity compromised? Bagaimana jika environment masih online tetapi tidak dapat dipercaya? Pertanyaan tersebut diterjemahkan menjadi Operational Impact<\/strong> sehingga security team dan business team dapat melihat consequence dalam bahasa yang sama.<\/p>\n\n\n\n Barulah management menentukan Recovery Priority<\/strong>, mengevaluasi Recovery Capability<\/strong>, menyiapkan Continuity Mode<\/strong> selama normal system belum tersedia, melakukan Restoration, lalu menggunakan hasil incident atau exercise sebagai Learning untuk memperbaiki architecture.<\/p>\n\n\n\n Framework ini membawa satu principle utama:<\/p>\n\n\n\n Tidak semua system harus pulih bersamaan. Yang perlu dipulihkan lebih dahulu adalah capability yang paling penting agar bisnis dapat tetap bergerak.<\/strong><\/p>\n\n\n\n Enterprise sering mempunyai disaster-recovery document yang sangat teknis: daftar server, IP address, backup schedule, database, VM, network, dan recovery procedure. Informasi tersebut penting untuk technical team, tetapi belum tentu menjawab prioritas business recovery.<\/p>\n\n\n\n Misalnya sebuah perusahaan memiliki 80 applications. Setelah incident besar, infrastructure team mungkin mempunyai kemampuan untuk memulihkan semuanya secara bertahap. Namun management membutuhkan jawaban yang berbeda: application mana yang harus tersedia dalam beberapa jam pertama, process apa yang masih dapat berjalan tanpa application tertentu, dependency apa yang harus hidup lebih dulu, dan data apa yang tidak boleh kehilangan integrity.<\/p>\n\n\n\n NIST pada guidance contingency planning menempatkan Business Impact Analysis<\/strong> sebelum recovery strategy. Tujuannya adalah memahami business requirement dan consequence dari disruption, kemudian menggunakan informasi tersebut untuk menentukan recovery priorities, preventive controls, recovery strategies, contingency plan, serta testing dan maintenance. NIST Contingency Planning Guidance NIST CSRC<\/a><\/p>\n\n\n\n Karena itu, cyber resilience architecture sebaiknya mempunyai traceability:<\/p>\n\n\n\n Business Capability \u2192 Process \u2192 Application \u2192 Data \u2192 Identity \u2192 Integration \u2192 Infrastructure \u2192 Vendor Dependency<\/strong><\/p>\n\n\n\n Jika dependency chain ini tidak diketahui, recovery sering dilakukan berdasarkan system yang paling mudah dipulihkan, bukan system yang memberikan business value paling tinggi.<\/p>\n\n\n\n Mengetahui bahwa sebuah system critical belum cukup. Enterprise juga perlu memahami recovery sequence<\/strong>.<\/p>\n\n\n\n Bayangkan ERP merupakan application paling critical. Namun ERP tidak dapat digunakan sebelum identity service tersedia. Identity service membutuhkan network, secrets, dan directory database. ERP juga membutuhkan integration dengan payment, warehouse, atau master-data system. Jika recovery plan hanya mengatakan \u201cERP harus pulih dalam empat jam\u201d, target tersebut belum operationally useful jika supporting dependency tidak ikut dipetakan.<\/p>\n\n\n\n Karena itu, resilience membutuhkan dependency-aware recovery<\/strong>.<\/p>\n\n\n\n Contoh sederhananya:<\/p>\n\n\n\nCyber Resilience Berbeda dari Cybersecurity Prevention<\/strong><\/h2>\n\n\n\n
Crocodic Cyber Resilience Framework<\/strong><\/h2>\n\n\n\n
Mulai dari Business Process, Bukan dari Infrastructure<\/strong><\/h2>\n\n\n\n
Recovery Priority Tidak Sama dengan System Criticality Saja<\/strong><\/h2>\n\n\n\n