4.9. Microsoft Security Development Lifecycle (SDL).md

Microsoft Security Development Lifecycle (SDL)

• Set of guidance, best practices, tools, and processes
  • used internally at Microsoft to build more secure products and services.
• Introduces security and privacy considerations throughout all phases of the development process.
• Helps developers
  • build highly secure software
  • address security compliance requirements
  • reduce development costs.

Provide training

• Security is everyone's job
  • E.g. developers, service engineers, and program and project managers.
• Everyone must understand
  • security basics
  • how to build security into software & services
  • attacker's perspective, their goals, and the art of the possible

Define security requirements

• Security requirements must be updated continuously in order to address changes in required functionality and changes to the threat landscape.
• Optimal time to define the security requirements is during the initial design and planning stages.
  • Early planning allows development teams to integrate security in ways that minimize disruption.
• Factors that influence security requirements include, but are not limited to:
  • Legal and industry requirements
  • Internal standards and coding practices
  • Review of previous incidents
  • Known threats
• Track requirements through e.g.
  • work-tracking system
  • telemetry from the engineering pipeline.

Define metrics and compliance reporting

• Essential to define the minimum acceptable levels of security quality

  • and to hold engineering teams accountable to meeting that criteria.

• Good to define as early as possible to apply standards throughout the entire project.

• E.g. all known vulnerabilities discovered with a "critical" or "important" severity rating must be fixed with a specified time frame.

• Track & report security work

  • Allows to have key performance indicators (KPIs)
  • Ensures security tasks are completed
  • Bug/work tracking mechanism should allow for security defects and security work items
    • to be clearly labeled as security
    • marked with their appropriate security severity

• Read more about defining metrics and compliance reporting at:

  • SDL Privacy Bug Bar Sample
  • Add or modify an Azure DevOps field to track work
  • SDL Security Bug Bar Sample

Perform threat modeling

• USE in environments where there is a meaningful security risk.
• Allows development teams to consider, document, and discuss the security implications of designs.
• Applying a structured approach to threat scenarios helps a team.
  1. Effectively and less expensively identify security vulnerabilities
  2. Determine risks from those threats
  3. make security feature selections and establish appropriate mitigations.
• You can apply threat modeling at the component, application, or system level.
• Read more: Threat Modeling

Establish design requirements

• Assurance activities that help engineers implement more secure features, e.g. well engineered for security.
• Methods e.g. cryptography, authentication, and logging.
• Complicated design & security features are likely to result in vulnerabilities.
• Crucial to apply consistently and with a understanding of the protection they provide.

Define and use cryptography standards

• Encrypt in transit to protect data from being alteration & unintended disclosure when moving.
• Making an incorrect choice when using any aspect of cryptography can be catastrophic.
  • Best to develop clear encryption standards with specifics on every element of the encryption implementation.
• Only use industry-vetted encryption libraries: Encryption should be left to experts.
• See the Microsoft SDL Cryptographic Recommendations whitepaper for more.

Manage security risks from using third-party components

• Understand the impact of security vulnerability in third-party components to rest of the system.
• Plan to respond when new vulnerabilities are discovered & consider additional validation
• Read more:
  • Managing Security Risks Inherent in the Use of Third-Party Components
  • Managing Security Risks Inherent in the Use of Open-Source Software

Use approved tools

• Define and publish a list of approved tools and their associated security checks.
  • e.g. compiler/linker options and warnings.
• Strive to
  • use the latest version of approved tools (such as compiler versions)
  • utilize new security analysis functionality and protections.
• Read more:
  • Recommended Tools, Compilers and Options for x86, x64, and ARM processors (whitepaper)
  • SDL Resources

Perform Static Analysis Security Testing (SAST)

• Analyzing source code prior to compilation
  • provides a highly scalable method of security code review
  • helps ensure that secure coding policies are being followed
• Typically integrated into the commit pipeline to identify vulnerabilities each time the software is built or packaged.
• Some offerings replace flawed (e.g. unsafe/banned) functions while developer is coding.
• Read more:
  • Microsoft DevSkim on GitHub
  • Roslyn Security Guard Rules
  • Visual Studio Marketplace
  • Analyzing C/C++ Code Quality by Using Code Analysis
  • Microsoft BinSkim on GitHub

Perform Dynamic Analysis Security Testing

• Performs run-time verification when all components are integrated and running.
• Achieved using a tool
  • e.g. a suite of pre-built attacks
  • e.g. to specifically monitor application behavior for memory corruption, user privilege issues, and other critical security problems.
• Some tools can be more readily integrated into the CI/CD pipeline
  • e.g. such as web app scanning tools
• Other such as fuzzing requires a different approach.
• Read more:
  • Visual Studio Marketplace
  • Automated Penetration Testing with White-Box Fuzzing

Perform penetration testing

• Security analysis of a software system by simulating the actions of a hacker.
• Uncovers potential vulnerabilities resulting from e.g.
  • coding errors, system configuration faults, or other operational deployment weaknesses.
• Finds the broadest variety of vulnerabilities
• Often performed in conjunction with automated and manual code reviews.
• Read more:
  • Attack Surface Analyzer
  • SDL Security Bug Bar Sample

Establish a standard incident response process

• Crucial for addressing new threats that can emerge over time
• The plan should be created in coordination with your organization's dedicated Product Security Incident Response Team (PSIRT).
• Your incident response plan should:
  • Include who to contact if a security emergency occurs
  • Establish the protocol for security servicing (including plans for code inherited from other groups within the organization and for third-party code)
  • Be tested before it is needed
• Read more:
  • Using Azure Security Center for an incident response
  • Microsoft Incident Response and shared responsibility for cloud computing
  • Microsoft Security Response Center