Cybersecurity Risk Assessment untuk Enterprise: Sistem Mana yang Harus Diamankan Lebih Dulu?

Enterprise dapat memiliki ratusan aplikasi, server, API, cloud workload, endpoint, database, SaaS platform, hingga legacy system yang semuanya membutuhkan perlindungan. Masalahnya, security budget, engineering capacity, dan waktu remediation selalu terbatas. Organisasi hampir tidak mungkin memperbaiki seluruh vulnerability, mengganti seluruh legacy component, meningkatkan semua security control, dan melakukan modernization pada setiap system secara bersamaan. Pertanyaan yang lebih realistis bukan “sistem mana yang memiliki vulnerability?”, tetapi “jika harus menentukan prioritas hari ini, sistem mana yang paling penting untuk diamankan terlebih dahulu?”

Di sinilah Cybersecurity Risk Assessment menjadi penting. Risk assessment tidak hanya mencari technical weakness. Assessment perlu menghubungkan vulnerability dengan business process, critical data, system dependency, threat exposure, existing control, dan consequence jika asset tersebut compromised. Dua system dapat mempunyai vulnerability dengan technical severity yang sama tetapi menghasilkan business risk yang sangat berbeda karena satu system mendukung critical revenue process sementara system lainnya hanya mendukung aktivitas administratif dengan impact terbatas.

Pendekatan tersebut sejalan dengan NIST Cybersecurity Framework 2.0, yang memosisikan cybersecurity sebagai aktivitas untuk memahami dan mengelola risk organisasi, bukan sekadar daftar technical controls. CSF 2.0 dirancang untuk membantu berbagai organisasi mengurangi cybersecurity risk, sementara NIST juga memperkuat fungsi Govern agar cybersecurity terhubung dengan enterprise context, responsibility, policy, dan risk-management strategy. NIST

Karena itu, hasil akhir Cybersecurity Risk Assessment yang baik bukan daftar panjang vulnerability. Hasil yang lebih berguna bagi management adalah urutan risk yang dapat menjelaskan mengapa suatu system harus diprioritaskan, business impact apa yang sedang dilindungi, dan response apa yang paling rasional dilakukan lebih dahulu.

Cybersecurity Risk Assessment Bukan Sekadar Vulnerability Assessment

Vulnerability assessment dan cybersecurity risk assessment mempunyai hubungan yang erat, tetapi keduanya tidak identik. Vulnerability assessment berfokus pada kelemahan yang ditemukan pada technology environment, seperti software version yang rentan, misconfiguration, weak authentication, exposed service, insecure dependency, atau control yang belum diterapkan. Cybersecurity Risk Assessment mengambil informasi tersebut dan menambahkan konteks yang lebih besar: apa yang dapat mengeksploitasi kelemahan tersebut, seberapa mungkin hal itu terjadi, asset atau process apa yang terdampak, dan seberapa besar consequence-nya terhadap enterprise.

NIST SP 800-30 Rev. 1 menjelaskan risk assessment sebagai bagian dari keseluruhan risk-management process yang memberikan informasi kepada senior leaders untuk menentukan response terhadap identified risk. Assessment mempertimbangkan threat, vulnerability, likelihood, impact, dan existing conditions sehingga keputusan security tidak berhenti pada temuan teknis. NIST CSRC

Perbedaan ini penting karena severity vulnerability tidak selalu sama dengan business priority. Sebuah vulnerability dengan technical severity tinggi pada isolated development system dapat mempunyai business consequence yang lebih rendah dibandingkan medium-severity issue pada internet-facing authentication service yang menjadi pintu masuk ke berbagai core application.

Itulah sebabnya enterprise tidak seharusnya bertanya hanya:

“Seberapa parah vulnerability ini?”

Pertanyaannya harus berkembang menjadi:

“Jika vulnerability ini benar-benar dieksploitasi, business capability apa yang terganggu dan seberapa besar dampaknya?”

Mulai dari Business Criticality, Bukan dari Daftar Server

Cybersecurity assessment sering dimulai dari inventory IT: server apa yang dimiliki, aplikasi apa yang berjalan, operating system apa yang digunakan, dan vulnerability apa yang ditemukan. Asset inventory tetap fundamental, tetapi prioritization menjadi lebih kuat jika dimulai satu langkah lebih awal, yaitu dari business process dan business capability yang tidak boleh terganggu.

