Microsoft Security Development Lifecycle (SDL)

(source: Microsoft Security Development Lifecycle)

The Security Development Lifecycle (SDL) is a software development process that helps developers build more secure software and address security compliance requirements while reducing development cost.

Phrase One: Training

  • Practice #1: Core Security Training
    • Stay informed about security basics and recent trends in security and privacy.
    • Recommended Training

Phrase Two: Requirements

  • Practice #2: Establish Security and Privacy Requirements
    • Identify key milestones and deliverables
    • Assign security experts
    • Define minimum security and privacy criteria for an application
    • Deploying a security vulnerability/work item tracking system
  • Practice #3: Create Quality Gates/Bug Bars
    • Define minimum acceptable levels of security and privacy quality
    • Set a meaningful bug bar (i.e., severity thresholds of security vulnerabilities)
  • Practice #4: Perform Security and Privacy Risk Assessments
    • Examine software design based on costs and regulatory requirements
    • Identify need for threat modeling and security design reviews

Phase Three: Design

  • Practice #5: Establish Design Requirements
    • Address security and privacy concerns early to minimize the risk of schedule disruptions and reduce a project's expense.
    • Validate all design specifications against a functional specification
  • Practice #6: Perform Attack Surface Analysis/Reduction
    • Thoroughly analyze overall attack surface
      • disable or restrict access to system services
      • apply the principle of least privilege
      • Employing layered defenses
  • Practice #7: Use Threat Modeling
    • Identify need for threat modeling and security design reviews
    • Apply a structured approach to threat scenarios to identify security vulnerabilities, determine risks from those threats, and establish appropriate mitigations.

Phase Five: Implementation

  • Practice #8: Use Approved Tools
    • Publish a list of approved tools and associated security checks
    • Keep the list regularly updated
  • Practice #9: Deprecate Unsafe Functions
    • Analyze all project functions and APIs to ban unsafe ones
    • Use newer compilers or code scanning tools to check code for functions on the banned list
    • Replace the unsafe functions with safer alternatives
  • Practice #10: Perform Static Analysis
    • Analyze the source code prior to compilation to ensure that secure coding policies are being followed

Phase Seven: Verification

  • Practice #11: Perform Dynamic Analysis
    • Perform run-time verification of the software
    • Check functionality using tools that monitor application behavior for memory corruption, user privilege issues, and other critical security problems.
  • Practice #12: Perform Fuzz Testing
    • Induce program failure by deliberately introducing malformed or random data to the application
  • Practice #13: Conduct Attack Surface Review
    • Review attack surface upon code completion
    • Ensure that any new attack vectors created as a result of the changes have been reviewed and mitigated including threat models

Phase Six: Release

  • Practice #14: Create an Incident Response Plan
    • Prepare an Incident Response Plan to address new threats that can emerge over time
      • identify appropriate security emergency contacts
      • establish security servicing plans for code inherited from other groups within the organization and for licensed third-party code
  • Practice #15: Conduct Final Security Review
    • Review all security activities that were performed to ensure software release readiness.
    • Eexamine threat models, tools outputs and performance against the quality gates and bug bars defined during the Requirements Phase
  • Practice #16: Certify Release and Archive
    • Certify software prior to a release to ensure security and privacy requirements were met
    • Archive all specifications, source code, binaries, private symbols, threat models, documentation, emergency response plans, and license and servicing terms for any third-party software.

Phase Seven: Response

  • Practice #17: Execute Incident Response Plan
    • Implement the Incident Response Plan instituted in the Release phase
    • Deliver security updates and authoritative security guidance