다음을 통해 공유

Introduction

  • 아티클

All software developers must address security threats. Computer users now require trustworthy and secure software, and developers who address security threats more effectively than others can gain competitive advantage in the marketplace. Also, an increased sense of social responsibility now compels developers to create secure software that requires fewer patches and less security management.

Privacy also demands attention. To ignore privacy concerns of users can invite blocked deployments, litigation, negative media coverage, and mistrust. Developers who protect privacy earn users’ loyalties and distinguish themselves from their competitors.

Secure software development has three elements-best practices, process improvements, and metrics. This document focuses primarily on the first two elements, and metrics are derived from measuring how they are applied.

Microsoft has implemented a stringent software development process that focuses on these elements. The goal is to minimize security-related vulnerabilities in the design, code, and documentation and to detect and eliminate vulnerabilities as early as possible in the development lifecycle. These improvements reduce the number and severity of security vulnerabilities and improve the protection of users’ privacy.

Secure software development is mandatory for software that is developed for the following uses:

  • In a business environment

  • To process personally identifiable information (PII) or other sensitive information

  • To communicate regularly over the Internet or other networks

(For more specific definitions, see the "What Products and Services are Required to Adopt the Security Development Lifecycle Process?" section later in this Introduction.)

This document describes both required and recommended changes to software development tools and processes. These changes should be integrated into existing software development processes to facilitate best practices and achieve measurably improved security and privacy.

Note: This document outlines the SDL process used by Microsoft product groups for application development. It has been modified slightly to remove references to internal Microsoft resources and to minimize Microsoft-specific jargon. We make no guarantees as to its applicability for all types of application development or for all development environments. Implementers should use common sense in choosing the portions of the SDL that make sense given existing resources and management support. Also read the Simplified Implementation of the Microsoft SDL white paper that illustrates the core concepts and security activities to be performed by any development organization that wants to implement the Microsoft SDL.

On This Page

The Traditional Microsoft Product Development Process
Secure by Design
Secure by Default
Secure in Deployment
Communications
Privacy by Design
Privacy by Default
Privacy in Deployment
Communications
The Security Development Lifecycle
What Products and Services Are Required to Adopt the SDL Process?
Are Service Releases Required to Adopt the SDL Process?
How Are New Recommendations and Requirements Added to the SDL Process?
How Are SDL Requirements Determined for a Specific Product Release?

The Traditional Microsoft Product Development Process

In response to the Trustworthy Computing (TwC) directive of January 2002, many software development groups at Microsoft instigated security pushes to find ways to improve the security of existing code and one or two prior versions of the code. However, the reliable delivery of more secure software requires a comprehensive process, so Microsoft defined Secure by Design, Secure by Default, Secure in Deployment, and Communications (SD3+C) to help determine where security and privacy efforts are needed. The guiding principles for SD3+C are identified in the following subsections.

Secure by Design

  • Secure architecture, design, and structure. Developers consider security issues part of the basic architectural design of software development. They review detailed designs for possible security issues and design and develop mitigations for all threats.

  • Threat modeling and mitigation. Threat models are created, and threat mitigations are present in all design and functional specifications.

  • Elimination of vulnerabilities. No known security vulnerabilities that would present a significant risk to anticipated use of the software remain in the code after review. This review includes the use of analysis and testing tools to eliminate classes of vulnerabilities.

  • Improvements in security. Less secure legacy protocols and code are deprecated, and, where possible, users are provided with secure alternatives that are consistent with industry standards.

Secure by Default

  • Least privilege. All components run with the fewest possible permissions.

  • Defense in depth. Components do not rely on a single threat mitigation solution that leaves customers exposed if it fails.

  • Conservative default settings. The development team is aware of the attack surface for the product and minimizes it in the default configuration.

  • Avoidance of risky default changes. Applications do not make any default changes to the operating system or security settings that reduce security for the host computer. In some cases, such as for security products (for example, Microsoft® Internet Security and Acceleration (ISA) Server), it is acceptable for a software program to strengthen (increase) security settings for the host computer. The most common violations of this principle are games that either open up firewall ports without informing the user or instruct users to do so without consideration of possible risks.

  • Less commonly used services off by default. If fewer than 80 percent of a program’s users use a feature, that feature should not be activated by default. Measuring 80 percent usage in a product is often difficult, because programs are designed for many different personas. It can be useful to consider whether a feature addresses a core/primary use scenario for all personas. If it does, the feature is sometimes referred to as a P1 feature.

