Microsoft Security Development Lifecycle

Microsoft Security Development Lifecycle (SDL), introduced by Howard and Lipner (2006), offers a set of security practices and tools for the software development process. SDL is a result of Microsoft’s systematic program to improve the security of its software products, and the perception that the regular software development methods were not offering adequate mecha- nisms to create secure software. Development of the SDL followed the con- siderable publicity of the security issues in Microsoft products, especially the Windows XP, released in 2001. To remedy the security flaws, and in an attempt to regain the lost trust, they established new security policies and a more security-oriented culture, resulting in the SDL. Microsoft advocated the internal use of the SDL by making it a process requirement for several types of applications. The model is to be followed in the development of all software which (a) handles personally sensitive information; (b) is used in academia or enterprises; or, (c) is operated in a networked environment. These categories comprise the majority of current software products. Win- dows Vista, released in 2007, was the first Windows release to go through the full SDL cycle (Howard and Lipner (2006); see also Anderson (2008)), and Microsoft gives credit to the SDL for the drastic drop of security-related

incidents compared to its direct predecessor, Windows XP.

The activities are distributed into phases in the development accord- ing to a traditional life cycle sequence. Later, the SDL was adapted for agile development by Microsoft (2017): in the agile adaptation, activities are presented not only by the phase but also by their frequency during the development. The frequency classes are one-time activities performed once during a project, “bucket” practices performed as seen necessary, and activ- ities performed in every iteration.

The SDL Process

The SDL model, with augmentations for agile development, is presented in Table 2.4.

Table 2.4: Activities in the Microsoft SDL (Microsoft (2017))

Phase Use in Agile Activity

Training Core Security Training

Requirements One-time Establish Security Requirements Bucket Create Quality Gates/Bug Bars

One-time Security and Privacy Risk Assessments Design One-time Establish Design Requirements

One-time Attack Surface Analysis / reduction Every-sprint Use Threat Modeling

Implementation Every-sprint Use Approved Tools

Every-sprint Deprecate Unsafe Functions Every-sprint Perform Static Analysis Testing Bucket Perform Static Analysis

Bucket Fuzz Testing

Bucket Attack Surface Review

Release One-time Create an Incident Response Plan Every-sprint Final Security Review

Every-sprint Certify Release and Archive Response Execute Incident Response Plan

SDL activities extend across the development phases, with a focus on the requirement and design activities. Microsoft also provides a rudimentary set of security tools, documentation templates and more detailed instructions for the security work. The accompanying software includes tools for threat modeling, static code review and attack surface analysis, and an analyzer for binaries. The tools and their terminology are limited to Microsoft operating systems, greatly limiting their applicability to general software development work.

Threat modeling is a central practice in the SDL. However, creating and

maintaining a sufficiently detailed security model of the TOE and its Op- erating Environment may provide substantial overhead. To avoid this, a threat modeling tool is to be used in iterative development from the be- ginning, and the tools is optimally an integral part of the design process. When the concept is turned around, the used design tool should also work as a threat modeling tool.

The main purpose of threat modeling is to make the security risks visible and therefore manageable. In terms of SSE-CMM processes, threat mod- eling contains the threat and vulnerability process areas. In the original text by Howard and Lipner (2006), SDL threat modeling is a document, or rather, a complex set of documents, consisting of data flow diagrams, a list of protected assets, and list of threats to the system ranked by the risk (implying the use of a quantitative risk management framework). While these documents are considered optional, the most relevant background in- formation consists of use scenarios, a list of external dependencies, security assumptions of the security services offered by other components, and ex- ternal security notes.

Manually maintaining a threat model in the extensive detail described by Howard and Lipner (2006) is hardly feasible, especially in an iterative process. SDL does, however, give a metric for evaluation of a threat model. An acceptable threat model:

• Conforms to the actual design

• Is dated no more than 12 months ago

• Contains a data flow diagram containing assets, users and trust bound- aries

• Details at least one threat for each software asset

• Provides mitigation for all high-level risks

In addition to these criteria, a good model adds authentication schemes to the data flow diagrams and provides classification of the threats. An

excellent model utilizes also a suitable security analysis technique to identify

