SEA-07.2: Fail Secure
Mechanisms exist to enable systems to fail to an organization-defined known-state for types of failures, preserving system state information in failure.
Control Question: Does the organization enable systems to fail to an organization-defined known-state for types of failures, preserving system state information in failure?
General (14)
| Framework | Mapping Values |
|---|---|
| CSA IoT SCF 2 | SAP-09 |
| GovRAMP High | SC-24 |
| IEC 62443-4-2 2019 | NDR 5.2 (15.12.3(3)) |
| NIST 800-53 R4 | CP-12 SC-24 |
| NIST 800-53 R4 (high) | SC-24 |
| NIST 800-53 R5 (source) | CP-12 SA-8(24) SC-24 |
| NIST 800-53B R5 (high) (source) | SC-24 |
| NIST 800-53 R5 (NOC) (source) | CP-12 SA-8(24) |
| NIST 800-82 R3 LOW OT Overlay | CP-12 |
| NIST 800-82 R3 MODERATE OT Overlay | CP-12 SC-24 |
| NIST 800-82 R3 HIGH OT Overlay | CP-12 SC-24 |
| OWASP Top 10 2021 | A01:2021 A05:2021 |
| SPARTA | CM0044 |
| SCF CORE Mergers, Acquisitions & Divestitures (MA&D) | SEA-07.2 |
US (6)
| Framework | Mapping Values |
|---|---|
| US CERT RMM 1.2 | EC:SG2.SP2 KIM:SG2.SP2 TM:SG2.SP2 |
| US FedRAMP R4 | SC-24 |
| US FedRAMP R4 (high) | SC-24 |
| US FedRAMP R5 (source) | SC-24 |
| US FedRAMP R5 (high) (source) | SC-24 |
| US NISPOM 2020 | 8-615 8-702 |
EMEA (1)
| Framework | Mapping Values |
|---|---|
| EMEA Israel CDMO 1.0 | 9.17 |
Capability Maturity Model
Level 0 — Not Performed
There is no evidence of a capability to enable systems to fail to an organization-defined known-state for types of failures, preserving system state information in failure.
Level 1 — Performed Informally
Secure Engineering & Architecture (SEA) efforts are ad hoc and inconsistent. CMM Level 1 control maturity would reasonably expect all, or at least most, the following criteria to exist:
- IT personnel use an informal process to design, build and maintain secure solutions.
- IT /cyber engineering governance is decentralized, with the responsibility for implementing and testing cybersecurity and data protection controls being assigned to the business process owner(s), including the definition and enforcement of roles and responsibilities.
Level 2 — Planned & Tracked
Secure Engineering & Architecture (SEA) efforts are requirements-driven and governed at a local/regional level, but are not consistent across the organization. CMM Level 2 control maturity would reasonably expect all, or at least most, the following criteria to exist:
- Architecture/engineering management is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.
- A Change Advisory Board (CAB), or similar function, exists to govern changes to systems, applications and services, ensuring their stability, reliability and predictability.
- Administrative processes and technologies focus on protecting High Value Assets (HVAs), including environments where sensitive/regulated data is stored, transmitted and processed.
- IT/cybersecurity personnel identify cybersecurity and data protection controls to address applicable statutory, regulatory and contractual requirements for architecture/engineering management.
- IT personnel implement secure engineering practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets, data and network(s).
- Technologies are configured to protect data with the strength and integrity commensurate with the classification or sensitivity of the information and mostly conform to industry-recognized standards for hardening (e.g., DISA STIGs, CIS Benchmarks or OEM security guides), including cryptographic protections for sensitive/regulated data.
Level 3 — Well Defined
Secure Engineering & Architecture (SEA) efforts are standardized across the organization and centrally managed, where technically feasible, to ensure consistency. CMM Level 3 control maturity would reasonably expect all, or at least most, the following criteria to exist:
- IT/cybersecurity architects, or a similar function, enable the implementation a “layered defense” network architecture that enables a resilient defense-in-depth approach through the use of industry-recognized cybersecurity and data privacy practices in the specification, design, development, implementation and modification of systems and services (e.g., DISA STIGs, CIS Benchmarks or OEM security guides).
- IT/cybersecurity engineers, or a similar function, operationalize enterprise architecture, aligned with industry-recognized leading practices, with consideration for cybersecurity and data privacy principles, including resiliency expectations, that addresses risk to organizational operations, assets, individuals, other organizations.
- A Validated Architecture Design Review (VADR), or similar process, is used to evaluate design criteria for secure practices and conformance with requirements for applicable statutory, regulatory and contractual controls to determine if the system/application/service is designed, built and operated in a secure and resilient manner.
- A Change Advisory Board (CAB), or similar function, governs changes to systems, applications and services to ensure their stability, reliability and predictability.
- A formal Change Management (CM) program helps to ensure that no unauthorized changes are made, all changes are documented, services are not disrupted and resources are used efficiently.
- An Identity & Access Management (IAM) function, or similar function, enables the implementation of identification and access management controls for “least privileges” practices, allowing for the management of user, group and system accounts, including privileged accounts.
- An IT Asset Management (ITAM) function, or similar function, categorizes assets according to the data the asset stores, transmits and/ or processes and applies the appropriate technology controls to protect the asset and data.
- Administrative processes exist and technologies are configured to enable systems to fail to an organization-defined known-state for types of failures, preserving system state information in failure.
Level 4 — Quantitatively Controlled
Secure Engineering & Architecture (SEA) efforts are metrics driven and provide sufficient management insight (based on a quantitative understanding of process capabilities) to predict optimal performance, ensure continued operations and identify areas for improvement. In addition to CMM Level 3 criteria, CMM Level 4 control maturity would reasonably expect all, or at least most, the following criteria to exist:
- Metrics reporting includes quantitative analysis of Key Performance Indicators (KPIs).
- Metrics reporting includes quantitative analysis of Key Risk Indicators (KRIs).
- Scope of metrics, KPIs and KRIs covers organization-wide cybersecurity and data protection controls, including functions performed by third-parties.
- Organizational leadership maintains a formal process to objectively review and respond to metrics, KPIs and KRIs (e.g., monthly or quarterly review).
- Based on metrics analysis, process improvement recommendations are submitted for review and are handled in accordance with change control processes.
- Both business and technical stakeholders are involved in reviewing and approving proposed changes.
Level 5 — Continuously Improving
Secure Engineering & Architecture (SEA) efforts are “world-class” capabilities that leverage predictive analysis (e.g., machine learning, AI, etc.). In addition to CMM Level 4 criteria, CMM Level 5 control maturity would reasonably expect all, or at least most, the following criteria to exist:
- Stakeholders make time-sensitive decisions to support operational efficiency, which may include automated remediation actions.
- Based on predictive analysis, process improvements are implemented according to “continuous improvement” practices that affect process changes.
Assessment Objectives
- SEA-07.2_A01 restrictions for safe mode of operation are defined.
- SEA-07.2_A02 conditions detected to enter a safe mode of operation are defined.
- SEA-07.2_A03 a safe mode of operation is entered with restrictions when conditions are detected.
- SEA-07.2_A04 systems or system components that implement the security design principle of secure failure are defined.
- SEA-07.2_A05 systems or system components that implement the security design principle of secure recovery are defined.
- SEA-07.2_A06 systems or system components implement the security design principle of secure failure.
- SEA-07.2_A07 systems or system components implement the security design principle of secure recovery.
- SEA-07.2_A08 types of system failures for which the system components fail to a known state are defined.
- SEA-07.2_A09 known system state to which system components fail in the event of a system failure is defined.
- SEA-07.2_A10 system state information to be preserved in the event of a system failure is defined.
- SEA-07.2_A11 types of system failures on system components fail to a known system state while preserving system state information in failure.
Technology Recommendations
Micro/Small
- Secure Baseline Configurations (SBC)
Small
- Secure Baseline Configurations (SBC)
Medium
- Secure Baseline Configurations (SBC)
Large
- Secure Baseline Configurations (SBC)
Enterprise
- Secure Baseline Configurations (SBC)