last sync: 2024-Oct-11 17:51:27 UTC

Require developers to describe accurate security functionality | Regulatory Compliance - Documentation

Azure BuiltIn Policy definition

Source Azure Portal
Display name Require developers to describe accurate security functionality
Id 3e37c891-840c-3eb4-78d2-e2e0bb5063e0
Version 1.1.0
Details on versioning
Versioning Versions supported for Versioning: 1
1.1.0
Built-in Versioning [Preview]
Category Regulatory Compliance
Microsoft Learn
Description CMA_C1613 - Require developers to describe accurate security functionality
Additional metadata Name/Id: CMA_C1613 / CMA_C1613
Category: Documentation
Title: Require developers to describe accurate security functionality
Ownership: Customer
Description: The customer is responsible for requiring the developer of customer-deployed resources to produce a design specification and security architecture that accurately and completely describes the required security functionality, and the allocation of security controls among logical resources.
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 10 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
mp.sw.1 IT Aplications development mp.sw.1 IT Aplications development 404 not found n/a n/a 51
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
op.pl.2 Security Architecture op.pl.2 Security Architecture 404 not found n/a n/a 65
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
Spain ENS 175daf90-21e1-4fec-b745-7b4c909aa94c 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 3e37c891-840c-3eb4-78d2-e2e0bb5063e0
JSON compare
compare mode: version left: version right:
JSON
api-version=2021-06-01
EPAC