last sync: 2024-May-24 18:03:04 UTC

Require developers to produce evidence of security assessment plan execution | Regulatory Compliance - Documentation

Azure BuiltIn Policy definition

Source Azure Portal
Display name Require developers to produce evidence of security assessment plan execution
Id f8a63511-66f1-503f-196d-d6217ee0823a
Version 1.1.0
Details on versioning
Category Regulatory Compliance
Microsoft Learn
Description CMA_C1602 - Require developers to produce evidence of security assessment plan execution
Additional metadata Name/Id: CMA_C1602 / CMA_C1602
Category: Documentation
Title: Require developers to produce evidence of security assessment plan execution
Ownership: Customer
Description: The customer is responsible for requiring the developer of customer-deployed resources to produce evidence of security assessment plan execution and the results of testing/evaluation.
Requirements: The customer is responsible for implementing this recommendation.
Mode All
Type BuiltIn
Preview False
Deprecated False
Effect Default
Manual
Allowed
Manual, Disabled
RBAC role(s) none
Rule aliases none
Rule resource types IF (1)
Microsoft.Resources/subscriptions
Compliance
The following 13 compliance controls are associated with this Policy definition 'Require developers to produce evidence of security assessment plan execution' (f8a63511-66f1-503f-196d-d6217ee0823a)
Control Domain Control Name MetadataId Category Title Owner Requirements Description Info Policy#
FedRAMP_High_R4 SA-11 FedRAMP_High_R4_SA-11 FedRAMP High SA-11 System And Services Acquisition Developer Security Testing And Evaluation Shared n/a The organization requires the developer of the information system, system component, or information system service to: a. Create and implement a security assessment plan; b. Perform [Selection (one or more): unit; integration; system; regression] testing/evaluation at [Assignment: organization-defined depth and coverage]; c. Produce evidence of the execution of the security assessment plan and the results of the security testing/evaluation; d. Implement a verifiable flaw remediation process; and e. Correct flaws identified during security testing/evaluation. Supplemental Guidance: Developmental security testing/evaluation occurs at all post‐design phases of the system development life cycle. Such testing/evaluation confirms that the required security controls are implemented correctly, operating as intended, enforcing the desired security policy, and meeting established security requirements. Security properties of information systems may be affected by the interconnection of system components or changes to those components. These interconnections or changes (e.g., upgrading or replacing applications and operating systems) may adversely affect previously implemented security controls. This control provides additional types of security testing/evaluation that developers can conduct to reduce or eliminate potential flaws. Testing custom software applications may require approaches such as static analysis, dynamic analysis, binary analysis, or a hybrid of the three approaches. Developers can employ these analysis approaches in a variety of tools (e.g., web-based application scanners, static analysis tools, binary analyzers) and in source code reviews. Security assessment plans provide the specific activities that developers plan to carry out including the types of analyses, testing, evaluation, and reviews of software and firmware components, the degree of rigor to be applied, and the types of artifacts produced during those processes. The depth of security testing/evaluation refers to the rigor and level of detail associated with the assessment process (e.g., black box, gray box, or white box testing). The coverage of security testing/evaluation refers to the scope (i.e., number and type) of the artifacts included in the assessment process. Contracts specify the acceptance criteria for security assessment plans, flaw remediation processes, and the evidence that the plans/processes have been diligently applied. Methods for reviewing and protecting assessment plans, evidence, and documentation are commensurate with the security category or classification level of the information system. Contracts may specify documentation protection requirements. Related controls: CA-2, CM-4, SA-3, SA-4, SA-5, SI-2. References: ISO/IEC 15408; NIST Special Publication 800-53A; Web: http://nvd.nist.gov, http://cwe.mitre.org, http://cve.mitre.org, http://capec.mitre.org. link 3
FedRAMP_Moderate_R4 SA-11 FedRAMP_Moderate_R4_SA-11 FedRAMP Moderate SA-11 System And Services Acquisition Developer Security Testing And Evaluation Shared n/a The organization requires the developer of the information system, system component, or information system service to: a. Create and implement a security assessment plan; b. Perform [Selection (one or more): unit; integration; system; regression] testing/evaluation at [Assignment: organization-defined depth and coverage]; c. Produce evidence of the execution of the security assessment plan and the results of the security testing/evaluation; d. Implement a verifiable flaw remediation process; and e. Correct flaws identified during security testing/evaluation. Supplemental Guidance: Developmental security testing/evaluation occurs at all post‐design phases of the system development life cycle. Such testing/evaluation confirms that the required security controls are implemented correctly, operating as intended, enforcing the desired security policy, and meeting established security requirements. Security properties of information systems may be affected by the interconnection of system components or changes to those components. These interconnections or changes (e.g., upgrading or replacing applications and operating systems) may adversely affect previously implemented security controls. This control provides additional types of security testing/evaluation that developers can conduct to reduce or eliminate potential flaws. Testing custom software applications may require approaches such as static analysis, dynamic analysis, binary analysis, or a hybrid of the three approaches. Developers can employ these analysis approaches in a variety of tools (e.g., web-based application scanners, static analysis tools, binary analyzers) and in source code reviews. Security assessment plans provide the specific activities that developers plan to carry out including the types of analyses, testing, evaluation, and reviews of software and firmware components, the degree of rigor to be applied, and the types of artifacts produced during those processes. The depth of security testing/evaluation refers to the rigor and level of detail associated with the assessment process (e.g., black box, gray box, or white box testing). The coverage of security testing/evaluation refers to the scope (i.e., number and type) of the artifacts included in the assessment process. Contracts specify the acceptance criteria for security assessment plans, flaw remediation processes, and the evidence that the plans/processes have been diligently applied. Methods for reviewing and protecting assessment plans, evidence, and documentation are commensurate with the security category or classification level of the information system. Contracts may specify documentation protection requirements. Related controls: CA-2, CM-4, SA-3, SA-4, SA-5, SI-2. References: ISO/IEC 15408; NIST Special Publication 800-53A; Web: http://nvd.nist.gov, http://cwe.mitre.org, http://cve.mitre.org, http://capec.mitre.org. link 3
hipaa 0640.10k2Organizational.1012-10.k hipaa-0640.10k2Organizational.1012-10.k 0640.10k2Organizational.1012-10.k 06 Configuration Management 0640.10k2Organizational.1012-10.k 10.05 Security In Development and Support Processes Shared n/a Where development is outsourced, change control procedures to address security are included in the contract(s) and specifically require the developer to track security flaws and flaw resolution within the system, component, or service and report findings to organization-defined personnel or roles. 22
hipaa 1417.10l2Organizational.1-10.l hipaa-1417.10l2Organizational.1-10.l 1417.10l2Organizational.1-10.l 14 Third Party Assurance 1417.10l2Organizational.1-10.l 10.05 Security In Development and Support Processes Shared n/a Where software development is outsourced, the development process is monitored by the organization and includes independent security and code reviews. 12
hipaa 1794.10a2Organizational.12-10.a hipaa-1794.10a2Organizational.12-10.a 1794.10a2Organizational.12-10.a 17 Risk Management 1794.10a2Organizational.12-10.a 10.01 Security Requirements of Information Systems Shared n/a When developing software or systems the organization performs thorough testing and verification during the development process. 1
hipaa 1795.10a2Organizational.13-10.a hipaa-1795.10a2Organizational.13-10.a 1795.10a2Organizational.13-10.a 17 Risk Management 1795.10a2Organizational.13-10.a 10.01 Security Requirements of Information Systems Shared n/a Independent acceptance testing proportional to the importance and nature of the system is performed both for in-house and for outsourced development to ensure the system works as expected and only as expected. 5
ISO27001-2013 A.14.2.7 ISO27001-2013_A.14.2.7 ISO 27001:2013 A.14.2.7 System Acquisition, Development And Maintenance Outsourced development Shared n/a The organization shall supervise and monitor the activity of outsourced system development. link 28
ISO27001-2013 A.14.2.8 ISO27001-2013_A.14.2.8 ISO 27001:2013 A.14.2.8 System Acquisition, Development And Maintenance System security testing Shared n/a Testing of security functionality shall be carried out during development. link 8
mp.sw.1 IT Aplications development mp.sw.1 IT Aplications development 404 not found n/a n/a 51
mp.sw.2 Acceptance and commissioning mp.sw.2 Acceptance and commissioning 404 not found n/a n/a 60
NIST_SP_800-53_R4 SA-11 NIST_SP_800-53_R4_SA-11 NIST SP 800-53 Rev. 4 SA-11 System And Services Acquisition Developer Security Testing And Evaluation Shared n/a The organization requires the developer of the information system, system component, or information system service to: a. Create and implement a security assessment plan; b. Perform [Selection (one or more): unit; integration; system; regression] testing/evaluation at [Assignment: organization-defined depth and coverage]; c. Produce evidence of the execution of the security assessment plan and the results of the security testing/evaluation; d. Implement a verifiable flaw remediation process; and e. Correct flaws identified during security testing/evaluation. Supplemental Guidance: Developmental security testing/evaluation occurs at all post‐design phases of the system development life cycle. Such testing/evaluation confirms that the required security controls are implemented correctly, operating as intended, enforcing the desired security policy, and meeting established security requirements. Security properties of information systems may be affected by the interconnection of system components or changes to those components. These interconnections or changes (e.g., upgrading or replacing applications and operating systems) may adversely affect previously implemented security controls. This control provides additional types of security testing/evaluation that developers can conduct to reduce or eliminate potential flaws. Testing custom software applications may require approaches such as static analysis, dynamic analysis, binary analysis, or a hybrid of the three approaches. Developers can employ these analysis approaches in a variety of tools (e.g., web-based application scanners, static analysis tools, binary analyzers) and in source code reviews. Security assessment plans provide the specific activities that developers plan to carry out including the types of analyses, testing, evaluation, and reviews of software and firmware components, the degree of rigor to be applied, and the types of artifacts produced during those processes. The depth of security testing/evaluation refers to the rigor and level of detail associated with the assessment process (e.g., black box, gray box, or white box testing). The coverage of security testing/evaluation refers to the scope (i.e., number and type) of the artifacts included in the assessment process. Contracts specify the acceptance criteria for security assessment plans, flaw remediation processes, and the evidence that the plans/processes have been diligently applied. Methods for reviewing and protecting assessment plans, evidence, and documentation are commensurate with the security category or classification level of the information system. Contracts may specify documentation protection requirements. Related controls: CA-2, CM-4, SA-3, SA-4, SA-5, SI-2. References: ISO/IEC 15408; NIST Special Publication 800-53A; Web: http://nvd.nist.gov, http://cwe.mitre.org, http://cve.mitre.org, http://capec.mitre.org. link 3
NIST_SP_800-53_R5 SA-11 NIST_SP_800-53_R5_SA-11 NIST SP 800-53 Rev. 5 SA-11 System and Services Acquisition Developer Testing and Evaluation Shared n/a Require the developer of the system, system component, or system service, at all post-design stages of the system development life cycle, to: a. Develop and implement a plan for ongoing security and privacy control assessments; b. Perform [Selection (OneOrMore): unit;integration;system;regression] testing/evaluation [Assignment: organization-defined frequency] at [Assignment: organization-defined depth and coverage]; c. Produce evidence of the execution of the assessment plan and the results of the testing and evaluation; d. Implement a verifiable flaw remediation process; and e. Correct flaws identified during testing and evaluation. link 3
SWIFT_CSCF_v2022 8.5 SWIFT_CSCF_v2022_8.5 SWIFT CSCF v2022 8.5 8. Set and Monitor Performance Ensure early availability of SWIFTNet releases and of the FIN standards for proper testing by the customer before going live. Shared n/a Ensure early availability of SWIFTNet releases and of the FIN standards for proper testing by the customer before going live. link 11
Initiatives usage
Initiative DisplayName Initiative Id Initiative Category State Type
FedRAMP High d5264498-16f4-418a-b659-fa7ef418175f Regulatory Compliance GA BuiltIn
FedRAMP Moderate e95f5a9f-57ad-4d03-bb0b-b1d16db93693 Regulatory Compliance GA BuiltIn
HITRUST/HIPAA a169a624-5599-4385-a696-c8d643089fab Regulatory Compliance GA BuiltIn
ISO 27001:2013 89c6cddc-1c73-4ac1-b19c-54d1a15a42f2 Regulatory Compliance GA BuiltIn
NIST SP 800-53 Rev. 4 cf25b9c1-bd23-4eb6-bd2c-f4f3ac644a5f Regulatory Compliance GA BuiltIn
NIST SP 800-53 Rev. 5 179d1daa-458f-4e47-8086-2a68d0d6c38f Regulatory Compliance GA BuiltIn
Spain ENS 175daf90-21e1-4fec-b745-7b4c909aa94c Regulatory Compliance GA BuiltIn
SWIFT CSP-CSCF v2022 7bc7cd6c-4114-ff31-3cac-59be3157596d Regulatory Compliance GA BuiltIn
History
Date/Time (UTC ymd) (i) Change type Change detail
2022-09-27 16:35:32 change Minor (1.0.0 > 1.1.0)
2022-09-19 17:41:40 add f8a63511-66f1-503f-196d-d6217ee0823a
JSON compare
compare mode: version left: version right:
JSON
api-version=2021-06-01
EPAC