Get on-the-go access to the latest insights featured on our Trustworthy Computing blogs.
Hi everyone, Bryan here. There is a common misconception that because the SDL was originally created for Microsoft’s big showcase box products like Windows and SQL Server, that it only works for those kinds of products. This is of course patently false: virtually every Microsoft product and online service, large or small, follows the SDL. Many other organizations outside of Microsoft are also successfully implementing the SDL. However, while the content of the SDL – its requirements and recommendations – may be universal, the structure of the SDL as originally designed is more suited to long-running waterfall- or spiral-style development methodologies. Consider the classic “chevron” SDL graphic:
As you can see, the SDL prescribes certain activities to take place during certain phases of the development lifecycle – threat modeling for example happens during the Design phase, and static analysis is performed during the Implementation phase. But not every development methodology has well-defined lifecycle phases like this. Specifically, Agile development methodologies do not have distinct phases and instead follow an iterative, time-boxed approach. How can the SDL be applied successfully in these environments?
One solution might be to take all the SDL requirements and put them into the product backlog, then pull them into the active queue (aka the sprint backlog, if you’re using Scrum) just like any other user story. This might work adequately for box products with well-defined product lifecycles that use Agile; for example, the Visual Studio teams that follow Scrum would fall into this category. However, the majority of internal teams (and very likely the majority of all development teams outside Microsoft too) that follow Agile use it to build web applications. This is important because web applications often don’t have a defined “end”; they just keep building and growing indefinitely. If we put the SDL requirements into the product backlog, it might take a year or more for a team to complete them all, but all the features added to the product after that date would go unsecured.
An alternative solution might be to just apply the entire SDL to every iteration. This would solve the problem of unsecured functionality being added after the SDL requirements have been completed, but it would create a whole new problem just as big, namely: how to complete all that SDL work in such a short amount of time! Per the Agile Manifesto, Agile projects should have short iterations, lasting from one month to a few weeks or less. There are online services teams here at Microsoft with one week long sprints. There’s no way these teams could complete the entire SDL in a sprint that short. And even if they could, there would be no time left to actually develop new features.
Another alternative would be to pare back the SDL, to cut out the “unnecessary” SDL requirements and just complete a smaller, core subset of the SDL each iteration. Unfortunately, this approach is flawed too, because none of the SDL requirements are unnecessary. Every requirement has been proven to prevent vulnerabilities or to reduce the impact of a successful exploit. Leaving requirements out of Agile projects would jeopardize their security, and that’s simply not an acceptable solution.
However, although none of these approaches solves the problem of adapting the SDL to Agile, that doesn’t mean the task is impossible. Over the last year, a team of security professionals throughout the Trustworthy Computing Security and Online Services Security & Compliance teams (including myself and Michael Howard from SDL) have worked to find a solution to the problem. Our resulting process has been in internal beta since the spring, has just recently released internally, and now I’m happy to announce that we’re releasing the details of the SDL for Agile Development Methodologies process today.
In brief, SDL-Agile breaks the SDL into three categories of requirements: every-sprint requirements, the requirements so important that they must be completed every iteration; one-time requirements, the requirements that only have to be completed once per project no matter how long it runs; and bucket requirements, the requirements that still need to be completed regularly but are not so important that they need to be completed every sprint.
Over and above the reorganization of requirements into a more Agile-friendly structure, SDL-Agile also provides guidance for adapting many of the core SDL activities to Agile. Threat modeling is a perfect example: a team could easily spend an entire week-long sprint performing threat modeling, but this may not be the best use of their time. SDL-Agile describes how a team can spend an appropriate amount of time modeling new features as well as how to build up a baseline of threat models for existing functionality.
Instead of getting into an in-depth discussion of SDL-Agile in the limited space I have here, I ask that you download and read the complete SDL-Agile guidance here, included as part of the SDL 4.1a Process Guidance document. We believe we’ve developed a process that is faithful to both Agile and to SDL, in which teams can innovate and react quickly to changing customer needs but in which the products they create are still more resilient to attack. As always, we welcome your feedback.
You do realize your images are unreadable?