Process+

Education +

Accountability

Security Development Lifecycle

Security Development LifecycleSecurity Development Lifecycle

A PROCESS by which Microsoft develops software, that A PROCESS by which Microsoft develops software, that defines security requirements and milestonesdefines security requirements and milestones

MANDATORY for products that are exposed to meaningful security MANDATORY for products that are exposed to meaningful security riskrisk

EVOLVING and new factors, such as privacy, are being addedEVOLVING and new factors, such as privacy, are being added

COMPATIBLE with COTS product development processesCOMPATIBLE with COTS product development processes

EFFECTIVE at addressing security issues; designed to produce EFFECTIVE at addressing security issues; designed to produce DEMONSTRATABLE RESULTS DEMONSTRATABLE RESULTS (not all methodologies do this)(not all methodologies do this)

It has shown itself to be highly effective at reducing vulnerabilities in It has shown itself to be highly effective at reducing vulnerabilities in commercial softwarecommercial software

A Security FrameworkA Security FrameworkSDSD33+C+C

Threat modelingThreat modelingCode inspectionCode inspectionPenetration testingPenetration testing

Unused features off by defaultUnused features off by defaultReduce attack surface areaReduce attack surface areaLeast PrivilegeLeast Privilege

Prescriptive GuidancePrescriptive GuidanceSecurity Tools Security Tools Training and EducationTraining and Education

Community EngagementCommunity EngagementTransparencyTransparencyClear policyClear policy

Requirements Design Implementation Verification Release Support & Servicing

Functional Specifications

Design Specifications

Testing and Verification

Development of New CodeBug fixes

Code Signing & Checkpoint

Express Signoff

RTM

Alpha & Beta Pre releases

Feature ListsQuality

GuidelinesArchitecture Docs

Schedules

Product SupportService Packs/QFEs

Security Updates

FinalSecurityReview

SecurityServicing

&ResponseExecution

PrepareSecurity

ResponsePlan

SecurityPush

Security Kickoff&

RegisterWith SWI

Use SecurityDevelopment Tools

&Security Best

Dev & Test PracticesThreat

Modeling

SecurityDesign

BestPractices

CreateSecurity

DocumentationAnd Tools

For Product

Security Training

Pen Testing

Final Release CandidateProduct Code

Complete

SecurityArchitecture

& Attack Surface Review

Threat ModelingComplete and

MitigationsReflected in

Specifications

Security Development Lifecycle Tasks and Processes

Traditional Microsoft Software Product Development Lifecycle Tasks and Process

Sign off onSecurity

RequirementsIn

Checkpoint Express

Security Development LifecycleSecurity Development Lifecyclevs. vs.

Traditional Development LifecycleTraditional Development Lifecycle

Security Development Lifecycle Security Development Lifecycle (SDL)(SDL)

Product Development TimelineProduct Development TimelineProduct Development TimelineProduct Development Timeline

Education-New Hire-Refresher

Design phase-Security plan complete-Security milestones understood-Design standards & guidelines identified-Security architecture complete-Threat models & design review complete-Ship criteria agreed upon

Requirements phase-Security “buddy” assigned

Implementation phase-Secure coding standards adhered to-Security testing standards adhered to-Security tools use

Verification phase-Security push

Release phase-Final Security Review

RTM & deployment-PRS requires FSR sign-off

Security response

http://swi/sdl

Security Development LifecycleSecurity Development Lifecycle

DrilldownDrilldown

Education and AwarenessEducation and Awareness(Prior to Requirements)(Prior to Requirements)

All disciplines (Dev/QA/PM/UA/UE) must understand All disciplines (Dev/QA/PM/UA/UE) must understand security!security!

All disciplines must complete at least one security training All disciplines must complete at least one security training class sometime in the last 12 months class sometime in the last 12 months

All disciplines must complete the following reading:All disciplines must complete the following reading:Writing Secure Code, Version 2 Writing Secure Code, Version 2 ((ISBN:  0-7356-1722-8ISBN:  0-7356-1722-8))

Threat ModelingThreat Modeling(ISBN: 0-7356-1991-3(ISBN: 0-7356-1991-3 ))

Exit criteriaExit criteriaSuccessful completion of requirements listed above Successful completion of requirements listed above

Required ReadingRequired Reading

