The Trustworthy Computing Security Development Lifecycle Steve Lipner Director of Security Engineering Strategy Security Business and Technology Unit.
Jan 11, 2016
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
The Trustworthy ComputingSecurity Development LifecycleThe Trustworthy ComputingSecurity Development Lifecycle
Steve LipnerDirector of Security Engineering StrategySecurity Business and Technology UnitMicrosoft [email protected]
Steve LipnerDirector of Security Engineering StrategySecurity Business and Technology UnitMicrosoft [email protected]
Microsoft Security EffortsMicrosoft Security Efforts
“B2 security” was an original objective of Windows NTSecurity vulnerabilities made need for improved security clear in late 1990sThrough 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 trainingCommon toolsTeam-wide “security days”
Introduction of Trustworthy Computing (early 2002)Windows (and other) security pushesFocused reviews of designs, code, penetration resistance
Security Development Lifecycle formalized (early 2004)
“B2 security” was an original objective of Windows NTSecurity vulnerabilities made need for improved security clear in late 1990sThrough 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 trainingCommon toolsTeam-wide “security days”
Introduction of Trustworthy Computing (early 2002)Windows (and other) security pushesFocused reviews of designs, code, penetration resistance
Security Development Lifecycle formalized (early 2004)
Process+
Education +
Accountability
Security Development Lifecycle
Engineering ExcellenceThe Security Development Lifecycle (SDL)Engineering ExcellenceThe 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 riskEVOLVING and new factors, such as privacy, are being addedCOMPATIBLE with COTS product development processesEFFECTIVE 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
A PROCESS by which Microsoft develops software, that defines security requirements and milestones
MANDATORY for products that are exposed to meaningful security riskEVOLVING and new factors, such as privacy, are being addedCOMPATIBLE with COTS product development processesEFFECTIVE 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
Requirements Design Implementation Verification Release Support & Servicing
Functional Specifications
Design Specifications
Testing and Verification
Development of New CodeBug fixes
Code Signing & Checkpoint
Express Signoff
RTM
Alpha & Beta Pre releases
Feature ListsQuality
GuidelinesArchitecture Docs
Schedules
Product SupportService Packs/QFEs
Security Updates
FinalSecurityReview
SecurityServicing
&ResponseExecution
PrepareSecurity
ResponsePlan
SecurityPush
Security Kickoff&
RegisterWith SWI
Use SecurityDevelopment Tools
&Security Best
Dev & Test PracticesThreat
Modeling
SecurityDesign
BestPractices
CreateSecurity
DocumentationAnd Tools
For Product
Security Training
Pen Testing
Final Release CandidateProduct Code
Complete
SecurityArchitecture
& Attack Surface Review
Threat ModelingComplete and
MitigationsReflected in
Specifications
Security Development Lifecycle Tasks and Processes
Traditional Microsoft Software Product Development Lifecycle Tasks and Process
Sign off onSecurity
RequirementsIn
Checkpoint Express
Security Development Lifecycle TasksMapped Against Traditional Microsoft
Software Development LifecycleV 1.4 (Jan 28, 2005)
Requirements Design Implementation Verification Release Support & Servicing
Functional Specifications
Design Specifications
Testing and Verification
Development of New CodeBug fixes
Code Signing & Checkpoint
Express Signoff
RTM
Alpha & Beta Pre releases
Feature ListsQuality
GuidelinesArchitecture Docs
Schedules
Product SupportService Packs/QFEs
Security Updates
FinalSecurityReview
SecurityServicing
&ResponseExecution
PrepareSecurity
ResponsePlan
SecurityPush
Security Kickoff&
RegisterWith SWI
Use SecurityDevelopment Tools
&Security Best
Dev & Test PracticesThreat
Modeling
SecurityDesign
BestPractices
CreateSecurity
DocumentationAnd Tools
For Product
Security Training
Pen Testing
Final Release CandidateProduct Code
Complete
SecurityArchitecture
& Attack Surface Review
Threat ModelingComplete and
MitigationsReflected in
Specifications
Security Development Lifecycle Tasks and Processes
Traditional Microsoft Software Product Development Lifecycle Tasks and Process
Sign off onSecurity
RequirementsIn
Checkpoint Express
Security Development Lifecycle TasksMapped Against Traditional Microsoft
Software Development LifecycleV 1.4 (Jan 28, 2005)
Requirements PhaseRequirements Phase
Consider security at the outsetSecure Windows Initiative (SWI) team assigns SWI BuddyDevelopment team identifies security functional requirementsSWI Buddy reviews product plan, makes recommendations, ensures resources allocated by managementSWI Buddy assesses security milestones and exit criteria(NOTE: This SWI Buddy will stay with the project through the Final Security Review)
Consider security at the outsetSecure Windows Initiative (SWI) team assigns SWI BuddyDevelopment team identifies security functional requirementsSWI Buddy reviews product plan, makes recommendations, ensures resources allocated by managementSWI Buddy assesses security milestones and exit criteria(NOTE: This SWI Buddy will stay with the project through the Final Security Review)
DesignDesign
Define and document security architectureIdentify 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 settingsCreate threat models (e.g., identify assets, interfaces, threats, risk) and mitigate threats through countermeasuresIdentify specialized test toolsDefine supplemental ship criteria due to unique product issues (e.g., cross-site scripting tests)Confer with SWI Buddy on questions
Define and document security architectureIdentify 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 settingsCreate threat models (e.g., identify assets, interfaces, threats, risk) and mitigate threats through countermeasuresIdentify specialized test toolsDefine supplemental ship criteria due to unique product issues (e.g., cross-site scripting tests)Confer with SWI Buddy on questions
DevelopmentDevelopment
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
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
VerificationVerification
Software functionality complete and enters BetaBecause code complete, testing both new and legacy codeSecurity Push
Security push is not a substitute for security work during developmentSecurity push provides an opportunity to focus on security
Code reviews (especially legacy/unchanged code)Penetration and other security testingReview design, architecture, threat models in light of new threats
Software functionality complete and enters BetaBecause code complete, testing both new and legacy codeSecurity Push
Security push is not a substitute for security work during developmentSecurity push provides an opportunity to focus on security
Code reviews (especially legacy/unchanged code)Penetration and other security testingReview design, architecture, threat models in light of new threats
Final Security Review (FSR)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)
“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)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
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 PhaseResponse Phase
Microsoft Security Response CenterDetect and respond to externally discovered vulnerabilities and attacks
Sustained Engineering TeamsDevelop, test, package updates
Patch ManagementSimplify update deployment for consumers and organizations
Post Mortems and feedback to the SDLSearch for related vulnerabilitiesInitiate “mini-security push” if neededDocument lessons learned to update tools, processes
Microsoft Security Response CenterDetect and respond to externally discovered vulnerabilities and attacks
Sustained Engineering TeamsDevelop, test, package updates
Patch ManagementSimplify update deployment for consumers and organizations
Post Mortems and feedback to the SDLSearch for related vulnerabilitiesInitiate “mini-security push” if neededDocument lessons learned to update tools, processes
Maintaining the SDLMaintaining the SDL
SDL process is NOT static!Process updates released on a six-month cycle
Draft requirements 1 March and 1 SeptemberRequirements finalized 1 April and 1 OctoberRequirements effective 1 July and 1 January
Proposed updates reviewed broadly by Microsoft security and engineering teams
SDL process is NOT static!Process updates released on a six-month cycle
Draft requirements 1 March and 1 SeptemberRequirements finalized 1 April and 1 OctoberRequirements effective 1 July and 1 January
Proposed updates reviewed broadly by Microsoft security and engineering teams
Maintaining the SDLMaintaining the SDL
Updates reflect new challenges and new solutions
Updated requirements respond to new threatsInteger 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 requirementsIf approach proves ineffective
If problem “solved”
Updates reflect new challenges and new solutions
Updated requirements respond to new threatsInteger 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 requirementsIf approach proves ineffective
If problem “solved”
Education for the SDLEducation for the SDL
New employees do not arrive with ability to develop secure software
Microsoft trains staff as a part of New Employee OrientationMicrosoft trains staff as part of a security pushMicrosoft trains developers, testers, program managers, user education staff and architects annuallyMicrosoft funds academic curriculum development through Microsoft ResearchMicrosoft publishes material on writing secure code, threat modeling, and SDL (pending) and offers courses (see http://www.microsoft.com/learning)
New employees do not arrive with ability to develop secure software
Microsoft trains staff as a part of New Employee OrientationMicrosoft trains staff as part of a security pushMicrosoft trains developers, testers, program managers, user education staff and architects annuallyMicrosoft funds academic curriculum development through Microsoft ResearchMicrosoft publishes material on writing secure code, threat modeling, and SDL (pending) and offers courses (see http://www.microsoft.com/learning)
Education ResourcesEducation Resources
Accountability for SDLAccountability for SDL
You can’t manage what you can’t measure…Education
Individual learning measurementTeam training compliance
Process implementationIn-process metrics provide early warning
Threat model completionCode reviewedTest coverageFSR results
Post-release metrics assess final payoffTotal and high severity vulnerabilities
You can’t manage what you can’t measure…Education
Individual learning measurementTeam training compliance
Process implementationIn-process metrics provide early warning
Threat model completionCode reviewedTest coverageFSR results
Post-release metrics assess final payoffTotal and high severity vulnerabilities
Source: Microsoft Security Bulletin Search
SDL Results: Windows Server 2003SDL Results: Windows Server 2003
2222
3535
2121
3535
1818
Client OS Critical and Important Client OS Critical and Important Security BulletinsSecurity Bulletins
Professional Service Pack 1 Service Pack 2
Source: Microsoft Security Bulletin Source: Microsoft Security Bulletin SearchSearch
SDL Results: Client OSSDL Results: Client OS
SDL Results: SQL ServerSDL Results: SQL Server
SQL Server 2000 SQL Server 2000 2002-2005 (YTD)2002-2005 (YTD)
SDL Results: IIS 4.0, 5.0, 5.1, 6.0SDL Results: IIS 4.0, 5.0, 5.1, 6.0
IIS 4.0, 5.0, 5.1, 6.0 IIS 4.0, 5.0, 5.1, 6.0 2002-2005 (YTD)2002-2005 (YTD)
Thoughts for the Academic CommunityThoughts for the Academic Community
Security educationWe 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 researchWe (and the industry) need better predictive metrics!
Security educationWe 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 researchWe (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.
Sample fillSample fillcolorcolor
Sample fillSample fillcolorcolor
Sample fillSample fillcolorcolor
PowerPoint GuidelinesPowerPoint 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
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
PowerPoint TemplateSubtitle colorPowerPoint TemplateSubtitle color
Example of a slide with a subheadSet 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
Example of a slide with a subheadSet 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 ChartSample Bar Chart
0
10
20
30
40
50
60
70
80
90
1st Qtr 2nd Qtr 3rd Qtr 4th Qtr
East
WestNorth
Demo TitleDemo Title
NameTitleGroup
NameTitleGroup
Video TitleVideo Title
Partner TitlePartner Title
NameTitleCompany
NameTitleCompany
Customer TitleCustomer Title
NameTitleCompany
NameTitleCompany
Announcement TitleAnnouncement Title
© 2005 Microsoft Corporation. All rights reserved.This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.
Related Documents