Secure in Deployment

  • Deployment guides. Prescriptive deployment guides outline how to deploy each feature of a program securely, including providing users with information that enables them to assess the security risk of activating non-default options (and thereby increasing the attack surface).

  • Analysis and management tools. Security analysis and management tools enable administrators to determine and configure the optimal security level for a software release. These tools include Microsoft Baseline Security Analyzer as well as Group Policy, through which you can manage all security-related configuration options.

  • Patch deployment tools. Deployment tools are provided to aid in patch deployment.

Communications

  • Security response. Development teams respond promptly to reports of security vulnerabilities and communicate information about security updates.

  • Community engagement. Development teams proactively engage with users to answer questions about security vulnerabilities, security updates, or changes in the security landscape.

An analogous concept to SD3+C for privacy is known as PD3+C. The guiding principles for PD3+C are:

Privacy by Design

  • Provide notice and consent. Provide appropriate notice about data that is collected, stored, or shared so that users can make informed decisions about their personal information.

  • Enable user policy and control. Enable parents to manage privacy settings for their children and enterprises to manage privacy settings for their employees.

  • Minimize data collection and sensitivity. Collect the minimum amount of data that is required for a particular purpose, and use the least sensitive form of that data.

  • Protect the storage and transfer of data. Encrypt personally identifiable information(PII) in transfer, limit access to stored data, and ensure that data usage complies with uses communicated to the customer.

Privacy by Default

  • Ship with conservative default settings. Obtain appropriate consent before collecting or transferring any data. To prevent unauthorized access, protect personal data stored in access control lists.

Privacy in Deployment

  • Publish deployment guides. Disclose privacy mechanisms to enterprise customers so that they can establish internal privacy policies and maintain their users’ and employees' privacy.

Communications

  • Publish author-appropriate privacy disclosures. Post privacy statements on appropriate websites.

  • Promote transparency. Actively engaging mainstream and trade media outlets with white papers and other documentation to help reduce anxiety about high-risk features.

  • Establish a privacy response team. Assign staff who are responsible for responding if a privacy incident or escalation occurs.

The Security Development Lifecycle (SDL)

After you add steps to the development process for all elements of SD3+C, the secure software development process model looks like the one shown in Figure 1.

The Security Development Lifecycle

Figure 1. Secure software development process model at Microsoft

Process improvements are incremental and do not require radical changes in the development process. However, it is important to make improvements consistently across an organization.

The rest of this document describes each step of the process in detail.

What Products and Services Are Required to Adopt the SDL Process?

  • Any software release that is commonly used or deployed within any organization, such as a business organization or a government or nonprofit agency.

  • Any software release that regularly stores, processes, or communicates personally identifiable information (PII) or other sensitive information. Examples include financial or medical information.

  • Any software product or service that targets or is attractive to children 13 years old and younger.

  • Any software release that regularly connects to the Internet or other networks. Such software might be designed to connect in different ways, including:

    • Always online. Services provided by a product that involve a presence on the Internet (for example, Windows® Messenger).

    • Designed to be online. Browser or mail applications that expose Internet functionality (for example, Microsoft Outlook® or Internet Explorer®).

    • Exposed online. Components that are routinely accessible through other products that interact with the Internet (for example, Microsoft ActiveX® controls or PC–based games with multiplayer online support).

  • Any software release that automatically downloads updates.

  • Any software release that accepts or processes data from an unauthenticated source, including:

    • Callable interfaces that “listen”.

    • Functionality that parses any unprotected file types should be limited to system administrators.

  • Any release that contains ActiveX controls.

  • Any release that contains COM controls.

Are Service Releases Required to Adopt the SDL Process?

