1. The Microsoft® Security Development Lifecycle (SDL)
12 November 2009
Bryan Sullivan
Senior Security Program Manager,
Microsoft SDL

2. Microsoft’s Security Development Lifecycle (SDL)
The SDL: Microsoft’s industry leading software security assurance
process designed to protect customers by reducing the number and severity of software vulnerabilities before release.
Key point: Microsoft has a proven method for more secure development – the SDL.
Since the formation of Trustworthy Computing in 2002, security has been a top priority for Microsoft. All company software products are designed and built with security in mind using Microsoft’s Security Development Lifecycle (SDL), a holistic and comprehensive approach for writing more secure code. The SDL has significantly improved the security, privacy and reliability of its software, with vulnerabilities in Microsoft products dropping year over year.
SDL Executive commitment  mandatory Microsoft process since 2004

3. Measurable Improvements At Microsoft

4. Microsoft SDL and SQL Server
Total Vulnerabilities Disclosed 36 Months After Release
Before SDL
After SDL
91% reduction in Vulnerabilities
Sources: Analysis by Jeff Jones (Microsoft technet security blog)

5. Windows: 45% reduction of vulnerabilities
Total vulnerabilities disclosed one year after release
45% reduction in vulnerabilities
Before SDL
After SDL
Source: Windows Vista One Year Vulnerability Report, Microsoft Security Blog 23 Jan 2008

6. Microsoft SDL and Internet Explorer (IE)
Vulnerabilities Fixed One Year After Release
Before SDL
After SDL
35% reduction in vulnerabilities
63% reduction in high severity vulnerabilities
Source: Browser Vulnerability Analysis, Microsoft Security Blog 27-NOV-2007

7. Attacks are focusing on applications
Calculated from the Microsoft Security Intelligence Report V6
90% of vulnerabilities are remotely exploitable
Sources: IBM X-Force, 2008

8. Most vulnerabilities are in smaller companies' applications
Sources: IBM X-Force 2008 Security Report

9. What is Microsoft doing about the threat?

10. Working to protect our users…
TwC
Education
Process
Accountability
Administer and track security training
Guide product teams to meet SDL requirements
Establish release criteria and sign-off as part of FSR
Incident
Response (MSRC)
Training
Requirements
Design
Implementation
Verification
Release
Response
Sign up with MSEC
Define business owner
Define security lead
Define product-specific security measures
Meet SDL requirements
Meet
release criteria
Security engineering
Feedback for SDL improvements
Product Groups
Ongoing Process Improvements

11. Pre-SDL Requirements: Security Training
Design
Implementation
Verification
Release
Response
Assess organizational knowledge on security and privacy – establish training program as necessary
Establish training criteria
Content covering secure design, development, test and privacy
Establish minimum training frequency
Employees must attend n classes per year
Establish minimum acceptable group training thresholds
Organizational training targets (e.g. 80% of all technical personnel trained prior to product RTM)

12. Phase One: Requirements
Training
Training
Requirements
Requirements
Design
Design
Implementation
Implementation
Verification
Verification
Release
Release
Response
Response
Opportunity to consider security at the outset of a project
Development team identifies lead security and privacy contacts – “Champions”
Security Advisor assigned
Security Advisor reviews product plan, makes recommendations, may set additional requirements
Mandate the use of a bug tracking/job assignment system
Define and document security and privacy bug bars

13. Phase Two: Design
Training
Requirements
Design
Implementation
Verification
Release
Response
Define and document security architecture, identify security critical components
Document attack surface and limit through default settings
Define supplemental security ship criteria due to unique product issues
Cross-site scripting tests
Deprecation of weak crypto
Threat Modeling
Systematic review of features and product architecture from a security point of view
Identify threats and mitigations

14. SDL Threat Modeling Tool
demonstration
SDL Threat Modeling Tool

15. Phase Three: Implementation
Training
Requirements
Design
Implementation
Verification
Release
Response
Full spectrum review – used to determine processes, documentation and tools necessary to ensure secure deployment and operation
Specification of approved build tools and options
Static analysis (/analyze (PREfast), FXCop, CAT.NET)
Banned APIs
Use of operating system “defense in depth” protections (NX, ASLR and HeapTermination)
Online services specific requirements (e.g., Cross-site scripting , SQL Injection etc)
Secure coding libraries
Consider other recommendations (e.g., Standard Annotation Language (SAL))

16. Phase Four: Verification
Training
Requirements
Design
Implementation
Verification
Release
Response
Started as early as possible – conducted after “code complete” stage
Start security response planning – including response plans for vulnerability reports
Re-evaluate attack surface
Fuzz testing – files, installable controls and network facing code
Conduct “security push” (as necessary, increasingly rare)
Not a substitute for security work done during development
Code review
Penetration testing and other security testing
Review design and architecture in light of new threats

17. Phase Five: Release – Response Plan
Training
Requirements
Design
Implementation
Verification
Release
Response
Creation of a clearly defined support policy – consistent with MS corporate policies
Provide Software Security Incident Response Plan (SSIRP)
Identify contacts for MSRC and resources to respond to events
24x7x365 contact information for 3-5 engineering, 3-5 marketing, and 1-2 management (PUM and higher) individuals
Ensure ability to service all code including “out of band” releases and all licensed 3rd party code.

18. Phase Five: Release – Final Security Review (FSR)
Training
Requirements
Design
Implementation
Verification
Release
Response
Verify SDL requirements are met and there are no known security vulnerabilities
Provides an independent view into “security ship readiness”
The FSR is NOT:
A penetration test – no “penetrate and patch” allowed
The first time security is reviewed
A signoff process
Key Concept: The tasks for this phase are used as a determining factor on whether or not to ship – not used as a “catchall” phase for missed work in earlier phases

19. Phase Five: Release – Archive
Training
Requirements
Design
Implementation
Verification
Release
Response
Security response plan complete
Customer documentation up-to-date
Archive RTM source code, symbols, threat models to a central location
Complete final signoffs on Checkpoint Express – validating security, privacy and corporate compliance policies

20. Post-SDL Requirement: Response
Training
Training
Requirements
Requirements
Design
Design
Implementation
Implementation
Verification
Verification
Release
Release
Response
Response
“Plan the work, work the plan…”
Execution on response tasks outlined during Security Response Planning and Release Phases

21. applicability

22. Universal Applicability
Any operating system
Any language
Any deployment scenario
Any development methodology

23. Agile Development Methodologies
SCRUM
Extreme Programming (XP)
DSDM
Adaptive Software Development
Crystal
Feature-Driven Development
Pragmatic Programming
Common trait: iterative approach

24. Unsuccessful Approaches
Make SDL requirements into product backlog items
Not secure
Do the complete SDL every iteration
Not Agile
Remove some requirements
Also not secure

25. SDL-Agile process

26. Three classes of requirements
Every Sprint
Training
Threat modeling
etc...
One-Time Only
Set up tracking
Upgrade compilers
Bucket
Fuzz parsers
Create response plan
etc…

27. conclusions

28. Secure Software Development Requires Process Improvement
Key Concepts
Simply “looking for bugs” doesn’t make software secure
Must reduce the chance vulnerabilities enter into design and code
Requires executive commitment
Requires ongoing process improvement
Requires education & training
Requires tools and automation
Requires incentives and consequences

29. Summary Attacks are moving to the application layer
SDL = embedding security into software and culture
Measurable results for Microsoft software
Microsoft is committed to making SDL widely available and accessible

30. Resources
SDL Portal: SDL Blog: SDL Process on MSDN (Web): SDL Process on MSDN (MS Word):

31. Questions?

32. 9/14/ :09 PM
© 2008 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.