The Trustworthy Computing
Security Development Lifecycle
Steve Lipner
Director of Security Engineering Strategy
Security Business and Technology Unit
Microsoft Corporation
SLipner@microsoft.com
Microsoft Security Efforts
“B2 security” was an original objective of Windows NT
Security vulnerabilities made need for improved security
clear in late 1990s
Through Windows 2000 release (early 2000)
Secure Windows Initiative (SWI)
Expert resource for consulting and code reviews
Through Windows XP release (summer 2001)
SWI as company wide resource
Security training
Common tools
Team-wide “security days”
Introduction of Trustworthy Computing (early 2002)
Windows (and other) security pushes
Focused reviews of designs, code, penetration resistance
Security Development Lifecycle formalized (early 2004)
Process
+
Education
+
Accountability
Security Development
Lifecycle
Engineering Excellence
The Security Development Lifecycle (SDL)
A PROCESS by which Microsoft develops software, that
defines security requirements and milestones
MANDATORY for products that are exposed to meaningful security
risk
EVOLVING and new factors, such as privacy, are being added
COMPATIBLE with COTS product development processes
EFFECTIVE at addressing security issues; designed to produce
DEMONSTRABLE RESULTS (not all methodologies do this)
It has shown itself to be highly effective at reducing vulnerabilities in
commercial software
In sum, the SDL puts Microsoft on path toward more secure software
Security Development Lifecycle Tasks
Mapped Against Traditional Microsoft
Software Development Lifecycle
V 1.4 (Jan 28, 2005)
Security Development Lifecycle Tasks and Processes
Security Training
Security Kickoff
&
Register
With SWI
Security
Design
Best
Practices
Security
Architecture
& Attack Surface
Review
Threat
Modeling
Threat Modeling
Complete and
Mitigations
Reflected in
Specifications
Use Security
Development Tools
&
Security Best
Dev & Test Practices
Create
Security
Documentation
And Tools
For Product
Requirements
Design
Specifications
Functional
Specifications
Final
Security
Review
Pen Testing
Sign off on
Security
Requirements
In
Checkpoint Express
Security
Servicing
&
Response
Execution
Final Release
Candidate
Alpha & Beta Pre releases
Testing and Verification
Development of New Code
Design
Security
Push
Traditional Microsoft Software Product Development Lifecycle Tasks and Process
Product Code
Complete
Feature Lists
Quality
Guidelines
Architecture Docs
Schedules
Prepare
Security
Response
Plan
Implementation
Bug fixes
Verification
Code Signing
& Checkpoint
Express
Signoff
Release
RTM
Product Support
Service Packs/QFEs
Security Updates
Support & Servicing
Requirements Phase
Consider security at the outset
Secure Windows Initiative (SWI) team assigns
SWI Buddy
Development team identifies security functional
requirements
SWI Buddy reviews product plan, makes
recommendations, ensures resources allocated
by management
SWI Buddy assesses security milestones and
exit criteria
(NOTE: This SWI Buddy will stay with the project
through the Final Security Review)
Design
Define and document security architecture
Identify security critical components (“trusted base”)
Identify design techniques (e.g., layering, managed code,
least privilege, attack surface minimization)
Document attack surface and limit through default
settings
Create threat models (e.g., identify assets, interfaces,
threats, risk) and mitigate threats through
countermeasures
Identify specialized test tools
Define supplemental ship criteria due to unique product
issues (e.g., cross-site scripting tests)
Confer with SWI Buddy on questions
Development
Apply coding and testing standards (e.g.,
safe string handling)
Apply fuzz testing tools (structured invalid
inputs to network protocol and file
parsers)
Apply static code analysis tools (to find,
e.g., buffer overruns, integer overruns,
uninitialized variables)
Conduct code reviews
Verification
Software functionality complete
and enters Beta
Because code complete, testing both new and
legacy code
Security Push
Security push is not a substitute for security work
during development
Security push provides an opportunity to focus on
security
Code reviews
(especially legacy/unchanged code)
Penetration and other security testing
Review design, architecture, threat models in light of new
threats
Final Security Review (FSR)
“From a security viewpoint, is this software ready
to deliver to customers?”
Two to six months prior to software completion,
depending on the scope of the software.
Software must be in a stable state with only minimal
non-security changes expected
prior to release
FSR results: If the FSR finds a pattern of
remaining vulnerabilities, the proper response is
not just to fix the vulnerabilities found, but to
revisit the earlier phases and take pointed
actions to address root causes (e.g., improve
training, enhance tools)
Final Security Review (FSR)
What is in the FSR?
Completion of a questionnaire by
the product team
Interview by a security team member assigned
to the FSR
Review of bugs that were initially identified as
security bugs, but on further analysis were
determined not to have impact on security, to ensure
that the analysis was done correctly
Analysis of any newly reported vulnerabilities
affecting similar software to check for resiliency
Additional penetration testing, possibly by outside
contractors to supplement security team
Response Phase
Microsoft Security Response Center
Detect and respond to externally discovered
vulnerabilities and attacks
Sustained Engineering Teams
Develop, test, package updates
Patch Management
Simplify update deployment for consumers and
organizations
Post Mortems and feedback to the SDL
Search for related vulnerabilities
Initiate “mini-security push” if needed
Document lessons learned to update tools,
processes
Maintaining the SDL
SDL process is NOT static!
Process updates released on a six-month
cycle
Draft requirements 1 March and 1 September
Requirements finalized 1 April and 1 October
Requirements effective 1 July and 1 January
Proposed updates reviewed broadly by
Microsoft security and engineering teams
Maintaining the SDL
Updates reflect new challenges and new
solutions
Updated requirements respond to new threats
Integer overruns, double frees
Updated requirements mandate new tools,
techniques, processes
Fuzz testing of files and RPC interfaces
Migration to new compilers
Updates could (in theory) remove requirements
If approach proves ineffective
If problem “solved”
Education for the SDL
New employees do not arrive with ability to
develop secure software
Microsoft trains staff as a part of New Employee
Orientation
Microsoft trains staff as part of a security push
Microsoft trains developers, testers, program managers,
user education staff and
architects annually
Microsoft funds academic curriculum development
through Microsoft Research
Microsoft publishes material on writing secure code,
threat modeling, and SDL (pending) and offers courses
(see http://www.microsoft.com/learning)
Education Resources
Accountability for SDL
You can’t manage what you can’t measure…
Education
Individual learning measurement
Team training compliance
Process implementation
In-process metrics provide early warning
Threat model completion
Code reviewed
Test coverage
FSR results
Post-release metrics assess final payoff
Total and high severity vulnerabilities
SDL Results: Windows Server
2003
Source: Microsoft Security Bulletin Search
SDL Results: Client OS
Client OS Critical and Important Security
Bulletins
35
22
35
21
Professional
18
Service Pack 1
Service Pack 2
Source: Microsoft Security Bulletin Search
SDL Results: SQL Server
SQL Server 2000
2002-2005 (YTD)
8/15/02
MS02-043
10/2/02
7/24/02
MS02-056
7/30/02
7/10/02 MS02-039
MS02-038 MS02-040
MS02-034,
10/16/02
MS02-035
MS02-061
6/12/02
MS02-030
11/19/02
MS02-065
4/17/02
MS02-020
2/20/02
MS02-007
2002
1/25/2003
Slammer
SQL Server 2000
2002-2005 (YTD)
7/23/03
8/20/03
MS03-031 MS03-033
2003
2004
1/17/03
SP3 released
5/20/03
SP3a released
2/20/03
SQL Server 2000
Security Tools
As of January 10, 2005
1/13/04
MS04-003
2005
IIS 4.0, 5.0, 5.1, 6.0
2002-2005 (YTD)
SDL Results: IIS 4.0, 5.0, 5.1, 6.0
IIS 4.0, 5.0, 5.1, 6.0
2002-2005 (YTD)
2/27/02
MS02-012
MS02-011
6/11/02
MS02-028
4/10/02
1/22/02
MS02-001 MS02-018
5/28/03
MS03-018
(IIS 4.0/5.0/5.1 only)
10/30/02
MS02-062
2002
2003
7/30/02
Windows 2000 SP3 released
2004
6/26/03
Windows 2000 SP4 released
4/15/03
Windows Server 2003
w/ IIS 6.0 Released
As of January 10, 2005
7/13/04
10/12/04
MS04-021
(IIS 4.0 only) MS04-030
2005
Thoughts for the Academic
Community
Security education
We have hundreds of engineers who must
implement security features, but…
Our entire engineering population must know
and apply the principles of secure design,
development, and testing
Trustworthy Computing curriculum grants
motivated by this need
Security research
We (and the industry) need better predictive
metrics!
© 2005 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.
PowerPoint Guidelines
Font, size, and color for text have
been formatted for you in the
Slide Master
Use the color palette shown below
See next slide for additional guidelines
Sample fill
color
Sample fill
color
Sample fill
color
PowerPoint Template
Subtitle color
Example of a slide with a subhead
Set the slide title in “Title Case”
Set subheads in “Sentence case”
Generally set subhead to 36pt or smaller so if
will fit on a single line
The subhead color is defined for this
template but must be selected; On the font
color palette, select the color to the right of
title color
Sample Bar Chart
East
West
North
90
80
70
60
50
40
30
20
10
0
1st Qtr
2nd Qtr
3rd Qtr
4th Qtr
Demo Title
Name
Title
Group
Video Title
Partner Title
Name
Title
Company
Customer Title
Name
Title
Company
Announcement Title
© 2005 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.