12 November 2009 Bryan Sullivan Senior Security Program Manager, Microsoft SDL

The Microsoft® Security Development Lifecycle (SDL)

12 November 2009

Bryan SullivanSenior Security Program Manager,Microsoft SDL

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.

SDL EXECUTIVE COMMITMENT MANDATORY MICROSOFT PROCESS SINCE 2004

Measurable Improvements At Microsoft

Microsoft SDL and SQL Server

Sources: Analysis by Jeff Jones (Microsoft technet security blog)

SQL Server 2000 SQL Server 2005 Competing commercial DB

34

3

187

Before SDL After SDL

91% reduction in Vulnerabilities

Total Vulnerabilities Disclosed 36 Months After Release

http://blogs.technet.com/security/archive/2007/11/30/download-internet-explorer-and-firefox-vulnerability-analysis.aspx

Windows: 45% reduction of vulnerabilities

Source: Windows Vista One Year Vulnerability Report, Microsoft Security Blog 23 Jan 2008

Windows XP Windows Vista OS I OS II OS III

119

66

400

242

157

Total vulnerabilities disclosed one year after release


45% reduction in vulnerabilities


Microsoft SDL and Internet Explorer (IE)

Source: Browser Vulnerability Analysis, Microsoft Security Blog 27-NOV-2007

Internet Explorer 6 Internet Explorer 7

1814

8

3

Medium High


35% reduction in vulnerabilities63% reduction in high severity vulnerabilities

Vulnerabilities Fixed One Year After Release


Attacks are focusing on applications

Calculated from the Microsoft Security Intelligence Report V6

90% of vulnerabilities are remotely exploitable Sources: IBM X-Force, 2008

1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 20080%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

% of vulnerability disclosures:Operating system vs browser and application vulnerabilities

OS vulns Browser vulns Application vulns

Most vulnerabilities are in smaller companies' applications

11%

89%

Vendors' accountability for vulnerabilities in 2008

Top 5 ISVs

Others

Sources: IBM X-Force 2008 Security Report

What is Microsoft doing about the threat?

Working to protect our users…

Administer and track security training

IncidentResponse (MSRC)

Sign up with MSECDefine business ownerDefine security lead

Define product-specific security measures Meet SDL requirements

Guide product teams to meet SDL requirements

Security engineeringFeedback for SDL improvements

Establish release criteria and sign-off

as part of FSR

Meet release criteria

Ongoing Process Improvements

Education

Process AccountabilityTwC

Product

Groups

Training Requirements DesignImplementati

onVerification Release ResponseTraining Requirements Design

Implementation

Verification Release Response

Pre-SDL Requirements: Security Training

Assess organizational knowledge on security and privacy – establish training program as necessary

Establish training criteriaContent covering secure design, development, test and privacy

Establish minimum training frequencyEmployees 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)



Implementation


Phase One: Requirements

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 requirementsMandate the use of a bug tracking/job assignment systemDefine and document security and privacy bug bars



Implementation


Phase Two: Design

Define and document security architecture, identify security critical components

Document attack surface and limit through default settingsDefine supplemental security ship criteria due to unique product issues

Cross-site scripting testsDeprecation of weak crypto

Threat ModelingSystematic review of features and product architecture from a security point of viewIdentify threats and mitigations



Implementation


SDL Threat Modeling Tool

demonstration

Phase Three: Implementation

Full spectrum review – used to determine processes, documentation and tools necessary to ensure secure deployment and operation

Specification of approved build tools and optionsStatic analysis (/analyze (PREfast), FXCop, CAT.NET)

Banned APIsUse 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 librariesConsider other recommendations (e.g., Standard Annotation Language (SAL))



Implementation


Phase Four: Verification

Started as early as possible – conducted after “code complete” stage

Start security response planning – including response plans for vulnerability reportsRe-evaluate attack surfaceFuzz testing – files, installable controls and network facing codeConduct “security push” (as necessary, increasingly rare)

Not a substitute for security work done during developmentCode reviewPenetration testing and other security testingReview design and architecture in light of new threats



Implementation


Phase Five: Release – Response Plan

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 events24x7x365 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.



Implementation


Phase Five: Release – Final Security Review (FSR)

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” allowedThe first time security is reviewedA 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



Implementation


Phase Five: Release – Archive

Security response plan complete

Customer documentation up-to-dateArchive RTM source code, symbols, threat models to a central locationComplete final signoffs on Checkpoint Express – validating security, privacy and corporate compliance policies



Implementation


Post-SDL Requirement: Response

“Plan the work, work the plan…”

Execution on response tasks outlined during Security Response Planning and Release Phases



Implementation


applicability

Universal Applicability

Any operating systemAny languageAny deployment scenarioAny development methodology

Agile Development Methodologies

SCRUMExtreme Programming (XP)DSDMAdaptive Software DevelopmentCrystalFeature-Driven DevelopmentPragmatic Programming

Common trait: iterative approach

Unsuccessful Approaches

Make SDL requirements into product backlog items

Not secure

Do the complete SDL every iterationNot Agile

Remove some requirementsAlso not secure

SDL-Agile process

Three classes of requirements

Every Sprint

Training

Threat modeling

etc...

One-Time Only

Set up tracking

Upgrade compilers

etc...

Bucket

Fuzz parsers

Create response

plan

etc…

conclusions

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

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

Resources

SDL Portal: http://www.microsoft.com/sdl

SDL Blog: http://blogs.msdn.com/sdl/

SDL Process on MSDN (Web): http://msdn.microsoft.com/en-us/library/cc307748.aspx

SDL Process on MSDN (MS Word):http://www.microsoft.com/downloads/details.aspx?FamilyID=967389d8-6ed0-4751-a8d2-9c2fad39adce&displaylang=en

http://www.microsoft.com/sdl

http://blogs.msdn.com/sdl/

http://msdn.microsoft.com/en-us/library/cc307748.aspx

http://msdn.microsoft.com/en-us/library/cc307748.aspx

http://www.microsoft.com/downloads/details.aspx?FamilyID=967389d8-6ed0-4751-a8d2-9c2fad39adce&displaylang=en




Questions?

© 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.

Documents

12 November 2009 Bryan Sullivan Senior Security Program Manager, Microsoft SDL