Hi everyone, Bryan here. Judging from the quantity of email I’ve been getting since Visual Studio 2010 shipped last month asking when we’ll have an SDL process template available for it, there are a lot of you out there who have already upgraded to VS 2010 and are looking to integrate SDL processes into your development environment. So, I am extremely happy to announce that the MSF-Agile+SDL Process Template for TFS 2010 is now available for download.
If you’re already using either the MSF-Agile+SDL template for TFS 2008 or the MSF for Agile Software Development template that ships in the box with TFS, you’ll find it extremely easy to pick up the new MSF-Agile+SDL template for TFS 2010. The new 2010 template retains all of the features of the 2008 template, including:
In addition, the 2010 template also includes some new features:
The MSF-Agile+SDL process template is freely downloadable, so if you’re running TFS 2010, give it a try and be sure to let us know what you think about it.
I have written about some of the security improvements in VC++ 2010 (here and here) and want to mention another important one: improved SAL support.
The Standard Annotation Language (SAL) is a way of annotating function prototypes to help static analysis tools find bugs, including many classes of security vulnerabilities, with a low false-positive rate.
If you are not familiar with SAL, declspec versus attribute syntax, and the use of macros to implement SAL, you should read this first.
The two biggest SAL changes in VC++ 2010 are:
What this means to you as a C or C++ developer using VC++ 2010, is that the compiler and static analysis toolset (/analyze) will find more bugs in your code. And all you did was upgrade to the newer compiler!
On a slightly different, but related topic, the advent of macros for attribute SAL (as used in VC++ 2010) is a major milestone for SAL, because it means we are in a position to make SAL a requirement for the next version of the SDL. Presently, SAL is a recommendation, although larger Microsoft teams use SAL anyway. It's important to realize that we can't make anything a requirement in the SDL unless:
The SAL requirement is going through the feedback period right now.
Clearly SAL can help with the second point, because SAL can help pinpoint buffer overruns in C and C++ code.
The addition of attribute SAL macros in sal.h means the third point is addressed too. Telling developers to annotate code using low-level SAL constructs in this manner:
void Func( [SA_Pre (Null=SA_No,ValidBytes="cb")] [SA_Pre(Deref=1,Valid=SA_Yes)] [SA_Pre(Deref=1,Access=SA_Read)] BYTE* pBuf, size_t cb );
Is simply not going to fly!
But asking developers to annotate their code using high-level SAL macros like this:
void Foo( _In_bytecount_(cb) BYTE* pBuf, size_t cb );
Is acceptable.
Steve Lipner here.
As many of you already know, Microsoft was one of the original nine companies that participated in the first iteration of the Building Security In Maturity Model (BSIMM). For those of you unfamiliar with BSIMM, it describes common software security practices across the participating companies - or as the authors describe it; "...a collection of good ideas and activities that are in use today." BSIMM allows you to determine which software security practices are most widely used across the sample set of development organizations.
The first BSIMM report was released in early 2009, and provided some great insights on security policies and practices currently in use. With today's announcement, BSIMM has been expanded to include more companies, in more industries, across a wider geographical area.
I’m happy to have been asked to participate on the newly established BSIMM Advisory Board - to help guide the theory and practice of BSIMM, and to ensure that the data gathered has practical application for the security community at large.
I'd encourage you to take a look at the BSIMM - and compare your practices to the ones outlined in the BSIMM report. You might be surprised at the results!
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.
- Dave
Almost from the time we created the SDL in 2004, we’ve been sharing information about our process, tools and training. We’ve taken this step because we recognize that our customers use lots of software that comes from organizations other than Microsoft, and that in order for them to have a more secure experience on the Internet, the organizations that develop that software also have to apply secure development practices.
Beyond making information and tools available through our web site, we also engage in direct collaboration with some development organizations. Those collaborations have been driven by the importance of the other organization to the Internet ecosystem and by the opportunity for us to have a technical exchange with a sophisticated development team that may have some ideas, approaches, or challenges that we haven’t thought of. At any one time in recent years, we’ve had several such collaborations going, usually driven by Jeremy Dallman from our SDL team. The collaborations are usually conducted under a nondisclosure agreement because we need to exchange proprietary information about companies’ processes and tools. We may never talk publicly about these agreements at all.
However, we are pleased to say that about three weeks ago, Cisco announced the creation of the Cisco Secure Development Lifecycle (CSDL) and elected to acknowledge that the CSDL had benefited from one of these collaborations. I’d like to thank our colleagues at Cisco for their acknowledgement, and to say that we’ve enjoyed and benefited from the opportunity to work with them.