Bayangkan perusahaan memiliki tiga system. System pertama adalah public corporate website. System kedua adalah ERP yang memproses financial transaction dan procurement. System ketiga adalah internal reporting application yang digunakan beberapa kali dalam sebulan. Ketiganya harus diamankan, tetapi consequence jika masing-masing unavailable, manipulated, atau mengalami data breach tentu tidak sama.

NIST IR 8286D secara eksplisit menghubungkan Business Impact Analysis dengan cybersecurity risk prioritization. NIST menjelaskan bahwa organization perlu memahami mission-essential functions, asset yang mendukung objective tersebut, dan consequence jika confidentiality, integrity, atau availability asset terganggu. Output Business Impact Analysis kemudian dapat digunakan untuk memberikan asset categorization dan protection requirement yang lebih konsisten. NIST CSRC

Bagi enterprise, prinsipnya sederhana: jangan mulai dari pertanyaan sistem mana yang paling banyak memiliki finding. Mulailah dari sistem mana yang kegagalannya paling mengganggu bisnis.

Crocodic Cyber Risk Prioritization Framework

Dalam working framework Crocodic, Cybersecurity Risk Assessment dapat dibaca melalui chain berikut:

Business Criticality → System & Data Dependency → Threat Exposure → Vulnerability / Control Gap → Evidence of Exploitation → Business Impact → Recovery Dependency → Risk Priority → Treatment

Framework ini dimulai dari Business Criticality. Enterprise perlu mengetahui process mana yang secara langsung memengaruhi revenue, cash flow, operation, customer service, safety, compliance, atau continuity. Setelah itu, organization mengidentifikasi System & Data Dependency, yaitu application, data, infrastructure, identity, API, atau third-party service yang membuat critical process tersebut dapat berjalan.

Lapisan berikutnya adalah Threat Exposure dan Vulnerability / Control Gap. Sebuah weakness menjadi lebih penting jika asset internet-facing, mempunyai privilege besar, terhubung ke banyak system, menyimpan sensitive data, atau merupakan attractive entry point bagi attacker. Setelah itu, evidence seperti known exploitation, active campaign, atau recurring incident membantu mempertajam priority.

Barulah organization melihat Business Impact dan Recovery Dependency. Jika system compromised, apakah perusahaan kehilangan revenue, menghentikan operation, kehilangan integrity data, menghadapi privacy exposure, atau membutuhkan waktu lama untuk recovery? Seluruh informasi tersebut digunakan untuk menentukan Risk Priority dan Treatment.

Framework ini sengaja tidak dimulai dari CVE count.

Security priority seharusnya mengikuti risk terhadap business, bukan jumlah temuan teknis semata.

Business Criticality: Sistem yang Sama-Sama Penting Belum Tentu Sama-Sama Kritis

Hampir setiap system owner akan mengatakan application mereka penting. Karena itu, istilah “critical” perlu memiliki meaning yang lebih jelas.

Sebuah system dapat dianggap lebih critical ketika interruption langsung menghentikan high-value business process, mendukung banyak downstream system, memproses sensitive atau regulated data, memegang privileged identity, mempunyai low tolerance terhadap downtime, atau membutuhkan recovery yang kompleks.

Contohnya, internal employee portal memang penting, tetapi production-control system yang berhenti dapat menghentikan operation. Marketing analytics platform valuable, tetapi identity provider yang compromised dapat membuka akses ke puluhan application. Customer-facing mobile application penting, tetapi database credential yang digunakan beberapa system dapat menjadi concentration risk yang lebih besar.

NIST IR 8286D menggunakan Business Impact Analysis untuk membantu organization menentukan asset yang mendukung mission objectives dan mengevaluasi faktor yang membuat asset critical atau sensitive. Pendekatan seperti ini membuat security prioritization lebih mudah dipahami management karena risk diterjemahkan menjadi business consequence, bukan technical jargon. NIST CSRC

Karena itu, enterprise perlu memetakan:

Business Process → Supporting System → Supporting Data → Identity → Integration → Infrastructure → External Dependency

Dari sini akan terlihat bahwa satu business process tidak hanya bergantung pada application yang terlihat oleh user. Authentication, database, API gateway, message queue, cloud service, third-party provider, dan network connection dapat menjadi bagian dari risk chain.

