Microsoft Security Development Lifecycle (SDL)
Optimization Model
Implementer Resource Guide: Standardized to Advanced
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 in their organization’s software development
lifecycle to assess their current state and to gradually move their organizations towards the adoption of the proven
Microsoft program for producing more secure software. The SDL Optimization Model enables development
managers and IT policy makers to assess the state of the 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 fourth of five resource guides. It explains the key practices for organizations beginning at the
Standardized level, where some significant software development security practices are in place, but the coverage
and mandate of these capabilities is still limited. This document provides guidance for conducting and managing
the practices to achieve Advanced capabilities and provides links to relevant resources where additional content
can be found. You can use the information contained in this guide to help you move from the Standardized level to
the Advanced level. For a full description of the model, concepts, capabilities, and maturity levels, please see the
first guide in this series: Microsoft Security Development Lifecycle (SDL) Optimization Model: Introduction to the
Optimization Model.
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, InfoPath, Visual Studio, Visual C#, Visual C++, Win32, SQL Server, ActiveX, and Windows 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
Resource Guide Overview .............................................................................................................................................1
Audience ....................................................................................................................................................................1
SDL Optimization Levels ............................................................................................................................................1
Preparing to Implement SDL Requirements ..................................................................................................................3
Phased Approach .......................................................................................................................................................3
Implementer Guide—Standardized to Advanced .........................................................................................................4
Capability Area: Training, Policy, and Organizational Capabilities ................................................................................4
Introduction ...............................................................................................................................................................4
Capability: Training ....................................................................................................................................................4
Capability: SDL Policy .................................................................................................................................................6
Capability: Central Ownership of Security and Privacy Advisement .........................................................................8
Capability Area: Requirements and Design ...................................................................................................................9
Introduction ...............................................................................................................................................................9
Capability: Risk Assessment .......................................................................................................................................9
Capability: Functional Security Requirements .........................................................................................................10
Capability: Design Requirements .............................................................................................................................12
Capability: Quality Gates .........................................................................................................................................13
Capability: Threat Modeling ....................................................................................................................................14
Capability Area: Implementation.................................................................................................................................16
Introduction .............................................................................................................................................................16
Capability: Security Tools .........................................................................................................................................16
Capability Area: Verification ........................................................................................................................................17
Introduction .............................................................................................................................................................17
Capability: Dynamic Analysis and Application Scanning (Web Applications) ..........................................................18
Capability: Fuzzing ...................................................................................................................................................19
Capability: Threat Model Validated .........................................................................................................................20
Capability Area: Release and Response .......................................................................................................................21
Introduction .............................................................................................................................................................21
Capability: Final Security Review (FSR) ....................................................................................................................22
Capability: Response Planning and Execution .........................................................................................................23
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 Microsoft® Security Development Lifecycle (SDL).
SDL Optimization Levels
The SDL Optimization Model defines
four optimization, or maturity, levels
(Basic, Standardized, Advanced, and
Dynamic) for each of the capability areas
described on the next page. This guide is
concerned with helping organizations
move from the Standardized level to the
Advanced level. The characteristics of these optimization levels are described in the following table.
1
2
Preparing to Implement SDL Requirements
The Advanced level of maturity 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 highrisk projects fall under the mandate for 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 applying security and privacy efforts at earlier lifecycle
phases helps reduce the overall cost of producing secure software.
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.
Implementation services
Implementation services for the projects outlined in this document are provided by Microsoft partners
and Microsoft Services. For assistance in implementing the SDL optimization improvements highlighted in
the SDL Optimization Model Implementer Resource Guides, please refer to the Microsoft SDL Pro Network
page on the SDL Web site or visit the Microsoft Services Web site.
3
Implementer Guide—Standardized to Advanced
The following section provides detailed information and guidance on fulfilling the requirements of each of
the five capability areas in the Advanced level. The checkpoints in each capability area follow the
requirements discussed in the Microsoft Security Development Lifecycle (SDL) Optimization Model: SelfAssessment Guide for the Advanced level. Start with the Self-Assessment Guide, and then use the detailed
implementation guidance that follows to increase maturity in the areas necessary for your organization.
Capability Area: Training, Policy, and Organizational
Capabilities
Introduction
Training, Policy, and Organizational Capabilities is an SDL Optimization capability area that focuses on
capabilities and practices at an organizational level across many projects and lifecycle phases. At the
Advanced level, these practices include creating organization-wide security and privacy guidelines
emphasizing explicit executive support. They also include expanding the breadth of the training
curriculum to reach all engineers, testers, and managers to make sure that they are trained on the SDL
practices relevant to their roles. The benefits of reaching the advanced level in this capability area include
improved security attention, awareness, and skills, along with increased standardization in security
development practices across the organization (compared to a few “pilot” projects at the Standardized
level).
Capability: Training
Overview
The average developer, tester, or manager knows very little about building secure software. They need to
be aware of the executive commitment to security and the resources available to them, and they should
have some knowledge about basic security tenets. Without this, and without understanding common
security bug types, basic secure design, and security testing, there is no reasonable chance that they will
produce secure software. Training is therefore one of the foundational practices of the SDL.
Phase 1: Assess
The Assess phase involves gathering the requirements to expand the training curriculum and reach. Key
areas for training needs assessment include:




Languages, platforms, and technologies employed.
Development and test environment and tools.
Current level of security awareness.
Availability and knowledge of organizational security standards, including technology choices, code
libraries, and standard mitigations.
 Security threats and past and current vulnerabilities.
 Number of developers and testers to be trained.
 Appropriate length of course.
