Get on-the-go access to the latest insights featured on our Trustworthy Computing blogs.
Hello all, Dave here...
There have been a number of insightful comments of late about the news that Microsoft and Cisco Systems have been collaborating on secure development concepts.
The most interesting set of comments I saw were from Adrian Lane at Securosis who in his post entitled "FireStarter: Secure Development Lifecycle-You're Doing It Wrong" stated the following:
"...If you take the SDL Microsoft has described and try to implement it, you will fail. I am talking to the 99% of people out there who would think about implementing SDL and think "Hey, Microsoft published this new thingie for free; let's use it and save ourselves the time and money!" Wrong."
What may surprise many of you is that we are largely in agreement - for many of the same reasons that Adrian stated in his post. If you take Adrian's comment as ‘let's use it exactly and expect to save time and money!' you'll run into problems. On the other hand, using what we've done as a base for your own security development process will save you time and money. That said, it's clear to me that "what we've got here is...failure to communicate." My profound apologies to "Cool Hand Luke" fans. : - )
We have received many requests over time for information on how Microsoft applies the SDL to our products and online services. The SDL process as outlined in the book written by Michael Howard and Steve Lipner as well as the guidance posted on the MSDN Developer Center is provided for one primary reason - to provide process transparency for our customers. There are a surprising number of customers who are starting to demand that vendors provide evidence of effective security processes, and we're happy to oblige.
While development teams external to Microsoft may find that our documented processes provide useful context, they are just that, our documented processes. It has never been the intent of Microsoft or the SDL team to present our process guidance on MSDN as implementation guidance.
Adrian's point #5 pretty much sums up our philosophy: "Do what Microsoft did, not what they do." We couldn't agree more - and that's the reason why we released a whitepaper I wrote entitled "Simplified Implementation of the Microsoft SDL" in February 2010 at Blackhat D.C. In contrast to the 150+ pages of us "showing our work" to our customer base, the "Simplified" paper is seventeen pages of proven, non-proprietary, platform agnostic information for development teams to consider when implementing the core security elements that make up the Microsoft SDL.
A skeptic might conclude that since Microsoft is a software company, there must be a reliance on Microsoft tools in order to "do" SDL. There is no reliance on Microsoft tools - while we do provide tools for various activities in the SDL, there are perfectly acceptable substitutes (or methods) available to those who wish to use something other than a Microsoft solution.
For example, we've heard of instances where dev teams have written narrative threat models in Word - heavy on the verbiage and light on the Visio diagrams. There was another instance where a team engaged in threat modeling as a whiteboard exercise; which seems like a really cool and interactive way for a team to get a solid understanding of the threats and mitigations for a particular application - until it's time to archive the result. So, they took a picture of the whiteboard and called it good.
While we think the SDL Threat Modeling tool is pretty handy in these situations and we are convinced of its effectiveness in surfacing design threats, the method used for the threat model is unimportant in the grand scheme of things. The importance lies in the act of threat modeling and using the output from the threat modeling process to drive the changes necessary to secure an application.
Similarly, if a dev team wants to start fuzzing, it makes no difference from an SDL perspective whether you use excellent free tools like the MiniFuzz fuzzer Michael Howard wrote, or Michael Eddington's Peach, or if you use any of the quality fuzzers available from SDL Pro Network tool vendors. Just find a tool that is appropriate to your needs and go fuzz your apps.
Adrian is "spot on" when he muses about the resources necessary to implement the SDL at Microsoft - it's a non-trivial bit of effort. Then again, there's only one Microsoft - we ship hundreds of applications, used in over 150 countries worldwide and deployed on a variety of software and hardware platforms. We feel we have a unique responsibility to make our products as secure as possible - that drives our security philosophy and our ongoing investment.
The Simplified SDL (or any proven security methodology for that matter) requires adequate resources, smart people, and subject matter expertise. We realize that not all organizations have the resource base of a Microsoft or a Cisco - but frankly speaking, you don't need to be an organization with several thousand developers, testers and architects to implement the SDL. Experience tells us that organizations (regardless of size) usually take an incremental approach to process improvement - security processes are no exception. If secure software is the end goal, then we can state with confidence that implementation of any of the processes listed in the Simplified SDL paper (in whole or in part) will contribute to more secure software.
The bottom line from our perspective is that development teams need to take an outcomes-based approach - they should strive to understand the operational environment in which their application will run and should take the steps necessary to ensure that the application (when code complete) is as safe as it can be, given available knowledge and resources.
So, a big hat tip to Securosis and Adrian for his insights - which gave us a great opportunity to talk about how the SDL is more than just a Microsoft process.