System Dependency Dapat Membuat System “Kecil” Menjadi Sangat Kritis

Cyber risk tidak selalu terlihat dari ukuran application. Sebuah component kecil dapat mempunyai blast radius yang sangat besar jika menjadi dependency banyak system.

Identity service adalah contoh paling sederhana. User mungkin jarang berinteraksi langsung dengannya, tetapi jika identity service gagal atau compromised, puluhan application dapat ikut terdampak. Hal yang sama berlaku untuk API gateway, integration layer, master-data service, shared database, DNS, backup infrastructure, secrets management, maupun administrator account.

Karena itu, Cybersecurity Risk Assessment perlu melihat dependency concentration.

Pertanyaannya bukan hanya “apa yang terjadi jika system A terkena serangan?”, tetapi juga “system apa saja yang ikut kehilangan confidentiality, integrity, atau availability ketika system A gagal?”

Pendekatan ini berhubungan dengan artikel Crocodic mengenai Zero Trust: Strategi Keamanan Wajib Sistem Enterprise. Zero Trust membantu mengurangi assumption bahwa akses di dalam environment otomatis dapat dipercaya. Namun sebelum menentukan security architecture, enterprise tetap perlu mengetahui identity, application, data, dan integration mana yang memiliki concentration risk terbesar.

Semakin banyak critical capability bergantung kepada satu asset, semakin besar alasan asset tersebut memperoleh attention lebih tinggi dalam security roadmap.

Exposure dan Exploitability Perlu Dibaca Bersama Business Impact

System yang business-critical belum tentu berada pada risk priority tertinggi jika exposure sangat rendah dan control sudah kuat. Sebaliknya, application dengan business criticality sedang dapat membutuhkan immediate action jika system internet-facing, mempunyai exploitable vulnerability, dan menjadi gateway menuju environment yang lebih sensitif.

Karena itu, risk prioritization membutuhkan konteks dari kedua sisi: impact jika incident terjadi dan kemungkinan bahwa weakness benar-benar digunakan oleh attacker.

Salah satu input penting adalah CISA Known Exploited Vulnerabilities Catalog. CISA mempertahankan katalog vulnerability yang diketahui telah dieksploitasi di dunia nyata dan secara eksplisit menyarankan organisasi menggunakan katalog tersebut sebagai input untuk vulnerability-management prioritization. CISA

Prinsipnya penting karena organisasi sering memiliki ribuan vulnerability. Tidak semuanya mempunyai urgency yang sama. Evidence bahwa vulnerability aktif dieksploitasi dapat meningkatkan priority dibandingkan weakness yang secara teoritis berat tetapi tidak memiliki threat context yang sama.

Namun KEV juga bukan satu-satunya faktor.

Enterprise tetap perlu menggabungkannya dengan asset exposure, privilege level, network reachability, compensating control, business criticality, dan consequence jika attacker berhasil masuk.

Dengan demikian:

Technical Severity ≠ Cybersecurity Risk Priority

Severity adalah input.

Risk priority adalah hasil dari technical evidence + threat context + business context.

CVSS Tinggi Tidak Otomatis Menjadi Prioritas Nomor Satu

CVSS membantu memberikan standardized indication mengenai technical severity vulnerability. Framework seperti ini sangat berguna untuk membuat language yang konsisten antara security team, vendor, dan engineering team. Namun technical severity tidak mengetahui secara penuh business context dari setiap organization.

Vulnerability dengan skor tinggi pada test environment yang tidak terhubung production dapat memiliki priority berbeda dengan skor lebih rendah pada public-facing system yang memproses transaction penting.

Karena itu, remediation backlog yang hanya disortir dari CVSS tertinggi ke terendah berisiko membuat organization menggunakan resource pada urutan yang belum tentu menghasilkan risk reduction terbesar.

NIST IR 8286 Rev. 1 menekankan bahwa cybersecurity risk harus dipahami dalam konteks broader enterprise objectives, dan risk practitioner perlu memahami strategic objective ketika melakukan assessment maupun menentukan treatment. NIST juga menempatkan cybersecurity risk register sebagai mekanisme untuk mengkomunikasikan risk dari system atau organizational level menuju enterprise risk management. NIST CSRC

Di sinilah security mulai menjadi management issue, bukan hanya technical issue.

