Microsoft Security Development Lifecycle

1. Microsoft Security Development Lifecycle امیرحسین علی اکبریان

2. Education +Process Improvement+Accountability Security Development Lifecycle

3. 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 • It has shown itself to be highly effective at reducing vulnerabilities in commercial software

4. Threat modeling Code inspection Unused features off by default Reduce attack surface area Least Privilege Security Tools Training and Education Community Engagement Transparency Clear policy A Security FrameworkSD3+C

5. Security Development Lifecycle (SDL) http://swi/sdl

6. Security Development Lifecycle Drilldown

7. Pre-SDL Requirement Security Training

8. SDL Practice 1: Training Requirement • Secure Design • Threat Modeling • Secure Coding • Security Testing • Privacy

9. Phase One Requirements

10. SDL Practice 2: Security Requirements • The optimal point to define trustworthiness requirements • Includes specification of minimum security requirements for the application

11. SDL Practice 3: Quality Gates/Bug Bars • Establish minimum acceptable levels of security and privacy quality • Improves the understanding of risks

12. SDL Practice 4: Security and Privacy Risk Assessment • Identify functional aspects of the software that require deep review • Include following information • (Security) Which portions of the project will require threat models before release? (Security) Which portions of the project will require security design reviews before release? • (Security) Which portions of the project (if any) will require penetration testing by a mutually agreed upon group that is external to the project team? • (Security) Are there any additional testing or analysis requirements the security advisor deems necessary to mitigate security risks? • (Security) What is the specific scope of the fuzz testing requirements? • (Privacy) What is the Privacy Impact Rating?

13. Phase Two Design

14. SDL Practice 5: Design Requirements • “Secure Features” vs. “Security Features” • Creation of security and privacy design specifications • design specifications against the application’s functional specification • Specification review • Specification of minimal cryptographic design requirements

15. SDL PRACTICE 6: ATTACK SURFACE REDUCTION • reducing risk by giving attackers less opportunity to exploit a potential weak spot or vulnerability • shutting off or restricting access to system services • applying the principle of least privilege • employing layered defenses

16. SDL PRACTICE 7: THREAT MODELING • used in environments where there is meaningful security risk • to consider, document, and discuss the security implications of designs • STRIDE

17. Phase 4: Implementaion

18. SDL Practice 8: Use Approved Tools • Define and publish a list of approved tools • Use the latest version of approved tools

19. SDL Practice 9: Deprecate Unsafe Functions • prohibit functions and APIs that are determined to be unsafe • header files (such as banned.h and strsafe.h) • newer compilers • code scanning tools

20. SDL Practice 10: Static Analysis • Can help ensure that secure coding policies are being followed • other tools or human review as appropriate

21. Phase 4 Verification

22. SDL Practice 11: Dynamic Program Analysis • Run-time verification of software

23. SDL Practice 12: Fuzz Testing • a specialized form of dynamic analysis • malformed or random data

24. SDL Practice 13: Threat Model and Attack Surface Review • Check deviation from design and requirements

25. Phase 5 Release

26. SDL Practice 14: Incident Response Plan • programs with no known vulnerabilities at the time of release can be subject to new threats that emerge over time

27. SDL Practice 15: Final Security Review • performed by the security advisor with assistance from the regular development staff and the security and privacy team leads • not a “penetrate and patch” exercise, nor is it a chance to perform security activities that were previously ignored or forgotten • Result • Passed FSR • Passed FSR with exceptions • FSR with escalation

28. SDL Practice 16: Release/Archive • Check that all Security and Privacy conditions are satisfied • Archive data for post-release servicing of the software

29. Optional Activities • Depend on size and security impact • Manual Code Review • Penetration Testing • Vulnerability Analysis of Similar Applications

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