Phase 1: RequirementsPhase 1: Requirements

Opportunity to consider security at the outsetOpportunity to consider security at the outset

Development team identifies security requirementsDevelopment team identifies security requirementsWho will use the applicationWho will use the application

Are security requirements equal for all usersAre security requirements equal for all users

Standalone, Intranet or Extranet availabilityStandalone, Intranet or Extranet availability

Internal or external usageInternal or external usage

What are the assetsWhat are the assets

What are the implications if security failsWhat are the implications if security fails

Who is responsible for operationsWho is responsible for operations

Project InceptionProject Inception(Requirements)(Requirements)

Designate a security coordinatorDesignate a security coordinator

Update Bug reporting toolsUpdate Bug reporting toolsSecurity Bug Effect fieldSecurity Bug Effect field

Security Cause fieldSecurity Cause field

Security bug bar documentSecurity bug bar documentCritical, Important & moderate bugs fixed before RTMCritical, Important & moderate bugs fixed before RTM. .

Project InceptionProject InceptionConfigure the bug reporting toolConfigure the bug reporting tool

Add a Security Bug Effect fieldAdd a Security Bug Effect fieldNot a Security Bug Not a Security Bug

Spoofing Spoofing

Tampering Tampering

Repudiation Repudiation

Information Disclosure Information Disclosure

Denial of Service Denial of Service

Elevation of Privilege Elevation of Privilege

Attack Surface Reduction*Attack Surface Reduction*

Project InceptionProject InceptionConfigure the bug reporting toolConfigure the bug reporting tool

Add a Security Cause fieldAdd a Security Cause field

Cryptographic Weakness Cryptographic Weakness

Weak Authentication Weak Authentication

Weak Authorization/Bad ACL Weak Authorization/Bad ACL

Ineffective Secret Hiding Ineffective Secret Hiding

Unlimited Resource Unlimited Resource Consumption Consumption

Incorrect/No Error Messages Incorrect/No Error Messages

Bad/No Path Canonicalization Bad/No Path Canonicalization

OtherOther

Not a Security Bug Not a Security Bug

Buffer Overflow/Underflow Buffer Overflow/Underflow

Arithmetic Error (int Arithmetic Error (int overflow) overflow)

SQL/Script Injection SQL/Script Injection

Directory Traversal Directory Traversal

Race Condition Race Condition

Cross-Site Scripting Cross-Site Scripting

Cryptographic Weakness Cryptographic Weakness

Project InceptionProject InceptionDeliverablesDeliverables

Security Plan DocumentSecurity Plan Document

Outlines the processes and work items that a Outlines the processes and work items that a product team will follow in order to integrate SDL product team will follow in order to integrate SDL into their product development process into their product development process

Security Bug Bar DefinitionSecurity Bug Bar Definition

Project Inception Project Inception (Microsoft specific)(Microsoft specific)

Secure Windows Initiative (SWI) team assigns Secure Windows Initiative (SWI) team assigns SWI BuddySWI Buddy

SWI Buddy reviews product plan, makes SWI Buddy reviews product plan, makes recommendations, ensures resources allocated recommendations, ensures resources allocated by managementby management

SWI Buddy assesses security milestones and SWI Buddy assesses security milestones and exit criteriaexit criteria

(NOTE: This SWI Buddy will stay with the project (NOTE: This SWI Buddy will stay with the project through the Final Security Review)through the Final Security Review)

DesignDesign

Define and document security architectureDefine and document security architecture

Identify security critical components (“trusted base”) Identify security critical components (“trusted base”)

Identify design techniques (e.g., layering, managed code, Identify design techniques (e.g., layering, managed code, least privilege, attack surface minimization)least privilege, attack surface minimization)

Document attack surface and limit through default settingsDocument attack surface and limit through default settings

Create threat models (e.g., identify assets, interfaces, Create threat models (e.g., identify assets, interfaces, threats, risk) and mitigate threats through threats, risk) and mitigate threats through countermeasurescountermeasures

Identify specialized test toolsIdentify specialized test tools

Define supplemental ship criteria due to unique product Define supplemental ship criteria due to unique product issues (e.g., cross-site scripting tests)issues (e.g., cross-site scripting tests)

DesignDesign

