Talking About the Security Development Lifecycle

Last week, the Microsoft Security Development Lifecycle (SDL) group in Microsoft released an update to three of its tools -- Threat Modeling, MiniFuzz and RegExFuzz -- incorporating feedback from the field and adding robust support for Visual Studio 2010 Team Foundation Server (TFS). You can find more detail on the release at the Microsoft Security Development Lifecycle blog.

I reached out to David Ladd, principal security program manager of the Security Development Lifecycle Team at Microsoft, to get his input on the update and learn what advice he has for developers seeking to implement SDL in their operations.

Michael Desmond: Team Foundation Server support was addressed in both the Threat Modeling and MiniFuzz tools. Can you describe the nature of this support? Was TFS support lacking previously, or is it simply being improved with this update?
David Ladd: The TFS support was available in the previous release of these tools, including RegEx Fuzzer. This support was updated in this release to provide coverage for the 2010 versions of TFS and VSTS.

MD: How does the SDL team go about enabling effective secure development in team-based environments? What issues can crop up in team dev scenarios that can undermine the innate security of application code?
DL: A lot of what we do focuses on team based approaches to security -- a good example is the threat modeling process. We feel that threat models that are created by a group that consists of architects, developers, testers and security subject matter experts produces a more complete picture of how an application will fare in its planned operational environment. What we see most often is that these roles exist in a silo; and as a result it leads to duplication of effort, or worse lack of communication about important security issues that should be addressed during the development phase of a product.

MD: All the updates seem based heavily on community feedback. I would guess this feedback would be uniquely important to your group, as new threats and avenues of vulnerability are identified in the field. How does SDL go about effectively capturing this feedback?
DL: Feedback is hugely important and we gather it from a variety of sources; from internal Microsoft teams, external venues such as our blog and forums and from customer interactions at conferences like TechEd. We also have a lot of one-on-one discussions with customers and other security experts in industry.

MD: For dev organizations that have committed to SDL, what are some of the most common or costly mistakes that you see them make? Are there, say, two or three things you would recommend developers do to get the full value out of the SDL program?
DL: First off, before I talk about observed mistakes, let me say that committing to a holistic security process is a big win -- regardless of whether it's SDL or any other methodology. Following "top n lists" may provide some security benefit in the short term, but on the whole, basing security practices on "security popularity contests" strikes me as nothing more than an expensive game of "whack a mole" that fails to provide long term ROI for a development organization.

Next, with regard to mistakes, the biggest one that I see is when people try to do everything, all at once. We think that the right approach is incremental in nature; deploying process or technologies where they have the best chance for success. Microsoft did not implement SDL overnight. We assessed where we could make the most impact, implemented the appropriate technology or policy, measured its effectiveness and then expanded or deprecated as necessary.

MD: Obviously HTML5 is emerging rapidly as a viable development target. For dev organizations shifting to HTML5 from other platforms, what are some of the biggest SDL-related issues or challenges they need to account for in the transition?
DL: While HTML5 offers a rich set of capabilities, and some of these new capabilities may themselves become attack vectors, I think that most security problems (for now) will simply be continuations or incremental changes to attacks currently in use. As long as organizations using SDL or other prescriptive practices have good security development policies in place for Web applications and they keep an eye on attack trends relating to HTML5, developers should be secure.