4
Phase 2: Identify
At the Standardized level, a “Basics of Secure Design, Development, and Test” or equivalent training
course exists. To move to the Advanced level, the organizational commitment to the SDL process is
introduced with courses covering an “Introduction to the SDL,” “Privacy in Development,” and an
“Introduction to Threat Modeling” that introduces one of the foundational capabilities of the SDL. Some
of the steps you need to consider to identify your training needs include:




Discovering existing organizational security standards, tools, libraries, and documentation.
Identifying trainers within the organization or qualified third parties.
Selecting an appropriate base curriculum.
Identifying organization-specific additions, modifications, or examples for base curriculum.
A number of resources are available for creating curricula:
 SDL Process Guidance—Pre-SDL Requirements: Security Training
 Training People on Threat Modeling from the SDL Blog
 Threat Modeling: Video Tutorials
The Open Web Application Security Project (OWASP) also provides presentations and videos on a variety
of application security topics that may be useful in developing or supplementing training content.
SDL Pro Network program members also provide training on all aspects of the SDL. Visit the SDL Pro
Network page on the SDL Web site to learn more.
Phase 3: Evaluate and Plan
During the Evaluate and Plan phase, the detailed course curriculum and materials will be assembled and a
delivery mechanism decided upon. Although in-person, instructor-led training with a hands-on lab
component is the most effective, on-demand video or interactive computer-based training (CBT) may be a
preferable option for organizations with unique requirements, such as high staffing volatility with
contractors or offshore development centers.
Note
Training is not intended to make all of your engineering staff into security experts. One
of the most important goals of training is to make members of the engineering
organization aware of when they may have a security issue that needs investigation,
whom to ask for help, and what resources are available to them. The initial training contact with a
given staff member should also introduce the organization’s commitment to security and the
quality gates (or bug bars). This will be different for every organization, so no security awareness
and training course should be completely “off-the-shelf.” If you elect to use a video or CBT, it is still
recommended that a member of the security expert team make in-person contact with all of the
staff to introduce these concepts (for example, as a 20-30 minute module added to general
orientation and training for new technical staff).
5
Phase 4: Deploy
The goal of the Deploy phase is to deliver the training to the engineering organization, with an emphasis
on new projects and projects with high security risk or impact.
Checkpoint: Training
Requirement
Create or acquire “Introduction to the SDL,” “Introduction to Threat
Modeling,” “Basics of Secure Design, Development and Test,” and
“Privacy in Development” course material.
Technical staff on new projects and projects with high security or privacy risk have
completed the above training (as appropriate for their role) and there is a system
in place to track attendance and compliance with the training requirements.
If you have completed the steps listed above, your organization has met the minimum requirements of
the Advanced level for Training. We recommend that you follow additional best practices for training
addressed in the SDL Process Guidance at Microsoft MSDN.
Capability: SDL Policy
Overview
At the Standardized level, the SDL Policy is minimal, mainly allowing security and privacy vulnerabilities to
be categorized and ranked according to the business impact of the vulnerability.
In moving to the Advanced level, policy becomes a larger part of governing the SDL process. Policy at the
Advanced level standardizes the types of projects that fall under the SDL mandate and the activities and
processes that must happen at each phase of the development lifecycle for a project to be considered in
compliance. It also determines the quality gates to be met before release.
Phase 1: Assess
The Assess phase involves gathering requirements to build the policy statements. The policy statement
will define the projects that must comply with the mandates of the SDL, along with the quality gates that
apply. In the Advanced stage, explicit executive support is required; the policy statement must require all
new projects ranked as high risk to fall under the mandates of the SDL.
The overall goal should be to create a framework that will allow each new project to conclude whether it
is subject to the SDL. Software classifications to consider might include (but are not limited to):



Will the software be used within an enterprise, business, or organization?
Will the software store, process, or communicate sensitive or private information? (For more
information, see the Microsoft Privacy Guidelines for Developing Software Products and Services.)
Will the software regularly touch or listen on the Internet or other networks?
6