Risk register yang baik tidak hanya mempunyai kolom vulnerability ID dan severity, tetapi juga business owner, affected process, potential impact, current control, treatment, accountable owner, target date, serta residual risk.

Data Sensitivity Harus Dipisahkan dari System Availability

Tidak semua system menjadi critical karena downtime.

Sebagian system berisiko besar karena data yang disimpan. Application mungkin bukan bagian dari daily mission-critical operation, tetapi menyimpan employee records, customer identity, financial information, contractual documents, authentication credentials, atau intellectual property.

Karena itu, Cybersecurity Risk Assessment perlu melihat tiga jenis impact secara terpisah:

Confidentiality — Integrity — Availability

Loss of confidentiality dapat menghasilkan data exposure. Loss of integrity dapat lebih berbahaya pada system tertentu karena attacker dapat memodifikasi financial record, transaction instruction, approval, atau operational parameter. Loss of availability dapat menghentikan operation.

NIST IR 8286D memperluas Business Impact Analysis bukan hanya terhadap downtime, tetapi juga impact dari compromise terhadap confidentiality dan integrity. Pendekatan ini membantu management memahami bahwa “system tidak pernah down” bukan bukti bahwa security risk rendah. NIST CSRC

Untuk perusahaan Indonesia yang memproses personal data, classification seperti ini juga perlu dibaca bersama privacy obligation. Crocodic sebelumnya telah membahas UU PDP: Kepatuhan Data Pribadi Sistem Enterprise dan Cara Menjaga Kepatuhan UU PDP dalam Pengembangan Sistem. Namun compliance sebaiknya tidak menjadi satu-satunya alasan melindungi data. Data risk perlu dipahami sebagai bagian dari reputational, operational, customer, legal, dan strategic exposure.

Existing Security Controls Mengubah Besarnya Risk

Dua system dapat memiliki vulnerability yang sama tetapi memiliki residual risk berbeda karena control yang melindunginya berbeda.

System A mungkin mempunyai network segmentation, MFA, restricted privilege, Web Application Firewall, centralized logging, EDR, tested backup, dan incident-response mechanism. System B mempunyai vulnerability sama tetapi berada langsung di internet, menggunakan shared administrator credential, tidak dimonitor, dan tidak mempunyai tested recovery process.

Technical weakness-nya sama.

Risk-nya belum tentu sama.

Karena itu, Cybersecurity Risk Assessment perlu mengevaluasi control effectiveness, bukan hanya control existence. Memiliki firewall tidak otomatis berarti exposure sudah terkendali. Memiliki backup belum berarti recovery dapat dilakukan. Memiliki log belum berarti organization mampu mendeteksi attacker. Memiliki MFA juga belum berarti privileged access secara keseluruhan sudah sehat.

Pendekatan seperti ini berkaitan dengan Security by Design: Proteksi Enterprise dari Source Code. Security tidak ideal jika menjadi layer yang baru ditambahkan setelah architecture selesai. Existing controls dan security requirement perlu menjadi bagian dari system design dan lifecycle, terutama untuk application yang membawa critical business process.

Assessment karena itu sebaiknya menghasilkan bukan hanya daftar “control tersedia / tidak tersedia”, tetapi pertanyaan:

Apakah control tersebut benar-benar mengurangi likelihood atau impact dari risk scenario yang sedang dinilai?

Recovery Capability Harus Masuk ke Risk Priority

Cybersecurity biasanya fokus pada prevention dan detection. Namun untuk management, pertanyaan lain sama pentingnya: jika attack berhasil, seberapa cepat bisnis dapat kembali beroperasi?

System yang mempunyai strong backup, tested recovery, alternative workflow, clean deployment mechanism, dan documented dependency dapat mempunyai impact profile yang berbeda dibandingkan system yang membutuhkan manual rebuild selama beberapa hari.

Recoverability tidak menghilangkan risk, tetapi memengaruhi potential business consequence.

Misalnya dua application mengalami ransomware scenario yang sama. Application pertama dapat dipulihkan dari immutable backup dengan tested procedure. Application kedua menggunakan undocumented legacy infrastructure dan hanya beberapa engineer yang memahami cara menghidupkannya kembali. Keduanya terkena incident yang sama, tetapi operational consequence dapat berbeda drastis.

