1. Security Development Lifecycle Randy Guthrie Microsoft Developer Evangelist http://blogs.msdn.com/MIS_Laboratory

2. Process + Education + Accountability Security Development Lifecycle

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

4. A Security Framework SD 3 +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

5. Security Development Lifecycle vs. Traditional Development Lifecycle

6. Security Development Lifecycle (SDL) 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 Requirements phase -Security “buddy” assigned Implementation phase -Secure coding standards adhered to -Security testing standards adhered to -Security tools use Verification phase -Security push Release phase -Final Security Review RTM & deployment -PRS requires FSR sign-off Security response http://swi/sdl

7. Security Development Lifecycle and MSF Project Plans Approved Scope Complete Release Readiness Approved Deployment Complete Vision/Scope Approved MSF

8. Security Development Lifecycle Drilldown

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

10. Required Reading

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

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

13. Project Inception Configure the bug reporting tool Add a Security Bug Effect field Not a Security Bug SpoofingTamperingRepudiation Information Disclosure Denial of Service Elevation of Privilege Attack Surface Reduction*

14. Project Inception Configure the bug reporting tool Add a Security Cause field Cryptographic Weakness Weak Authentication Weak Authorization/Bad ACL Ineffective Secret Hiding Unlimited Resource Consumption Incorrect/No Error Messages Bad/No Path Canonicalization Other Not a Security Bug Buffer Overflow/Underflow Arithmetic Error (int overflow) SQL/Script Injection Directory Traversal Race Condition Cross-Site Scripting Cryptographic Weakness

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

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

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

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

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

20. Design Threat modeling in detail

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

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

23. Verification Security Testing in detail

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

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

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

28. Security Response Planning (Release) Support policy – what versions are supported, how long and in what manner. PM point of contact with MSRC. Dev, test & PM team that can work on security response issues. Owner for any code shipped should be identified. Sustaining model documented for patch release

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

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

31. 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) ToolsBooksTraining Process details less important than process Try the process Measure effectiveness Update the process

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

33. Further reading

34. Threat Modeling Tool http://www.microsoft.com/downloads/details.aspx?familyid=59888078-9DAF-4E96- B7D1-944703479451&displaylang=en

35. © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.