Any external release of software that can be installed on a customer’s computer, regardless of operating system or platform, must comply with security and privacy policies as described in the Security Development Lifecycle. This SDL applies to new products, service releases such as product service packs, feature packs, development kits, and resource kits. The terms service pack and feature pack might not always be used in the descriptive title of a release to customers, but the following definitions differentiate what constitutes a new product from a service release or feature pack.

  • New Product Releases are either completely new products (version 1.0) or significant updates of existing products (for example, Microsoft Office 2003). A new product release always requires a customer to agree to a new software license, and typically involves new packaging.

  • Service Releases include service packs or feature packs and resource kits.

  • Service Packs are the means by which product updates are distributed. Service packs might contain updates for system reliability, program compatibility, security, or privacy. A service pack requires a previous version of a product before it can be installed and used. A service pack might not always be named as such; some products may refer to a service pack as a service release, update, or refresh.

  • Resource Kits are collections of resources to help administrators streamline management tasks. A resource kit must be targeted at a single product release to be treated as a service release. If a resource kit is targeted at multiple products, or at multiple versions of a product, SDL requirements will apply to it as described above for a product release.

  • Development Kits provide information, detailed architecture details, and tools to developers. A development kit must be targeted at a single product release to be treated as a service release. If a development kit is targeted at multiple products or at multiple versions of a product, SDL requirements from the corresponding product release will apply.

All software releases referenced in the "What Products and Services Are Required to Adopt the SDL Process?" section must adopt SDL. However, current SDL requirements will be applied only to the new features in the service release and not retroactively to the entire product. Also, product teams are not required to change compiler versions or compile options in a service release.

How Are New Recommendations and Requirements Added to the SDL Process?

The Security Development Lifecycle consists of the proven best practices and tools that were successfully used to develop recent products. However, the area of security and privacy changes frequently, and the Security Development Lifecycle must continue to evolve and to use new knowledge and tools to help build even more trusted products. But because product development teams must also have some visibility and predictability of security requirements in order to plan schedules, it is necessary to define how new recommendations and requirements are introduced, as well as when new requirements are added to the SDL.

New SDL recommendations may be added at any time, and they do not require immediate implementation by product teams. New SDL requirements should be released and published at six-month intervals. New requirements will be finalized and published three months before the beginning of the next six-month interval for which they are required. For more information about how to hold teams accountable for requirements, see How Are SDL Requirements Determined for a Specific Product Release?

The list of required development tools (for example, compiler versions or updated security tools) is typically the area of greatest interest because of the potential impact on schedule and resources. The following example timeline helps to illustrate this point:

  • October 1, 2012. Publish updated requirements that will apply to all products registering after January 1, 2012.

  • January 1, 2013. Updated requirements list takes effect.

  • April 1, 2013. Publish updated requirements that will apply to all products registering after July 1, 2012.

  • July 1, 2013. Updated requirements list takes effect.

How Are SDL Requirements Determined for a Specific Product Release?

A product release is held accountable for the SDL requirements that are current on the day the product registers a request for SDL review. Product teams can refer to the SDL version numbers to determine the appropriate policies to follow. There are some caveats to this rule:

  • One-year cap. At a minimum, a product must meet SDL requirements that are older than one year at the time of release to manufacture (RTM) or release to web (RTW).

  • Multi-version limit. If you register more than one version of your product to be released in succession, later versions are held to the requirements that are in effect on the date the previous version was released.

  • Previous version. All projects that are already registered before July 1 of a given year will be subject to the SDL requirements published on January 1 of the same year.

  • Threat evolution. The security engineering team reserves the right to add new requirements at any time in response to the availability of high-impact tools or the evolution of new threats.

The following examples illustrate how SDL requirements are determined:

  • If a product registered with the SDL team in the first half of calendar year 2012 (H1CY12) but does not ship until H2CY13, it must meet all H2CY12 requirements.

  • If a team registers two versions of a product to be released within a three-month period, the first version is subject to current requirements, but the second version is subject to the published requirements on the day the first version ships.

Content Disclaimer

This documentation is not an exhaustive reference on the SDL process as practiced at Microsoft. Additional assurance work may be performed by product teams (but not necessarily documented) at their discretion. As a result, this example should not be considered as the exact process that Microsoft follows to secure all products.

This documentation is provided “as-is.” Information and views expressed in this document, including URL and other Internet website references, may change without notice. You bear the risk of using it.

This documentation does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes.

© 2012 Microsoft Corporation. All rights reserved.

Licensed under Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported