The Trustworthy Computing Security Development Lifecycle

2. The Trustworthy ComputingSecurity Development Lifecycle 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)

4. Process+Education +Accountability Security Development Lifecycle

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

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

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

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

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)

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

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

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

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”

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)

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

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

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

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!

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. 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 fillcolor Sample fillcolor Sample fillcolor

26. PowerPoint TemplateSubtitle 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 NameTitle Group

29. Video Title

30. Partner Title NameTitle Company

31. Customer Title NameTitle 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.