DOCX

Microsoft Security Development Lifecycle (SDL) Optimization Model

By Philip Dunn,2014-06-20 13:53
14 views 0
Microsoft Security Development Lifecycle (SDL) Optimization Model

    Microsoft Security Development Lifecycle (SDL) Optimization Model

    Self-Assessment Guide

    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 organization 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 currently 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 Self-Assessment Guide will help those responsible for implementing the SDL to assess the current level of maturity in their organizations and to identify the necessary activities and capabilities needed to move to the next, higher level of maturity. The guide was designed to be used in conjunction with the detailed Implementer Resource Guides for advancing

    in the maturity levels of the SDL 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, Visual C++, Visual Studio, SQL Server, and Win32 are either trademarks or registered 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 Maturity Levels Overview ............................................................................................................................................. 1 Self Assessment ............................................................................................................................................................... 3 Capability Area: Training, Policy, and Organizational Capabilities .................................................................................. 3 Requirements for the Standardized maturity level .................................................................................................... 3 Requirements for the Advanced maturity level ......................................................................................................... 4 Requirements for the Dynamic maturity level ........................................................................................................... 5 Capability Area: Requirements and Design .................................................................................................................... 7 Requirements for the Standardized maturity level .................................................................................................... 7 Requirements for the Advanced maturity level ......................................................................................................... 8 Requirements for the Dynamic maturity level ......................................................................................................... 10 Capability Area: Implementation ................................................................................................................................ 10 Requirements for the Standardized maturity level .................................................................................................. 10 Requirements for the Advanced maturity level ....................................................................................................... 12 Requirements for the Dynamic maturity level ......................................................................................................... 12 Capability Area: Verification ....................................................................................................................................... 13 Requirements for the Standardized maturity level .................................................................................................. 13 Requirements for the Advanced maturity level ....................................................................................................... 14 Requirements for the Dynamic maturity level ......................................................................................................... 15 Capability Area: Release and Response ....................................................................................................................... 16 Requirements for the Standardized maturity level .................................................................................................. 16 Requirements for the Advanced maturity level ....................................................................................................... 17 Requirements for the Dynamic maturity level ......................................................................................................... 18

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).

    Maturity Levels Overview

    This guide describes a checklist of requirements to meet each maturity level for the five capability areas in the

    SDL Optimization Model. The following table offers a general overview of the various capability areas and

    maturity levels. To make the table more readable, the activities specified for each maturity level should be read

    to include the activities from the lower level.

     1

2

Self Assessment

    The following section presents questions for each of the core capabilities to help you assess your maturity level in a given capability area. Many of the requirements in the following section have minimum attributes associated with them. If your organization meets every requirement and attribute outlined in a certain maturity level, you have already achieved that level and can proceed to the next maturity level in the SDL Optimization Model. You can print this section as a scorecard for determining which requirements and attributes you need to implement in your organization.

    Capability Area: Training, Policy, and Organizational Capabilities

    Requirements for the Standardized maturity level

    Capability: Training

    The Standardized level of optimization requires that the security practices, skills, and sophistication of the developer and tester roles in the software engineering process be assessed to determine the need and the specific content for security training materials. A “Basics of Secure Design, Development, and Test” or equivalent

    curriculum should be developed internally, or a training partner can be engaged from the SDL Pro Network, and the course should be completed by architects, developers, and quality assurance testers for the SDL pilot projects.

    Training needs have been determined and content and an

    appropriate curriculum for developers and testers in the

    organization has been created or acquired.

    Architects, developers, and testers for Basic to Standardized pilot

    projects have completed introductory training.

For more information, see the Training capability section in the SDL Optimization Model Implementer Resource

    Guide: Basic to Standardized.

    Capability: Bug Tracking

    The Standardized level of optimization requires that bug-tracking systems be updated to include fields to classify vulnerabilities by their security cause (for example, buffer overflow), effect (for example, elevation of privilege), and method of discovery (for example, code review).

     3

    Bug databases and tracking software can record and classify

    vulnerabilities by security cause, effect, and method of discovery.