Security section in design / functional spec.Security section in design / functional spec.Explaining the impact of security on the feature.Explaining the impact of security on the feature.

Security architecture document Security architecture document Attack surface measurementAttack surface measurement

Product structure, emphasis on layering. Product structure, emphasis on layering.

Exit criteria: Exit criteria: Design review complete and signed Design review complete and signed off by development team and SWI Buddyoff by development team and SWI Buddy

DesignDesign

Team members should complete threat modeling Team members should complete threat modeling training.training.

Threat models addressing all the functionality of Threat models addressing all the functionality of the product should be completed.the product should be completed.

Functional specs / Design specs should Functional specs / Design specs should document mitigationsdocument mitigations

Threat models should be reviewed by architects, Threat models should be reviewed by architects, dev, test and PM to ensure its dev, test and PM to ensure its comprehensiveness.comprehensiveness.

DesignDesign

Threat modeling in detailThreat modeling in detail

DevelopmentDevelopment

Apply coding and testing standards (e.g., Apply coding and testing standards (e.g., safe string handling)safe string handling)

Apply fuzz testing tools (structured invalid Apply fuzz testing tools (structured invalid inputs to network protocol and file parsers)inputs to network protocol and file parsers)

Apply static code analysis tools to find, e.g., Apply static code analysis tools to find, e.g., buffer overruns, integer overruns, buffer overruns, integer overruns, uninitialized variables, etc (e.g. FxCop)uninitialized variables, etc (e.g. FxCop)

Conduct code reviewsConduct code reviews

VerificationVerification

Software functionality complete Software functionality complete and enters Betaand enters Beta

Because code complete, testing both new and Because code complete, testing both new and legacy codelegacy code

Security PushSecurity PushSecurity push is not a substitute for security work Security push is not a substitute for security work during developmentduring development

Security push provides an opportunity to focus on Security push provides an opportunity to focus on securitysecurity

Code reviews (especially legacy/unchanged code)Code reviews (especially legacy/unchanged code)

Penetration and other security testingPenetration and other security testing

Review design, architecture, threat models in light of new Review design, architecture, threat models in light of new threatsthreats

VerificationVerification

Security Testing in detailSecurity Testing in detail

Final Security Review (FSR)Final Security Review (FSR)

““From a security viewpoint, is this software ready to From a security viewpoint, is this software ready to deliver to customers?” deliver to customers?”

Two to six months prior to software completionTwo to six months prior to software completionSoftware must be in a stable state with only minimal non-security Software must be in a stable state with only minimal non-security changes expected prior to releasechanges expected prior to release

FSR componentsFSR componentsCompletion of a questionnaire by the product teamCompletion of a questionnaire by the product teamInterview by a security team member assigned Interview by a security team member assigned to the FSRto the FSRReview of bugs that were initially identified as security bugs, but on Review of bugs that were initially identified as security bugs, but on further analysis were determined not to have impact on security, to further analysis were determined not to have impact on security, to ensure that the analysis was done correctlyensure that the analysis was done correctlyAnalysis of any newly reported vulnerabilities affecting similar Analysis of any newly reported vulnerabilities affecting similar software to check for resiliencysoftware to check for resiliencyAdditional penetration testing, possibly by outside contractors to Additional penetration testing, possibly by outside contractors to supplement security teamsupplement security team

Final Security Review (FSR)Final Security Review (FSR)

FSR results: If the FSR finds a pattern of FSR results: If the FSR finds a pattern of remaining vulnerabilities, the proper remaining vulnerabilities, the proper response is not just to fix the vulnerabilities response is not just to fix the vulnerabilities found, but to revisit the earlier phases and found, but to revisit the earlier phases and take pointed actions to address root take pointed actions to address root causes (e.g., improve training, enhance causes (e.g., improve training, enhance tools)tools)

FSR is NOT “penetrate and patch”FSR is NOT “penetrate and patch”

Response PhaseResponse Phase

Patch Management in placePatch Management in place

Team on standby to address security response Team on standby to address security response issues if necessary.issues if necessary.

Post Mortems and feedback to the SDLPost Mortems and feedback to the SDLReinitiate security push (or more of process)Reinitiate security push (or more of process)

Update code review guidelinesUpdate code review guidelines

Update toolsUpdate tools

