Security Development
Lifecycle:
Changing the Software Development Process
to build in Security from the start
Eric Bidstrup
Ellen Cram Kowalczyk
Security Business and Technology Unit
Microsoft Corporation
Microsoft’s Security Focus
Origin Of Microsoft
Security Efforts
Through Windows 2000 release
Secure Windows Initiative (SWI)
Expert resource for consulting and code reviews
Through Windows XP release
SWI as company wide resource
Security training
Common tools
Team-wide “security days”
Introduction of Trustworthy Computing
Windows (and other) security pushes
Focused reviews of designs, code, penetration
resistance
Framework for Better Security
Threat modeling
Code inspection
Penetration testing
Unused features off by default
Reduce attack surface area
Least Privilege
Prescriptive guidance
Security tools
Training and education
Community engagement
Transparency
Clear policy
Security Development Lifecycle addresses
Secure by Design, Secure by Default
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
DEMONSTRATABLE 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
Traditional Baseline Process
Integrating SDL into the development process
Security Development Lifecycle Tasks and Processes
Security Kickoff
&
Security
Requirements
Security Training
Security
Architecture
& Attack
Surface
Security
Review
Design
Best
Practices
Threat
Modeling
Complete and
Mitigations
Reflected in
Specifications
Feature Lists,
Quality
Guidelines,
Architecture
Docs, and
Schedules
Threat
Modeling
Use Security
Development Tools
&
Security Best
Dev & Test Practices
Create
Security
Documentation
And Tools
For Product
Security
Push
Prepare
Security
Response
Plan
Final
Security
Review
Sign off on
Security
Requirements
&
Final Security
Review
Pen Testing
Traditional Microsoft Software Product Development Lifecycle Tasks and Process
Product Code
Complete
Design
Specifications
Functional
Specifications
Security
Servicing
&
Response
Execution
Final Release
Candidate
Alpha & Beta Pre releases
Testing and Verification
Development of New Code
Virus
Scanning,
Code
Signing,
and release
processes
RTM
Product Support
Service Packs/
QFEs
Security Updates
Bug fixes
Requirements
Design
Implementation
Verification
Release
Support &
Servicing
Requirements Phase
Opportunity to consider security at the outset
Secure Windows Initiative (SWI) team assigns
SWI Buddy
Development team identifies security
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
Design stage
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
Exit criteria: Design review complete and signed off by
development team and SWI Buddy
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 does provide 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
Sustained Engineering Teams
Patch Management
Post Mortems and feedback to the SDL
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
SDL Results: Windows 2003
Source: Microsoft Security Bulletin Search
SDL Results: Office 2003
Office Bulletins since Office 2003 shipped (Aug 2003)
12
4
All Office Bulletins since
ship 8/03
Affecting Office 2003
Bulletins after August 2003:
(* affected Office 2003)
• September: MS03-035, MS03036, MS03-037, MS03-038
• November: MS03-050
2004
• October: MS04-033
• September: MS04-028* (GDI+
issue) …
• September: MS04-027*
(WordPerfect converter)
• March: MS04-009
2005
• February: MS05-005
• February: MS05-012*
(OLE issue) …
• April: MS05-023*
(Word buffer overflow)
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
SDL Results: Exchange
Exchange 5.0, 5.5, 2000, 2003
2002-2005 (YTD)
Exchange 5.0, 5.5, 2000, 2003
2002-2005 (YTD)
10/15/03
MS03-046 (Crit)
MS03-047 (Mod)
1/13/04
(Exch 5.0, 5.5,
2000 only) MS04-002
2/27/02
7/24/02
MS02-011
MS02-037
2/7/02
5/28/02
MS02-003
MS02-025
2002
2003
8/10/04
10/12/04
MS04-026 MS04-035
(Exch 5.5 only) MS04-036
2004
2005
7/18/02
Exchange 2000
SP3 released
21/10/03
Exchange Server
2003 released
As of January 10, 2005
5/25/04
Exchange 2003 SP1
released
Discussion
© 2005 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.