Q&A: Microsoft's Bryan Sullivan Discusses SDL 4.1a

Microsoft Security Program Manager Bryan Sullivan talks about the new agile-focused SDL 4.1a.

• By Michael Desmond
• 11/10/2009

SDL Version 4.1a introduces updates specific to agile development scenarios. The new release addresses the fact that the iterative, time-constrained nature of agile development can make it difficult for dev shops to effectively deploy earlier SDL guidance. For more on the new release, read Security Design Lifecycle Gets an Agile Update.

On Monday, Microsoft Security Program Manager in the SDL team, Bryan Sullivan, gave a presentation at the Microsoft Tech-Ed Conference in Berlin, Germany, discussing the latest SDL iteration and how dev shops can go about adopting it. We caught up by email with Bryan during his stay in Germany. Here is what he had to say about the SDL program and how it can help dev shops.

Visual Studio Magazine: I understand SDL4 is updated for agile development scenarios. Can you talk about some of the specific guidance or changes of approach required by agile activities? What unique aspects of agile development make it a target for specific SDL guidance?
Bryan Sullivan: We developed SDL-Agile for the simple reasons that there are many teams using Agile, both inside and outside Microsoft, and that the existing "classic" SDL is not a good fit for these teams. Classic SDL is designed so that specific security activities take place at specific points in the development lifecycle. For example, teams threat model during the application's design phase, and they perform dynamic fuzz testing during the testing phase.

However, agile does not have well-defined phases like the spiral and waterfall projects that SDL was originally designed for. Agile has iterations, in which any or all types of development activities, such as design, coding or testing might be taking place at the same time. So teams cannot just apply the SDL as-is to agile, and they cannot realistically complete the entire scope of SDL requirements every single iteration.

Finally, we were -- and still are -- opposed to removing existing classic SDL requirements for agile. Every SDL requirement has been proven to prevent or reduce vulnerabilities. If we were to remove requirements for SDL-Agile, that would make SDL-Agile a less secure process than SDL-Classic, and we are definitely not willing to do that.

The solution we have developed is to take all of the same security activities found in SDL-Classic, and restructure them into a format more easily followed by agile teams. Essentially we have broken the SDL into three categories of requirements: Every-sprint requirements -- the requirements so critical to security that they must be completed every sprint). One-time requirements -- requirements that only need to be completed once, even if the project potentially runs forever, as in the case of many online services. And finally Bucket requirements. The Bucket requirements are those requirements, which still need to be performed periodically, and thus are not suitable as one-time requirements, but that are not so critical as to be required to be completed every single sprint. Fuzz testing is a great example of this. It is important to fuzz your parsing code periodically, but you are probably not going to find so many potential vulnerabilities doing so that you need to fuzz it every sprint.

VSM: Are there any common mistakes that agile groups tend to make when it comes to ensuring secure code? Any advice on what dev managers can do to avoid those common mistakes?
BS: Agile teams are usually just like spiral or waterfall teams in that they love to ship code. However, sometimes this leads agile teams to defer bugs to later iterations, bugs that in many cases should just be fixed immediately. This practice is both anti-agile, since the idea behind iterations is that they are self-contained, and anti-security in the case where the bugs found have security implications.

The SDL-Agile solution to this problem is to define a security "bug bar" used to classify the severity of vulnerabilities. The entries on the bug bar are based on STRIDE (Spoofing user identity, Tampering with data, Repudiation, Information disclosure, Denial of service, Elevation of privilege), and are completely objective and easy for anyone to classify vulnerabilities against. For example, an information disclosure vulnerability that could potentially leak a user's personally identifiable information is classed as a Critical vulnerability. A denial-of-service vulnerability that could disable a server until it is manually rebooted is classed as a High vulnerability. In SDL-Agile, any bug that is classified more critical than "Low" is a must-fix bug and cannot be deferred. If more dev managers were to adopt this objective methodology for classifying security vulnerabilities, fewer serious vulnerabilities would be deferred to later sprints and potentially shipped to customers.

VSM: What kind of response did you get from TechEd show attendees in Berlin to your presentation?
BS: It was a uniformly positive response, I was very pleased. The attendees had some great questions, mostly around how the SDL-Agile process is specifically implemented inside Microsoft teams. Several people were curious to know if there is a central security organization inside Microsoft that helps the product and service teams complete their SDL requirements. There definitely is such an organization -- the Microsoft Security Engineering Center (MSEC) -- but it is important to note that their role is not to complete all of the security work for the team, but rather to provide the team with guidance and support so that the team can complete their own security work more accurately and thoroughly.

VSM: Any advice for agile (or other) dev shops looking to adopt SDL? What are some things they can do to best take advantage of the guidelines?
BS: Do not feel that you need to dive in head-first and start completing the full SDL on day one! If you want to start this way, that is great, but most smaller development shops will not have the resources to perform all the same security activities that Microsoft internal teams perform. A better approach is to start by performing a smaller subset of the SDL requirements, ones that are easier to complete and that have a very high return on investment.

To help teams start working with the SDL more effectively, we have developed the SDL Optimization Model (located at the SDL portal), which details four stages of SDL maturity. This model works equally well for both classic SDL and for SDL-Agile, so regardless of your preferred methodology I would recommend downloading the model and getting started developing more secure code.