Microsoft's SDL: Software Security for the Rest of Us

Microsoft’s Secure Development Lifecycle (SDL) is the most comprehensive, practical resource for secure software development that I have found. No other organization comes close to the level of transparency that Microsoft offers into its secure SDLC, even to the point of publicly analyzing problems which made it through the SDL security reviews and gates, and what the team learned from these failures.

Of course, you can argue that Microsoft has a lot of making up to do for the security mess that they helped to create by ignoring quality and security issues for so long, but the SDL, with its detailed process framework and tools and other supporting resources, all freely accessible, is a valuable contribution to the general software development community.

The SDL includes:

1. the SDL process framework, a prescriptive, step-by-step guideline for applying software security practices throughout development and implementation;
2. a Starter Kit which provides guidance for adopting the SDL and training resources;
3. business case resources if you or your boss needs a justification for investment in secure software development;
4. a repository of free tools, including fuzzers, static analysis tools for .NET code and other tools that are Microsoft-specific. However, this repository also includes a general-purpose Threat Modeling tool which helps you walk through and document threat models;
5. a set of white papers and presentations supporting the SDL;
6. and a blog on software security and SDL related topics.
   

Earlier versions of the Microsoft SDL as described in the 2006 book (which, while sometimes preachy and shrill in defense of Microsoft, is still worth reading) are more approachable, especially to the wider software development community. As the SDL continues to develop, becomes more institutionalized within Microsoft, it is becoming more inward-looking, bound up with specific practices and technologies – it’s become, well, more Microsofty. This is to be expected, and reflects Microsoft’s priorities for the SDL:

1. first to address Microsoft’s own weaknesses in software security and reliability, after years of focusing on shipping features;
2. to help make Microsoft’s .Windows a more secure platform, and .NET a more secure development environment, to further the sale of Microsoft technology;
3. and finally to share Microsoft’s insights, experience and frameworks on building secure software with the software community, and polish up the Microsoft brand by establishing the "new Microsoft" as a thought leader in the field.

So what lessons, what value can the wider software community take from the SDL, especially teams that do not develop on or for MS Windows, don’t use .NET or Microsoft development tools? Here are the main points that I have taken from the SDL, the ideas and practices that stood out for me:

Information Privacy

First, the SDL makes a special point of separating security and privacy issues, and lays out design guidelines and considerations, best practices and review gates for ensuring both security and privacy in software design and construction, implementation and support. This is an important and useful perspective for software teams working in regulated industries such as finance or health with special obligations for ensuring information privacy.

Training

The SDL emphasizes the value of training for the entire team – not only awareness training, but a training ladder which addresses the needs of different specialists (architects, developers, testers, project managers). It also emphasizes the need for constant upgrading of training – every member of the team must complete at least 1 training course every year – to ensure that the team is updated with the changing threat landscape and advances in the state of the art, as well as to reinforce basic practices.

Issue Tracking

Security issues need to be tracked in the bug tracking system, and made visible to the team. For each security bug, information about the cause and impact/effect should be recorded for metrics and root cause analysis purposes.

Design

Secure design is centered on threat modeling which the authors describe as the corner stone of their secure development process, using the STRIDE approach. There is a growing emphasis in more recent versions of the SDL on the importance of creating and maintaining artifacts from threat modeling exercises to be used in other steps of the SDL (such as attack surface reviews, testing, fuzzing and other review gates), and using software tools to assist in threat modeling (not surprising, coming from a company that builds tools for other developers).

The other important consideration in secure design is reviewing and reducing the attack surface of the application – fundamentally a good idea of course, while not necessarily easy to do (the reducing part).

Construction

Security practices and controls here emphasize the use of secure coding guidelines and checklists, and the use of static binary analysis tools – some of which are provided by Microsoft in the free SDL tool repository.

Verification

I was interested in the emphasis on fuzzing by Microsoft. It makes sense, given that they started with a large legacy code base, with well known reliability problems: fuzzing protocols and files and other interfaces offers a high return in finding basic problems in validation and other fundamental mistakes which contribute to a lot of reliability and security problems. This encouraged me to introduce fuzzing into our testing regimen last year, something that we are continuing to work on.

The other key practices in verification are vulnerability regression testing (if a vulnerability is found, create tests to ensure that the problem is not reintroduced); and code reviews, following a risk-based approach to focus on high-risk areas of code:

- internet-facing and network-facing code
- code that runs with elevated privileges
- code that handles secrets
- code that has a history of vulnerabilities
- older code

Release Management

Security incident response planning: face that you may encounter problems in production, prepare to handle them.

And final reviews for security and privacy: review the threat model (again); review the team's compliance with SDL practices; and review security issues that were deferred or not addressed by the team.

Scaling the SDL for agile development

Microsoft recognizes that the SDL is heavyweight (it was created to support long, spiral development cycles for products like Microsoft Windows and MS Office) and that teams following agile, rapid delivery methods will not have enough time to apply the full SDL. In its most recent release, Microsoft provides guidelines for smaller, agile teams to scale the SDL, breaking out its activities as follows:

One-time – generally done at the start of the project (iteration 0)
- choose a security advisor
- baseline threat models
- setup bug tracking

Every iteration – must be done
- static analysis
- threat model for all new features
- strong crypto
- review of error messages

Buckets: 1 of each activity type needs to be done in each iteration
- verification: fuzzing, attack surface analysis, or code review of high-risk code
- design: crypto review, privacy review, threat model training, or attack surface reduction
- response planning: contacts, planning and updating for incident response

At the end of every sprint, there is a lightweight review gate to ensure that the team is following the SDL guidelines.

The SDL for agile teams is a compromise: but it may be a compromise that not all small teams can handle, at least to start. An extremely lightweight approach is offered by Michael Howard, a principal security program manager at Microsoft and one of the author’s of the SDL, in his Everything Developer Security presentation, where he hilights the critical importance of 1 core practice each for designers, developers and testers, which together address a significant number of security problems:

1. Designers: threat modeling.
   
2. Coders: never trust data (“all input is evil until proven otherwise”) - half of all security bugs are input validation problems.
3. Testers: fuzzing – which is described as “brutally effective” for both security and reliability issues.

This list can be thought of as the lowest possible bar, a minimum set of practices that teams need to build on.

I like that the ideas, practices and tools in the SDL can be scaled up and down; that it can be applied at different levels of organizational maturity; and that it provides so many useful resources, even to teams who are not building software in the Microsoft world.