Karena itu, Crocodic memasukkan Recovery Dependency dalam Cyber Risk Prioritization Framework. Enterprise perlu mengetahui Recovery Time Objective, data-recovery requirement, dependency sequence, backup health, availability of clean environment, critical vendor dependency, dan manual fallback process.

Cybersecurity Risk Assessment dengan demikian bukan hanya mencari cara mencegah incident.

Assessment juga perlu mengetahui asset mana yang paling sulit dipulihkan ketika prevention gagal.

Contoh Prioritas Empat Sistem Enterprise

Untuk membuat konsepnya lebih konkret, pertimbangkan empat system berikut. Tabel ini hanya ilustrasi decision-making, bukan scoring standard.

Corporate website dapat mempunyai exposure lebih besar daripada ERP karena public-facing, tetapi ERP mempunyai business criticality, sensitive data, financial integrity, dan recovery dependency jauh lebih besar. Identity platform bahkan dapat memperoleh priority tertinggi karena compromise pada satu system dapat membuka akses kepada banyak application lainnya.

Inilah alasan “internet-facing dulu”, “CVSS tertinggi dulu”, atau “system terbesar dulu” tidak selalu cukup sebagai prioritization strategy.

Cyber risk perlu melihat keseluruhan relationship antara asset, threat, business, dan dependency.

Risk Treatment Tidak Selalu Berarti Memperbaiki Semua Vulnerability

Setelah risk diprioritaskan, enterprise perlu memilih treatment. Remediation hanyalah salah satu kemungkinan.

NIST IR 8286 series menghubungkan cybersecurity risk dengan enterprise risk management dan membantu organization memprioritaskan risk berdasarkan enterprise objectives sebelum menentukan response. Risk decision dapat mencakup mitigation, avoidance, transfer, sharing, atau acceptance sesuai konteks dan risk tolerance organization. NIST

Dalam praktik enterprise, treatment dapat berbentuk patch, reconfiguration, network segmentation, stronger authentication, removal of unnecessary access, application modernization, code remediation, data encryption, monitoring improvement, vendor control, backup improvement, replacement system, atau decommissioning.

Kadang-kadang solusi terbaik bukan memperkuat system lama.

Jika legacy application sudah memiliki terlalu banyak unsupported component dan hanya mempertahankan business capability kecil, retirement atau consolidation dapat menghasilkan risk reduction lebih besar dibandingkan terus menambahkan security control.

Hal ini membuat cybersecurity assessment relevan terhadap technology roadmap. Security finding tidak selalu harus menghasilkan security project. Ia dapat menjadi input bagi modernization, integration, application rationalization, dan architecture redesign.

Cybersecurity Risk Assessment Harus Menghasilkan Prioritized Roadmap

Assessment yang berakhir dengan laporan 200 halaman tetapi tidak mengubah investment priority mempunyai business value yang terbatas.

Output assessment seharusnya membantu management mengetahui tiga hal: risk mana yang membutuhkan immediate response, risk mana yang membutuhkan structural improvement, dan risk mana yang masih dapat diterima atau dimonitor.

Dalam working approach Crocodic, output dapat dibagi menjadi:

Immediate Risk Reduction untuk exposure yang sudah mempunyai high likelihood dan high impact.

Structural Remediation untuk masalah yang membutuhkan architecture, integration, identity, data, atau legacy modernization.

Control Improvement untuk strengthening monitoring, access, backup, configuration, atau process.

Accepted / Monitored Risk untuk risk yang berada dalam tolerance atau belum mempunyai economic justification untuk immediate remediation.

Classification tersebut membantu security roadmap bersaing secara lebih sehat dengan technology investment lain.

Alih-alih meminta “budget cybersecurity” secara abstrak, CIO atau CISO dapat menjelaskan:

“Investment ini melindungi revenue process X, menurunkan concentration risk pada identity, dan mempercepat recovery untuk system yang mempunyai tolerance downtime rendah.”

Bahasa tersebut jauh lebih dekat dengan enterprise decision making.

Jangan Pisahkan Cybersecurity Risk dari Enterprise Risk

Salah satu perubahan penting dalam cybersecurity governance beberapa tahun terakhir adalah semakin kuatnya hubungan antara cyber risk dan Enterprise Risk Management.