Will the software accept or process data from an unauthenticated source?
Policy will also codify what activities must be completed for a project to be SDL compliant. Assess the cost
and effectiveness of various activities from practices at the Standardized level, and determine what an
acceptable and necessary overhead is for SDL activities.
Phase 2: Identify
Identify the specific criteria that will qualify a project for the SDL mandate. This may be the risk
questionnaire score. It may also include outside factors, such as qualifying all projects that fall under
certain regulatory requirements.
Identify the set of practices that must be followed at each phase of the lifecycle for a project to be SDL
compliant and the quality gates the projects must meet for release.
Phase 3: Evaluate and Plan
In the Evaluate and Plan phase, determine the costs and time frame for adopting the new SDL mandates.
Project timelines and resourcing should be appropriately adjusted for the tasks required. A governance
framework must also be put in place to track compliance, set release criteria, and issue the necessary
exceptions.
Phase 4: Deploy
In the Deploy phase, these policies are rolled out to the organization, and a governance process is in place
to verify process compliance and to ensure that release quality gates are met and exceptions are tracked.
Checkpoint: SDL Policy
Requirement
The SDL policy formally defines what projects qualify for SDL mandates and
which practices and quality gates are necessary for compliance. A governance
process exists to track SDL compliance and issue necessary exceptions.
If you have completed the step listed above, your organization has met the minimum requirements of the
Advanced level for SDL Policy. We recommend that you follow additional best practices for SDL policy
addressed in the SDL Process Guidance at Microsoft MSDN.
7
Capability: Central Ownership of Security and Privacy Advisement
Overview
Although it is a fundamental principle of the SDL that every person and every role in the engineering
organization should receive security training and participate in 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. Teams will need advice and assistance in a variety of aspects of the SDL.
It is possible to outsource technical advising to external experts, particularly when specific skill sets are
required to resolve the issues at hand. In general, however, organizations reaching the Advanced level
should develop an in-house capability to provide advice and governance on the specific policy aspects of
the SDL, such as security and privacy requirements and best practices.
Phase 1: Assess
In the Assess phase, determine the organizational need for advisement and governance, along with the
available resources for building a security expert team. Smaller organizations may only need a single
individual. Larger organizations will need to build a team appropriate to the number of projects to which
the SDL applies. Also consider whether technical advisement will continue to be outsourced to external
experts, as is typical in the Standardized and Basic phases, or whether the need and resources exist to
develop this capacity in-house.
Phase 2: Identify
In the Identify phase, responsibilities and requirements are developed for the security expert team and its
positions. New positions are filled. Responsibilities and requirements still fulfilled by external experts are
identified.
Phase 3: Evaluate and Plan
During the Evaluate and Plan phase, members of the security expert team are trained on relevant policies
and on other responsibilities and requirements. Necessary external resources are budgeted.
Phase 4: Deploy
In the Deploy phase, the security expert team and external experts are deployed to meet their roles and
responsibilities throughout the practice of the SDL.
Checkpoint: Central Ownership of Security and Privacy Advisement
Requirement
A central security expert team exists to provide advice and guidance on
security and privacy policies and to help and verify compliance with the SDL
requirements.
8
practices and quality gates are necessary for compliance. A governance process
exists to track SDL compliance and issue necessary exceptions.
If you have completed the step listed above, your organization has met the minimum requirements of the
Advanced level for Central Ownership of Security and Privacy Advisement. We recommend that you
follow additional best practices for central ownership of security and privacy advisement addressed in the
SDL Process Guidance at Microsoft MSDN.
Capability Area: Requirements and Design
Introduction
In Requirements and Design, new practices are first introduced into the lifecycle of specific products and
projects. As is generally well established in software engineering, the later in the product lifecycle a
vulnerability or ‘bug’ is found, the more expensive it is to fix. This is perhaps even more true for security
vulnerabilities. Insecure designs, in particular, resemble other nonfunctional requirements, such as
scalability. Without careful attention, mistakes can easily propagate and become extraordinarily costly to
fix. Assessing risk and applying security analysis early in the lifecycle can drive the most dramatic cost
savings in a well-optimized SDL practice. At the advanced maturity level, the following activities are
introduced for all new or high-risk projects: implementing a mandatory risk-assessment questionnaire,
cataloging approved, standard security solutions, and Threat Modeling. The benefits of these activities
include better understanding of the relative risk of projects and features to inform focused and costeffective security efforts. In addition, security dependencies among various system components can be
analyzed in a structured and methodical manner.
Capability: Risk Assessment
Overview
Risk-assessment questionnaires are in use for some projects at the Standardized level. To reach the
Advanced level, risk assessment must be comprehensive for new projects and should be part of the
overall SDL policy governance process.
Phase 1: Assess
Assess the total number of new projects handled by your organization on a yearly basis and what type of
governance is necessary to track and analyze risk questionnaires from every project.
Phase 2: Identify
The Identify phase involves determining the appropriate place in the general software development
lifecycle to place and enforce the risk questionnaire. This might be a Microsoft Office Word document, an
InfoPath® form, or a simple Web application. In addition, opportunities might exist to integrate directly
into Enterprise Resource Planning (ERP) or project management systems that drive the rest of the product
lifecycle.
9
Phase 3: Evaluate and Plan
During the Evaluate and Plan phase, the governance framework is designed such that completion of the
questionnaire can be audited in a timely manner, and qualifying projects start promptly on other SDL
mandates that follow the risk assessment. This may be a manual or automated process and will vary
depending on the size of the organization, the maturity of the general software development lifecycle,
and the availability and use of enterprise resource or software-development planning tools and processes.
Phase 4: Deploy
The goal of the Deploy phase is to deliver the questionnaire and to get responses from all of the new
projects during the project initiation or requirements lifecycle phase. All legacy projects with meaningful
security risk should also be assessed to determine their relative priority in the allocation of the ongoing
security investment.
Checkpoint: Risk Assessment
Requirement
A risk-assessment questionnaire exists and all new and legacy projects in
business areas with the potential to create meaningful risk have responded.
If you have completed the step listed above, your organization has met the minimum requirements of the
Advanced level for Risk Assessment. We recommend that you follow additional best practices for risk
assessment addressed in the SDL Process Guidance at Microsoft MSDN.
Capability: Functional Security Requirements
Overview
Michael Howard, one of the authors (along with Steve Lipner) of The Security Development Lifecycle: SDL:
A Process for Developing Demonstrably More Secure Software, often emphasizes that the SDL is more
about building secure features than it is about building security features. Nonetheless, failures of
functional security requirements will almost always rank as important vulnerabilities, and the failure to
properly and consistently apply standard mitigations—or misunderstanding the guarantees they
provide—are common causes of software insecurity. An important part of the practice of secure design is
to create a standard security solution collection for the organization (including authentication and
authorization, input filtering, or data protection and encryption APIs). It is then critical to make sure that
developers are aware of your standard security solution collection and know when and how to use it for
security functionality.
Designing security features is a complicated practice that is outside of the scope of the SDL as such. For
more information, see the following resources:
 Writing Secure Code, Second Edition (ISBN 9780735617223; ISBN 100735617228), by Michael
Howard and David LeBlanc (Microsoft Press, 2002)
10
 Security Engineering, A Guide to Building Dependable Distributed Systems (ISBN 978-0471389224;
ISBN 100471389226), by Ross J. Anderson (Wiley, John & Sons, 2001)
 Patterns & practices: Security Engineering Index
Also consider making use of industry standard solutions and libraries, such as the Microsoft Application
Security Anti-Cross-Site Scripting Library or the OWASP reform library.
Phase 1: Assess
The Assess phase for functional security requirements begins with understanding the current state of
knowledge and documentation about existing security features. Consider the following questions: Do
standard libraries and APIs exist? Are developers aware of them? Are they being used? Are they
adequately and accurately documented? Reviewing internal documentation and interviewing members of
the development staff will be the primary means of gathering this information.
Phase 2: Identify
In the Identify phase, the particular common functional requirements and necessary attack surface
mitigations for the organization are cataloged, and gaps or deficiencies in existing libraries and
documentation are identified. For example, for Web applications, some common security functional
requirements include:




Cross-site request forgery (CSRF) protection
Anti-cross-site scripting (XSS) input and output filtering
Session management
Uniform Resource Identifier (URI) authorization
Phase 3: Evaluate and Plan
During the Evaluate and Plan phase, documentation and sample code for security features and mitigations
is reorganized, updated, and created as needed, and best practices are added to cover gaps where
common solutions do not currently exist.
Phase 4: Deploy
The Deploy phase involves publicizing and evangelizing the catalog of standard security solutions and best
practices to the development organization. This should make up a portion of the Training curriculum and
should be a permanently accessible resource, like an intranet Web page or Wiki.
Checkpoint: Functional Security Requirements
Requirement
The security expert team has cataloged and made available approved,
standard solutions for meeting functional security requirements and
mitigating common attack classes.
11
If you have completed the step listed above, your organization has met the minimum requirements of the
Advanced level for Functional Security Requirements. We recommend that you follow additional best
practices for functional security requirements addressed in the SDL Process Guidance at Microsoft MSDN.
Capability: Design Requirements
Overview
The security expert team should be prepared to perform security requirements and design reviews as
necessary and as resources allow. This is the opportunity to audit and enforce the standards set in the
Functional Security Requirements practice and to prevent security vulnerabilities early in the lifecycle,
when it is most cost effective to do so.
For more information, see the following resources:
 Patterns & practices: Security Architecture and Design Review Index
 Patterns & practices: Security Engineering Index
Phase 1: Assess
In the Assess phase, determine the readiness and availability of resources on the security expert team to
perform functional requirements and design review of high-risk or pilot projects.
Phase 2: Identify
Identify the features to be reviewed for design requirements. Use the feature Risk Assessment activity, or
select specific SDL pilot teams.
Phase 3: Evaluate and Plan
In the Evaluate and Plan phase, arrange time to meet with the appropriate project managers and
development leads for the selected projects. Requirements and design documents should be reviewed in
advance, as available.
Phase 4: Deploy
Conduct design review meetings, applying standard mitigations as necessary. File vulnerabilities and track
identified issues. The security design review is also an excellent opportunity to note which features, if any,
are good candidates for a Final Security Review.
Checkpoint: Design Requirements
Requirement
The security expert team is capable of auditing and verifying the application
of standard and approved solutions for functional security requirements and
threat mitigation for new projects classified as high risk.
12
If you have completed the step listed above, your organization has met the minimum requirements of the
Advanced level for Design Requirements. We recommend that you follow additional best practices for
design requirements addressed in the SDL Process Guidance at Microsoft MSDN.
Capability: Quality Gates
Overview
At project inception, it should be determined whether a feature or product qualifies for the SDL. Typically,
features that are rated as low risk, or certain classes of product (such as development kits), may not
qualify for these practices. At the Advanced level, participation in the SDL is mandated for all new projects
or projects with high security risk. It is important to identify which projects qualify, and what their final
security exit criteria before release will be at this early stage of the software development lifecycle. This
helps ensure that accurate estimates of security practices can be built into the project timeline (for
projects that are opted in to the SDL).
Additional guidance can be found in the Howard and Lipner book, The Security Development Lifecycle:
SDL: A Process for Developing Demonstrably More Secure Software, Chapter 6: “Stage 1—Project
Inception,” and on the following Web sites:




SDL Process Guidance—Phase 1: Requirements: Project Inception
Privacy Guidelines for Developing Software Products and Services
SDL Process Guidance—Appendix M: SDL Privacy Bug Bar (Sample)
SDL Process Guidance—Appendix N: SDL Security Bug Bar (Sample)
Phase 1: Assess
In the Assess phase, refer to the output of the SDL Policy activity to determine what qualifies as
“meaningful security risk” potential for the organization, and use the Risk Assessment activity to
determine the high-risk projects. At the Advanced level, all new projects with high security risk have
quality gates to meet.
Phase 2: Identify
In the Identify phase, determine what the quality gates will be for various types of projects. A unified
ranking system may be employed, or different criteria may apply for different applications. For example,
publicly shipped binaries may be held to a higher standard than service offerings or line-of-business
applications, or certain types of vulnerabilities may have a more stringent policy where regulatory or
other requirements are in force.
Phase 3: Evaluate and Plan
During the Evaluate and Plan phase, attempt to determine, based on the set of practices to be mandated,
the time and resource requirements of participation in the SDL. It is important that these practices be
built into the project schedule from the beginning, so that security practices are not neglected under
deadline pressures.
13
Phase 4: Deploy
The Deploy phase involves notifying teams that they have been selected for SDL participation and working
with the appropriate project management staff to schedule and coordinate the rest of the SDL processes
and practices into their schedules. Each project will also be assigned the quality gates it must meet, which
will be defined in terms of the SDL Policy bug-ranking matrix.
Checkpoint: Quality Gates
Requirement
All new or high-risk projects fall under the SDL requirements and their security
and privacy mandates for release are assigned in the requirements phase. Quality
Gates are defined for all projects that need to comply with the SDL.
If you have completed the step listed above, your organization has met the minimum requirements of the
Advanced level for Quality Gates. We recommend that you follow additional best practices for quality
gates addressed in the SDL Process Guidance at Microsoft MSDN.
Capability: Threat Modeling
Overview
Threat Modeling is a more formalized process for cataloging the security requirements and design of a
system, evaluating its attack surface, and identifying mitigations and unmitigated threats. Threat
Modeling serves two purposes:
1.
2.
The Threat Modeling process can be an effective way of identifying design vulnerabilities and
fixes for those vulnerabilities, outside of the narrow categories of the functional security
requirements addressed by previous practices in the Requirements and Design phase.
The threat model document is a durable artifact that can be used to guide creation of test cases,
to focus penetration testing and code review, and to communicate the security specifications of
the system to dependent feature teams and future engineers, reviewers, and auditors.
At the Standardized level, Threat Modeling is performed opportunistically with direct expert assistance. At
the Advanced level, all components with significant risk must be threat modeled to give a clear
understanding, to appropriately mitigate the attack surface of individual areas, and to uncover
mismatched security assumptions at component boundaries.
As the organization moves from Standardized to Advanced, it should have several internal “exemplar”
threat models to set expectations as to what a good threat model should contain, and most staff will have
completed some training on the Threat Modeling process. Teams will still need assistance in creating their
first threat models, but that assistance can be a less hands-on moderation from the security expert team
than was necessary in the transition from Basic to Standardized.
Phase 1: Assess
14
In the Assess phase, determine the readiness and availability of resources on the security expert team to
assist teams in performing Threat Modeling. Assess tools that will make the Threat Modeling process
easier for architects to perform on their own, and consider how to integrate the Threat Modeling process
into your organization’s standard development activities.
Phase 2: Identify
Identify the features to be reviewed, using the feature Risk Assessment activity. One of the key factors in
determining the importance of Threat Modeling is the degree of connectedness to other systems, that is,
the number of other products and components that create security dependencies on a given feature. In
addition, identify the Threat Modeling tools and methodology that will work best for your organization.
Phase 3: Evaluate and Plan
In the Evaluate and Plan phase, arrange time to meet with the appropriate project managers and
development leads for the selected projects. Requirements and design documents should be reviewed in
advance, as available.
Phase 4: Deploy
A representative from the security expert team conducts initial Threat Modeling sessions with the team,
with the goal of having the team perform future threat models independently (with light assistance from
the central security team). For more information about tools and methodologies for building threat
models, see the following resources:







Microsoft SDL Threat Modeling Tool
Reinvigorate your Threat Modeling Process
Uncover Security Design Flaws Using the STRIDE Approach
SDL Process Guidance—Phase 2: Design Phase: Establish and Follow Best Practices for Design
Posts on Threat Modeling from the SDL Blog
The essentials of Web application threat modeling
Fending Off Future Attacks by Reducing Attack Surface, an MSDN article on the process for
determining attack surface
 Measuring Relative Attack Surfaces, an in-depth research paper
Checkpoint: Threat Modeling
Requirement
The central security team assists product groups with creating initial threat
models for all new or high-risk projects.
The central security team can validate existing threat models for correctness using
the STRIDE threat classification taxonomy.
Threat models are used to enumerate attack surface and the appropriate actions
for attack surface reduction and mitigations are identified.
15
If you have completed the steps listed above, your organization has met the minimum requirements of
the Advanced level for Threat Modeling. We recommend that you follow the additional best practices for
Threat Modeling addressed in the SDL Process Guidance at Microsoft MSDN.
Capability Area: Implementation
Introduction
Implementation is the SDL optimization capability area focused on security practices to eliminate and
reduce the impact of vulnerabilities in the construction of software. Ongoing implementation activity
focuses on improving the use and sophistication of tools and policies when building software. This leads
to a higher level of confidence in eliminating potential security vulnerabilities in a consistent and scalable
manner.
Capability: Security Tools
Overview
The Advanced level of the SDL introduces a new tool requirement: static analysis. Static analysis tools
perform data flow analysis on source or object code to identify potential security vulnerabilities, such as
buffer overruns, out-of-bounds memory access, double frees, and other memory management
vulnerabilities that may lead to exploitable security weaknesses. Most static analysis tools are commercial
products that require a significant investment to adopt, and even the best require a fairly high degree of
technical sophistication to operate. Nevertheless, they can be some of the most cost-effective ways to
eliminate critical vulnerabilities from large, complex code bases.
Static analysis tools are critical for native C or Visual C++® code. For managed code (.NET CLR languages or
Java), static analysis often focus on application domain–specific issues. For example, a static analysis tool
targeting Web applications written in a managed language might attempt to identify potential cross-site
scripting (XSS) vulnerabilities by tracing data flows from known sources of user input to known output
functions and checking for the presence of a sanitization function along every data path.
Phase 1: Assess
In the Assess phase, determine the systems that will be in scope for static analysis. This should include all
native code that handles untrusted input and Web applications written in C, C++, a .NET language, or Java.
For C or C++, the platform should also be identified, as some tools may be stronger or weaker in analyzing
Unix-style versus Win32® code.
Phase 2: Identify
In the Identify phase, determine potential tools to use for evaluation. Wikipedia provides a list of static
analysis tools.
For organizations developing with Microsoft technologies, the following tools are available for static code
analysis:



PREfast
FxCop
Code Analysis for C/C++ Overview (using/analyze)
16
Phase 3: Evaluate and Plan
In the Evaluate and Plan phase, decide which of the identified tools is most appropriate and can be
productively applied and accepted by the development organization. These tools tend to be expensive
and require advanced configuration and triage capabilities. Be sure to get a vendor-supported test drive
of the product on your actual codebase to see how well it can handle your particular coding conventions
and to determine if the output is usable by your organization.
Phase 4: Deploy
In this phase, deploy the tool. The central security team will need to assist in tuning the tool and triaging
output to identify false positives and false negatives. Some tools can produce a large volume of false
positives, and it is important to eliminate as many of these as possible before they become unnecessary
work for development teams. The security expert team will also need to assist teams in understanding
and prioritizing the output of the tool until the teams become accustomed to evaluating and repairing the
identified issues.
Checkpoint: Security Tools
Requirement
The central security team has evaluated and recommended appropriate static
analysis tools for the organization.
The central security team is able to tune the tool and triage output to identify
false positives and false negatives. The security team can assist product teams in
understanding and prioritizing the output of the tool.
If you have completed the steps listed above, your organization has met the minimum requirements of
the Advanced level for Security Tools. We recommend that you follow additional best practices for
security tools addressed in the SDL Process Guidance at Microsoft MSDN.
Capability Area: Verification
Introduction
Verification is the SDL optimization capability area focused on security practices to discover weaknesses
and to verify security guarantees after software construction is functionally complete. The verification
activities in the Advanced level include evaluating and deploying dynamic scanning tools for Web
applications, comprehensive fuzzing, reviewing of threat models against test plans, and engaging thirdparty penetration testers, as appropriate. (For information about external penetration testing, see the SDL
Optimization Model Implementer Resource Guide: Basic to Standardized. (The requirements at the
Advanced level in this area are the same as those for the Standardized level.) The main benefit of these
activities is that vulnerabilities that might have been easily discovered in an automated manner by
attackers can now be caught and fixed in the Verification phase.
17
Capability: Dynamic Analysis and Application Scanning (Web
Applications)
Overview
Web applications are becoming a major target of choice for attackers. They tend to suffer from a variety
of common attacks. WhiteHat Security noted in a 2008 report that 70 percent of Web sites it examined
suffered from XSS vulnerabilities. Attackers have effective, automated tools to scan for such
vulnerabilities, so defenders must utilize similar tools to find and eliminate these kinds of easily
discoverable weaknesses at the verification stage.
Phase 1: Assess
Most available scanners will work generically on all Web applications, regardless of the underlying
technology platform. However, there may be some edge cases or framework-specific attacks where one
tool or another can cover more deeply, and some scanners may offer better compatibility and coverage
for heavily AJAX-enabled applications. These basic characteristics of the applications to be scanned should
be assessed to help with tool selection. You should also assess which classes of vulnerabilities you expect
the tools to assist in discovering.
Phase 2: Identify
Identify tools to evaluate. Tools in this area vary from fully automated scanners to managed services, to
semi-manual browser toolbars that can integrate into the normal functional testing process. Most
offerings in this area are commercial products, but free or open-source tools to investigate include:
 Scrawlr, a vulnerability scanner co-developed by Hewlett-Packard and Microsoft for identifying SQL
Injection vulnerabilities in Web sites.
 Grendel-Scan by David Byrne.
 Microsoft Application Verifier.
Multiple tools may be beneficial to increase coverage. Certain tools may only offer specialized testing for
one class of vulnerability and should be used in conjunction with a more general scanner. Some tools,
such as Nikto, can be used to scan for Web-server configuration vulnerabilities, but they do not target
discovery of vulnerabilities in custom applications. These should always be used in conjunction with an
application-specific scanner.
Phase 3: Evaluate and Plan
In the Evaluate and Plan phase, decide which of the identified tools are most appropriate and how many
can be productively applied and accepted by the test and development organizations. It will be helpful if
previous versions of the application with known vulnerabilities can be tested or if vulnerabilities can be
deliberately introduced to evaluate the relative effectiveness of each tool. At the Standardized level, one
of the major challenges of this kind of tool is a high false positive rate. Consider the ability of the test and
development organizations to consume and act on the output of the tool, and avoid tools that require
large amounts of effort to comb through mountains of unimportant or illusory bugs.
18
Phase 4: Deploy
In the Deploy phase, roll out the tool to the test organization, or have the security expert group apply it to
selected pilot projects. Gather data on the tool’s effectiveness, and tune it with the goal of making it an
acceptable part of mandatory practices.
Checkpoint: Dynamic Analysis and Application Scanning (Web Applications)
Requirement
Dynamic scanning tools for Web applications are employed against all projects
with high security or privacy risk in the verification or quality assurance phase.
If you have completed the step listed above, your organization has met the minimum requirements of the
Advanced level for Dynamic Analysis. We recommend that you follow additional best practices for
dynamic analysis addressed in the SDL Process Guidance at Microsoft MSDN.
Capability: Fuzzing
Overview
Complex parsers for file formats and custom network protocols are a frequent cause of high-severity
vulnerabilities due to buffer overrun, integer overflow, and related issues possible in languages like C and
C++. Identifying these issues with traditional testing and code review is a time-consuming and error-prone
process. While not 100-percent effective, fuzz testing, the automated creation and execution of many test
cases created by targeted and random mutation, has proven itself as a cost-effective method for
identifying security vulnerabilities. Widely employed by attackers, fuzzing should be proactively utilized by
defenders in verifying their software. At the Standardized level, fuzzing is employed to test file parsers. At
the Advanced level, all complex parsers handling untrusted input must have fuzz coverage, including
network protocol parsers.
For more information, see the following resources:
 Fuzz testing
 Fuzz Testing at Microsoft and the Triage Process from the SDL Blog
 Fuzzing: Brute Force Vulnerability Discovery (ISBN: 0321446119) by Michael Sutton, Adam Greene,
and Pedram Amini (Addison Wesley Professional, 2007)
Phase 1: Assess
The Assess phase involves identifying what kinds of parsers will be required for fuzzing. At the
Standardized level, fuzzing is required for all new file parsers written in C or C++ that accept data across a
trust boundary. Depending on the history of vulnerabilities, it may be desirable to extend this mandate to
cover all such parsers in legacy code and network protocol parsers that are exposed to unauthenticated
data.
19
Phase 2: Identify
In the Identify phase, the security expert team should identify candidate fuzzers. A wide variety of free
and commercial tools are available to satisfy many requirements and styles, including:
 Fuzzing Software, a list of (mostly free) tools, including FileFuzz, from the book Fuzzing: Brute Force
Vulnerability Discovery by Sutton, Greene, and Amini.
 Peach 2 a free, easy-to-use, extensible fuzzing platform. Peach is capable of fuzzing just about
anything you can imagine, including network-based services, RPC, COM/DCOM, SQL stored
procedures, and file formats.
 File Fuzzers, Fuzzbox, Windows® IPC Fuzzing Tools, and Forensic Fuzzing Tools are free fuzz testing
libraries from iSEC Partners.
Phase 3: Evaluate and Plan
During the Evaluate and Plan phase, the security expert team evaluates a few candidate fuzzing
frameworks and tools, and then selects one to use.
Phase 4: Deploy
In the Deploy phase, the selected tool is deployed against eligible parsers. The relevant teams in the
testing organization may own this task, with guidance from the central security team. Vulnerabilities
identified through fuzzing—and their remediation—should be tracked and verified.
Checkpoint: Fuzzing
Requirement
Fuzzing of all parsers handling untrusted input has been integrated into standard
testing procedures.
If you have completed the step listed above, your organization has met the minimum requirements of the
Advanced level for Fuzzing. We recommend that you follow additional best practices for fuzzing
addressed in the SDL Process Guidance at Microsoft MSDN.
Capability: Threat Model Validated
Overview
Threat models prepared at the design phase should be “living” documents that serve as input to and
guidance for later phases of the SDL. In particular, they are primary documents for driving security work at
the Verification stage.
20
Phase 1: Assess
In the Assess phase, determine the process for creating test plans in the organization. Ask yourself: Are
formal test plans created? When in the product development lifecycle does this happen? Who is involved
with the creation of test plans, and how can security be integrated into this process?
Phase 2: Identify
Identify owners in the development and test organization to receive completed threat models as an input
to test plan creation. Prior to that, the architect for the project needs to make sure that the threat model
reflects the functionality that was actually built. If this is not the case, the threat models need to be
modified to reflect the reality of the applications.
Phase 3: Evaluate and Plan
In the Evaluate and Plan phase, work with test plan owners to ensure that appropriate time is budgeted
for additional security testing requirements arising out of threat model re-review.
Phase 4: Deploy
In the Deploy phase, institute threat model re-review as a standard activity in the product development
lifecycle. When possible, test cases should validate threat mitigation strategies.
Checkpoint: Threat Model Validated
Requirement
Threat models are used in the creation of test plans and test cases validate threatmitigation strategies.
If you have completed the step listed above, your organization has met the minimum requirements of the
Advanced level for Threat Model Validated. We recommend that you follow additional best practices for
threat model validated addressed in the SDL Process Guidance at Microsoft MSDN.
Capability Area: Release and Response
Introduction
This capability area focuses on security practices performed for final security assurance before release,
helping to prepare for and execute responses in the event that security vulnerabilities are discovered in
production software. At the Advanced maturity level, the Final Security Review (FSR) is expanded to all
new or high-risk projects. Better archiving and response practices enable speedier and more effective
21
incident investigation and response. These activities result in better protection for the organization and its
customers, and they require less time and cost to remediate security issues that may arise.
Capability: Final Security Review (FSR)
Overview
The Final Security Review is the last chance to determine whether a product is ready for release to
customers. At the more optimized levels of the SDL implementation, the FSR consists primarily of quality
gates to verify that the SDL has been properly followed throughout the development lifecycle. The FSR is
performed jointly by the product team and the central security expert group. It is not primarily an activity
designed to discover bugs, rather it is a governance activity to identify whether discovered bugs have
been properly managed and whether security procedures have been followed.
At the Standardized level, the FSR is performed opportunistically. At the Advanced level, it is a mandatory
governance process for all projects falling under the SDL mandate.
Phase 1: Assess
The FSR at the Advanced level is the key governance activity of the SDL. Scaling the ability to perform and
audit FSR completion and remediation activities to all eligible projects is the key challenge of moving to
the next maturity level. Begin by assessing the resources and practices currently in place at your
organization for software development governance. Consider the following questions: Can existing tools
and processes for audit, ERP, or release tracking be used or expanded to handle the requirements of a
Final Security Review? What new capabilities must be created if these tools do not exist or are
inadequate?
Phase 2: Identify
Next, identify the tasks to be completed as part of the FSR and the artifacts that will result. The tasks to be
completed are driven by the organization’s SDL policy; the FSR supplies verification that the processes and
activities dictated by policy have actually been completed. Example activities for an FSR could include
checking threat models and verifying the output of fuzzing tools, proper compiler settings, and design
review sign-offs.
The output artifacts of the FSR might be a document or spreadsheet archived with other project
documentation, or it might be a more structured audit trail integrated with existing compliance and
project-tracking systems.
Phase 3: Evaluate and Plan
During the Evaluate and Plan phase, resources for performing FSRs are identified, and templates or
system modifications to capture the results of the FSR are created. Additionally, an exception mechanism
must be in place for projects not in compliance that must go forward for other business reasons.
Phase 4: Deploy
The FSR is conducted prior to release of the software, likely concurrent with functional regression testing.
The central security expert team meets with the team and assesses their execution of the required SDL
22
practices. At the Advanced level, projects that do not meet their FSR requirements must come into
compliance or go through an approved exception mechanism.
Checkpoint: Final Security Review
Requirement
The security expert team performs a Final Security Review for all projects falling
under the organizational mandate for SDL compliance. Projects must meet their
FSR requirements or complete an approved exception process prior to release.
If you have completed the step listed above, your organization has met the minimum requirements of the
Advanced level for the Final Security Review. We recommend that you follow additional best practices for
Final Security Review addressed in the SDL Process Guidance at Microsoft TechNet.
Capability: Response Planning and Execution
Overview
Even a perfectly executed SDL cannot prevent all vulnerabilities. Some may be missed, and vulnerabilities
may emerge as new classes of attack are discovered. For an organization just beginning to implement an
SDL process, an orderly response plan is a key competency, not only for externally reported
vulnerabilities, but also for those discovered internally in existing products and systems through increased
security awareness and review.
For more information, refer to the following resources:
 SDL Process Guidance—Phase 5: Release: Planning
 SDL Process Guidance—Post-SDL Requirement: Response
 The Security Development Lifecycle, by Howard and Lipner, Chapter 15: “Stage 10—Security
Response Planning” and Chapter 17: “Stage 12—Security Response Execution”
 Responding to Security Incidents (The Microsoft Security Response Center [MSRC])
 FIRST (Forum of Incident Response and Security Teams)
 IT-ISAC (Information Technology: Information Sharing and Analysis Center)
Phase 1: Assess
The Assess phase involves identifying what the response process must encompass. The general
characteristics of your application will also shape the response plan. Rolling out security updates will
typically be much simpler for Web applications or software-as-a-service (Saas) offerings than it will be for
“shrink-wrapped” products. Consider the following questions when setting goals for incident response
and determining how to involve various principals:
 Do mechanisms exist to automatically notify customers of updates or to automatically apply
patches?
 What is the population of vulnerable users for each product, and how long will it take them to
upgrade?
23
 Do you ship redistributable components (such as libraries or COM objects) that may be a part of
other products?
 What third-party code or binary objects are included in your products which may need servicing?
 Do you ship ActiveX® controls that are not site-locked?
 Will there be potential compatibility impacts for partner or third-party products?
 Will there be compatibility impacts for older versions of your own products?
 What obligations do you have to provide security updates for older versions of your products?
 Are there special characteristics of your products (for example, certified configurations) that may
prevent customers from being able to patch or upgrade?
Phase 2: Identify
In the Identify phase, components that may require security servicing are cataloged. Ask yourself: What
are the target response times for each, and how will they be serviced? What third-party components may
need updating? What kinds of bugs require a special release, and which can wait until the next regular
release cycle?
Phase 3: Evaluate and Plan
During the Evaluate and Plan phase, an incident response plan is created. For the Advanced phase, there
are three major parts to this planning. The first is to identify the owners of modules which may require
servicing. For legacy code, this division may be fairly broad. For new projects, part of the release process
should be to record an incident response owner for every component. There should be a means to
identify that component from customer reports, by URL path, binary module, or otherwise, as appropriate
for your products. Contact information for someone that is available around the clock, 365 days a year,
should be recorded for the development and test staff and for the relevant operations team. An
emergency response will require all three: operational personnel to deploy emergency remediation,
notify affected users, or shut down affected functionality; the development team to do root-cause
analysis and develop a fix; and the test team to verify the fix.
Second, the security expert team or operations should be prepared to monitor and triage mail sent to
public disclosure addresses. You may want to consider publishing a responsible disclosure policy,
especially for online services. See the Microsoft Online Services Security Researcher Acknowledgements
FAQ for an example policy.
Phase 4: Deploy
To deploy the incident response plan, a public contact point for security issues is publicized to collect
notices from the public or security research community. Posting a notice on your company’s Web site is a
good start. Common e-mail address choices for responsible disclosure of vulnerabilities contacts (when a
specific person cannot be otherwise identified) include secure@yourcompanyname.com and
security@yourcompanyname.com. Even if you choose to publicize a different contact address, mail to
these addresses should be monitored.
The final portion of execution is tracking incidents and collecting metrics and analysis on the success of
responses and the ways to prevent similar issues in the future. Bugs should be tracked and root-cause
24
analyses performed to identify whether vulnerabilities affect other products and how they can be
prevented with new or modified SDL practices.
Checkpoint: Response Planning and Execution
Requirement
A proven response plan is in place and has been tested by real-world incidents or
in readiness exercises.
The knowledge gained from incidents is a primary input for improving the security
response process and tools for the future. Root causes of security vulnerabilities
are analyzed and recorded.
If you have completed the steps listed above, your organization has met the minimum requirements of
the Advanced level for Response Planning and Execution. We recommend that you follow additional best
practices for response planning and execution addressed in the SDL Process Guidance at Microsoft MSDN.
25