introduction to the microsoft security development lifecycle sdl n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Introduction to the Microsoft ® Security Development Lifecycle (SDL) PowerPoint Presentation
Download Presentation
Introduction to the Microsoft ® Security Development Lifecycle (SDL)

Loading in 2 Seconds...

play fullscreen
1 / 30

Introduction to the Microsoft ® Security Development Lifecycle (SDL) - PowerPoint PPT Presentation


  • 257 Views
  • Uploaded on

Introduction to the Microsoft ® Security Development Lifecycle (SDL). Secure software made easier . Agenda. Applications under attack Origins of the Microsoft SDL What is Microsoft doing about the threat? Measurable improvements at Microsoft. Applications under attack….

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 'Introduction to the Microsoft ® Security Development Lifecycle (SDL)' - elsa


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
introduction to the microsoft security development lifecycle sdl

Introduction to the Microsoft® Security Development Lifecycle (SDL)

Secure software made easier

agenda
Agenda
  • Applications under attack
  • Origins of the Microsoft SDL
  • What is Microsoft doing about the threat?
  • Measurable improvements at Microsoft
cybercrime evolution
Cybercrime Evolution

1986–1995

1995–2003

2004+

2006+

  • LANs
  • First PC virus
  • Motivation: damage
  • Internet Era
  • “Big Worms”
  • Motivation: damage
  • OS, DB attacks
  • Spyware, Spam
  • Motivation: Financial
  • Targeted attacks
  • Social engineering
  • Financial + Political

 Cost of U.S. cybercrime: About $70B

Source: U.S. Government Accountability Office (GAO), FBI

slide5

Attacks are focusing on applications

% of vulnerability disclosures:

Operating system vs browser and application vulnerabilities

From the Microsoft Security Intelligence Report V7

90% of vulnerabilities are remotely exploitable

Sources: IBM X-Force, 2008

most vulnerabilities are in smaller isv apps
Most vulnerabilities are in smaller ISV apps

Sources: IBM X-Force 2008 Security Report

security timeline at microsoft
Security Timeline at Microsoft…

Now

  • Optimize the process through feedback,analysis and automation
  • Evangelize the SDL to the software development community:
    • SDL Process Guidance
    • SDL Optimization Model
    • SDL Pro Network
    • SDL Threat Modeling Tool
    • SDL Process Templates

2005-2007

  • SDL is enhanced
    • “Fuzz” testing
    • Code analysis
    • Crypto design requirements
    • Privacy
    • Banned APIs
    • and more…
  • Windows Vista is the first OS to go through full SDL cycle

2004

  • Microsoft Senior Leadership Team agrees to require SDL for all products that:
    • Are exposed to meaningful risk and/or
    • Are Process sensitive data

2002-2003

  • Bill Gates writes “Trustworthy Computing” memo early 2002
  • “Windows security push” for Windows Server 2003
  • Security push and FSR extended to other products
which apps are required to follow sdl
Which apps are required to follow SDL?
  • Any release commonly used or deployed within an enterprise, business, or organization
  • Any release that regularly stores, processes, or communicates PII (as defined in Microsoft Privacy Guidelines for Developing Software Products and Services) or other sensitive customer information
  • Any release that regularly touches or listens on the Internet or other networks
  • Any release that accepts and/or processes data from an unauthenticated source
  • Any functionality that parses any file type that is not protected, (i.e. not limited to system administrators)
  • Any release that contains ActiveX and/or COM controls
  • All Microsoft, MSN and Live.com online services that are used by external customers and hosted in the MSN environment
working to protect our users
Working to protect our users…

Education

Process

Accountability

Administer and track security training

Guide product teams to meet SDL requirements

Establish release criteria and sign-off as part of FSR

Incident

Response (MSRC)

Ongoing Process Improvements

pre sdl requirements security training
Pre-SDL Requirements: Security Training

Assess organizational knowledge on security and privacy –establish training program as necessary

  • Establish training criteria
    • Content covering secure design, development, test and privacy
  • Establish minimum training frequency
    • Employees must attend n classes per year
  • Establish minimum acceptable group training thresholds
    • Organizational training targets (e.g. 80% of all technical personnel trained prior to product RTM)

Requirements

Design

Implementation

Verification

Release

Response

phase one requirements
Phase One: Requirements

Opportunity to consider security at the outset of a project

  • Development team identifies security and privacy requirements
  • Development team identifies lead security and privacy contacts
  • Security Advisor assigned
  • Security Advisor reviews product plan, makes recommendations,may set additional requirements
  • Mandate the use of a bug tracking/job assignment system
  • Define and document security and privacy bug bars

Design

Implementation

Verification

Release

Response

