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 |