Microsoft Security Development Lifecycle (SDL)
Optimization Model
Introduction to the Optimization Model
Published: November 2008
Abstract
The Microsoft® Security Development Lifecycle (SDL) Optimization Model is designed to facilitate gradual,
consistent, and cost-effective implementation of the SDL by development organizations outside of Microsoft. The
model helps those responsible for integrating security and privacy into their organization’s software development
lifecycle to assess their current state and to gradually move their organizations towards the adoption of the proven
Microsoft process for producing more secure software. The SDL Optimization Model enables development
managers and IT policy makers to assess the state of security in development. They can then create a vision and
road map for reducing customer risk by creating more secure and reliable software in a cost-effective, consistent,
and gradual manner. Although achieving security assurance requires long-term commitment, this guide outlines a
plan for attaining measureable process improvements, quickly, with realistic budgets and resources.
This is the first of five resource guides. This guide introduces the concepts behind the Optimization Model, defines
the capabilities and maturity levels, and helps prepare you to begin implementing the SDL through this program.
The remaining guides each describe the path for organizations to increase their SDL capabilities from their current
state to the next, more mature level. At each level, you will find a self-assessment checklist of relevant capabilities,
advice for conducting and managing the practices to achieve these capabilities, and links to helpful resources
where additional content can be found.
For the latest information, more detailed descriptions, and the business benefits of the Microsoft Security
Development Lifecycle, go to http://www.microsoft.com/SDL.
Microsoft makes no warranties, express, implied, or statutory, as to the information in this document or
information referenced or linked to by this document.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the
date of publication. 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 presented after the date of
publication.
This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED, OR STATUTORY, AS
TO THE INFORMATION IN THIS DOCUMENT OR INFORMATION REFERENCED OR LINKED TO BY THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of
this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means
(electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of
Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject
matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this
document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
© 2008 Microsoft Corporation. All rights reserved. This work is licensed under the Creative Commons Attribution-Non-Commercial
License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nc/2.5/ or send a letter to Creative Commons,
543 Howard Street, 5th Floor, San Francisco, California, 94105, USA.
Microsoft, Visual C#, and Visual C++ are either registered trademarks or trademarks of Microsoft Corporation in the United States
and/or other countries.
All other trademarks are property of their respective owners.
Contents
Introduction to the SDL Optimization Model ................................................................................................................1
Resource Guide Overview .............................................................................................................................................1
Audience ....................................................................................................................................................................1
The SDL Optimization Model Concept .......................................................................................................................1
How to Use This Model..............................................................................................................................................2
SDL Capability Areas ..................................................................................................................................................2
Training, Policy, and Organizational Capabilities ...................................................................................................3
Requirements and Design ......................................................................................................................................3
Implementation .....................................................................................................................................................3
Verification ............................................................................................................................................................3
Release and Response ...........................................................................................................................................3
SDL Optimization—Maturity Levels ...........................................................................................................................4
Optimization level 1: Basic.....................................................................................................................................4
Optimization level 2: Standardized ........................................................................................................................4
Optimization level 3: Advanced .............................................................................................................................4
Optimization level 4: Dynamic ...............................................................................................................................4
Increasing SDL Maturity over Time ............................................................................................................................5
Preparing to Meet SDL Requirements ...........................................................................................................................7
Phased Approach .......................................................................................................................................................9
Using the SDL Optimization Model ......................................................................................................................10
Implementation services .....................................................................................................................................10
Additional resources ............................................................................................................................................11
Introduction to the SDL Optimization Model
This document provides a technical road map designed to help those responsible for implementing the
Security Development Lifecycle understand the state of their current practices and move their
organizations towards full adoption of the SDL. This guide is one of a series of guides about the SDL. These
resource guides are not meant as an exhaustive reference of the SDL process as practiced at Microsoft.
Users of this series of guides should be familiar with the book by Michael Howard and Steve Lipner, The
Security Development Lifecycle: SDL: A Process for Developing Demonstrably More Secure Software, which
describes the practices, history, and insights of the SDL. It includes valuable collateral material for the
processes described in this guide, including a six-part security class video and sample SDL documents and
tools. The purpose of this series of guides is to help readers to assess their current state of maturity within
the SDL and to then plan a progressive implementation of new, more mature capabilities and practices.
The Microsoft SDL portal and the SDL Process Guidance documentation section of the MSDN Web site
provide additional resources and are the best sources for the most up-to-date information,
recommendations, and practices for the SDL.
The SDL is based on sound security principles, quality tools, and training, but such tools and training need
not be those specifically created by Microsoft. In recognition of the fact that every software solution will
present its own security challenges and tool requirements, there are frequent references in these
documents to guidance from third parties that may be relevant to non-Microsoft–based software
development platforms.
Resource Guide Overview
Audience
This document is designed for development managers and IT decision makers who are responsible for
planning, deploying, and governing security and privacy measures in software development and who want
to implement the practices and concepts of the SDL.
The SDL Optimization Model Concept
The SDL Optimization Model is structured around
five capability areas that roughly correspond to the
phases within the software development lifecycle:
 Training, policy, and organizational
capabilities
 Requirements and design
 Implementation
 Verification
 Release and response
The SDL Optimization Model defines four levels of
maturity for the practices and capabilities in these areas—Basic, Standardized, Advanced, and Dynamic.
1
Microsoft and the SDL Pro Network provide the technologies, processes, and procedures to help
organizations move along the optimization path. Third-party solutions can also be used to meet all of the
requirements in the model.
The guide reflects the experiences Microsoft has had implementing the SDL in the past six years. The main
objective has been to develop a maturity framework that can help you to benchmark, plan, and improve
the technical capability and business value your organization realizes from implementing the SDL.
How to Use This Model
The first step in using the model is to review the Microsoft Security Development Lifecycle (SDL)
Optimization Model: Self-Assessment Guide and evaluate the current optimization level of your security
development practices. This evaluation helps to determine which capabilities your organization needs to
develop and in what sequence they should be deployed.
This document focuses on introducing the basic concepts and strategies of the SDL Optimization Model.
The other resource guides in this series focus on the capabilities necessary to move from one maturity
level to the next in the SDL Optimization Model.
SDL Capability Areas
The full SDL process is illustrated in the following figure. The green chevrons highlight the security and
privacy steps taken in the software development lifecycle and these are reinforced on either side by
training and response practices.
The Microsoft SDL
To simplify adoption, the SDL Optimization Model is grouped into five capability areas. To assist with
budgeting, planning, and staffing of the SDL optimization efforts, the capability areas are designed to
correspond to the structure of most software development organizations, with employee roles in project
management, development, test, and operations. These basic responsibilities and roles likely apply even
for smaller organizations or those with an organizational structure that doesn’t exactly match the roles
presented here. Additionally, it is recommended that a central security expert team be staffed to manage
governance activities and to provide expert assistance and resources to teams adopting new security and
privacy practices. The SDL Pro Network can be a good starting point for establishing the capabilities of a
central security team. Visit the SDL Pro Network page on the SDL Web site for more information.
2
The next section provides a high-level overview of the five capability areas:
Training, Policy, and Organizational Capabilities
The scope of the practices in this area is broader than any single software project. It includes the
organization’s process for determining security and privacy risks, the applicability of the SDL on a perproject basis, the level of management support, and the creation and delivery of training and
foundational governance activities, such as security bug tracking standards. These activities are primarily
the responsibility of members of the management team, project managers, and the central security
expert group.
Requirements and Design
This capability area covers practices at the requirements, architecture, and design phases. It includes risk
assessment, understanding and reducing product attack surfaces, Threat Modeling, and security design
review. Responsibility for the execution of these practices lies with project managers and architects, with
some tasks involving developers and the quality assurance testers. The central security expert team will
often be called on to provide bootstrap assistance.
Implementation
This area focuses on preventing security weaknesses from being introduced at the implementation level.
It includes the use of tools, such as static analysis, defensive compiler settings, and code scanners. Finally,
it addresses the implementation of vulnerability mitigations identified in threat modeling. The
responsibility for executing these practices falls on developers, with targeted assistance from the central
security expert team.
Verification
This area describes practices in discovering and remediating security weaknesses that might have been
introduced at the design and implementation levels. It also includes the use of tools, such as dynamic
analysis tools and fuzzers. Fuzzers are tools that perform fuzz testing—a means of testing that causes a
software program to consume deliberately malformed data to see how the program reacts. Other helpful
practices in this area include
security testing procedures and code reviews. The responsibility for
executing these practices falls on the Quality Assurance testers and developers, with targeted assistance
from the central security expert team.
Release and Response
This area describes the practices used to verify compliance before release through the Final Security
Review (FSR). It also describes how to enhance the preparedness and agility of the organization in
responding to discovered security weaknesses at minimal cost and disruption, both internally and to
affected customers. Most of the tasks take place immediately before and after the release, and the
responsibility for execution is divided among the central security expert team, production operations,
support teams, and the development and testing teams.
3
SDL Optimization—Maturity Levels
In addition to the capability areas, the SDL Optimization Model defines four optimization, or maturity,
levels (Basic, Standardized, Advanced, and Dynamic) for each of the capability areas described above. A
description of the characteristics of each optimization level follows.
Optimization level 1: Basic
The Basic level is characterized by manual, voluntary, or localized processes; minimal central control; and
nonexistent, undefined, or unenforced policies and standards for secure architecture, design,
development, testing, compliance, and other common security practices. Due to a lack of tools and
resources, overall security health of applications and services is unknown. Generally, all security practices
are established only for a specific purpose, if they exist at all, and are mainly reactive practices driven by
external pressures.
Optimization level 2: Standardized
At the Standardized level, security practices and standards are beginning to be introduced into the
development lifecycle. Organizations at this level are able to assess the security and privacy risk of new
projects and to select the best candidates for implementing security and privacy practices into the
development lifecycle. The organization has realized the value of basic standards and policies, but it still
has significant room to improve. Security and privacy practices are applied to a few pilot projects and
there is only tacit executive support for the efforts. Much of the effort is still spent at later phases of the
lifecycle and in security response, where improvements come at a greater cost compared to the more
integrated and proactive practices at the higher optimization levels.
Optimization level 3: Advanced
The Advanced level represents the minimum set of objectively verifiable tasks necessary for a claim of
adherence to the Microsoft SDL. At this level, executive support is explicit, and all new and high-risk
projects fall under the mandate for the SDL practices and quality gates. Security and privacy practices are
integrated throughout the software development lifecycle, and each feeds into the next, maximizing the
value of the effort. Security testing guidelines are in place, and tools are effectively used to reduce costs.
Security response is rapid and controlled, and the practice of applying security and privacy efforts at
earlier lifecycle phases helps to reduce the overall cost of producing secure software.
Optimization level 4: Dynamic
Organizations with Dynamic SDL processes are aware of the strategic value that a fully realized SDL
provides in helping them protect customers, innovate efficiently, and stay ahead of competitors. Unlike at
the Advanced level, where SDL practices are targeted at new and high-risk products and projects,
organizational training goals are in place, and the mandate for secure software at the Dynamic level
covers all applicable projects across the entire organization. In essence, the Dynamic level means that an
organization has reached a level of maturity where all projects have a history of SDL engagement.
Increasing security assurance is attained with each release cycle, and legacy systems have been brought
into compliance. Teams have internalized the development of secure software, and many practices
proceed without assistance from the central security expert team. Security efforts can be focused on
4
proactive innovation and tool customization, in addition to reactive incident response, and products are
known for security excellence in the marketplace.
Increasing SDL Maturity over Time
As it moves through the maturity levels of the SDL Optimization Model, your organization’s executive
commitment to the goals and results of SDL will increase from tentative acceptance to a strong mandate,
your SDL practices will grow in technical sophistication and efficiency, and the coverage of the SDL
activities will expand from a few pilot projects to all products and services with meaningful security and
privacy risk.
5
The following table provides a high-level overview of the main activities included in the different maturity
levels for each capability area. To make the table more readable, the activities specified for each maturity
level should be read to include the activities from the lower level.
6
Preparing to Meet SDL Requirements
The Basic level is the first step on the road to the SDL. At this level, an organization defines its goals for
the SDL and identifies a road map for getting there. At the Standardized level, security practices and
standards begin to be introduced into the development lifecycle. Risk assessment is being done for all
new projects and system components to identify high-risk areas. Security training and secure coding
policies help prevent new vulnerabilities from being introduced, and a defined incident response process
exists. Organizations in a Standardized state have realized the value of basic standards and some policies,
but they still have significant room to improve. Generally, security lifecycle services are provided with
concerted effort at medium to high cost. These organizations have a good start on security practices for
new code, and increase in maturity in the Advanced state. Once organizations have addressed security
issues and design deficiencies with legacy systems, and security assurance has become a fully internalized,
iterative process, they reach the Dynamic state.
Every organization will face different challenges in implementing the SDL. Levels of security expertise,
resources, and executive commitment will vary. For example, a Web application written in Java will have a
different SDL profile from an operating system written in C and C++. The general maturity level of
software development and the size of the engineering organization relative to the size of the security
team will also greatly impact the rate and success of the rollout of the SDL. At each relevant checkpoint,
look for targeted notes and best practices call-out boxes addressing these concerns.
For any type of organization, a few common principles and strategies are recommended for starting
implementation of the SDL.
An expert or team of experts must have responsibility for managing and executing the
implementation of the SDL.
Although it is a fundamental principle of the SDL that every person and every role in the engineering
organization should receive security training and apply security practices, this does not mean that the SDL
can operate in a completely distributed manner or that every developer or tester will or can become a
security expert. At the higher maturity levels, teams will have developed enough internal expertise to
become mostly self sufficient, but they will need direct assistance to get started, and an independent
perspective and specialized expertise is always a key component of the Final Security Review (FSR). At
least one person should have implementation of the SDL as a primary responsibility, and he or she should
have the authority to enforce security mandates when product teams are not in compliance. Smaller
organizations should strongly consider contracting external experts to help with the SDL bootstrapping
process, and larger organizations will almost certainly need to develop an in-house team of specialists
dedicated to security engineering to make the SDL fully effective.
The order in which SDL capabilities are developed may vary depending on the
circumstances of the organization and the project.
The goal of the SDL Optimization Model is to take security practices from a reactive to a proactive stance,
but that goal isn’t necessarily best reached by starting with the earliest phases. Many organizations may
find it more effective to adopt the SDL by moving in the opposite direction through the phases of the
lifecycle—beginning with improvements to incident response and pushing back towards security
7
requirements review. This helps ground the work in practical fact: Knowledge of incidents in the field will
inform the kinds of issues that should have been tested for during verification; root-cause analysis informs
coding practices; and knowing the types of issues that tools and automation can find and prevent helps
focus effort in earlier phases on the right classes of bugs. It is also easier to identify and track concrete
metrics from the verification, release, and response stages than to do so from the requirements and
design phases and to show measurable improvements there as the process matures and as coverage
becomes more complete. These metrics help to maintain executive commitment and to justify ongoing
resources devoted to SDL optimization.
The SDL provides a set of holistic and integrated activities.
Many practices in the SDL feed into and reinforce each other. For example, Threat Modeling in the design
phase informs and guides the practices in the implementation, verification, and release phases.
Performing these practices in isolation will not yield the best possible results. This is just one of the
reasons why it is so critical to push security and privacy upstream as part of the SDL.
The most effective use of your security resources is to give a few pilot projects end-to-end coverage with
an abbreviated set of practices first and to then expand to cover more projects as your organization
increases in maturity and the pilot teams become more self-sufficient. Rolling out the SDL in this manner,
on a project-by-project basis, provides the greatest opportunity to learn, develop internal competencies,
and tailor the processes to your specific organization. It also reduces the cost and risk as the processes are
rolled out to the broader organization.
An approach that rolls out “orphan” practices (for example, Threat Modeling) to many teams or to an
entire company at once, with no follow-up practices elsewhere in the lifecycle, can undermine the
credibility of the program with executive sponsors. The costs will be high, the ability to provide expert
supervision for most instances of the practice will be diminished, and demonstrable improvements will be
hard to produce without an integrated set of practices.
Most lifecycle practices should be first applied to new projects and code.
This is somewhat counterintuitive—as Michael Howard points out in “Lessons Learned from Five Years of
Building More Secure Software,” the age of a piece of code is the single best rule of thumb for
determining how likely it is to harbor security bugs. If your organization has the luxury (or the unfortunate
necessity) of a “stop-the-world” security push on existing systems, that will certainly yield some results.
However, that is rarely how SDL efforts are begun and, as Michael also says in his article, “The primary
goal of the SDL is to reduce the chance of developers adding new vulnerabilities to a product.” Beginning
SDL practices on new projects and code has several important advantages:


New code and projects have clear owners and well-understood requirements and design. In
many organizations, locating the party responsible for legacy code, or even understanding what
it does and how it works, can be a costly and time-consuming endeavor.
SDL practices can be added on as incremental changes in the flow of work as it happens for new
projects. Ramping up a security push and compliance enforcement effort on old code is more
costly at the early stages of SDL maturity. In addition, on a new project, SDL activities can be
budgeted into the schedule more accurately, leading to better fiscal responsibility.
8

Securing new code helps keep down compatibility and roll-out costs. Patching old code in the
field or releasing major “security update” versions is often much more expensive than rolling out
new products that are secure from the start. This is especially true for design vulnerabilities—
when a large ecosystem of partners, clients, and independent software vendors (ISVs) has
integrated with existing designs, deploying a major security update can be extremely costly. It is
much better to prevent such issues before they occur, especially since some legacy security
design issues may be impossible to remedy except by upgrading to newer, more secure designs.
For more information on managing the SDL, including discussions of factors affecting the cost of the SDL,
rules of thumb for cost estimation, and SDL tracking, see the Howard and Lipner book, The Security
Development Lifecycle, Chapter 4: “SDL for Management.”
Phased Approach
Microsoft recommends a phased approach to meeting the requirements in each of the SDL capability
areas. The four phases are shown in the following illustration.
In the Assess phase, you determine the current capabilities and resources within your organization.
In the Identify phase, you determine what you need to accomplish and which capabilities you want to
incorporate.
In the Evaluate and Plan phase, you determine what you need to do to implement the capabilities
outlined in the Identify phase.
In the Deploy phase, you execute the plan that you built in the previous phase.
9
Using the SDL Optimization Model
The Implementer Resource Guide for the SDL Optimization Model consists of five documents. This
document, the Introduction, gives an overview of the model and the process. After reading the
Introduction, move on to the Self-Assessment Guide, which will help you to assess the current state of
your organization’s SDL maturity and to understand where you need to begin implementing and
improving your practices. You can use the Self-Assessment Guide as a checklist to help move your
organization through the entire Optimization Model. At each checkpoint, the Self-Assessment Guide will
refer you to more specific information and planning details available in the Implementer Resource Guides.
There are three Resource Guides for planning and implementing the transition from one maturity level to
the next. Most organizations will start with the Basic to Standardized Guide, while some organizations
with more established security practices may begin immediately with activities from the Standardized to
Advanced Guide. The Advanced to Dynamic Guide completes the road map to fully mature
implementation of the SDL.
Using the SDL Optimization Model
Introduction
Self-Assessment Guide
Implementer Guide
Basic  Standardized
Standardized  Advanced
An overview of the model and how to use it
A questionnaire for mapping your current
secure development practices to the SDL
maturity levels (Basic, Standardized,
Advanced, and Dynamic)
Detailed and actionable guidance on
the necessary steps for moving up the
SDL maturity levels in each of the five
capability areas
Advanced  Dynamic
Implementation services
Implementation services for the projects outlined in this document are provided by the Microsoft SDL Pro
Network and Microsoft Services. For assistance in implementing the SDL in your organization according to
the SDL Optimization Model described here, please visit the SDL Pro Network page on the SDL Web site.
10
Additional resources
Users of this guide should be familiar with the book by Michael Howard and Steve Lipner, The Security
Development Lifecycle: SDL: A Process for Developing Demonstrably More Secure Software, which fully
describes the practices, history, and insights of the SDL, and includes valuable collateral material for the
processes described in this guide. It also includes a six-part security class video and sample SDL
documents and tools.
The Microsoft SDL Portal, which includes further training, tools, and the most up-to-date process
guidance, is another valuable resource to draw upon.
In addition, please visit the SDL Blog, which is a growing collection of lively debates, insider insights, and
discussions contributed by experts across the security engineering organization at Microsoft.
11