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. |
PR.IR-01.6: The organisation shall ensure that its critical systems are designed to fail securely and remain protected in the event of an operational failure of a border protection device. |
|
PR.IR-01.6 |
|
|
http://cyfun.data.gift/data/loc_CyFun2025_Booklet_ESSENTIAL_E_p135 |
|
|
Relates a concept to a concept that is more general in meaning. |
|
|
A general note, for any purpose. |
The goal of this control is to ensure that critical systems remain protected and do not become exposed orvul- nerable if a firewall, proxy, or other boundary protection device fails. In OT environments, where availability and safety are paramount, systems should be designed to fail securely, for example, by defaulting to a deny-all state, isolating affected segments, or triggering alerts, so that a failure in one component does not compromise the entire system or allow unauthorised access. To achieve this goal, the following should be considered: • Fail-Secure Configuration Devices should be configured to default to a secure state (e.g. deny all traffic) in the event of failure, pre- venting unauthorised access or data leakage. • Redundancy and High Availability Redundant systems or failover mechanisms should be in place to ensure continuous protection. Avoid single points of failure, especially in OT environments where uptime is critical. • Regular Testing and Maintenance Failover mechanisms and secure failure configurations should be tested regularly. Maintenance should ensure devices remain in a secure and functional state. • Access Control Integrity Access Control Lists (ACLs) and security policies should remain protected and unaltered during failures to preserve the system’s security posture. • Monitoring and Alerts Real-time monitoring and alerting should be implemented to detect failures promptly and initiate corrective actions. • Segmentation and Isolation Network design should include segmentation and isolation to limit the impact of a failure and prevent cas- cading effects across systems. These practices align with recognised standards, including NIST SP 800-53 Rev. 5, NIST SP 800-53A, and IEC 62443-3-3 SR 5.2 RE 3 – Fail Close, which emphasise secure failure and resilience in critical infrastructure systems. |
|
A general note, for any purpose. |
The goal of this control is to ensure that critical systems remain protected and do not become exposed orvul- nerable if a firewall, proxy, or other boundary protection device fails. In OT environments, where availability and safety are paramount, systems should be designed to fail securely, for example, by defaulting to a deny-all state, isolating affected segments, or triggering alerts, so that a failure in one component does not compromise the entire system or allow unauthorised access. To achieve this goal, the following should be considered: - Fail-Secure Configuration Devices should be configured to default to a secure state (e.g. deny all traffic) in the event of failure, pre- venting unauthorised access or data leakage. - Redundancy and High Availability Redundant systems or failover mechanisms should be in place to ensure continuous protection. Avoid single points of failure, especially in OT environments where uptime is critical. - Regular Testing and Maintenance Failover mechanisms and secure failure configurations should be tested regularly. Maintenance should ensure devices remain in a secure and functional state. - Access Control Integrity Access Control Lists (ACLs) and security policies should remain protected and unaltered during failures to preserve the system’s security posture. - Monitoring and Alerts Real-time monitoring and alerting should be implemented to detect failures promptly and initiate corrective actions. - Segmentation and Isolation Network design should include segmentation and isolation to limit the impact of a failure and prevent cas- cading effects across systems. These practices align with recognised standards, including NIST SP 800-53 Rev. 5, NIST SP 800-53A, and IEC 62443-3-3 SR 5.2 RE 3 – Fail Close, which emphasise secure failure and resilience in critical infrastructure systems. |
|
A general note, for any purpose. |
<div><p>The goal of this control is to ensure that critical systems remain protected and do not become exposed orvul- nerable if a firewall, proxy, or other boundary protection device fails. In OT environments, where availability and safety are paramount, systems should be designed to fail securely, for example, by defaulting to a deny-all state, isolating affected segments, or triggering alerts, so that a failure in one component does not compromise the entire system or allow unauthorised access. To achieve this goal, the following should be considered:</p><ul><li>Fail-Secure Configuration Devices should be configured to default to a secure state (e.g. deny all traffic) in the event of failure, pre- venting unauthorised access or data leakage.</li><li>Redundancy and High Availability Redundant systems or failover mechanisms should be in place to ensure continuous protection. Avoid single points of failure, especially in OT environments where uptime is critical.</li><li>Regular Testing and Maintenance Failover mechanisms and secure failure configurations should be tested regularly. Maintenance should ensure devices remain in a secure and functional state.</li><li>Access Control Integrity Access Control Lists (ACLs) and security policies should remain protected and unaltered during failures to preserve the system’s security posture.</li><li>Monitoring and Alerts Real-time monitoring and alerting should be implemented to detect failures promptly and initiate corrective actions.</li><li>Segmentation and Isolation Network design should include segmentation and isolation to limit the impact of a failure and prevent cas- cading effects across systems. These practices align with recognised standards, including NIST SP 800-53 Rev. 5, NIST SP 800-53A, and IEC 62443-3-3 SR 5.2 RE 3 – Fail Close, which emphasise secure failure and resilience in critical infrastructure systems.</li></ul></div> |
|
A general note, for any purpose. |
The goal of this control is to ensure that critical systems remain protected and do not become exposed orvul- nerable if a firewall, proxy, or other boundary protection device fails. In OT environments, where availability and safety are paramount, systems should be designed to fail securely, for example, by defaulting to a deny-all state, isolating affected segments, or triggering alerts, so that a failure in one component does not compromise the entire system or allow unauthorised access. To achieve this goal, the following should be considered: - Fail-Secure Configuration Devices should be configured to default to a secure state (e.g. deny all traffic) in the event of failure, pre- venting unauthorised access or data leakage. - Redundancy and High Availability Redundant systems or failover mechanisms should be in place to ensure continuous protection. Avoid single points of failure, especially in OT environments where uptime is critical. - Regular Testing and Maintenance Failover mechanisms and secure failure configurations should be tested regularly. Maintenance should ensure devices remain in a secure and functional state. - Access Control Integrity Access Control Lists (ACLs) and security policies should remain protected and unaltered during failures to preserve the system’s security posture. - Monitoring and Alerts Real-time monitoring and alerting should be implemented to detect failures promptly and initiate corrective actions. - Segmentation and Isolation Network design should include segmentation and isolation to limit the impact of a failure and prevent cas- cading effects across systems. These practices align with recognised standards, including NIST SP 800-53 Rev. 5, NIST SP 800-53A, and IEC 62443-3-3 SR 5.2 RE 3 – Fail Close, which emphasise secure failure and resilience in critical infrastructure systems. |
|
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. |
PR.IR-01.6 |
|
skos:prefLabel, skos:altLabel and skos:hiddenLabel are pairwise disjoint properties. |
Secure failure of boundary devices |
|
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 ensure that its critical systems are designed to fail securely and remain protected in the event of an operational failure of a border protection device. |
|
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