| Source | Azure Portal | ||
| Display name | Microsoft Managed Control 1564 - System Development Life Cycle | ||
| Id | 157f0ef9-143f-496d-b8f9-f8c8eeaad801 | ||
| Version | 1.0.0 Details on versioning |
||
| Versioning |
Versions supported for Versioning: 0 Built-in Versioning [Preview] |
||
| Category | Regulatory Compliance Microsoft Learn |
||
| Description | Microsoft implements this System and Services Acquisition control | ||
| Additional metadata |
Name/Id: ACF1564 / Microsoft Managed Control 1564 Category: System and Services Acquisition Title: System Development Life Cycle - Define the System Development Life Cycle Used Ownership: Customer, Microsoft Description: The organization: Manages the information system using Microsoft’s Security Development Lifecycle that incorporates information security considerations; Requirements: Microsoft implements life cycle support for Azure through its Security Development Lifecycle (SDL) process that is followed for all engineering and development projects. A security requirements analysis and applicability must be completed for all system development projects. This analysis acts as a framework and includes the identification of possible risks to the finished development project as well as mitigation strategies which can be implemented and tested during the development phases. A Threat Modeling security review is included during the SDL process. Microsoft integrates essential information technology (IT) security considerations defined in (NIST) SP 800-64, Security Considerations in the System Development Life Cycle, into their established SDL process. Pre-SDL Requirements: Security Training All members of software development teams receive appropriate training to stay informed about security basics and recent trends in security and privacy. Individuals who develop software programs are required to attend at least one security training class each year. Security training can help ensure software is created with security and privacy in mind and can also help development teams stay current on security issues. Project team members are strongly encouraged to seek additional security and privacy education that is appropriate to their needs or products. SDL Core Phases The Microsoft SDL process includes the following phases: * Phase 1: Requirements - The Requirements phase of the SDL includes the project inception—when the organization considers security and privacy at a foundational level—and a cost analysis—when determining if development and support costs for improving security and privacy are consistent with business needs. This phase also includes defining security roles and responsibilities and identifying individuals with these roles and responsibilities. * Phase 2: Design - The Design phase is when the organization builds the plan for how to take the project through the rest of the SDL process—from implementation, to verification, to release. During the Design phase the organization establishes best practices to follow for this phase by way of functional and design specifications, and by performing risk analysis to identify threats and vulnerabilities in the software. TMA (Threat Model Analysis) is required to define all attack surfaces and their associated risks; all security gaps and risks and documented and analyzed. This security impact analysis results in dataflow documentation in order to identify all intended paths for information and potential attack vectors. * Phase 3: Implementation - The Implementation phase is when the organization creates the documentation and tools the customer uses to make informed decisions about how to deploy the software securely. To this end, the Implementation phase is when the organization establishes development best practices to detect and remove security and privacy issues early in the development cycle. Microsoft understands, observes, and implements the security requirements and considerations as outlined in IT Security Procedural Guide 09-48, Security Language for IT Acquisition Efforts, dated September 2009 for the information system consistent with the Azure offering’s requirements. * Phase 4: Verification - During the Verification phase, the organization ensures that the code meets the security and privacy tenets established in the previous phases. This is done through security and privacy testing, and a security push—which is a team-wide focus on threat model updates, code review, testing, and thorough documentation review and edit. A public release privacy review is also completed during the Verification phase. * Phase 5: Release - The Release phase is when the organization prepares the software for consumption and prepares for what happens once the software is released. One of the core concepts in the Release phase is response planning—mapping out a plan of action, should any security or privacy vulnerabilities be discovered in the release—and this carries over to post-release, as well, in terms of response execution. Post-SDL Requirement: Security Servicing and Response Execution After a software program is released, the product development team must be available to respond to any possible security vulnerabilities or privacy issues that warrant a response. In addition, the development team is required to follow the Azure Incident Management SOP for potential post-release issues. Azure has implemented information validation through checking of data inputs as part of the SDL process. Thorough code reviews and testing are completed during the Verification Phase of the SDL prior to software being put into a production environment. The code reviews and testing check for cases of SQL injection, format string vulnerabilities, XSS, integer arithmetic, command injection, and buffer overflow vulnerabilities. For more details on the SDL process, please refer to |
||
| 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 |
|