Introduction to the Microsoft®

Security Development
Lifecycle (SDL)
Secure software made easier
Agenda
• Applications under attack
• Origins of the Microsoft SDL
• What is Microsoft doing about the threat?
• Measurable improvements at Microsoft
Cybercrime Evolution
1986–1995 1995–2003 2004+ 2006+

• LANs • Internet Era • OS, DB attacks • Targeted attacks

• First PC virus • “Big Worms” • Spyware, Spam • Social engineering
• Motivation: damage • Motivation: damage • Motivation: Financial • Financial + Political

 Cost of U.S. 2007 Market prices:

cybercrime: Credit Card Number

Full Identity
$0.50 - $20
$1 - $15
About $70B Bank Account $10 - $1000

Source: U.S. Government Accountability Office (GAO), FBI

Attacks are focusing on applications
% of vulnerability disclosures:
Operating system vs browser and application vulnerabilities

From the Microsoft Security Intelligence Report V7

90% of vulnerabilities are remotely exploitable

Sources: IBM X-Force, 2008
Most vulnerabilities are in smaller ISV apps

Vendors' accountability for vulnerabilities in 2008

11% Top 5 ISVs

89% Others

Sources: IBM X-Force 2008 Security Report

Security Timeline at Microsoft…
Now
• Optimize the
2005-2007 process through
feedback,
• SDL is enhanced analysis and
2004 • “Fuzz” testing
automation
• Code analysis • Evangelize
2002-2003 • Microsoft Senior
Leadership Team • Crypto design the SDL to the
requirements software
agrees to require
• Bill Gates writes SDL for all
• Privacy development
“Trustworthy products that: • Banned APIs community:
Computing” • Are exposed to
• and more… • SDL Process
memo early 2002 meaningful risk
Guidance
• Windows Vista is • SDL Optimization
and/or
• “Windows the first OS to Model
• Are Process go through full
security push” for sensitive data • SDL Pro Network
Windows Server SDL cycle • SDL Threat
2003 Modeling Tool
• SDL Process
• Security push and Templates
FSR extended to
other products
Which apps are required to follow SDL?
• Any release commonly used or • Any release that accepts and/or
deployed within an enterprise, processes data from
business, or organization an unauthenticated source
• Any release that regularly stores, • Any functionality that parses any
processes, or file type that is not
communicates PII (as defined in protected, (i.e. not limited to
Microsoft Privacy Guidelines system administrators)
for Developing Software
Products and Services) or other
• Any release that contains
ActiveX and/or COM controls
sensitive customer information
• Any release that regularly
• All Microsoft, MSN and Live.com
online services that are used
touches or listens on the
by external customers and
Internet or other networks
hosted in the MSN environment
Working to protect our users…
Education Process Accountability

Administer and track Establish release criteria Incident

Guide product teams to
security training and sign-off as part of Response
meet SDL requirements
FSR (MSRC)

Ongoing Process Improvements

Pre-SDL Requirements: Security Training
Requirements 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)
Phase One: Requirements
Design Implementation Verification Release Response

Opportunity to consider security at the outset of a project

• Development team identifies security and privacy requirements
• Development team identifies lead security and privacy contacts
• 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
Phase Two: Design
Implementation Verification Release Response

Define and document security architecture, identify security critical

components
• Identify design techniques (layering, managed code, least privilege, attack
surface minimization)
• 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
• Online services specific requirements
Phase Three: 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 (PREFix, /analyze (PREfast), FXCop)
• 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)
• Consider other recommendations (e.g., Standard Annotation
Language (SAL))
Phase Four: 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
• Online services specific requirements
Phase Five: Release – Response Plan
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.
Phase Five: Release – Final Security Review
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
Phase Five: Release – Archive
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
Post-SDL Requirement: Response

“Plan the work, work the plan…”

• Execution on response tasks outlined during Security Response
Planning and Release Phases
SDL Process Guidance for LOB Apps
The Microsoft SDL includes online services and Line-of-Business
application development guidance.
• Line-of-Business applications are a set of critical computer applications that are vital to running an
enterprise, such as accounting, human resources (HR), payroll, supply chain management, and resource
planning applications.
• Many of the requirements and recommendations in the SDL for online services are closely related to what is
required for Line-of-Business applications.
• Line-of-Business SDL process guidance allows you to tailor a process specific to your LOB application
development while meeting SDL requirements.

Training Requirements Design Implementation Verification Release

LOB-specific Risk assessment Asset-centric Internal review Pre-production Post-production

training threat modeling assessment assessment

• Application • Threat model • Incorporate • Comprehensive • Host level scan

portfolio • Design review security checklists security
• Application Risk and standards assessment
assessment • Conduct self • Bug
• Determine code review remediation
service level • Security Code
analysis
SDL Guidance for Agile Methodologies

• Requirements defined by
frequency, not phase
– Every-Sprint (most critical)
– One-Time (non-repeating)
– Bucket (all others)

• Great for projects without

end dates, like cloud services
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
Microsoft SDL and Windows
Total Vulnerabilities 400
Disclosed One Year
After Release
242

157
119
66

Windows XP Windows Vista OS I OS II OS III

Before SDL After SDL

45% reduction in Vulnerabilities

Source: Windows Vista One Year Vulnerability Report, Microsoft Security Blog 23 Jan 2008
Microsoft SDL and SQL Server
187
Total Vulnerabilities Disclosed
36 Months After Release

34
3

SQL Server 2000 SQL Server 2005 Competing commercial DB

Before SDL After SDL

91% reduction in Vulnerabilities

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

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/downloa
ds/details.aspx?FamilyID=d045a
05a-c1fc-48c3-b4d5-
b20353f97122&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.