7/17/2018 8:17 AM 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

Agenda Background Privacy at Microsoft Security at Microsoft 7/17/2018 8:17 AM Agenda Background Privacy at Microsoft Security at Microsoft Call to Action…

Background

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 TwC About control & choice – the fair horse-trade 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

Security and Privacy Process Deliverables throughout the Product lifecycle. Integrated Compliance Tracking Tools Online and Live Privacy Training available High level Process flow looks like this.  Training throughout.  Privacy and Security start early in the development process.  Issues found early on can be mitigated much more easily and cost efficiently than issues found later. IAPP_10-19-2006a.ppt © 2006 Microsoft Corporation 5

7/17/2018 8:17 AM Privacy at Microsoft

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

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)

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 IP address – discuss IP when associated with PII and EU position

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

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

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

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 Value Proposition Explicit Opt-in Consent Privacy Impact Discoverable Notice

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

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

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

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

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

Security at Microsoft

7/17/2018 8:17 AM 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

Security Development Lifecycle Analyst recognition 7/17/2018 8:17 AM Security Development Lifecycle Analyst recognition “We actually consider Microsoft to be leading the software [industry] now in improvements in their security development life cycle [SDL].” http://www.crn.com/sections/coverstory/coverstory.jhtml;jsessionid=VV1Q351RM5A1YQSNDBOCKH0CJUMEKJVN?articleId=179103240 John Pescatore Vice President and Distinguished Analyst Gartner, Inc (From CRN, Feb 13th 2006)

Security Development Lifecycle 7/17/2018 8:17 AM Security Development Lifecycle Process 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 Education 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 Accountability In-process metrics to provide early warning Post-release metrics assess final payoff (# of vulns) Training compliance for team and individuals

More Encouraging results 7/17/2018 8:17 AM More Encouraging results IIS5 vs IIS6 SQL Server 2000 vs SQL Server 2000 SP3 Comparing Critical + Important Bulletins Typically ~50% reduction in vulnerabilities IE6 vs IE6 SP2

Security Development Lifecycle Competition recognition 7/17/2018 8:17 AM Security Development Lifecycle Competition recognition Microsoft Under Attack Not 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

Secure Product Development Requires Process Improvements 7/17/2018 8:17 AM 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

Security Development Lifecycle 7/17/2018 8:17 AM Security Development Lifecycle

7/17/2018 8:17 AM 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

7/17/2018 8:17 AM 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

7/17/2018 8:17 AM 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)

7/17/2018 8:17 AM 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

Security Response Planning 7/17/2018 8:17 AM 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

7/17/2018 8:17 AM 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

7/17/2018 8:17 AM 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

Call to Action Privacy: Security 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

7/17/2018 8:17 AM © 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.

History of Secure Engineering at Microsoft 7/17/2018 8:17 AM History of Secure Engineering at Microsoft 2002-2003 Bill Gates writes “Trustworthy Computing” memo early 2002 “Security push” originated with .NET Framework 1.0 and Windows Server 2003 Final Security Review (FSR) for Windows Server 2003 RTM proves effective Security push and FSR extended to other products Security education program deployed company wide 2004 Senior Leadership team agrees to require all products with meaningful risk to adopt Security Development Lifecycle SDL and Checkpoint Express deployed internally 2005 SDL enhancements added: “Fuzzing”, additional static code analysis rules, cryptographic design requirements and more… Increasing external visibility of SDL 2006 Additional enhancements added: Privacy, Banned APIs, VS2005 compilers, and more… Customers are asking for more information on SDL Education, tools, engagement, support…. Now Optimize the process through feedback and analysis We begin to evangelize the SDL

7/17/2018 8:17 AM Encouraging results 6 month stats will be announced 6/21, trend continues. Background on methodology is @ http://blogs.csoonline.com/methodology_sources_and_assumptions_for_monthly_vulnerability_scorecards http://blogs.csoonline.com/april_2007_operating_system_vulnerability_scorecard

7/17/2018 8:17 AM 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 MS stats from http://nvd.nist.gov/statistics.cfm?results=1 You have asked for statistics on vulnerabilities with the following limitations: Has vendor name: Microsoft Occurred after December, 2005 Occurred before January, 2007 Industry stats You have asked for statistics on vulnerabilities with the following limitations: Occurred after January, 2006 Table of Data Matching the Above Limitations Year 2006 # of Vulns 6600 % of Total 100% Table of Data Matching the Above Limitations Year 2006 2005 # of Vulns 262 18 % of Total 4% 0%

SDL Education and Training 7/17/2018 8:17 AM 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

SDL Formal Education Curriculum 7/17/2018 8:17 AM SDL Formal Education Curriculum 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 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 Annual formal training + ongoing career growth Planned migration towards “dual horizon” model

Additional Education Resources 7/17/2018 8:17 AM Additional Education Resources

SDL Evolution Why: Security landscape changes 7/17/2018 8:17 AM 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

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

7/17/2018 8:17 AM 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 Microsoft’s SDL requirements for product team Register for a security advisor Identify security contact in product team Track security issues in bug tracking system explicitly Define and document a “bug bar”

Design Phase Microsoft’s SDL requirements for product team 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 Microsoft’s SDL requirements for product team Follow Microsoft Privacy Standard Security design review for “V1” products Satisfy minimal cryptographic requirements, including crypto agility Review and apply various “sub” policies as needed e.g. firewall, APTCA, Web Services, System Services, etc. Complete threat models

Implementation Phase Microsoft’s SDL requirements for product team 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) Microsoft’s SDL requirements for product team Min version of build tools + build options (/GS, /SAFESEH, /NXCOMPAT) Use of appropriate static analysis tools + fix minimum warning reqs No Banned APIs in new code + No shared PE sections Service Watson /GS reports Vista Heap Termination support Several online services requirements

7/17/2018 8:17 AM 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 Microsoft’s SDL requirements for product team Fuzz testing for files, RPC, ActiveX controls, network facing code Use AppVerifier Re-evaluate attack surface Run binary analysis tests to verify build options on all code in product Validate security tools and documentation needs of customers Several online services requirements Provide all necessary security response planning deliverables

Security Response Planning 7/17/2018 8:17 AM 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. Microsoft’s SDL requirements for product team Clearly defined support policy that is consistent with MS policy 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 Ability to service all code, including OOB releases and “giblets”

Final Security Review Goal: 7/17/2018 8:17 AM 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 Microsoft’s SDL requirements for product team Reflect and plan for FSR in product schedule Coordinate with SWI well in advance Ensure that all information (questionnaire + tool results) is provided well before FSR begins Keep SWI informed of schedule changes

Release Phase After everything has been reviewed and approved… 7/17/2018 8:17 AM Release Phase After everything has been reviewed and approved… Complete other corporate release policies and processes Microsoft’s SDL requirements for product team Successfully complete FSR Security response plan done Customer documentation up-to-date Provide final RTM symbols to a central location Complete final signoffs on “Checkpoint Express” Validating security & other Microsoft corporate policies