A New TLA - Security Development Lifecycle - SDL

Today at Tech Ed, I met with Michael Howard, co-author of the new book, The Security Development Lifecycle.

The Security Development Lifecycle is the way that Microsoft intends to create more secure applications, as well as mitigating risks when there is a security risk. SDL is a 13 step lifecycle that proposes to be a process for developing demonstrably more secure software. I think the "demonstrably more secure" is the key to that statement. For far too long, any security project has been sold by describing all the terrible things that could happen if you do not do "x", whatever "x" might be. By creating code that is clearly more secure, and in general more reliable, you can get the budget required.

Microsoft is the place where the SDL took shape, and by all accounts, it was a company most in need of such changes. Microsoft was hit by lots of problems, from the slammer virus on down, within a short period of time. Part of the problem was timing. Many of the applications and OS' that had vulnerabilities were designed for the pre-Internet era. Now, when broadband connections are virtually universally available, much of the software created in the 90's looks pretty bad.

So, what does the SDL entail? The key to implementing an SDL is developer awareness. From the book, I knew that MS requires developers to have at least once a year classes covering security. Having been to a number of employer mandated classes that made my eyes bleed from boredom, I was happily surprised to hear from Michael that compliance at Microsoft is not that difficult to obtain. The fact that BillG wrote an email on security certainly helped.

Best Practices, Risk Assessment and creating documentation is next. One problem these days is that many of the security risks are not entirely an issue of development. Administrators can do things to create security vulnerabilities. For instance, when editing the Web.Config file on an ASP.NET application, it is not uncommon for folks to rename it Web.Config.Bak. Unfortunately, when doing so, the file becomes servable, meaning that if someone requests the file, it will be streamed and displayed on the browser. This is clearly not a development issue, but developers can help by documenting what sortd of actions administrators of the system can take to expose the system to security risks.

The SDL goes on to address some specific coding issues (mostly C++ issues, often dealing with functions that should be banned). A surprise to me was how strongly Michael felt about the banning of the "n" functions in C++, such as strncpy and sprintfn. At one point, those were the more secure functions used in place of strcpy and sprintf. The problem with these functions is in the complexity and some confusion over the implementation of the functions. The book covers a number of safe string handling functions, certainly something that C++ developers should look at.

The interesting thing about The Security Development Lifecycle is that, unlike Michael's other books, this is very specifically not a code heavy book. It is a book that developers can gain from reading, but it is also something that you could hopefully get your currently security clueless manager to read. I have not read the entire book (I have read chapter 1 and parts of the chapters related to C++ functions) but thus far, it is an interesting look at an area where we for too long have generally not focused.

One database related question came up in my interview with Michael, and he assured me that the security team works hand in hand with the SQL Server folks, and that in general, SQL Server has been a success story, with very few vulnerabilities exposed for recent releases. I have always been impressed with the fit and finish of the SQL Server products, and so it was good to hear that it is not just my impression. The code is good!

Posted by Douglas Reilly at 02:26 PM  Permalink