Agile SDL

Non-RSS readers might have noticed the title "Announcing SDL for Agile Development Methodologies" (by Bryan Sullivan of the MS-SDL team) float past in the "Blogs" sidebar yesterday.

The SDL structure presents a problem for Agile methodologies, simply by virtue of having been in development for so long; it's basically presented as a waterfall (or at best, a discrete and non-time-boxed iterative cycle) process, because that was the predominant mode of working in the early years of this millennium. In addition to this, the SDL was originally developed to support very large products, such as Windows itself, and Office; products with very long development cycles. Looked at from an Agile perspective, the SDL is enormous, monolithic, and chiseled out of Aberdeen granite.

Getting these two to play nice together was never going to be very easy.

As you might have expected, Microsoft has been working on this problem over the past year. Specifically, a cooperation of security professionals from the Online Services Security & Compliance team, Trustworthy Computing Security, and the SDL, have developed a process to solve the methodology mismatch. Their solution is incorporated into the latest release (4.1a) of the SDL Process Guidance document (1.1MB docx), starting on page 45, in a chapter creatively captioned "Security Development Lifecycle for Agile Development".

The key idea is to split the SDL requirements. With Agile cycles of a week or three being the norm, not all of the SDL requirements can be addressed in every sprint (to take Scrum as an example). The optimum compromise has been determined to comprise three categories of SDL requirement, and their related task sets:

1. Every-Sprint - e.g. new feature thread modelling, web i/o sanitizing;
   
2. Bucket - e.g. verification, design review, response planning tasks;
   
3. One-Time - baseline threat model being the largest of these.
   

The source document goes into plenty of detail about these task sets, both in the Agile section and in the related appendices. To quote Bryan Sullivan,

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.

Download it here.