Privacy and Security by Design: How Microsoft Builds Privacy and Security into Software and Online Services

1. Privacy and Security by Design: How Microsoft Builds Privacy and Security into Software and Online Services Adam Shostack Senior Program Manager Security Engineering & Communications Sue Glueck Senior Privacy Attorney Microsoft Corporation

2. Agenda • Background • Privacy at Microsoft • Security at Microsoft • Call to Action…

3. Background

4. Privacy versus Security Privacy:Empowering users to control the collection, use, and distribution of their personal information Security:Establishing protective measures that defend against hostile acts or influences It is possible to have a secure system that does not respect the privacy of the user. Privacy AND Security are key factors for trust

5. Security and Privacy Process Deliverables throughout the Product lifecycle. Integrated Compliance Tracking Tools Online and Live Privacy Training available © 2006 Microsoft Corporation

6. Privacy at Microsoft

7. Why bother with privacy? • Keeps us out of legal hot water • High stakes, lowers overall risk • COPPA, GLBA, HIPAA, CFAA, EU, FTC • Unblocks product deployments • Enterprise, government • Increases customer satisfaction and trust • Loyalty goes up with choice and control • Powerful emotional factor, "Right Thing" to do

8. What did we do? • Created rules • Built privacy into the design process • Created tools • Setup and empowered a team • Created a public version of the rules – the Privacy Guidelines for Developing Software Products and Services (available at http://go.microsoft.com/fwlink/?LinkID=75045)

9. Public Guidelines Definitions • Personally Identifiable Information (PII) is any information: • That identifies or can be used to identify, contact, or locate the person to whom such information pertains, or • From which identification or contact information of an individual person can be derived • Includes: name, address, phone number, fax number, email address, financial profiles, medical profile, national ID numbers (e.g., social security number), and credit card information • Includes information associated with PII • Anonymous Data: • Is not unique or tied to a specific person such as hair color, system configuration, method by which product was purchased (retail, online, etc), or usage statistics distilled from a large collection of users • Note that if this information is associated with PII, it must also be treated like PII

10. Public Guidelines Definitions • Please send me the latest information on special offers of Xbox® games. • Types of Notice • Prominent • Discoverable • Types of Consent • Opt-in Explicit Consent • Opt-out Explicit Consent • Implicit Consent

11. Public Guidelines - 9 Scenarios • Transferring PII to and from the User’s System • Storing PII on the Customer’s System • Transferring Anonymous Data from Customer’s System • Installing Software on a Customer’s System • Deploying a Web Site • Storing and Processing User Data at the Company • Transferring User Data outside the Company • Interacting with Children • Server Deployment

12. Transfer PII from the User’s System • Examples: • Sending product registration to the Company • Submitting data customer entered in a web form • Transferring a file containing hidden PII

13. Transfer PII - Notice and Consent • Must provide user prominent notice and get explicit opt-in consent at any point prior to transfer • Must provide a privacy statement or similar discoverable notice ValueProposition ExplicitOpt-in Consent PrivacyImpact Discoverable Notice

14. Transfer PII - Notice and Consent • Must provide prominent notice and get explicit consent if PII being transferred will be used for secondary purposes (marketing)

15. Transfer PII - Notice and Consent • Should clearly distinguish in user interface (UI) between optional and required items Mandatory

16. Transfer PII - Security and Data Integrity • Should use data validation controls to filter out inconsistent, incomplete or incorrect PII

17. Transfer PII - Security and Data Integrity • Must transfer Sensitive PII (and should transfer non-sensitive PII) using a secure method that prevents unauthorized access

18. Transfer PII - Access • Must provide a secure means for individuals to access and correct their PII

19. Security at Microsoft

20. Who is SEC? • Microsoft Security Response Center (MSRC) + Secure Windows Initiative (SWI) • Help product groups secure their products • “Security-as-in-threats” NOT “Security-as-in-crypto” • We develop, administer, and promote the SDL

21. Security Development LifecycleAnalyst recognition “We actually consider Microsoft to be leading the software [industry] now in improvements in their security development life cycle [SDL].” John Pescatore Vice President and Distinguished Analyst Gartner, Inc (From CRN, Feb 13th 2006)

22. Process Education Accountability Security Development Lifecycle • Defines security requirements and milestones • MANDATORY if exposed to meaningful security risks • Requires response and service planning • Includes Final Security Review (FSR) and Sign-off • Mandatory annual training – internal trainers • BlueHat – external speakers on current trends • Publish guidance on writing secure code, threat modeling and SDL; as well as courses • In-process metrics to provide early warning • Post-release metrics assess final payoff (# of vulns) • Training compliance for team and individuals

23. More Encouraging results IIS5 vs IIS6 SQL Server 2000 vs SQL Server 2000 SP3 Typically ~50% reduction in vulnerabilities IE6 vs IE6 SP2

24. Security Development LifecycleCompetition recognition Microsoft Under AttackNot by angry customers suing for damages after security breaches, or by governments breaking up monopolies, but by open source developers and security professionals accusing them of being obsessed by security. Johan Peters June 2, 2006 http://www.artima.com/weblogs/viewpost.jsp?thread=162577

25. Secure Product Development Requires Process Improvements • Simply “looking for bugs” doesn’t make software secure • Must reduce the chance defects enter into design and code • Requires executive commitment • Requires ongoing process improvement • Requires education • Requires tools • Requires incentive and consequences

26. Security Development Lifecycle

27. Requirements Phase • Opportunity to consider security at the outset of a project • Development team identifies security requirements • SWI or Live!/MSN Security Advisor assigned • Issue tracking and planning

28. Design Phase • Define and document security architecture, identify security critical components • Identify privacy issues • Identify design techniques (layering, managed code, least privilege, attack surface minimization) • Document attack surface and limit through default settings • Define supplemental security ship criteria due to unique product issues • ex: cross-site scripting tests • Threat Modeling • Systematic review of features and product architecture from a security point of view • Identify threats and mitigations

29. Implementation Phase • Review customer needs for documentation and tools for secure deployment and operation • Build tools and options • Static analysis tools (PREFix, /analyze (PREfast), FXCop) • Banned APIs + No shared PE sections • Use of operation system defense in depth protections • (HeapTermination & ASLR) • Online services specific requirements • Cross-site scripting , SQL Injection etc • Consider other recommendations (ex: SAL)

30. Verification Phase • Started as early as possible, conducted fully after “code complete” • Conduct all security response planning • Response plans for vulnerability reports • Security push • Not a substitute for security work done during development • Code review • Fuzzing • Pen testing and other security testing • Review design and architecture in light of new threats

31. Security Response Planning • Goal to be prepared for: • Responsible disclosures of vulnerabilities in Microsoft software • Events stemming from non-responsibly disclosed vulnerabilities • Applies Microsoft learning over last 7+ years • 24x7x365 contact information for • 3-5 engineering • 3-5 marketing • 1-2 management (Product Unit Manager or higher) individuals

32. Final Security Review • Goal: • Verify SDL requirements are met and there are no known security vulnerabilities • Provide an independent view into “security ship readiness” • The FSR is NOT • A pen test • The first time security is reviewed • A signoff that will go smoothly without preparation

33. Summary • Security is ultimately another requirement for software to satisfy, similar to any other feature • Different in that security is a holistic requirement and only one weak link in a product can break it • Building secure software requires: • Education, Process, Tools, Continual Improvement and Executive Support • Following the Security Development Lifecycle has resulted in a measurable decrease in both number and severity of vulnerabilities

34. Call to Action Privacy: Download the Privacy Guidelines at http://go.microsoft.com/fwlink/?LinkID=75045 Send us feedback at privdoc@microsoft.com Participate in the dialog - help set industry best practices Security Read The Security Development Lifecycle (Lipner and Howard) Adopt an SDL for your business Without security, there’s less “protect” in data protection

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

36. History of Secure Engineering at Microsoft

37. Encouraging results http://blogs.csoonline.com/april_2007_operating_system_vulnerability_scorecard

38. Industry Context According to the National Vulnerability Database, 262 vulnerabilities were reported in Microsoft products in 2006 NVD cataloged 6600 total vulnerabilities in 2006 (industry wide), ~18 vulnerabilities per day

39. SDL Education and Training • New employees do not arrive with ability to develop secure software • Education program currently requires each employee involved with product development to minimally enroll in one security training class each year • Security training classes available to align with multiple roles and different experience levels • Evolving towards a “dual horizon” training program that separates conceptual knowledge from specific training on tools and current techniques

40. SDL Formal Education Curriculum • Classes of Security Defects • Security Code Reviews • New Security Features in Vista • Secure Coding Practices • Security Code Review • Security Defects in Detail • Trustworthy User Interface • Using the Fuzzer Common Library • Security in .NET Framework • Understanding Exploit Development • Basics of Secure Software Design, Development, and Test • Introduction to Fuzzing • Threat Modeling • Implementing Threat Mitigations • Introduction to Cryptography • Time-tested Security Design Principles • Defect Estimation and Management • Attack Surface Reduction and Analysis • Security for Management • Introduction to the SDL and FSR Process

41. Additional Education Resources

42. SDL Evolution • Why: • Security landscape changes • New threats, increased sophistication of methods • Tools and technologies improve • Code analysis tools, Build tools, Underlying OS defense in depth technologies, Testing tools • Refining existing development processes • Threat modeling • Optimizing investments by development teams • How • Biannual change process • Company wide review opportunity • Challenges: • Diverse technologies and tools • Quantifying ROI is still as much art as science

43. SDL Phases—extended versions • The next slides contain more detail than the ones used in the presentation

44. Requirements Phase • Opportunity to consider security at the outset of a project • Development team identifies security requirements • SWI or Live!/MSN Security Advisor assigned • SA reviews product plan, makes recommendations, may set additional requirements

45. Design Phase • Define and document security architecture, identify security critical components • Identify design techniques (layering, managed code, least privilege, attack surface minimization) • Document attack surface and limit through default settings • Define supplemental security ship criteria due to unique product issues • ex: cross-site scripting tests • Threat Modeling • Systematic review of features and product architecture from a security point of view • Identify threats and mitigations

46. Implementation Phase • Review customer needs for documentation and tools for secure deployment and operation • Build tools and options • Static analysis tools (PREFix, /analyze (PREfast), FXCop) • Banned APIs + No shared PE sections • Use of operation system defense in depth protections (HeapTermination & ASLR) • Online services specific requirements • Cross-site scripting , SQL Injection etc • Consider other recommendations (ex: SAL)

47. Verification Phase • Started as early as possible, conducted fully after “code complete” • Conduct all security response planning: Response plans for vulnerability reports • Security push • Not a substitute for security work done during development • Code review • Pen testing and other security testing • Review design and architecture in light of new threats

48. Security Response Planning • Goal to be prepared for: • Responsible disclosures of vulnerabilities in Microsoft software • Events stemming from non-responsibly disclosed vulnerabilities • Applies Microsoft learning over last 7+ years.

49. Final Security Review • Goal: • Verify SDL requirements are met and there are no known security vulnerabilities • Provide an independent view into “security ship readiness” • The FSR is NOT • A pen test • The first time security is reviewed • A signoff that will go smoothly without preparation

50. Release Phase • After everything has been reviewed and approved… • Complete other corporate release policies and processes