Skip to main content

SEA-03: Defense-In-Depth (DiD) Architecture

SEA 10 — Critical Protect

Mechanisms exist to implement security functions as a layered structure minimizing interactions between layers of the design and avoiding any dependence by lower layers on the functionality or correctness of higher layers.

Control Question: Does the organization implement security functions as a layered structure minimizing interactions between layers of the design and avoiding any dependence by lower layers on the functionality or correctness of higher layers?

General (16)
Framework Mapping Values
COBIT 2019 APO03.01 APO04.05
CSA CCM 4 IVS-09
ISO 27017 2015 CLD.13.1.4
NIST 800-53 R4 PL-8(1) SC-3(5)
NIST 800-53 R5 (source) PL-8(1) SC-3(5)
NIST 800-53 R5 (NOC) (source) PL-8(1) SC-3(5)
NIST 800-160 3.4 3.4.1 3.4.2 3.4.3 3.4.4 3.4.5 3.4.6
NIST 800-171 R2 (source) 3.13.2
OWASP Top 10 2021 A01:2021 A05:2021
PCI DSS 4.0.1 (source) 1.2.1 1.4.1
PCI DSS 4.0.1 SAQ A-EP (source) 1.2.1 1.4.1
PCI DSS 4.0.1 SAQ D Merchant (source) 1.2.1 1.4.1
PCI DSS 4.0.1 SAQ D Service Provider (source) 1.2.1 1.4.1
SCF CORE Mergers, Acquisitions & Divestitures (MA&D) SEA-03
SCF CORE ESP Level 2 Critical Infrastructure SEA-03
SCF CORE ESP Level 3 Advanced Threats SEA-03
US (37)
Framework Mapping Values
US C2M2 2.1 ARCHITECTURE-1.A.MIL1 ARCHITECTURE-1.B.MIL2 ARCHITECTURE-1.C.MIL2 ARCHITECTURE-1.D.MIL2 ARCHITECTURE-1.E.MIL2 ARCHITECTURE-1.F.MIL2 ARCHITECTURE-1.I.MIL3 ARCHITECTURE-1.J.MIL3 ARCHITECTURE-1.K.MIL3
US CISA CPG 2022 1.E
US CMMC 2.0 Level 2 (source) SC.L2-3.13.2
US CMMC 2.0 Level 3 (source) SC.L2-3.13.2
US DoD Zero Trust Reference Architecture 2.0 3.0
US DHS CISA TIC 3.0 3.UNI.RESIL
US FDA 21 CFR Part 11 11.30 11.50 11.70 11.100 11.100(a) 11.100(b)
US FedRAMP R4 SC-1 SA-8 SC-7(18) SI-1
US FedRAMP R4 (low) SC-1 SI-1
US FedRAMP R4 (moderate) SC-1 SA-8 SC-7(18) SI-1
US FedRAMP R4 (high) SC-1 SA-8 SC-7(18) SI-1
US FedRAMP R4 (LI-SaaS) SC-1 SI-1
US FedRAMP R5 (source) SA-8 SC-1 SC-7(18) SI-1
US FedRAMP R5 (low) (source) SA-8 SC-1 SI-1
US FedRAMP R5 (moderate) (source) SA-8 SC-1 SC-7(18) SI-1
US FedRAMP R5 (high) (source) SA-8 SC-1 SC-7(18) SI-1
US FedRAMP R5 (LI-SaaS) (source) SA-8 SC-1 SI-1
US FTC Act §45(a) §45b(d)(1)
US GLBA CFR 314 2023 (source) 314.4(c)
US HIPAA Administrative Simplification 2013 (source) 164.306(b)(1)
US HIPAA Security Rule / NIST SP 800-66 R2 (source) 164.306(b)(1)
US HIPAA HICP Small Practice 1.S.A 2.S.A 3.S.A 5.S.A 5.S.B 5.S.C 6.S.A 6.S.C 9.S.A
US HIPAA HICP Medium Practice 1.M.A 5.M.B 9.M.B
US HIPAA HICP Large Practice 1.M.A 5.M.B 9.M.B 1.L.A
US IRS 1075 PT-1 SA-8 SC-1 SC-7(18) SI-1
US NISPOM 2020 8-101 8-302 8-311
US NNPI (unclass) 16.2
US SSA EIESR 8.0 5.6
US - CA SB327 1798.91.04(a) 1798.91.04(a)(1) 1798.91.04(a)(2) 1798.91.04(a)(3) 1798.91.04(b) 1798.91.04(b)(1) 1798.91.04(b)(2)
US - CO Colorado Privacy Act 6-1-1305(4) 6-1-1308(5)
US - NY DFS 23 NYCRR500 2023 Amd 2 500.2(b)(2)
US - NY SHIELD Act S5575B 4(2)(b)(ii)(B)(1) 4(2)(b)(ii)(B)(2) 4(2)(b)(ii)(B)(3) 4(2)(b)(ii)(B)(4)
US - TX BC521 521.052
US - TX DIR Control Standards 2.0 SA-8 SC-1 SI-1
US - TX TX-RAMP Level 1 SC-1 SI-1
US - TX TX-RAMP Level 2 SA-8 SC-1 SC-7(18) SI-1
US - VT Act 171 of 2018 2447(a) 2447(a)(1) 2447(a)(1)(A) 2447(a)(1)(B) 2447(a)(1)(C) 2447(a)(1)(D) 2447(a)(2)
EMEA (29)
Framework Mapping Values
EMEA EU EBA GL/2019/04 3.7.1(79)
EMEA EU DORA 9.3(a) 9.3(b) 9.3(c) 9.3(d)
EMEA Austria Sec 14 Sec 15
EMEA Belgium 16
EMEA Germany Sec 4b Sec 9 Sec 9a Sec 16 Annex
EMEA Germany Banking Supervisory Requirements for IT (BAIT) 12.1
EMEA Germany C5 2020 COS-01
EMEA Greece 9
EMEA Hungary 7 8
EMEA Ireland 2
EMEA Israel CDMO 1.0 2.1 15.6 17.7
EMEA Israel 16 17
EMEA Italy 31 33 34 35 42
EMEA Netherlands 12 13 14
EMEA Norway 13 14 29
EMEA Poland 1 36 47
EMEA Russia 7 12 19
EMEA Saudi Arabia ECC-1 2018 1-6-3-4 2-4-3 2-15-3-3
EMEA Saudi Arabia OTCC-1 2022 1-1-2
EMEA Saudi Arabia SACS-002 TPC-43
EMEA Saudi Arabia SAMA CSF 1.0 3.3.4 3.3.8 3.3.13
EMEA South Africa 19 21
EMEA Spain BOE-A-2022-7191 9.1 9.1(a) 9.1(b) 9.2
EMEA Spain 311/2022 29
EMEA Spain CCN-STIC 825 7.1.2 [OP.PL.2]
EMEA Sweden 31 33
EMEA Switzerland 6 7
EMEA Turkey 8 12
EMEA UK CAP 1850 B4 B5
APAC (16)
Framework Mapping Values
APAC Australia Privacy Act APP Part 8 APP Part 11
APAC Australia ISM June 2024 ISM-1739 ISM-1743
APAC Australia IoT Code of Practice Principle 4 Principle 5 Principle 6 Principle 7
APAC Australia Prudential Standard CPS234 15 18
APAC China DNSIP 4
APAC Hong Kong Principle 4 Sec 33
APAC India ITR 7 8
APAC Japan APPI 20
APAC Japan ISMAP 14.1.2 14.2.5
APAC Malaysia 9
APAC New Zealand NZISM 3.6 1.2.13.C.01 1.2.13.C.02
APAC Philippines 25 29
APAC Singapore 24 26
APAC Singapore MAS TRM 2021 5.6.1 5.6.2 5.6.3 11.2.8
APAC South Korea 3 29
APAC Taiwan 21
Americas (12)

