2. The Trustworthy Computing Security Development Lifecycle Steve Lipner Director of Security Engineering Strategy Security Business and Technology Unit Microsoft Corporation SLipner@microsoft.com Steve Lipner Director of Security Engineering Strategy Security Business and Technology Unit Microsoft Corporation SLipner@microsoft.com

3. 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) “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)

4. Process + Education + Accountability Security Development Lifecycle

5. 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 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

7. 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) 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)

8. 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 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

9. 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 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

10. 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 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

11. 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)

12. 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

13. 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 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

14. 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 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

15. 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” 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”

16. 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)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 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)http://www.microsoft.com/learning

17. Education Resources

18. 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 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

19. Source: Microsoft Security Bulletin Search SDL Results: Windows Server 2003

20. 22 35 21 35 18 Client OS Critical and Important Security Bulletins Professional Service Pack 1Service Pack 2 Source: Microsoft Security Bulletin Search SDL Results: Client OS

21. SDL Results: SQL Server SQL Server 2000 2002-2005 (YTD)

22. SDL Results: IIS 4.0, 5.0, 5.1, 6.0 IIS 4.0, 5.0, 5.1, 6.0 2002-2005 (YTD)

23. 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! 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!

24. © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

25. Sample fill color 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 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

26. 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 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

27. Sample Bar Chart

28. Demo Title Name Title Group Name Title Group

29. Video Title

30. Partner Title Name Title Company Name Title Company

31. Customer Title Name Title Company Name Title Company

32. Announcement Title

33. © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.