Other corrective steps as neededOther corrective steps as needed

Requirements Design Implementation Verification Release Support & Servicing

Functional Specifications

Design Specifications

Testing and Verification

Development of New CodeBug fixes

Code Signing & Checkpoint

Express Signoff

RTM

Alpha & Beta Pre releases

Feature ListsQuality

GuidelinesArchitecture Docs

Schedules

Product SupportService Packs/QFEs

Security Updates

FinalSecurityReview

SecurityServicing

&ResponseExecution

PrepareSecurity

ResponsePlan

SecurityPush

Security Kickoff&

RegisterWith SWI

Use SecurityDevelopment Tools

&Security Best

Dev & Test PracticesThreat

Modeling

SecurityDesign

BestPractices

CreateSecurity

DocumentationAnd Tools

For Product

Security Training

Pen Testing

Final Release CandidateProduct Code

Complete

SecurityArchitecture

& Attack Surface Review

Threat ModelingComplete and

MitigationsReflected in

Specifications

Security Development Lifecycle Tasks and Processes

Traditional Microsoft Software Product Development Lifecycle Tasks and Process

Sign off onSecurity

RequirementsIn

Checkpoint Express

Final SafetyReview(Privacy

+ Security)

PrivacyServicing

&ResponseExecution

Prepare Privacy Response Plan

PrivacyDesignBest

Practices

Create Privacy GPO and Deployment Guides

Security Training with Privacy Added

Sign off onUpdated Privacy

RequirementsIn

Checkpoint Express

Formal Privacy Reviews (FPR) of P1Products for EACH Public Release

(Random FPR audits for P2)

Use PrivacyDevelopment Tools &Privacy Best Dev +

Test Practices

Privacy Additions to SDL

Security Development Lifecycle (with Privacy) Tasksmapped against Traditional Microsoft Software Development Lifecycle

V 1.4 (Jan 28, 2005)

Alpha & Beta Pre releases

PrivacyDesignReview(P1 &

some P2)

PrivacyInitial

Assessment

DraftPrivacyPolicyStmt

FPR*FPR*

PrivacyDetailed

Asmt(P1 & P2)

FPR*FPR*

Privacy AddedTo Threat Modeling

FPR needed for initial public pre-release (alpha or beta releases), and

subsequent releases if significant changes happen after initial release

Consult with Privacy SMEs as needed

Accountability for SDLAccountability for SDL

You can’t manage what you can’t measure…You can’t manage what you can’t measure…

EducationEducationIndividual learning measurementIndividual learning measurement

Team training complianceTeam training compliance

Process implementationProcess implementationIn-process metrics provide early warningIn-process metrics provide early warning

Threat model completionThreat model completion

Code reviewedCode reviewed

Test coverageTest coverage

FSR resultsFSR results

Post-release metrics assess final payoffPost-release metrics assess final payoffTotal and high severity vulnerabilitiesTotal and high severity vulnerabilities

Implications for Partners and CustomersImplications for Partners and Customers

As operating system security improves, attackers will As operating system security improves, attackers will move “up the stack”move “up the stack”

Be ready to meet the challengeBe ready to meet the challenge

Take advantage of SDL lessons learnedTake advantage of SDL lessons learned

Use available resources (Microsoft or other)Use available resources (Microsoft or other)ToolsTools

Books Books

TrainingTraining

Process details less important than processProcess details less important than processTry the processTry the process

Measure effectivenessMeasure effectiveness

Update the processUpdate the process

SummarySummary

Security is an evolving challengeSecurity is an evolving challenge

SDL process has proven effective at SDL process has proven effective at improving software securityimproving software security

SDL can be emulated by other SDL can be emulated by other organizationsorganizations

Key component of SDL – and improving Key component of SDL – and improving security – is commitment to continuous security – is commitment to continuous improvement improvement

Threat Modeling ToolThreat Modeling Tool

http://www.microsoft.com/downloads/http://www.microsoft.com/downloads/details.aspx?familyid=59888078-9DAF-details.aspx?familyid=59888078-9DAF-4E96-B7D1-4E96-B7D1-944703479451&displaylang=en944703479451&displaylang=en

© 2005 Microsoft Corporation. All rights reserved.© 2005 Microsoft Corporation. All rights reserved.This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.This presentation is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.