Process + Education + Accountability Security Development Lifecycle

1. Process+Education +Accountability Security Development Lifecycle

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

3. 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 A Security FrameworkSD3+C

4. Security Development Lifecyclevs. Traditional Development Lifecycle

5. 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 • 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 Security Development Lifecycle (SDL) Product Development Timeline http://swi/sdl

6. Security Development Lifecycle Drilldown

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

8. Required Reading

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

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

11. Project InceptionConfigure 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*

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

13. Project InceptionDeliverables • 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

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

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

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

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

18. Design Threat modeling in detail

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

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

21. Verification Security Testing in detail

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

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

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

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

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

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

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

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