Microsoft Security Development Lifecycle (SDL)

(source: Microsoft Security Development Lifecycle)

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