all threats; furthermore, all threats have mitigation, and external security notes include a plan to create customer-facing instructions.

As an example of a security analysis technique to be used in threat mod- eling, Howard and Lipner (2006) suggest STRIDE to identify six common categories of security threats: Spoofing, Tampering, Repudiation, Informa- tion Disclosure, Denial of Service, and Elevation of Privileges. A number of mitigation techniques are suggested against these, ranging from program- ming techniques to organizational processes and infrastructure security. For

a software practitioner, techniques usable for threat or vulnerability identi- fication are vital. However, the mitigation techniques may be found beyond software engineering as noted by McGraw (2006).

The list of details and requirements in the original SDL model is stag- gering. Without clear prioritization, they may not be implementable within the limitations of a smaller development organization, facing acute person- nel and time constraints. Fuzz testing is another task difficult to perform in a time-boxed manner. Fuzz tests require expertise, tools, and an extended period of time to produce results of practical benefit.

Applying the SDL

The original model by Howard and Lipner (2006) presents the SDL process as a sequential waterfall-like process, progressing in 12 stages from project inception to product release, and finally, security response execution. The individual techniques are of importance, having an extensive focus on pro- gramming techniques and code quality and the validity of the design. Se- curity requirements and the risk process revolve around the software and security design, which itself relies on careful analysis and reduction of at- tack surface, and creating the design based on threat models. This approach reflects the primary purpose of software security engineering: creating se- cure software by preventing and finding software bugs during development. At Microsoft, the effort could be labeled “security-driven quality improve- ment”, as security, privacy and reliability were seen, and marketed to the company management under the umbrella of quality (Howard and Lipner (2006) pp. 9-10).

The SDL addresses security training as a prerequisite for all security work. Training is to be complemented and improved as necessary during the development whenever changes in requirements or design warrant for it. A noteworthy requirement-phase practice is setting the quality gates called “bug bars”. Essentially, this is a quality assurance technique involving the setting of a bug standard, and the triage for placing the found bugs into three categories based on the risk assessment. The process also involves setting clear error categories for bugs that would necessitate a fix or further investigation, especially when a fix is probably needed. These categories are separately set for both client and server side software and are largely results of fuzz testing (see Howard and Lipner (2006) pp. 163-164). In the SDL, security testing techniques also have a focus on the improvement of code quality, in addition to producing test reports for the security assurance process.

SDL’s adoption for agile development is a late addition to the model. In the original form by Howard and Lipner (2006), the SDL is described as a process, with 12 distinct stages. The instructions for integrating the process

with agile consists mainly of recapitulating the agile principles and Extreme Programming quality improvement techniques. In the current model by Mi- crosoft (2017), the main changes are simplifying the process into six phases, and adding superficial labeling to the activities according to their perceived frequency during an iterative project.

If followed literally, restricting some activities’ use frequency to a strict one-time limit may even be detrimental for security. In iterative work, no activity can be guaranteed to be limited to simple one-time execution. This thinking appears to originate from the model’s “waterfall-like” origins: for example, the model instructs risk assessment to be done only once during a project. In iterative development, it is essential for the risk assessment process to be performed after each change in relevant design or requirements. Finally, Microsoft’s original online documentation for the agile model created confusion by treating an agile iteration as a synonym for release. This echoes the early agile ideal of each agile iteration producing a potentially shippable product release.

Much like the SSE-CMM, the abstraction level of the instructions in SDL is high. The model captures the essentials of software security engineering and assurance processes and promotes the use of threat modeling as a way to manage security risks. The SDL model does not, however, provide a standalone security solution for security implementation, and in practice provides a loose framework of practice categories. In addition, the central concept of a threat model will require either a very competent tool, or a very dedicated security-minded person to get created and maintained at an acceptable level.

Howard and Lipner (2006) do describe the rationale, and much of the practical reasoning and even the process of building up the SDL activities, as it was done at Microsoft. It is conceivable, however, that many of the condi- tions and motives are hardly applicable to more modest-sized organizations, with perhaps more meagre resources. Applying SDL, more detailed mod- els should be consulted, including the Common Criteria for evaluation and the SSE-CMM for implementation. Security rationale justifies the security means.