slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Privacy and Security by Design: How Microsoft Builds Privacy and Security into Software and Online Services PowerPoint Presentation
Download Presentation
Privacy and Security by Design: How Microsoft Builds Privacy and Security into Software and Online Services

Loading in 2 Seconds...

play fullscreen
1 / 50

Privacy and Security by Design: How Microsoft Builds Privacy and Security into Software and Online Services - PowerPoint PPT Presentation


  • 192 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Privacy and Security by Design: How Microsoft Builds Privacy and Security into Software and Online Services' - martha


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

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

Agenda

  • Background
  • Privacy at Microsoft
  • Security at Microsoft
  • Call to Action…
privacy versus security
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

security and privacy process
Security and Privacy Process

Deliverables throughout the Product lifecycle.

Integrated Compliance Tracking Tools

Online and Live Privacy Training available

© 2006 Microsoft Corporation

why bother with privacy
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
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
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
public guidelines definitions1
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
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
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
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

transfer pii notice and consent1
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 consent2
Transfer PII - Notice and Consent
  • Should clearly distinguish in user interface (UI) between optional and required items

Mandatory

transfer pii security and data integrity
Transfer PII - Security and Data Integrity
  • Should use data validation controls to filter out inconsistent, incomplete or incorrect PII
transfer pii security and data integrity1
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
Transfer PII - Access
  • Must provide a secure means for individuals to access and correct their PII
who is sec

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

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)

security development lifecycle

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
more encouraging results

More Encouraging results

IIS5 vs IIS6

SQL Server 2000 vs SQL Server 2000 SP3

Typically ~50%

reduction in vulnerabilities

IE6 vs IE6 SP2

security development lifecycle competition recognition

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

secure product development requires process improvements

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
requirements phase

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
design phase

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
implementation phase

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)
verification phase

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

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
final security review

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
summary

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

slide35

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

encouraging results

Encouraging results

http://blogs.csoonline.com/april_2007_operating_system_vulnerability_scorecard

industry context

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

sdl education and training

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

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
sdl evolution

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
SDL Phases—extended versions
  • The next slides contain more detail than the ones used in the presentation
requirements phase1

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
design phase1

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
implementation phase1

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)
verification phase1

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
security response planning1

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.
final security review1

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
release phase

Release Phase

  • After everything has been reviewed and approved…
  • Complete other corporate release policies and processes