TDA-14.2: Hardware Integrity Verification
Mechanisms exist to require developers of Technology Assets, Applications and/or Services (TAAS) to enable integrity verification of hardware components.
Control Question: Does the organization require developers of Technology Assets, Applications and/or Services (TAAS) to enable integrity verification of hardware components?
General (8)
| Framework | Mapping Values |
|---|---|
| NIST 800-53 R4 | SA-10(3) |
| NIST 800-53 R5 (source) | SA-10(3) |
| NIST 800-53 R5 (NOC) (source) | SA-10(3) |
| NIST 800-172 | 3.14.7e |
| NIST CSF 2.0 (source) | ID.RA-09 |
| SCF CORE ESP Level 1 Foundational | TDA-14.2 |
| SCF CORE ESP Level 2 Critical Infrastructure | TDA-14.2 |
| SCF CORE ESP Level 3 Advanced Threats | TDA-14.2 |
US (1)
| Framework | Mapping Values |
|---|---|
| US IRS 1075 | SA-10(3) |
Capability Maturity Model
Level 0 — Not Performed
There is no evidence of a capability to require developers of Technology Assets, Applications and/or Services (TAAS) to enable integrity verification of hardware components.
Level 1 — Performed Informally
C|P-CMM1 is N/A, since a structured process is required to require developers of Technology Assets, Applications and/or Services (TAAS) to enable integrity verification of hardware components.
Level 2 — Planned & Tracked
C|P-CMM2 is N/A, since a well-defined process is required to require developers of Technology Assets, Applications and/or Services (TAAS) to enable integrity verification of hardware components.
Level 3 — Well Defined
Technology Development & Acquisition (TDA) 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: o Provides governance oversight for the implementation of applicable statutory, regulatory and contractual cybersecurity and data protection controls to protect the confidentiality, integrity, availability and safety of the organization's applications, systems, services and data for technology development and acquisition. o Ensures the Information Assurance Program (IAP) evaluates applicable cybersecurity and data protection controls as part of “business as usual” pre-production testing. o Operates the Cybersecurity Supply Chain Risk Management (C-SCRM) program to identify and mitigate supply chain-related risks and threats.
- Secure development practices conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).
- A procurement team, or similar function, ensures that third party development and/ or acquisitions meet, or exceed, the organization's business, cybersecurity and data privacy requirements to have secure and resilient systems, applications, services and processes.
- A Software Assurance Maturity Model (SAMM) governs a secure development lifecycle for the development of systems, applications and services.
- Administrative processes exist and technologies are configured to implement secure configuration settings by default to reduce the likelihood of software being deployed with weak security settings, putting the asset at a greater risk of compromise.
- An IT Asset Management (ITAM) function, or similar function, categorizes devices according to the data the asset stores, transmits and/ or processes and applies the appropriate technology controls to protect the asset and data.
- A formal Change Management (CM) program help to ensure that no unauthorized changes are made, all changes are documented, services are not disrupted and resources are used efficiently.
- A Governance, Risk & Compliance (GRC) function, or similar function;
- A Project Management Office (PMO), or project management function, enables IAP pre-production testing of cybersecurity and data protection controls as part of the organization's established project management processes.
Level 4 — Quantitatively Controlled
See C|P-CMM3. There are no defined C|P-CMM4 criteria, since it is reasonable to assume a quantitatively-controlled process is not necessary to require developers of Technology Assets, Applications and/or Services (TAAS) to enable integrity verification of hardware components.
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 require developers of Technology Assets, Applications and/or Services (TAAS) to enable integrity verification of hardware components.
Assessment Objectives
- TDA-14.2_A01 the developer of the system, system component or system service is required to enable integrity verification of hardware components.
- TDA-14.2_A02 the integrity of hardware components is verified.
- TDA-14.2_A03 independence criteria to be satisfied by an independent agent are defined.
- TDA-14.2_A04 an independent agent is required to satisfy organization-defined independence criteria to verify the correct implementation of the developer security assessment plan and the evidence produced during testing and evaluation.
- TDA-14.2_A05 an independent agent is required to satisfy organization-defined independence criteria to verify the correct implementation of the developer privacy assessment plan and the evidence produced during testing and evaluation.
- TDA-14.2_A06 the independent agent is provided with sufficient information to complete the verification process or granted the authority to obtain such information.
Evidence Requirements
- E-TDA-01 Secure Software Development Principles (SSDP)
-
Documented evidence of a Secure Software Development Principles (SSDP). This is program-level documentation in the form of a runbook, playbook or a similar format provides guidance on organizational practices that support existing policies and standards.
Technology Design & Acquisition - E-TDA-02 Secure Engineering & Data Privacy (SEDP)
-
Documented evidence of a Secure Engineering & Data Privacy (SEDP) program. This is program-level documentation in the form of a runbook, playbook or a similar format provides guidance on organizational practices that support existing policies and standards.
Technology Design & Acquisition - 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-08 Secure Engineering Principles (SEP)
-
Documented evidence of defined secure engineering principles used to ensure Sensitivity, Integrity, Availability & Safety (CIAS) concerns are properly addressed in the design and implementation of systems, applications and services.
Technology Design & Acquisition