TDA-04.1: Functional Properties
Mechanisms exist to require software developers to provide information describing the functional properties of the security controls to be utilized within Technology Assets, Applications and/or Services (TAAS) in sufficient detail to permit analysis and testing of the controls.
Control Question: Does the organization require software developers to provide information describing the functional properties of the security controls to be utilized within Technology Assets, Applications and/or Services (TAAS) in sufficient detail to permit analysis and testing of the controls?
General (16)
| Framework | Mapping Values |
|---|---|
| GovRAMP Moderate | SA-04(01) |
| GovRAMP High | SA-04(01) SA-04(02) |
| NIST 800-53 R4 | SA-4(1) SA-4(2) |
| NIST 800-53 R4 (moderate) | SA-4(1) SA-4(2) |
| NIST 800-53 R4 (high) | SA-4(1) SA-4(2) |
| NIST 800-53 R5 (source) | SA-4(1) SA-4(2) |
| NIST 800-53B R5 (moderate) (source) | SA-4(1) SA-4(2) |
| NIST 800-53B R5 (high) (source) | SA-4(1) SA-4(2) |
| NIST 800-82 R3 MODERATE OT Overlay | SA-4(1) SA-4(2) |
| NIST 800-82 R3 HIGH OT Overlay | SA-4(1) SA-4(2) |
| NIST 800-161 R1 | CM-8(10) |
| NIST 800-171 R2 (source) | NFO-SA-4(1) NFO-SA-4(2) |
| NIST 800-218 | PO.3.3 RV.1.1 |
| OWASP Top 10 2021 | A01:2021 A02:2021 A03:2021 A04:2021 A05:2021 A06:2021 A07:2021 A08:2021 A09:2021 A10:2021 |
| UL 2900-1 2017 | 4.1 5.1 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 |
| SCF CORE Mergers, Acquisitions & Divestitures (MA&D) | TDA-04.1 |
US (12)
| Framework | Mapping Values |
|---|---|
| US CMS MARS-E 2.0 | SA-4(1) SA-4(2) |
| US DHS CISA SSDAF | 1.d |
| US EO 14028 | 4e(i)(D) |
| US FedRAMP R4 | SA-4(1) SA-4(2) |
| US FedRAMP R4 (moderate) | SA-4(1) SA-4(2) |
| US FedRAMP R4 (high) | SA-4(1) SA-4(2) |
| US FedRAMP R5 (source) | SA-4(1) SA-4(2) |
| US FedRAMP R5 (moderate) (source) | SA-4(1) SA-4(2) |
| US FedRAMP R5 (high) (source) | SA-4(1) SA-4(2) |
| US IRS 1075 | SA-4(1) SA-4(2) |
| US - TX TX-RAMP Level 1 | SA-4(1) |
| US - TX TX-RAMP Level 2 | SA-4(1) SA-4(2) |
EMEA (3)
| Framework | Mapping Values |
|---|---|
| EMEA EU EBA GL/2019/04 | 3.6.2(69) |
| EMEA Germany C5 2020 | DEV-02 |
| EMEA Israel CDMO 1.0 | 17.6 17.10 |
APAC (1)
| Framework | Mapping Values |
|---|---|
| APAC Australia ISM June 2024 | ISM-1798 |
Capability Maturity Model
Level 0 — Not Performed
There is no evidence of a capability to require software developers to provide information describing the functional properties of the security controls to be utilized within Technology Assets, Applications and/or Services (TAAS) in sufficient detail to permit analysis and testing of the controls.
Level 1 — Performed Informally
Technology Development & Acquisition (TDA) 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 govern technology development and acquisition.
- Secure development practices loosely conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).
- IT personnel work with data/process owners to help ensure secure practices are implemented throughout the System Development Lifecycle (SDLC) for all high-value projects.
Level 2 — Planned & Tracked
Technology Development & Acquisition (TDA) 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:
- Development and acquisition management is decentralized (e.g., a localized/regionalized function) and uses non-standardized methods to implement secure, resilient and compliant practices.
- IT/cybersecurity personnel identify cybersecurity and data protection controls to address applicable statutory, regulatory and contractual requirements for technology development and acquisition management.
- IT/cybersecurity personnel implement secure practices to protect the confidentiality, integrity, availability and safety of the organization's technology assets, data and network(s).
- Secure development practices mostly conform to industry-recognized standards for secure engineering (e.g., OWASP, NIST SP 800-218, NIST SP 800-160, etc.).
- Procurement practices require third-party developers of Technology Assets, Applications and/or Services (TAAS) to follow secure engineering practices.
- A Project Management Office (PMO), or project management function, enables the implementation of cybersecurity and data privacy-related resource planning controls across the System Development Lifecycle (SDLC) for all high-value projects.
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
Technology Development & Acquisition (TDA) 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 require software developers to provide information describing the functional properties of the security controls to be utilized within Technology Assets, Applications and/or Services (TAAS) in sufficient detail to permit analysis and testing of the controls.
Assessment Objectives
- TDA-04.1_A01 the developer of the system, system component or system service is required to provide a description of the functional properties of the controls to be implemented.
- TDA-04.1_A02 organization-defined criteria for security-relevant information pertaining to external system interfaces, high-level design, low-level design, source code or hardware schematics and design and implementation information are documented in a System Security & Privacy Plan (SSPP), or similar document.
- TDA-04.1_A03 design and implementation information is defined.
- TDA-04.1_A04 level of detail is defined.
- TDA-04.1_A05 the developer of the system, system component or system service is required to provide design and implementation information for the controls that includes using at level of detail.
Evidence Requirements
- E-CPL-06 Manufacturer Disclosure Statement for Medical Device Security (MDS2)
-
Documented Manufacturer Disclosure Statement for Medical Device Security (MDS2) that communicates information about medical device cybersecurity & data privacy characteristics to current device owners and potential buyers. [note MDS2 is specific to medical device manufacturers]
Compliance - E-TDA-06 Multi Patient Harm View (MPHV)
-
Documented evidence of a description of a Multi Patient Harm View (MPHV) that explains how the device / system defends against and/or responds to attacks with the potential to harm multiple patients. [note MPHV is specific to medical device manufacturers]
Technology Design & Acquisition - E-TDA-10 Security Use Case View (SUCV)
-
Documented evidence of diagrams, with explanatory text, describing various security scenarios in each of the operational and clinical functionality states of the system and how the system addresses each scenario architecturally. [note SUCV is specific to medical device manufacturers]
Technology Design & Acquisition - E-TDA-15 Updateability / Patchability View
-
Documented evidence of a description of the end-to-end process permitting software updates and patches to be deployed to the device/service.
Technology Design & Acquisition
Technology Recommendations
Micro/Small
- Cybersecurity Supply Chain Risk Management (C-SCRM) program
- Product / project management
Small
- Cybersecurity Supply Chain Risk Management (C-SCRM) program
- Product / project management
Medium
- Cybersecurity Supply Chain Risk Management (C-SCRM) program
- Product / project management
Large
- Cybersecurity Supply Chain Risk Management (C-SCRM) program
- Product / project management
Enterprise
- Cybersecurity Supply Chain Risk Management (C-SCRM) program
- Product / project management