last sync: 2024-Apr-19 17:43:58 UTC

Require developers to build security architecture | Regulatory Compliance - Documentation

Azure BuiltIn Policy definition

Source Azure Portal
Display name Require developers to build security architecture
Id f131c8c5-a54a-4888-1efc-158928924bc1
Version 1.1.0
Details on versioning
Category Regulatory Compliance
Microsoft Learn
Description CMA_C1612 - Require developers to build security architecture
Additional metadata Name/Id: CMA_C1612 / CMA_C1612
Category: Documentation
Title: Require developers to build security architecture
Ownership: Customer
Description: The customer is responsible for requiring the developer of customer-deployed resources to produce a design specification and security architecture that is consistent with and supportive of the customer's security architecture.
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 9 compliance controls are associated with this Policy definition 'Require developers to build security architecture' (f131c8c5-a54a-4888-1efc-158928924bc1)
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 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 1798.10a3Organizational.2-10.a hipaa-1798.10a3Organizational.2-10.a 1798.10a3Organizational.2-10.a 17 Risk Management 1798.10a3Organizational.2-10.a 10.01 Security Requirements of Information Systems Shared n/a The organization has developed an information security architecture for the information system. 4
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
SWIFT_CSCF_v2022 7.3A SWIFT_CSCF_v2022_7.3A SWIFT CSCF v2022 7.3A 7. Plan for Incident Response and Information Sharing Validate the operational security configuration and identify security gaps by performing penetration testing. Shared n/a Application, host, and network penetration testing is conducted towards the secure zone and the operator PCs or, when used, the jump server. link 2
Initiatives usage
Initiative DisplayName Initiative Id Initiative Category State Type
FedRAMP High d5264498-16f4-418a-b659-fa7ef418175f 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
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 f131c8c5-a54a-4888-1efc-158928924bc1
JSON compare
compare mode: version left: version right:
JSON
api-version=2021-06-01
EPAC