| Source | Azure Portal | ||
| Display name | Microsoft Managed Control 1200 - Security Impact Analysis | ||
| Id | e98fe9d7-2ed3-44f8-93b7-24dca69783ff | ||
| Version | 1.0.0 Details on versioning |
||
| Category | Regulatory Compliance Microsoft Learn |
||
| Description | Microsoft implements this Configuration Management control | ||
| Additional metadata |
Name/Id: ACF1200 / Microsoft Managed Control 1200 Category: Configuration Management Title: Security Impact Analysis Ownership: Customer, Microsoft Description: The organization analyzes changes to the information system to determine potential security impacts prior to change implementation. Requirements: As part of the Security Development Lifecycle (SDL) process, Azure analyzes software and hardware changes to determine potential security impacts prior to change implementation. Changes are required to be documented, tested, and approved by appropriate service team personnel. For all asset types, changes are analyzed as part of the standard change management process, both prior to and after implementation, to verify what was modified resulted in expected output. The SDL process is followed for all engineering and development projects. The SDL process consists of five phases: Requirements, Design, Implementation, Verification and Release. The Requirements phase considers the foundational security, privacy, and cost requirements for a given product. The Design phase is the creation of the plan to implement the product to meet the defined requirements, including risk and threat model analysis. The implementation phase is when security documentation is created for the product, allowing users and customers to make informed decisions on how to deploy it, as well as initial testing to remove any security or privacy issues. The Verification phase is when the implementation is reviewed to ensure that the security and privacy tenets defined in the Requirements phase, and where full product testing takes place. Finally, the Release phase is the creation of incident planning, should any issues regarding the product arise once it is available. Each service team tests proposed system changes prior to deployment, either in a separate test environment, or by removing a server from production, making changes, testing, and returning the server to production upon successful completion. Azure implements safe deployment known as Safe Deployment Practices (SDP), which includes testing in canary regions and rolling out to increasing percentages of the applicable environment before considering the rollout complete. Azure assets have a set of runners which leverage information captured by Geneva Monitoring to run automated tests for checking the health of the components. Runners are configured to automatically generate alerts if any component health discrepancies are identified. This ensures recently deployed software should be propagated to more assets or rolled back as health indicators dictate. If there are any issues during the rollout, the deployment is halted to investigate. |
||
| Mode | Indexed | ||
| Type | Static | ||
| Preview | False | ||
| Deprecated | False | ||
| Effect | Fixed audit |
||
| RBAC role(s) | none | ||
| Rule aliases | none | ||
| Rule resource types | IF (2) Microsoft.Resources/subscriptions Microsoft.Resources/subscriptions/resourceGroups |
||
| Compliance | Not a Compliance control | ||
| Initiatives usage | none | ||
| History | none | ||
| JSON compare | n/a | ||
| JSON |
|