Microsoft Security Development Lifecycle for IT

1. Microsoft Security Development Lifecycle for IT Rob Labbé Security Engagement Manager MSIT Infosec – ACE roblab@microsoft.com

2. Microsoft IT Environment First and Best Customer 94,000 Vista clients 48,000 Windows 7 clients 127,238 Office 2007 clients 129,000 Exchange 2007 mailboxes 359,000 SharePoint Sites MSCRM deployment for premier services business Dynamics business running on Dynamics products Enterprise Infrastructure High Scale Processes 5 data centers 9,700 production servers 108,000 servers (MSN) 98 countries 550 buildings 260,000+ SMS managed computers 585,000 devices 141,549 end users 2,400,000 internal e-mails with 18,000,000 inbound (97% filter rate) 36,000,000 IMs per month 136,000+ e-mail server accounts 137,000,000+ remote connections per month

3. Know Yourself, Know your Enemies “If you know your enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle.” Sun Tzu, The Art of War “Hacking Microsoft UK” http://www.youtube.com/watch?v=tJSRnJkH2Ek

4. The Reasons for Secure Software

5. Application Layer = Weak Point • Attackers target the weakest point. The OS Layer and Network layer are too hard now • On Average over 70% of IT security budget is spent on Infrastructure, yet over 75% of attacks happen at the Application level • According to Microsoft research, only 1/3 of developers are confident that they write secure code • The focus must be on hardening the application layer

6. Reasons for IT Security • Card Services - A Real World Example • $10 Million a month in revenue • Processed credit cards for American Express, Master Card, and VISA • They Lost 40 Million records to hacking • Government imposed heavy fines • Subject to audits every 6 months for 20 years • Amex, Master Card and Visa dropped them • A $10 Million a month company destroyed

7. Understanding The Attackers

8. National Interest, Chaos Steal Something of Value / assets Personal Fame, To Embarrass, To Win Curiosity Nothing Spy, Terrorist Thief, Booster, Fence, Classic Criminals Disgruntled Employee Mal-Tech Trespasser Author Vandal, Cyberpunk Anyone Un- intentional HobbyistHacker Script- Kiddie Expert Specialist

9. Hackers are very smart

10. We need better security

11. Implement an SDL • Implement an SDL to build security into your development process • Train your developers in secure coding techniques • Incorporate Threat Modeling, Secure Code Review, Security Focused Testing into the process

12. Purpose of the SDL • Inventory and assess applications • Identify and ensure resolution of security/privacy vulnerabilities found in those applications • Enable Application Risk Management: • Strategic • Tactical • Operational • Legal

13. The SDL is NOT Optional • At Microsoft all line-of-business application teams must go through SDL-IT, All shrink-wrapped products must go through the SDL • If they fail to do so, they cannot go into production • Enforcement of the SDL-IT process attributes to it’s success

14. Visibly Measure the Process • Have internally visible score cards • Have contests to see if you can find bugs and offer prizes • Offer incentives to teams with the best security records (no cheating!)

15. SDL aligns with SDLC Design Develop / Purchase Envision Test Release / Sustainment SDLC Threat Model / Design Review Application Entry / Risk Assessment Post-Production Assessment Internal Review Pre-Production Assessment SDL-IT

16. Application Entry / Risk Assessment Post-Production Assessment App Entry Internal Review • Objective: • Application Inventory • Determine Application Risk Categorization • High Risk Security/Privacy Release • Medium Risk Security/Privacy Release • Low Risk Security/Privacy Release Threat Model / Design Review Pre-Production Assessment

17. Threat Model / Design Review Post-Production Assessment App Entry Internal Review • Objective: • Threat modeling provides a consistent methodology for objectively evaluating threats to applications. • Review application design to verify compliance with security standards and best practices • Verify application meets application principles • Confidentiality • Integrity • Authentication • Authorization • Availability • Non-repudiation Threat Model / Design Review Pre-Production Assessment

18. Internal Review Post-Production Assessment Internal Review App Entry • Review security checklist/policy site • Team conducts ‘self’ code review and attack and penetration testing Threat Model / Design Review Pre-Production Assessment

19. Pre-Production Assessment Post-Production Assessment Internal Review App Entry • Objective: • Low Risk Applications • Host Level Scan • Windows • IIS • SQL • High/Medium Risk Applications • Host Level Scan • White Box Code Review Threat Model / Design Review Pre-Production Assessment

20. White Box Code Review • Process • Application team provides source code • Analysts review application code uncovering security vulnerabilities • Vulnerabilities logged in bug database • Application team required to address all sev 1 bugs prior to going into production

21. Some common attack patterns white box review may reveal • Cross-Site Script Vulnerabilities • SQL Injection • Buffer Overflow • Poor Authorization Controls • Secrets Stored In Clear Text

22. Post-Production Assessment Post-Production Assessment App Entry Internal Review • Objective: • High/Medium/Low Risk Applications • Host Level Scan • Windows • IIS • SQL Threat Model / Design Review Pre-Production Assessment

23. Conclusion • The need for security is obvious, we have to protect the company and our customers • To do that we need • Management Support • Secure Development Life Cycles • Developers trained in secure development • A Security First attitude!

24. Conclusions • Continuous improvement of the process • Invest time in upfront activities: • Threat Modeling • Design Reviews • A holistic view • People • Process • Tools • It may seem hard to get started – ask for help! People: Providing guidance on secure application development Process: Security cannot be an afterthought Tools: Providing the most innovative tools

25. Call To Action • Implement a Secure Development Lifecycle • Create more secure and reliable software • Build Trust!

26. Resources • ACE Team Blog: • http://blogs.msdn.com/ace_team/default.aspx • Threat Modeling Tool • http://go.microsoft.com/fwlink?linkid=77002 • Threat Modeling Blog: • http://blogs.msdn.com/threatmodeling/

27. © 2006 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.