12 November 2009 Bryan Sullivan Senior 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 E XECUTIVE COMMITMENT  MANDATORY M ICROSOFT PROCESS SINCE 2004

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

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

Source: Browser Vulnerability Analysis, Microsoft Security Blog 27-NOV-2007 Before SDL After SDL 35% reduction in vulnerabilities 63% reduction in high severity vulnerabilities Vulnerabilities Fixed One Year After Release

Calculated from the Microsoft Security Intelligence Report V6 90% of vulnerabilities are remotely exploitable Sources: IBM X-Force, 2008

Sources: IBM X-Force 2008 Security Report

Administer and track security training Incident Response (MSRC) Incident Sign up with MSEC Define business owner Define security lead Sign up with MSEC Define business owner Define security lead Define product-specific security measures Meet SDL requirements Define product-specific security measures Meet SDL requirements Guide product teams to meet SDL requirements Security engineering Feedback for SDL improvements Security engineering Feedback for SDL improvements Establish release criteria and sign-off as part of FSR Meet release criteria release criteriaMeet Ongoing Process Improvements Education Process Accountability TrainingTrainingRequirementsRequirementsDesignDesignImplementationImplementationVerificationVerificationReleaseReleaseResponseResponseTrainingTrainingRequirementsRequirementsDesignDesignImplementationImplementationVerificationVerificationReleaseReleaseResponseResponse

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) TrainingTrainingRequirementsRequirementsDesignDesignImplementationImplementationVerificationVerificationReleaseReleaseResponseResponseTrainingTrainingRequirementsRequirementsDesignDesignImplementationImplementationVerificationVerificationReleaseReleaseResponseResponse

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 TrainingTrainingRequirementsRequirementsDesignDesignImplementationImplementationVerificationVerificationReleaseReleaseResponseResponseTrainingTrainingRequirementsRequirementsDesignDesignImplementationImplementationVerificationVerificationReleaseReleaseResponseResponse

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 TrainingTrainingRequirementsRequirementsDesignDesignImplementationImplementationVerificationVerificationReleaseReleaseResponseResponseTrainingTrainingRequirementsRequirementsDesignDesignImplementationImplementationVerificationVerificationReleaseReleaseResponseResponse

SDL Threat Modeling Tool

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)) TrainingTrainingRequirementsRequirementsDesignDesignImplementationImplementationVerificationVerificationReleaseReleaseResponseResponseTrainingTrainingRequirementsRequirementsDesignDesignImplementationImplementationVerificationVerificationReleaseReleaseResponseResponse

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 TrainingTrainingRequirementsRequirementsDesignDesignImplementationImplementationVerificationVerificationReleaseReleaseResponseResponseTrainingTrainingRequirementsRequirementsDesignDesignImplementationImplementationVerificationVerificationReleaseReleaseResponseResponse

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 3 rd party code. TrainingTrainingRequirementsRequirementsDesignDesignImplementationImplementationVerificationVerificationReleaseReleaseResponseResponseTrainingTrainingRequirementsRequirementsDesignDesignImplementationImplementationVerificationVerificationReleaseReleaseResponseResponse

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 TrainingTrainingRequirementsRequirementsDesignDesignImplementationImplementationVerificationVerificationReleaseReleaseResponseResponseTrainingTrainingRequirementsRequirementsDesignDesignImplementationImplementationVerificationVerificationReleaseReleaseResponseResponse

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 TrainingTrainingRequirementsRequirementsDesignDesignImplementationImplementationVerificationVerificationReleaseReleaseResponseResponseTrainingTrainingRequirementsRequirementsDesignDesignImplementationImplementationVerificationVerificationReleaseReleaseResponseResponse

“Plan the work, work the plan…” Execution on response tasks outlined during Security Response Planning and Release Phases TrainingTrainingRequirementsRequirementsDesignDesignImplementationImplementationVerificationVerificationReleaseReleaseResponseResponseTrainingTrainingRequirementsRequirementsDesignDesignImplementationImplementationVerificationVerificationReleaseReleaseResponseResponse

Any operating system Any language Any deployment scenario Any development methodology

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

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

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

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

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

SDL Portal: SDL Blog: SDL Process on MSDN (Web): us/library/cc aspx SDL Process on MSDN (MS Word): etails.aspx?FamilyID=967389d8-6ed a8d2- 9c2fad39adce&displaylang=en

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