Introduction to the Microsoft Security Development Lifecycle (SDL)

8/3/2019 Introduction to the Microsoft Security Development Lifecycle (SDL)

1/30

Introduction to the

Microsoft SecurityDevelopment Lifecycle(SDL)Secure software made easier


2/30

Agenda

Applications under attack

Origins of the Microsoft SDL

What is Microsoft doing about the threat?

Measurable improvements at Microsoft


3/30

Applications underattack


4/30

Cybercrime Evolution

LANs

First PC virus

Motivation:damage

19861995

Internet Era

Big Worms

Motivation:damage

19952003

OS, DB attacks

Spyware, Spam

Motivation:Financial

2004+

Targeted attacks

Socialengineering

Financial +Political

2006+

2007 Market prices:

Credit Card Number $0.50 - $20

Full Identity $1 - $15

Bank Account $10 - $1000

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

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


5/30

Attacks are focusing on applications

90% of vulnerabilities are remotely

From the Microsoft Security Intelligence Report V7

Sources: IBM X-Force, 2008

% of vulnerability disclosures:Operating system vs browser and application vulnerabilities


6/30

Most vulnerabilities are in smaller

ISV apps

Vendors' accountability for vulnerabilities in 2008

Sources: IBM X-Force 2008 Security Report


7/30

Origins of the MicrosoftSDL


8/30

Security Timeline at Microsoft

2002-2003

2004

2005-2007

Now

Bill GateswritesTrustworthyComputing

memo early2002

Windowssecurity pushfor WindowsServer 2003

Security push

MicrosoftSeniorLeadership

Team agreesto require SDLfor all productsthat:

Are exposedto meaningfulrisk and/or

Are Processsensitive data

SDL isenhanced

Fuzz testing Code analysis Crypto design

requirements Privacy Banned APIs and more

Windows Vistais the first OSto go throughfull SDL cycle

Optimize theprocessthroughfeedback,analysis andautomation

Evangelizethe SDL to thesoftwaredevelopmentcommunity: SDL Process

Guidance SDL

OptimizationModel

SDL ProNetwork

SDL ThreatModeling Tool

SDL ProcessTemplates


9/30

Which apps are required to follow

SDL?Any release commonlyused or deployed withinan enterprise,business, or organization

Any release thatregularly stores,processes, orcommunicates PII (as

defined inMicrosoft Privacy Guidelines

for Developing Software Products and Services

) or othersensitive customer

Any release that acceptsand/or processes datafroman unauthenticatedsource

Any functionality thatparses any file type thatis not

protected, (i.e. notlimited to systemadministrators)

Any release that

contains ActiveX and/orCOM controls
http://www.microsoft.com/downloads/details.aspx?FamilyID=c48cf80f-6e87-48f5-83ec-a18d1ad2fc1f&displaylang=enhttp://www.microsoft.com/downloads/details.aspx?FamilyID=c48cf80f-6e87-48f5-83ec-a18d1ad2fc1f&displaylang=enhttp://www.microsoft.com/downloads/details.aspx?FamilyID=c48cf80f-6e87-48f5-83ec-a18d1ad2fc1f&displaylang=enhttp://www.microsoft.com/downloads/details.aspx?FamilyID=c48cf80f-6e87-48f5-83ec-a18d1ad2fc1f&displaylang=enhttp://www.microsoft.com/downloads/details.aspx?FamilyID=c48cf80f-6e87-48f5-83ec-a18d1ad2fc1f&displaylang=en


10/30

What is Microsoft doingabout the threat?


11/30

Working to protect our users

Education

Accountability

Administer and tracksecurity training

IncidentResponse (MSRC)

Establish releasecriteria and sign-off as

part of FSR

Ongoing Process Improvements

Process

Guide product teamsto meet SDLrequirements


12/30

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 priorto product RTM)

Requirements Design Implementation Verification Release Response


13/30

Phase One: Requirements

Opportunity to consider security at theoutset of a project

Development team identifies security and privacyrequirements

Development team identifies lead security andprivacy contacts

Security Advisor assigned

Security Advisor reviews product plan, makesrecommendations

Design Implementation Verification Release Response


14/30

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 touni ue roduct issues

Define and document security architecture, identify securitycritical components

Implementation Verification Release Response


15/30

Phase Three: Implementation

Full spectrum review used to determineprocesses, documentationand tools necessary to ensure securedeployment and operation

Specification of approved build tools and optionsStatic analysis (PREFix, /analyze (PREfast), FXCop)

Banned APIs

Use of operating system defense in depthrotections

Verification Release Response


16/30

Phase Four: Verification

Started as early as possible conducted after code complete stageStart security response planning including response plans for vulnerabilityreports

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


17/30

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 bandreleases and all licensed 3rd party code.

Response


18/30

Phase Five: Release Final Security

Review

Verify SDL requirements are met and thereare no knownsecurity vulnerabilities

Provides an independent view into security ship

readinessThe FSR is NOT:

A penetration test no penetrate and patch allowed

The first time security is reviewed

Response


19/30

Phase Five: Release Archive

Security response plan completeCustomer documentation up-to-date

Archive RTM source code, symbols, threat models to a centrallocation

Complete final signoffs on Checkpoint Express validatingsecurity, privacy and corporate compliance policies

Response


20/30

Post-SDL Requirement: Response

Plan the work, work the planExecution on response tasks outlined during SecurityResponse Planning and Release Phases


21/30

Training Requirements Design Implementation Verification Release

LOB-specific

training

Risk assessment

Applicationportfolio Application Riskassessment Determineservice level

Asset-centric

threat modeling

Threat model Design review

Internal review

Incorporatesecuritychecklists andstandards Conduct selfcode review Security Code

analysis

Pre-production

assessment

Comprehensivesecurityassessment Bug remediation

Post-production

assessment

Host level scan

SDL Process Guidance for LOB Apps

Line-of-Business applications are a set of critical computer applications that are vital torunning an enterprise, such as accounting, human resources (HR), payroll, supply chainmanagement, and resource planning applications.

Many of the requirements and recommendations in the SDL for online services areclosely 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 LOBapplication development while meeting SDL requirements.

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


22/30

SDL Guidance for Agile

MethodologiesRequirements defined byfrequency, not phase

Every-Sprint (most critical)One-Time (non-repeating)

Bucket (all others)

Great for projects without enddates, like cloud services


23/30

Secure Software Development

Requires Process Improvement

Key Concepts

Simply looking for bugs doesnt 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


24/30

Measurable ImprovementsAt Microsoft


25/30

Microsoft SDL and Windows

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

Before SDL After SDL

45% reduction in Vulnerabilities

TotalVulnerabilities Disclosed

One YearAfterRelease


26/30

Microsoft SDL and SQL Server

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

Before SDL After SDL91% reduction in Vulnerabilities

Total VulnerabilitiesDisclosed36 Months After Release


27/30

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 widelyavailable

and accessible


28/30

SDL Portalhttp://www.microsoft.com/sdl

SDL Blog

http://blogs.msdn.com/sdl/

SDL Process on MSDN(Web)

http://msdn.microsoft.com/en-us/library/cc3

SDL Process on MSDN (MSWord)

http://www.microsoft.com/downloads/detail

Resources
http://www.microsoft.com/sdlhttp://blogs.msdn.com/sdl/http://msdn.microsoft.com/en-us/library/cc307748.aspxhttp://www.microsoft.com/downloads/details.aspx?FamilyID=d045a05a-c1fc-48c3-b4d5-b20353f97122&displaylang=enhttp://www.microsoft.com/downloads/details.aspx?FamilyID=d045a05a-c1fc-48c3-b4d5-b20353f97122&displaylang=enhttp://msdn.microsoft.com/en-us/library/cc307748.aspxhttp://blogs.msdn.com/sdl/http://www.microsoft.com/sdl


29/30

Questions?


30/30

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/orother 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 Microsoftmust 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.

Introduction to the Microsoft Security Development Lifecycle (SDL)

Documents

Transcript of Introduction to the Microsoft Security Development Lifecycle (SDL)