NIST IR 8286 Rev. 1 menekankan bahwa directors dan senior leaders perlu mempunyai clear understanding terhadap cybersecurity risk posture, sementara orang yang mengidentifikasi dan menangani cyber risk perlu memahami enterprise strategic objectives. Cyber risk kemudian dibawa melalui risk register sehingga dapat dilihat sebagai bagian dari broader enterprise risk portfolio. NIST CSRC

Ini berarti risk seperti ransomware, credential compromise, API breach, data manipulation, atau supply-chain attack tidak seharusnya hanya dibicarakan sebagai technical scenario.

Management perlu mengetahui:

apakah production berhenti,

apakah customer tidak dapat dilayani,

apakah revenue tertunda,

apakah financial record kehilangan integrity,

apakah confidential information terekspos,

atau apakah recovery membutuhkan biaya dan waktu yang material.

Pada level tersebut, cybersecurity tidak lagi hanya menjadi tanggung jawab IT security.

Ia menjadi business-risk decision.

Crocodic Perspective: Amankan Business Capability, Bukan Hanya Asset

Dalam perspective Crocodic, asset inventory tetap penting, tetapi endpoint dari Cybersecurity Risk Assessment bukan melindungi sebanyak mungkin asset dengan tingkat prioritas yang sama.

Targetnya adalah menjaga business capability yang paling penting terhadap enterprise.

Framework Crocodic adalah:

Business Criticality → System & Data Dependency → Threat Exposure → Vulnerability / Control Gap → Evidence of Exploitation → Business Impact → Recovery Dependency → Risk Priority → Treatment

Framework tersebut mengubah pertanyaan security dari:

“Berapa banyak vulnerability yang kita punya?”

menjadi:

“Vulnerability mana yang paling mungkin mengganggu outcome bisnis yang paling penting?”

NIST CSF 2.0 menempatkan cybersecurity sebagai risk-management discipline yang dapat digunakan organization untuk memahami dan meningkatkan cybersecurity posture. NIST IR 8286 membawa risk tersebut ke enterprise objectives dan risk register, sedangkan NIST IR 8286D menggunakan Business Impact Analysis untuk menentukan asset mana yang paling critical dan sensitive. CISA KEV kemudian memberikan threat evidence tambahan dengan menunjukkan vulnerability yang diketahui sudah dieksploitasi di dunia nyata. NIST

Ketika keempat perspective tersebut digabungkan, security priority menjadi jauh lebih kuat daripada hanya mengikuti severity scanner.

Business Value menentukan apa yang perlu dilindungi. Threat dan vulnerability menunjukkan bagaimana asset dapat diserang. Existing controls menunjukkan seberapa besar exposure yang masih tersisa. Recovery menunjukkan seberapa besar organization dapat menyerap incident.

Barulah risk treatment ditentukan.

Kesimpulan

Enterprise tidak dapat memperlakukan seluruh application, vulnerability, dan security finding dengan priority yang sama. Resource terbatas, architecture kompleks, dan tidak semua system mempunyai business consequence yang identik.

Cybersecurity Risk Assessment membantu organization menentukan urutan tersebut dengan menghubungkan technical risk terhadap business reality.

Assessment tidak cukup berhenti pada vulnerability severity. Enterprise perlu memahami Business Criticality, System & Data Dependency, Threat Exposure, Vulnerability atau Control Gap, Evidence of Exploitation, Business Impact, serta Recovery Dependency sebelum menentukan Risk Priority.

Dalam working framework Crocodic:

Business Criticality → System & Data Dependency → Threat Exposure → Vulnerability / Control Gap → Evidence of Exploitation → Business Impact → Recovery Dependency → Risk Priority → Treatment

memberikan satu prinsip yang sederhana tetapi penting:

sistem yang paling banyak memiliki vulnerability belum tentu menjadi sistem yang harus diamankan pertama.

Prioritas tertinggi seharusnya diberikan kepada risk yang memiliki kombinasi paling berbahaya antara critical business dependency, credible threat exposure, insufficient control, high potential impact, dan limited recovery capability.

Tujuan cybersecurity pada akhirnya bukan membuat seluruh infrastructure terlihat “secure” di atas checklist.

Tujuannya adalah memastikan bahwa ketika cyber risk terjadi, business capability yang paling penting bagi enterprise mempunyai protection, detection, response, dan recovery capability yang sebanding dengan nilai yang sedang dilindungi.