compliance controls are associated with this Policy definition 'Require developers to describe accurate security functionality' (3e37c891-840c-3eb4-78d2-e2e0bb5063e0)
| Control Domain |
Control |
Name |
MetadataId |
Category |
Title |
Owner |
Requirements |
Description |
Info |
Policy# |
| FedRAMP_High_R4 |
SA-17 |
FedRAMP_High_R4_SA-17 |
FedRAMP High SA-17 |
System And Services Acquisition |
Developer Security Architecture And Design |
Shared |
n/a |
The organization requires the developer of the information system, system component, or information system service to produce a design specification and security architecture that:
a. Is consistent with and supportive of the organization’s security architecture which is established within and is an integrated part of the organization’s enterprise architecture;
b. Accurately and completely describes the required security functionality, and the allocation of security controls among physical and logical components; and
c. Expresses how individual security functions, mechanisms, and services work together to provide required security capabilities and a unified approach to protection.
Supplemental Guidance: This control is primarily directed at external developers, although it could also be used for internal (in-house) development. In contrast, PL-8 is primarily directed at internal developers to help ensure that organizations develop an information security architecture and such security architecture is integrated or tightly coupled to the enterprise architecture. This distinction is important if/when organizations outsource the development of information systems, information system components, or information system services to external entities, and there is a requirement to demonstrate consistency with the organization’s enterprise architecture and information security architecture. Related controls: PL-8, PM-7, SA-3, SA-8.
References: None. |
link |
3 |
| hipaa |
1785.10a1Organizational.8-10.a |
hipaa-1785.10a1Organizational.8-10.a |
1785.10a1Organizational.8-10.a |
17 Risk Management |
1785.10a1Organizational.8-10.a 10.01 Security Requirements of Information Systems |
Shared |
n/a |
Where additional functionality is supplied and causes a security risk, the functionality is disabled or mitigated through application of additional controls. |
|
5 |
| hipaa |
1797.10a3Organizational.1-10.a |
hipaa-1797.10a3Organizational.1-10.a |
1797.10a3Organizational.1-10.a |
17 Risk Management |
1797.10a3Organizational.1-10.a 10.01 Security Requirements of Information Systems |
Shared |
n/a |
The organization develops enterprise architecture with consideration for information security and the resulting risk to the organization's operations, assets, and individuals, as well as other organizations. |
|
5 |
| hipaa |
1799.10a3Organizational.34-10.a |
hipaa-1799.10a3Organizational.34-10.a |
1799.10a3Organizational.34-10.a |
17 Risk Management |
1799.10a3Organizational.34-10.a 10.01 Security Requirements of Information Systems |
Shared |
n/a |
The organization reviews and updates (as necessary) the information security architecture whenever changes are made to the enterprise architecture, and ensures that planned information security architecture changes are reflected in the security plan and organizational procurements and acquisitions. |
|
6 |
| ISO27001-2013 |
A.14.2.1 |
ISO27001-2013_A.14.2.1 |
ISO 27001:2013 A.14.2.1 |
System Acquisition, Development And Maintenance |
Secure development policy |
Shared |
n/a |
Rules for the development of software and systems shall be established and applied to developments within the organization. |
link |
7 |
| ISO27001-2013 |
A.14.2.5 |
ISO27001-2013_A.14.2.5 |
ISO 27001:2013 A.14.2.5 |
System Acquisition, Development And Maintenance |
Secure system engineering principles |
Shared |
n/a |
Principles for engineering secure systems shall be established, documented, maintained and applied to any information system implementation efforts. |
link |
5 |
| NIST_SP_800-53_R4 |
SA-17 |
NIST_SP_800-53_R4_SA-17 |
NIST SP 800-53 Rev. 4 SA-17 |
System And Services Acquisition |
Developer Security Architecture And Design |
Shared |
n/a |
The organization requires the developer of the information system, system component, or information system service to produce a design specification and security architecture that:
a. Is consistent with and supportive of the organization’s security architecture which is established within and is an integrated part of the organization’s enterprise architecture;
b. Accurately and completely describes the required security functionality, and the allocation of security controls among physical and logical components; and
c. Expresses how individual security functions, mechanisms, and services work together to provide required security capabilities and a unified approach to protection.
Supplemental Guidance: This control is primarily directed at external developers, although it could also be used for internal (in-house) development. In contrast, PL-8 is primarily directed at internal developers to help ensure that organizations develop an information security architecture and such security architecture is integrated or tightly coupled to the enterprise architecture. This distinction is important if/when organizations outsource the development of information systems, information system components, or information system services to external entities, and there is a requirement to demonstrate consistency with the organization’s enterprise architecture and information security architecture. Related controls: PL-8, PM-7, SA-3, SA-8.
References: None. |
link |
3 |
| NIST_SP_800-53_R5 |
SA-17 |
NIST_SP_800-53_R5_SA-17 |
NIST SP 800-53 Rev. 5 SA-17 |
System and Services Acquisition |
Developer Security and Privacy Architecture and Design |
Shared |
n/a |
Require the developer of the system, system component, or system service to produce a design specification and security and privacy architecture that:
a. Is consistent with the organization???s security and privacy architecture that is an integral part the organization???s enterprise architecture;
b. Accurately and completely describes the required security and privacy functionality, and the allocation of controls among physical and logical components; and
c. Expresses how individual security and privacy functions, mechanisms, and services work together to provide required security and privacy capabilities and a unified approach to protection. |
link |
3 |