phase two design
Phase Two: Design
  • 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
    • Cross-site scripting tests
    • Deprecation of weak crypto
  • Threat Modeling
    • Systematic review of features and product architecture from a security point of view
    • Identify threats and mitigations
  • Online services specific requirements

Implementation

Verification

Release

Response

Define and document security architecture, identify security critical components

phase three implementation
Phase Three: Implementation

Full spectrum review – used to determine processes, documentation and tools necessary to ensure secure deployment and operation

  • Specification of approved build tools and options
  • Static analysis (PREFix, /analyze (PREfast), FXCop)
  • Banned APIs
  • Use of operating system “defense in depth” protections(NX, ASLR and HeapTermination)
  • Online services specific requirements (e.g., Cross-site scripting ,SQL Injection etc)
  • Consider other recommendations (e.g., Standard Annotation Language (SAL))

Verification

Release

Response

phase four verification
Phase Four: Verification

Started as early as possible – conducted after “code complete” stage

  • Start security response planning – including response plans for vulnerability reports
  • Re-evaluate attack surface
  • Fuzz testing – files, installable controls and network facing code
  • Conduct “security push” (as necessary, increasingly rare)
    • Not a substitute for security work done during development
    • Code review
    • Penetration testing and other security testing
    • Review design and architecture in light of new threats
  • Online services specific requirements

Release

Response

phase five release response plan
Phase Five: Release – Response Plan

Creation of a clearly defined support policy – consistentwith MS corporate policies

  • 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
  • Ensure ability to service all code including “out of band” releases and all licensed 3rd party code.

Response

phase five release final security review
Phase Five: Release – Final Security Review

Verify SDL requirements are met and there are no knownsecurity vulnerabilities

  • Provides an independent view into “security ship readiness”
  • The FSR is NOT:
    • A penetration test – no “penetrate and patch” allowed
    • The first time security is reviewed
    • A signoff process
    • Key Concept: The tasks for this phase are used as a determining factor on whether or not to ship – not used as a “catchall” phase for missed work in earlier phases

Response

phase five release archive
Phase Five: Release – Archive

Security response plan complete

  • Customer documentation up-to-date
  • Archive RTM source code, symbols, threat models to a central location
  • Complete final signoffs on Checkpoint Express – validating security, privacy and corporate compliance policies

Response

post sdl requirement response
Post-SDL Requirement: Response

“Plan the work, work the plan…”

  • Execution on response tasks outlined during Security Response Planning and Release Phases
sdl process guidance for lob apps
SDL Process Guidance for LOB Apps
  • Line-of-Business applications are a set of critical computer applications that are vital to running an enterprise, such as accounting, human resources (HR), payroll, supply chain management, and resource planning applications.
  • Many of the requirements and recommendations in the SDL for online services are closely related to what is required for Line-of-Business applications.
  • Line-of-Business SDL process guidance allows you to tailor a process specific to your LOB application development while meeting SDL requirements.

The Microsoft SDL includes online services and Line-of-Business application development guidance.

sdl guidance for agile methodologies
SDL Guidance for Agile Methodologies
  • Requirements defined by frequency, not phase
    • Every-Sprint (most critical)
    • One-Time (non-repeating)
    • Bucket (all others)
  • Great for projects without end dates, like cloud services
secure software development requires process improvement
Secure Software Development Requires Process Improvement
  • Key Concepts
    • Simply “looking for bugs” doesn’t make software secure
    • Must reduce the chance vulnerabilities enter into design and code
    • Requires executive commitment
    • Requires ongoing process improvement
    • Requires education & training
    • Requires tools and automation
    • Requires incentives and consequences
microsoft sdl and windows
Microsoft SDL and Windows

Total Vulnerabilities Disclosed One Year After Release

Before SDL

After SDL

45% reduction in Vulnerabilities

Source: Windows Vista One Year Vulnerability Report, Microsoft Security Blog 23 Jan 2008

microsoft sdl and sql server
Microsoft SDL and SQL Server

Total Vulnerabilities Disclosed 36 Months After Release

After SDL

Before SDL

91% reduction in Vulnerabilities

Sources: Analysis by Jeff Jones (Microsoft technet security blog)

summary
Summary

Attacks are moving to the application layer

SDL = embedding security into software and culture

Measurable results for Microsoft software

Microsoft is committed to making SDL widely available and accessible

resources
Resources
  • SDL Portal

http://www.microsoft.com/sdl

  • SDL Blog
  • http://blogs.msdn.com/sdl/
  • SDL Process on MSDN (Web)
  • http://msdn.microsoft.com/en-us/library/cc307748.aspx
  • SDL Process on MSDN (MS Word)
  • http://www.microsoft.com/downloads/details.aspx?FamilyID=d045a05a-c1fc-48c3-b4d5-b20353f97122&displaylang=en
slide30

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