Direct links from the subject.
| Property | Value |
|---|---|
|
The subject is an instance of a class. |
|
|
The subject is an instance of a class. |
An idea or notion; a unit of thought. |
|
A human-readable name for the subject. |
DE.CM-09.2: The organisation shall implement hardware integrity checks to detect unauthorised tampering of critical system hardware. Controls shall be proportionate to the organ- isation’s risk profile and operational capacity. |
|
DE.CM-09.2 |
|
|
http://cyfun.data.gift/data/loc_CyFun2025_Booklet_ESSENTIAL_E_p153 |
|
|
Relates a concept to a concept that is more general in meaning. |
|
|
A general note, for any purpose. |
<div><p>The goal of this control is to ensure that critical hardware components are protected against unauthorised tampering. By implementing integrity checks that match the organisation’s risk level and operational capacity, it becomes possible to detect physical or firmware-level changes that could compromise security. Consider the following elements to achieve this goal:</p><ul><li>Define What Needs Protection Identify which systems are most critical, such as servers handling sensitive data, industrial control systems (ICS/SCADA), or cryptographic devices, and prioritise them based on business impact, legal requirements, and exposure to threats.</li><li>Choose the Right Level of Protection Select controls based on how critical the system is and what the organisation can support:<ul><li>Basic controls: Locked server rooms, tamper-evident seals, secure boot, and regular hardware audits.</li><li>Intermediate controls: Alerts when hardware is opened, use of Trusted Platform Modules (TPMs), and firmware validation tools.</li><li>Advancedcontrols: Remotevalidation ofhardware state, tamper-resistant cryptographic hardware (HSMs), and monitoring for hardware-level anomalies using security tools.</li></ul></li><li>Connect to Security Operations Feed alerts from hardware integrity tools into central monitoring systems (like a SIEM or SOC) for real-time visibility. Define how to respond if tampering is suspected.</li><li>Assign Clear Responsibilities Designate roles for designing, implementing, and responding to hardware integrity issues. Use role profiles (e.g. from ENISA ECSF) to guide responsibilities:<ul><li>Security architects design the controls.</li><li>System administrators implement and monitor them.</li><li>Incident responders investigate alerts.</li></ul></li><li>Document and Review Include hardware integrity checks in security policies, risk assessments, and audit logs. Review their effective- ness at least once a year or after major changes or incidents.</li><li>Train Staff and Raise Awareness Train relevant personnel to recognise signs of tampering, use integrity tools correctly, and follow reporting procedures.</li></ul></div> |
|
A general note, for any purpose. |
The goal of this control is to ensure that critical hardware components are protected against unauthorised tampering. By implementing integrity checks that match the organisation’s risk level and operational capacity, it becomes possible to detect physical or firmware-level changes that could compromise security. Consider the following elements to achieve this goal: • Define What Needs Protection Identify which systems are most critical, such as servers handling sensitive data, industrial control systems (ICS/SCADA), or cryptographic devices, and prioritise them based on business impact, legal requirements, and exposure to threats. • Choose the Right Level of Protection Select controls based on how critical the system is and what the organisation can support: o Basic controls: Locked server rooms, tamper-evident seals, secure boot, and regular hardware audits. o Intermediate controls: Alerts when hardware is opened, use of Trusted Platform Modules (TPMs), and firmware validation tools. o Advancedcontrols: Remotevalidation ofhardware state, tamper-resistant cryptographic hardware (HSMs), and monitoring for hardware-level anomalies using security tools. • Connect to Security Operations Feed alerts from hardware integrity tools into central monitoring systems (like a SIEM or SOC) for real-time visibility. Define how to respond if tampering is suspected. • Assign Clear Responsibilities Designate roles for designing, implementing, and responding to hardware integrity issues. Use role profiles (e.g. from ENISA ECSF) to guide responsibilities: o Security architects design the controls. o System administrators implement and monitor them. o Incident responders investigate alerts. • Document and Review Include hardware integrity checks in security policies, risk assessments, and audit logs. Review their effective- ness at least once a year or after major changes or incidents. • Train Staff and Raise Awareness Train relevant personnel to recognise signs of tampering, use integrity tools correctly, and follow reporting procedures. |
|
A general note, for any purpose. |
The goal of this control is to ensure that critical hardware components are protected against unauthorised tampering. By implementing integrity checks that match the organisation’s risk level and operational capacity, it becomes possible to detect physical or firmware-level changes that could compromise security. Consider the following elements to achieve this goal: - Define What Needs Protection Identify which systems are most critical, such as servers handling sensitive data, industrial control systems (ICS/SCADA), or cryptographic devices, and prioritise them based on business impact, legal requirements, and exposure to threats. - Choose the Right Level of Protection Select controls based on how critical the system is and what the organisation can support: - Basic controls: Locked server rooms, tamper-evident seals, secure boot, and regular hardware audits. - Intermediate controls: Alerts when hardware is opened, use of Trusted Platform Modules (TPMs), and firmware validation tools. - Advancedcontrols: Remotevalidation ofhardware state, tamper-resistant cryptographic hardware (HSMs), and monitoring for hardware-level anomalies using security tools. - Connect to Security Operations Feed alerts from hardware integrity tools into central monitoring systems (like a SIEM or SOC) for real-time visibility. Define how to respond if tampering is suspected. - Assign Clear Responsibilities Designate roles for designing, implementing, and responding to hardware integrity issues. Use role profiles (e.g. from ENISA ECSF) to guide responsibilities: - Security architects design the controls. - System administrators implement and monitor them. - Incident responders investigate alerts. - Document and Review Include hardware integrity checks in security policies, risk assessments, and audit logs. Review their effective- ness at least once a year or after major changes or incidents. - Train Staff and Raise Awareness Train relevant personnel to recognise signs of tampering, use integrity tools correctly, and follow reporting procedures. |
|
A general note, for any purpose. |
The goal of this control is to ensure that critical hardware components are protected against unauthorised tampering. By implementing integrity checks that match the organisation’s risk level and operational capacity, it becomes possible to detect physical or firmware-level changes that could compromise security. Consider the following elements to achieve this goal: - Define What Needs Protection Identify which systems are most critical, such as servers handling sensitive data, industrial control systems (ICS/SCADA), or cryptographic devices, and prioritise them based on business impact, legal requirements, and exposure to threats. - Choose the Right Level of Protection Select controls based on how critical the system is and what the organisation can support: - Basic controls: Locked server rooms, tamper-evident seals, secure boot, and regular hardware audits. - Intermediate controls: Alerts when hardware is opened, use of Trusted Platform Modules (TPMs), and firmware validation tools. - Advancedcontrols: Remotevalidation ofhardware state, tamper-resistant cryptographic hardware (HSMs), and monitoring for hardware-level anomalies using security tools. - Connect to Security Operations Feed alerts from hardware integrity tools into central monitoring systems (like a SIEM or SOC) for real-time visibility. Define how to respond if tampering is suspected. - Assign Clear Responsibilities Designate roles for designing, implementing, and responding to hardware integrity issues. Use role profiles (e.g. from ENISA ECSF) to guide responsibilities: - Security architects design the controls. - System administrators implement and monitor them. - Incident responders investigate alerts. - Document and Review Include hardware integrity checks in security policies, risk assessments, and audit logs. Review their effective- ness at least once a year or after major changes or incidents. - Train Staff and Raise Awareness Train relevant personnel to recognise signs of tampering, use integrity tools correctly, and follow reporting procedures. |
|
A notation, also known as classification code, is a string of characters such as "T58.5" or "303.4833" used to uniquely identify a concept within the scope of a given concept scheme. |
DE.CM-09.2 |
|
skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise disjoint properties. |
Hardware integrity tampering detection |
|
A resource has no more than one value of skos:prefLabel per language tag, and no more than one value of skos:prefLabel without language tag. |
The organisation shall implement hardware integrity checks to detect unauthorised tampering of critical system hardware. Controls shall be proportionate to the organ- isation’s risk profile and operational capacity. |
|
Relates a resource (for example a concept) to a concept scheme in which it is included. |
|
|
Relates a resource (for example a concept) to a concept scheme in which it is included. |
http://cyfun.data.gift/data/CyFun2025_delta_IMPORTANT_to_ESSENTIAL |
|
Relates a resource (for example a concept) to a concept scheme in which it is included. |
|
|
The number of triples associated with the subject. |
17 |
|
Specifies the dataset the subject is part of. |
Resultaten 1 - 19 of 19
Inverse links to the subject.
| Property | Subject |
|---|---|
|
Relates a concept to a concept that is more specific in meaning. |
Resultaten 1 - 1 of 1