More Related Content
![[DevSecOps Live] DevSecOps: Challenges and Opportunities](https://cdn.slidesharecdn.com/ss_thumbnails/20200316dsochallengesopportunities-200416111818-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to Microsoft Security Development Lifecycle
Microsoft Security Development Lifecycle
- 1. Microsoft Security Development Lifecycle(SDL) Razi Rais | Senior Software Engineer | Microsoft
- 2.
- 3. Tech Foundation UserGroup Founder Established in 2011 IT Pros and Developers Open for all to join! JOIN https://www.meetup.com/techfoundation
- 4. Key Takeaways UnderstandSDL (Secure Development Lifecycle) Process & Practices needed for SDL Threat Modeling Q&A Slides will be emailed to you! Reach out for full workshop!
- 5. History of SDL| Started with a memo!!
- 6. History of SDLat Microsoft • Bill Gates writes “Trustworthy Computing” memo early 2002 • “Windows security push” for Windows Server 2003 • Security push and FSR (Final Security Review) extended to other products • Microsoft Senior Leadership Team agrees to require SDL for all products that: • Are exposed to meaningful risk and/or • Are Process sensitive data • SDL is enhanced • “Fuzz” testing • Code analysis • Crypto design requirements • Privacy • Banned APIs • and more… • Windows Vista is the first OS to go through full SDL cycle • Optimize the process through feedback, analysis and automation • Evangelize the SDL to the software development community: • SDL Process Guidance • SDL Optimization Model • SDL Pro Network • SDL Threat Modeling Tool • SDL Process Templates 2002-2003 2004 2005-2007 Now
- 7. SDL | BiggerPicture Education Accountability Administer and track security training Incident Response (MSRC) Establish release criteria and sign-off as part of FSR Process Guide product teams to meet SDL requirements
- 8. Pre-SDL Requirements: SecurityTraining Requirements Design Implementation Verification Release Response Assess organizational knowledge on security and privacy – establish training program as necessary Establish training criteria Content covering secure design, development, test and privacy Establish minimum training frequency Employees must attend n classes per year Establish minimum acceptable group training thresholds Organizational training targets (e.g. 80% of all technical personnel trained prior to product RTM)
- 9. Phase One: Requirements Opportunityto consider security at the outset of a project Design Implementation Verification Release Response Security Advisor reviews product plan, makes recommendations, may set additional requirements Mandate the use of a bug tracking/job assignment system Define and document security and privacy bug bars Development team identifies security and privacy requirements Development team identifies lead security and privacy contacts Security Advisor assigned
- 10. SDL Security &Privacy Bug Bar Privacy bug bar sample https://docs.microsoft.com/en-us/previous- versions/windows/desktop/cc307403(v=msdn.10)?r edirectedfrom=MSDN Security Bug Bar https://docs.microsoft.com/en- us/previous- versions/windows/desktop/cc307404(v=msdn.10)?r edirectedfrom=MSDN
- 11. Phase Two: Design Identify design techniques (layering, managed code, least privilege, attack surface minimization) Document attack surface and limit through default settings Define and document security architecture, identify security critical components Implementation Verification Release Response Threat Modeling Systematic review of features and product architecture from a security point of view Identify threats and mitigations Online services specific requirements
- 12. Phase Three: Implementation Fullspectrum review – used to determine processes, documentation and tools necessary to ensure secure deployment and operation Verification Release Response Specification of approved build tools and options Static analysis (PREFix, /analyze (PREfast), FXCop) Banned APIs Use of operating system “defense in depth” protections (NX, ASLR and HeapTermination) Online services specific requirements (e.g., Cross-site scripting , SQL Injection etc.) Consider other recommendations (e.g., Standard Annotation Language (SAL))
- 13. Phase Four: Verification Startedas early as possible – conducted after “code complete” stage Release Response Start security response planning – including response plans for vulnerability reports Re-evaluate attack surface Fuzz testing – files, installable controls and network facing code Online services specific requirements Conduct “security push” (as necessary) Not a substitute for security work done during development Code review Penetration testing and other security testing Review design and architecture in light of new threats
- 14. Phase Five: Release– Response Plan Creation of a clearly defined support policy – consistent with MS corporate policies Response Provide Software Security Incident Response Plan (SSIRP) Identify contacts for MSRC and resources to respond to events 24x7x365 contact information for 3-5 engineering, 3-5 marketing, and 1-2 management (PUM and higher) individuals Ensure ability to service all code including “out of band” releases and all licensed 3rd party code. Complete final signoffs on Checkpoint Express – validating security, privacy and corporate compliance policies
- 15. Post-SDL Requirement: Response “Planthe work, work the plan…” Execution on response tasks outlined during Security Response Planning and Release Phases
- 16. SDL Guidance forAgile Methodologies Requirements defined by frequency, not phase Every-Sprint (most critical) One-Time (non-repeating) Bucket (all others)
- 17. Alert: SDL RequiresProcess Improvement! Simply “looking for bugs” doesn’t make software secure Must reduce the chance vulnerabilities enter into design and code Requires executive commitment Requires ongoing process improvement Requires education & training Requires tools and automation Requires incentives and consequences
- 18. Resources Simplified Implementationof Microsoft SDL (Document & Planning Sheet)https://www.microsoft.com/en- us/download/details.aspx?id=12379
- 19. Resources Practical Guideto A Practical Guide to Designing Secure Health Solutions Using Microsoft Azure https://aka.ms/azureindustrysecurity
- 20. Resources Microsoft SDLCryptographic Recommendations http://download.microsoft.com/download/6/3/A/63AFA3DF -BB84-4B38-8704- B27605B99DA7/Microsoft%20SDL%20Cryptographic%20Re commendations.pdf
- 21. Resources Manage theSecurity Risk of Using Third-Party Components https://safecode.org/wp- content/uploads/2017/05/SAFECode _TPC_Whitepaper.pdf
- 22. Resources Microsoft SDLTools https://www.microsoft.com/en- us/securityengineering/sdl/resources
- 23.
- 24. Threat Modeling Why? Find security and privacy problems when there’s time to fix them Security Development Lifecycle (SDL) requirement Deliver more secure products Who? The bad guys will do a good job of it! Maybe you will…your choice What? A repeatable process to find and address threats to your product When? The earlier you start, the more time to plan and fix Worst case is when you’re trying to ship/release
- 25. Example | ArchitectureDiagram
- 26. Example | BuildThreat Model
- 27. Example | ReviewThreats
- 28. Example | ReviewThreats
- 29. Resources Microsoft ThreatModeling Tool: https://www.microsoft.com/en- us/securityengineering/sdl/threatmodeling Microsoft Secure Development Lifecycle: https://www.microsoft.com/en- us/securityengineering/sdl Threat Modeling Course: https://www.linkedin.com/learning/learning-threat-modeling-for- security-professionals/ Getting Started Guide: https://docs.microsoft.com/en-us/azure/security/develop/threat- modeling-tool-getting-started Introduction to SDL: https://download.microsoft.com/download/9/3/5/935520EC-D9E2-413E-BEA7- 0B865A79B18C/Introduction%20to%20the%20Microsoft%20Security%20Development%20Lifecycle%20 (SDL).ppsx