Capability Maturity Model

Level 0 — Not Performed

There is no evidence of a capability to implement security functions as a layered structure minimizing interactions between layers of the design and avoiding any dependence by lower layers on the functionality or correctness of higher layers.

Level 1 — Performed Informally

C|P-CMM1 is N/A, since a structured process is required to implement security functions as a layered structure minimizing interactions between layers of the design and avoiding any dependence by lower layers on the functionality or correctness of higher layers.

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.
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

See C|P-CMM4. There are no defined C|P-CMM5 criteria, since it is reasonable to assume a continuously-improving process is not necessary to implement security functions as a layered structure minimizing interactions between layers of the design and avoiding any dependence by lower layers on the functionality or correctness of higher layers.

Assessment Objectives

  1. SEA-03_A01 security functions are implemented as a layered structure, minimizing interactions between layers of the design and avoiding any dependence by lower layers on the functionality or correctness of higher layers.
  2. SEA-03_A02 the cybersecurity / data privacy architecture for the system is designed using a defense-in-depth approach that allocates controls to locations and architectural layers.
  3. SEA-03_A03 the cybersecurity / data privacy architecture for the system is designed using a defense-in-depth approach that ensures the allocated controls operate in a coordinated and mutually reinforcing manner.
  4. SEA-03_A04 controls to be allocated are defined.
  5. SEA-03_A05 locations and architectural layers are defined.

Evidence Requirements

E-TDA-04 Design and Development Plan (DDP)

Documented evidence of an engineering method to control the design process and govern the lifecycle of the product/service.

Technology Design & Acquisition
E-TDA-09 Security Architecture View

Documented evidence that identifies security-relevant system elements and their interfaces: • Define security context, domains, boundaries, and external interfaces of the system; • Align the architecture with (a) the system security objectives and requirements, (b) security design characteristics; and • Establish traceability of architecture elements to user and system security requirements.

Technology Design & Acquisition

Technology Recommendations

Micro/Small

  • Defined "secure engineering principles" (e.g., alignment with NIST 800-160)
  • Defense-in-depth (DiD) architecture

Small

  • Defined "secure engineering principles" (e.g., alignment with NIST 800-160)
  • Defense-in-depth (DiD) architecture

Medium

  • Defined "secure engineering principles" (e.g., alignment with NIST 800-160)
  • Defense-in-depth (DiD) architecture
  • Enterprise architecture committee

Large

  • Defined "secure engineering principles" (e.g., alignment with NIST 800-160)
  • Defense-in-depth (DiD) architecture
  • Enterprise architecture committee

Enterprise

  • Defined "secure engineering principles" (e.g., alignment with NIST 800-160)
  • Defense-in-depth (DiD) architecture
  • Enterprise architecture committee

The Secure Controls Framework (SCF) is maintained by SCF Council. Use of SCF content is subject to the SCF Terms & Conditions.

Manage this control in SCF Connect

Track implementation status, collect evidence, and map controls to your compliance frameworks automatically.