Security Development Lifecycle (SDL), developed at Microsoft, is a security assurance process with a focus on software development. It introduces security and privacy aspects in all phases of the software development process with the goal of protecting end-users. The framework also includes a collection of mandatory security activities, grouped by the phases of the traditional software development life cycle.
There are seven phases in the SDL process which are as follows:
- Security Training: This is part of the pre-SDL requirements where a well thought out security training program allows software development teams to learn about security and privacy basics, specific technical issues and stay informed about recent trends in security and privacy.
- Requirements: The Requirements phase is where development teams consider how to best integrate security and privacy into the development process, identify key security objectives - while minimizing disruption to application usability, project plans, and schedules.
- Design: The Design phase identifies the overall requirements and structure for the software product and establishes design best practices. A core element of SDL design phase is threat modeling which can be performed using the SDL Threat Modeling Tool. Threat Modeling tool can be used by security as well as non-security subject matter experts to create and analyze threat models by:
- Communicating about the security design of their systems,
- Analyzing those designs for potential security issues, and
- Suggesting and managing mitigations for security issues
- Implementation: During the Implementation phase, the development team mandates and enforces best practices to be followed for the duration of a project.
- Verification: The Verification phase is the point at which the software is functionally complete and is tested against security and privacy goals outlined in the requirements and design phases.
- Release: The Release phase is when a project team creates the incident response plan, performs the Final Security Review and archives all pertinent data for post release servicing of the software.
- Response: This is a post-SDL requirement where after a software program is released, the product development team must be available to respond to any possible security vulnerabilities or privacy issues that warrant a response, using the plans and resources output from the Release phase. Microsoft Security response Center (MSRC) provides the guidelines on how to manage the security response.
SDL includes several security analysis, development and testing tools to help the developers in various phases of the development process. Some of these tools include:
- SDL Process Template for Visual Studio Team System
- MSF-Agile+SDL Process Template
- Banned.h
- SiteLock ATL Template
- FxCop
- Code Analysis for C/C++
- Anti-XSS Library
- CAT.NET
- BinScope
- MiniFuzz
- SDL Regex Fuzzer
InfoQ spoke with Bryan Sullivan from SDL team about the framework, how it helps the architects and developers with developing secure code, and the future road-map of the framework. Bryan spoke about SDL framework and tools at RSA 2010 Conference and on Cryptographic Agility topic at BlackHat 2010 Conference this year.
InfoQ: Can you tell us more about the Security Development Lifecycle (SDL) project and your current role in the project?
Bryan Sullivan: The Microsoft Security Development Lifecycle is the development process Microsoft has developed and uses internally in order to create more secure software. Essentially, it's a collection of mandatory security and privacy activities that teams perform throughout the development process. To name just a couple of examples, every team must create a threat model of their application, and every team must perform an attack surface analysis (and reduction) of their application.
I want to stress how important it is that these activities happen throughout the application development lifecycle. Often we see outside organizations trying to implement security just by doing a lot of security testing right before the product is about to ship. This approach never works. Verification testing is important (and a required part of the Microsoft SDL), but it's equally important to ensure that the application design is secure, that it's been written according to secure development standards, even that the application requirements themselves have been written with security in mind. This holistic approach to secure development is really what makes the SDL so effective.
My particular role in the SDL team is twofold. First, I'm responsible for making sure that web application security issues are appropriately addressed with SDL required activities. This means not just adding tasks for development teams to perform, but also to make sure whenever possible that there are tools to automate these tasks, so that the effort required by the teams is as low as possible. Sometimes this means that we write the tools ourselves, sometimes other Microsoft teams write them, and sometimes there are existing third party tools we can use. It doesn't matter to us where a tool comes from; the important thing is that it does its job well.
This brings me to my second role on the SDL team, which is to manage the external public releases of SDL tools that we develop internally. We don't see SDL as a "secret sauce" that we have to hide from the rest of the world - just the opposite in fact, we want as many organizations as possible to adopt the SDL. This means that if we have tools we've written to help make the process easier, then we should be sharing them with the community as well. To date, we've publicly (and freely) released many of the internal tools we use, like the SDL Threat Modeling Tool, Binscope Binary Analyzer, Minifuzz File Fuzzer, and the SDL and SDL-Agile Process Templates.
InfoQ: What was the main motivation for developing SDL framework?
Bryan: Back in 2001, Microsoft products were hit with two very damaging, high-profile worms: Code Red and Nimda. Industry analysts began advising organizations to migrate off of our IIS web server and onto competing products. The Microsoft security team at the time - including Steve Lipner, now the Senior Director of Security Engineering Strategy (and the Microsoft SDL team) realized that the only way to stop these attacks in the future was to address the underlying problems in the code. They began developing what would become the SDL, a set of activities to ensure fewer vulnerabilities would find their way into our applications, and to ensure that the ones that do sneak through have less impact and do less damage.
InfoQ: How does SDL address the two sub-domains of security: Security Architecture and Operational Security?
Bryan: As its name implies, the SDL is really more focused on development and design practices and less on operational security. I agree that operational security is critically important, but this area is handled by entirely different groups within Microsoft. We do work closely with these groups, but generally we don't include operational security requirements in the SDL.
InfoQ: Can SDL framework be applied in organizations that are using Agile or Lean Software development frameworks for their SDLC?
Bryan: Absolutely. The original, "classic" SDL was developed for waterfall- or spiral-type development methodologies such as those used by the Windows, Office, and SQL Server teams. However, we quickly realized that most of the online services teams (who were also subject to SDL requirements) and even a growing number of box product teams were following Agile development practices. These teams were finding it challenging to complete all of the SDL required activities with release cycles as short as one week long. Even more problematic was the fact that Agile projects often have no planned "end" when a final security review audit can be performed.
To address these problems, a group of us on the SDL team got together and developed what we now call SDL-Agile or SDL-A for short. SDL-A includes all the same activities as the classic SDL - after all, attackers don't care what development methodology you use, so your Agile applications have to be just as secure as your waterfall ones - but the activities are reorganized into a structure that's better suited to Agile timelines. Internal Microsoft teams have been using SDL-A since October 2009, and we released the SDL-A process details externally in February this year so that any outside organization who wants to follow SDL in an Agile environment has a set of blueprints to do so.
InfoQ: Can SDL be used in security operations area (i.e. post-implementation in the SDLC process)?
Bryan: Like I talked about earlier, the SDL is really more of a development-centric process. There is one notable exception to this though, in that there are SDL policies concerning security incident response procedures.
InfoQ: What are the best practices and "gotchas" when it comes to application security validation and policy enforcement? Can SDL aid in the security architecture assessment?
Bryan: We really don't have too much trouble with policy enforcement: at Microsoft, SDL is a mandatory policy that comes directly from Bill Gates' Trustworthy Computing Memo, and when Bill makes a mandatory policy at Microsoft people listen! Seriously, if you're looking to implement an SDL program within your own organization it's important to get executive commitment to it. If you're having difficulty with this, then I recommend taking a look at the SDL Optimization Model that you can find on the SDL web site: www.microsoft.com/sdl. The Optimization Model defines four "maturity levels" of SDL, starting with the activities that provide the highest ROI. Start at the Standardized level of SDL, collect some evidence for your executive team that the SDL works and that it's actually saving you money, then go back and approach them for support.
As for security architecture assessment, we have the SDL Threat Modeling Tool (another freely available tool from www.microsoft.com/sdl) that is designed for exactly that purpose. We've heard a lot of lamenting that developers should just "think like hackers" and that if they did that, their code would automatically become more secure. Unfortunately, if you're not trained in security, it's no more possible for you to think like a hacker than it is for you to think like an airplane pilot if you've never flown in a plane. So, we developed the Threat Modeling Tool to be used by security experts and non-experts alike. All you need to do is model your application into Data Flow Diagrams, and the Threat Modeling Tool will prompt you to implement mitigations for potential design vulnerabilities.
InfoQ: Can SDL be used in development environments that are using non-Microsoft technologies like Java or Ruby?
Bryan: Definitely, the SDL is completely language- and OS-agnostic. There's a persistent misconception that SDL is only for Windows, or only for large organizations like Microsoft. The SDL is about creating more secure software, and while the particular implementation details or tools used may vary from platform to platform, the core principles remain the same. We've collected these core principles into a white paper titled "Simplified Implementation of the Microsoft SDL" and published it on www.microsoft.com/sdl. Whether you're a 1000-developer C++ shop or two guys in a garage banging out PHP code, you'll find useful and relevant guidance in the Simplified SDL document.
InfoQ: What is the future road-map of SDL project?
Bryan: One of our big pushes for the rest of 2010 and 2011 will be to focus more heavily on the earlier stages of the development lifecycle; specifically, the design and requirements gathering stages. We have some new tools we're working on that will help programmers and architects design more secure applications.
InfoQ: Thank you Bryan.