For more information, see the Bug Tracking capability section in the SDL Optimization Model Implementer

    Resource Guide: Basic to Standardized.

    Requirements for the Advanced maturity level

    Capability: Training

    At the Standardized level, the training requirement encompasses only the completion of a “Basics of Secure Design,

    Development, and Test” or equivalent course for developers and testers involved in pilot projects. Broadening and extending staff training is a key component of reaching the Advanced maturity level.

    The organization has acquired or developed a training curriculum

    for the following subject areas:

     Basics of Secure Design, Development, and Test or equivalent

     Privacy in Development

     Introduction to the Microsoft Security Development Lifecycle

     Introduction to Threat Modeling

    Personnel have completed both the “Introduction to the Microsoft

    SDL” and “Introduction to Threat Modeling” classes, and the “Basics”

    or “Privacy in Development” course as appropriate to their role.

    For more information, see the Training capability section in the SDL Optimization Model Implementer Resource Guide: Standardized to Advanced.

    Capability: SDL Policy

    At the Advanced level, policy becomes a larger part of governing the SDL process. Policy 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 sets the quality gates that need to be

    met before release.

     4

    The SDL policy formally defines which projects qualify for SDL mandates

    and what the requirements are for compliance. A process exists to track

    SDL compliance and issue the necessary exceptions for high-risk projects.

    For more information, see the SDL Policy capability section in the SDL Optimization Model Implementer Resource

    Guide: Standardized to Advanced.

    Capability: Central Ownership of Security and Privacy Advisement

    At the Standardized level, advisement by the involved expert is on a per-project basis. To reach the Advanced level, this should become an official organizational capability that is owned by a centralized security team.

    Security and privacy advisement is an official organizational capability

    that is owned by a central security team.

    For more information, see the Security and Privacy Advisement capability section in the SDL Optimization Model

    Implementer Resource Guide: Standardized to Advanced.

    Requirements for the Dynamic maturity level

    Capability: SDL Policy

    At the Dynamic level, SDL policy places every project with meaningful security or privacy risk under the mandate of the SDL. At this level, the policy provides specific requirements based on different development criteria, such as product type (for example, client, server, or online services), code type (for example, native or managed) and platform (for example, target operating system [OS] or device). In addition, activities and standards in the policy are periodically refreshed, incorporating lessons learned from root-cause analysis of security incidents, adaptations to the changing threat environment, and improvements in tools and techniques.

    The SDL policy covers all projects that have a meaningful security and

    privacy risk and is periodically updated to cover new threats and practices.

    For more information, see the SDL Policy capability section in the SDL Optimization Model Implementer Resource

    Guide: Advanced to Dynamic.

     5

Capability: Training

    At the Advanced level, organizations are offering specialized training to address the security needs and emerging threats to particular modules and product groups. This training may be developed in-house or sourced from reputable conferences or third parties, such as Microsoft SDL Pro Network members.

    Engineers and testers have access to advanced training topics

    targeted to the specific security and privacy requirements of

    individual product groups.

    For more information, see the Training capability section in the SDL Optimization Model Implementer Resource

    Guide: Advanced to Dynamic.

    Capability: Security “Champions” in Product Groups

    At the Advanced level, most SDL activities are heavily supported by the central security team. As organizations move to the Dynamic level, security expertise and responsibility will become more distributed to “champions” embedded in each product group who have a deeper level of experience and can specialize and contribute security expertise on a continual basis across the lifecycle. At this level, the central security team will focus more on ensuring compliance with the policy prior to release, assisting the product teams as necessary and developing technologies to improve the effectiveness of the SDL within the organization.

    Ownership of the SDL activities and responsibilities is partially distributed

    to embedded security “champions” in major product groups.

    For more information, see the Security Champions” in Product Groups capability section in the SDL Optimization

    Model Implementer Resource Guide: Advanced to Dynamic.

    Capability: SDL Is Adapted to the Development Methodology

    By the time the Advanced level is reached, the SDL is becoming a regular part of developing software at an organization. At the Dynamic level, the SDL activities are fully integrated into the ordinary process and governance of the software development methodology, whether it is waterfall, Agile, or another style. For product teams, the SDL is a normal part of the way they create software, not an additional set of requirements.

    The SDL activities are an integral and mandatory part of how the

    organization creates software, and practices are integrated with

    the development methodology (such as waterfall or Agile).

    For more information, see the Development Methodology Integration capability section in the SDL Optimization

    Model Implementer Resource Guide: Advanced to Dynamic.

     6

Capability Area: Requirements and Design

    Requirements for the Standardized maturity level

    Capability: Risk Assessment

    The Standardized level of optimization requires that new projects in business areas with meaningful security risk (as defined by the organization’s SDL policy) fill out a risk-assessment questionnaire. This gives the security

    management team visibility into the total organizational need for a security review and helps to prioritize the most important projects so resources can be properly allocated.

    A risk questionnaire exists and is a mandatory part of the project

    initiation or requirements lifecycle phase and the SDL pilot

    projects have been identified based upon this questionnaire.

    For more information, see the Risk Assessment capability section in the SDL Optimization Model Implementer

    Resource Guide: Basic to Standardized.

    Capability: Quality Gates

    At project inception, it should be determined whether a feature or product qualifies for the SDL. Typically, features rated as low risk, or certain classes of product (such as software development kits [SDKs]), may not qualify for these practices. At the Standardized level, participation in the SDL is opportunistic, rather than mandated, and it applies only to the pilot projects selected for their risk ranking or ability to absorb and perform the newly required practices. It is important at an early stage of the software development lifecycle to identify which projects qualify and what their final security exit criteria before release will be. This allows accurate estimates of security practices to be built into the project timeline.

    A definition of security and privacy bug classifications exist as

    release criteria for the SDL pilot projects.

    For more information, please see the Quality Gates capability section in SDL Optimization Model Implementer

    Resource Guide: Basic to Standardized.

    Capability: Threat Modeling

    At the Standardized level, it is recommended that threat models be created for system components that have large attack surfaces, are relied upon by other components to enforce security requirements, or have complex interactions with untrusted systems. A security expert (internal or external) can provide direct assistance and moderation in the creation of a threat model with the product team.

     7

Report this document

For any questions or suggestions please email
cust-service@docsford.com