Microsoft's "The Security Development Lifecycle" - Chapter One

I started reading Microsoft's "The Security Development Lifecycle" a few weeks ago but got distracted and didn't finish. I figured I'd start the book over from the beginning and write commentary on a chapter-by-chapter basis. Hopefully this is useful if only for my own record keeping.

**********************************
Chapter 1 - Enough is Enough: The Threats Have Changed


Chapter One is an overview of why security is important, why everyone needs to be concerned about it, but specifically developers. I already buy the premise so the first chapter isn't exactly a hard sell. That said - I do have a few sections I find interesting and/or controversial.

Overall I agree with the definitions and distinctions made between Security and Privacy as concepts. Drawing this distinction isn't all that useful though for the general SDL practitioner. Its kind of a sad commentary on who the assumed audience is that the authors have to give this definition at all in the book. One disconcerting piece of this section though is their attempt to justify the SDL based on Privacy but not Security concerns. Justifying the SDL and software security in general is an extremely lengthly discussion and the subject of much debate about how much security to bake in, how many defects to fix, etc. Privacy is a big buzzword now though especially in places that are heavily regulated. Its a big stick just like SOX was 2-3 years ago to get management attention.

In their section on Reliability they mention an OpenBSD security/reliability item in BIND back from 2004. The OpenBSD team categorized the issue as one of reliability back then, and the authors appear to agree with this assessment. Little did they know this topic would explode again recently with another OpenBSD defect that the OpenBSD folks would try to categorize as a reliability issue but many folks disagreed. I have to say that I'm clearly in the reliability issues can be security issues camp and so I disagree with the author's position on this topic. I also disagree with their assessment that no major vendors distinguish between reliability and security concerns. Plenty of vendors post plenty of reliability patches that fix defects that aren't directly exploitable to cause an outage. If something can be exploited to cause both, it is both a reliability (availability) and a security defect.

In the next section on quality I'm a little confused. The book is supposed to be about securing software, but again takes a break and examines security failures in general.

In their section "Why Major Software Vendors Should Create More Secure Software" they take a bit of a jab at Apache based on the progress they finally made in shipping a more secure IIS. While they properly point out (I didn't check it, taking them at their word) that Apache had more security vulnerabilities/defects than did IIS in 2006, they make the leap that these were the cause of more compromises on Apache. Proper configuration management, ease of configuration management, and "secure by default" configurations go a long way towards achieving security and are part of the job of shipping "secure software." But to claim that the differential in Apache vs. IIS attacks is due solely to security defects is perhaps pushing the point a bit much.

Overall Chapter One is a decent start to the book though it moves between too many subject areas to focus on them enough in the space alloted. I know it gets better from here on in (I read ahead) but I think the intro could have been a little tighter.