Adam Shostack Senior Program Manager Security Engineering & Communications Sue Glueck Senior Privacy Attorney Microsoft Corporation

Background Privacy at Microsoft Security at Microsoft Call to Action…

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

IAPP_ a.ppt© 2006 Microsoft Corporation5 Security and Privacy Process Deliverables throughout the Product lifecycle. Integrated Compliance Tracking Tools Online and Live Privacy Training available

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? 1. Created rules 2. Built privacy into the design process 3. Created tools 4. Setup and empowered a team 5. Created a public version of the rules – the Privacy Guidelines for Developing Software Products and Services (available at

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, 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

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

Public Guidelines - 9 Scenarios 1. Transferring PII to and from the User’s System 2. Storing PII on the Customer’s System 3. Transferring Anonymous Data from Customer’s System 4. Installing Software on a Customer’s System 5. Deploying a Web Site 6. Storing and Processing User Data at the Company 7. Transferring User Data outside the Company 8. Interacting with Children 9. 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 Privacy Impact Explicit Opt-in Consent 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

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

“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 13 th 2006)

Process Education Accountability  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

Typically ~50% reduction in vulnerabilities IIS5 vs IIS6 SQL Server 2000 vs SQL Server 2000 SP3 IE6 vs IE6 SP2

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,

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

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

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

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)

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

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

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

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

Privacy: Download the Privacy Guidelines at Send us feedback at 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

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

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

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

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

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 1.Annual formal training + ongoing career growth 2.Planned migration towards “dual horizon” model

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

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 1.Register for a security advisor 2.Identify security contact in product team 3.Track security issues in bug tracking system explicitly 4.Define and document a “bug bar”

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

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 1.Min version of build tools + build options (/GS, /SAFESEH, /NXCOMPAT) 2.Use of appropriate static analysis tools + fix minimum warning reqs 3.No Banned APIs in new code + No shared PE sections 4.Service Watson /GS reports 5.Vista Heap Termination support 6.Several online services requirements

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 1.Fuzz testing for files, RPC, ActiveX controls, network facing code 2.Use AppVerifier 3.Re-evaluate attack surface 4.Run binary analysis tests to verify build options on all code in product 5.Validate security tools and documentation needs of customers 6.Several online services requirements 7.Provide all necessary security response planning deliverables

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 1.Clearly defined support policy that is consistent with MS policy 2.Provide Software Security Incident Response Plan (SSIRP) 1.Identify contacts for MSRC and resources to respond to events 2.24x7x365 contact information for 3-5 engineering, 3-5 marketing, and 1-2 management (PUM and higher) individuals 3.Ability to service all code, including OOB releases and “giblets”

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 1.Reflect and plan for FSR in product schedule 2.Coordinate with SWI well in advance 3.Ensure that all information (questionnaire + tool results) is provided well before FSR begins 4.Keep SWI informed of schedule changes

After everything has been reviewed and approved… Complete other corporate release policies and processes Microsoft’s SDL requirements for product team 1.Successfully complete FSR 2.Security response plan done 3.Customer documentation up-to-date 4.Provide final RTM symbols to a central location 5.Complete final signoffs on “Checkpoint Express” 1.Validating security & other Microsoft corporate policies