Adam ShostackSenior Program Manager

Security Engineering & Communications

Sue GlueckSenior Privacy Attorney

Microsoft Corporation

•Background•Privacy at Microsoft•Security at Microsoft•Call to Action…

Privacy versus SecurityPrivacy versus SecurityPrivacy: 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 notrespect the privacy of the user.

Privacy AND Security are key factors for trust

IAPP_10-19-2006a.ppt © 2006 Microsoft Corporation 5

Security and Privacy Security and Privacy ProcessProcess

Deliverables throughout the Product lifecycle.Deliverables throughout the Product lifecycle.Integrated Compliance Tracking ToolsIntegrated Compliance Tracking ToolsOnline and Live Privacy Training availableOnline and Live Privacy Training available

Why bother with privacy?Why bother with privacy?Keeps us out of legal hot water

High stakes, lowers overall riskCOPPA, GLBA, HIPAA, CFAA, EU, FTC

Unblocks product deploymentsEnterprise, government

Increases customer satisfaction and trustLoyalty goes up with choice and controlPowerful emotional factor, "Right Thing" to do

What did we do?What did we do?1. Created rules2. Built privacy into the design process3. Created tools4. Setup and empowered a team5. 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 Public Guidelines DefinitionsDefinitions

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, orFrom which identification or contact information of an individual person can be derivedIncludes: name, address, phone number, fax number, email address, financial profiles, medical profile, national ID numbers (e.g., social security number), and credit card informationIncludes 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 Public Guidelines DefinitionsDefinitions

Types of NoticeProminentDiscoverable

Types of ConsentOpt-in Explicit ConsentOpt-out Explicit ConsentImplicit Consent

Please send me the latest informationon special offers of Xbox® games.

Public Guidelines Public Guidelines -- 9 9 ScenariosScenarios1. Transferring PII to and from the User’s System2. Storing PII on the Customer’s System3. Transferring Anonymous Data from Customer’s System4. Installing Software on a Customer’s System5. Deploying a Web Site 6. Storing and Processing User Data at the Company7. Transferring User Data outside the Company8. Interacting with Children9. Server Deployment

Transfer PII from the Transfer PII from the UserUser’’s Systems System

Examples: Sending product registration to the CompanySubmitting data customer entered in a web formTransferring a file containing hidden PII

Transfer PII Transfer PII -- Notice and Notice and ConsentConsent

Must provide user prominent notice and get explicit opt-in consent at any point prior to transferMust provide a privacy statement or similar discoverable notice

ValueProposition

Privacy ImpactExplicit Opt-in Consent

Discoverable Notice

Transfer PII Transfer PII -- Notice and Notice and ConsentConsent

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

Transfer PII Transfer PII -- Notice and Notice and ConsentConsent

Should clearly distinguish in user interface (UI) between optional and required items

Mandatory

Transfer PII Transfer PII -- Security and Security and Data IntegrityData Integrity

Should use data validation controls to filter out inconsistent, incomplete or incorrect PII

Transfer PII Transfer PII -- Security and Security and Data IntegrityData Integrity

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

Transfer PII Transfer PII -- AccessAccessMust 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 PescatoreVice President and Distinguished Analyst

Gartner, Inc(From CRN, Feb 13th 2006)

ProcessProcess

EducationEducation

AccountabilityAccountability

Defines security requirements and milestonesMANDATORY if exposed to meaningful security risksRequires response and service planningIncludes Final Security Review (FSR) and Sign-off

Mandatory annual training – internal trainersBlueHat – external speakers on current trendsPublish guidance on writing secure code, threat modeling and SDL; as well as courses

In-process metrics to provide early warningPost-release metrics assess final payoff (# of vulns)Training compliance for team and individuals

64

27

0

10

20

30

40

50

60

70

IE 6 SP1 (pre-SDL) IE 6 SP2 (post -SDL)

16

30

2

4

6

8

10

12

14

16

SQL Server 2000 (pre-SDL) SQL Server 2000 SP3 (post -SDL)

3

10

1

2

3

IIS5 (pre-SDL) IIS6 (post -SDL)

Typically ~50%reduction in vulnerabilities

IIS5 vs IIS6IIS5 vs IIS6 SQL Server 2000 vs SQL Server 2000 SQL Server 2000 vs SQL Server 2000 SP3SP3

IE6 vs IE6 SP2IE6 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 PetersJune 2, 2006

http://www.artima.com/weblogs/viewpost.jsp?thread=162577

•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 securityvulnerabilities

•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

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

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

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

http://blogs.csoonline.com/april_2007_operating_system_vulnerability_scorecard

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 rolesand 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 growth2. 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 team1. Register for a security advisor2. Identify security contact in product team3. Track security issues in bug tracking system explicitly4. 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 team1. Follow Microsoft Privacy Standard2. Security design review for “V1” products3. Satisfy minimal cryptographic requirements, including crypto agility4. 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 team1. Min version of build tools + build options (/GS, /SAFESEH, /NXCOMPAT)2. Use of appropriate static analysis tools + fix minimum warning reqs3. No Banned APIs in new code + No shared PE sections4. Service Watson /GS reports5. Vista Heap Termination support6. 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 team1. Fuzz testing for files, RPC, ActiveX controls, network facing code2. Use AppVerifier3. Re-evaluate attack surface4. Run binary analysis tests to verify build options on all code in product5. Validate security tools and documentation needs of customers6. 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 team1. Clearly defined support policy that is consistent with MS policy2. Provide Software Security Incident Response Plan (SSIRP)

1. Identify contacts for MSRC and resources to respond to events2. 24x7x365 contact information for 3-5 engineering, 3-5 marketing, and 1-2

management (PUM and higher) individuals3. 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 team1. Reflect and plan for FSR in product schedule2. Coordinate with SWI well in advance3. Ensure that all information (questionnaire + tool results) is provided well before FSR

begins4. 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 team1. Successfully complete FSR2. Security response plan done3. Customer documentation up-to-date4. Provide final RTM symbols to a central location5. Complete final signoffs on “Checkpoint Express”

1. Validating security & other Microsoft corporate policies