Process
+
Education
+
Accountability
Security Development
Lifecycle
Security Development Lifecycle
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
A Security Framework
SD3+C
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
vs.
Traditional Development Lifecycle
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
Security Development Lifecycle
(SDL)
Requirements phase
-Security “buddy” assigned
Implementation phase
-Secure coding standards adhered to
-Security testing standards adhered to
-Security tools use
Release phase
-Final Security Review
Security response
Product Development Timeline
Education
-New Hire
-Refresher
Design phase
-Security plan complete
-Security milestones understood
-Design standards & guidelines identified
-Security architecture complete
-Threat models & design review complete
-Ship criteria agreed upon
Verification phase
-Security push
RTM & deployment
-PRS requires FSR sign-off
http://swi/sdl
Security Development Lifecycle
Drilldown
Education and Awareness
(Prior to Requirements)
All disciplines (Dev/QA/PM/UA/UE) must understand
security!
All disciplines must complete at least one security training
class sometime in the last 12 months
All disciplines must complete the following reading:
Writing Secure Code, Version 2
(ISBN: 0-7356-1722-8)
Threat Modeling
(ISBN: 0-7356-1991-3 )
Exit criteria
Successful completion of requirements listed above
Required Reading
Phase 1: Requirements
Opportunity to consider security at the outset
Development team identifies security requirements
Who will use the application
Are security requirements equal for all users
Standalone, Intranet or Extranet availability
Internal or external usage
What are the assets
What are the implications if security fails
Who is responsible for operations
Project Inception
(Requirements)
Designate a security coordinator
Update Bug reporting tools
Security Bug Effect field
Security Cause field
Security bug bar document
Critical, Important & moderate bugs fixed before RTM.
Project Inception
Configure the bug reporting tool
Add a Security Bug Effect field
Not a Security Bug
Spoofing
Tampering
Repudiation
Information Disclosure
Denial of Service
Elevation of Privilege
Attack Surface Reduction*
Project Inception
Configure the bug reporting tool
Add a Security Cause field
Not a Security Bug
Buffer Overflow/Underflow
Arithmetic Error (int
overflow)
SQL/Script Injection
Directory Traversal
Race Condition
Cross-Site Scripting
Cryptographic Weakness
Cryptographic Weakness
Weak Authentication
Weak Authorization/Bad ACL
Ineffective Secret Hiding
Unlimited Resource
Consumption
Incorrect/No Error Messages
Bad/No Path Canonicalization
Other
Project Inception
Deliverables
Security Plan Document
Outlines the processes and work items that a
product team will follow in order to integrate SDL
into their product development process
Security Bug Bar Definition
Project Inception
(Microsoft specific)
Secure Windows Initiative (SWI) team assigns
SWI Buddy
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)
Design
Security section in design / functional spec.
Explaining the impact of security on the feature.
Security architecture document
Attack surface measurement
Product structure, emphasis on layering.
Exit criteria: Design review complete and signed
off by development team and SWI Buddy
Design
Team members should complete threat modeling
training.
Threat models addressing all the functionality of
the product should be completed.
Functional specs / Design specs should
document mitigations
Threat models should be reviewed by architects,
dev, test and PM to ensure its
comprehensiveness.
Design
Threat modeling in detail
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, etc (e.g. FxCop)
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
Verification
Security Testing in detail
Final Security Review (FSR)
“From a security viewpoint, is this software ready to
deliver to customers?”
Two to six months prior to software completion
Software must be in a stable state with only minimal non-security
changes expected prior to release
FSR components
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
Final Security Review (FSR)
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)
FSR is NOT “penetrate and patch”
Response Phase
Patch Management in place
Team on standby to address security response
issues if necessary.
Post Mortems and feedback to the SDL
Reinitiate security push (or more of process)
Update code review guidelines
Update tools
Other corrective steps as needed
Security Development Lifecycle (with Privacy) Tasks
mapped against Traditional Microsoft Software Development Lifecycle
V 1.4 (Jan 28, 2005)
FPR needed for initial public prerelease (alpha or beta releases), and
subsequent releases if significant
changes happen after initial release
Privacy Additions to SDL
Alpha & Beta Pre releases
Security Training with Privacy Added
Privacy
Initial
Assessment
Privacy
Design
Best
Practices
Privacy
Detailed
Asmt
(P1 & P2)
Privacy
Design
Review
(P1 &
some P2)
Privacy Added
To Threat Modeling
Use Privacy
Development Tools &
Privacy Best Dev +
Test Practices
Draft
Privacy
Policy
Stmt
Consult with Privacy
SMEs as needed
Formal Privacy Reviews (FPR) of P1
Products for EACH Public Release
(Random FPR audits for P2)
FPR*
FPR*
FPR*
FPR*
Create Privacy GPO and Deployment Guides
Final
Safety
Review
(Privacy
+
Security)
Sign off on
Updated Privacy
Requirements
In
Checkpoint Express
Privacy
Servicing
&
Response
Execution
Final
Security
Review
Sign off on
Security
Requirements
In
Checkpoint Express
Security
Servicing
&
Response
Execution
Prepare Privacy Response Plan
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
Pen Testing
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
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
Implications for Partners and Customers
As operating system security improves, attackers will
move “up the stack”
Be ready to meet the challenge
Take advantage of SDL lessons learned
Use available resources (Microsoft or other)
Tools
Books
Training
Process details less important than process
Try the process
Measure effectiveness
Update the process
Summary
Security is an evolving challenge
SDL process has proven effective at
improving software security
SDL can be emulated by other
organizations
Key component of SDL – and improving
security – is commitment to continuous
improvement
Threat Modeling Tool
http://www.microsoft.com/downloads/details
.aspx?familyid=59888078-9DAF-4E96B7D1-944703479451&displaylang=en
© 2005 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.
