Sunday, May 27, 2007

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

Chapter 2: Current Software Development Methods Fail to Produce Secure Software
Chapter 1 Here

Chapter 2 of the SDL book focuses on other development methodologies and how successful they are in addressing security concerns and in actually delivering secure software. The premise is that existing software development methodologies don't produce secure code. The authors don't quite make the controversial claim that they cannot produce secure code, but that they don't in practice.

You could of course extend this claim to showing that pretty much nothing produces secure code since we both can't define and are reasonably sure it doesn't exist. Let's stick to their unstated premise though - current software development methodologies aren't focused enough on security to produce secure code. This seems like a more straightforward and fair reading of their intent.

Four claims are examined:
  • "Given enough eyeballs, all bugs are shallow"
  • Proprietary software development methods
  • Agile software development methods
  • Common Criteria (CC)
One slightly problematic issue with these 4 items is that they aren't all of the same type. The Common Criteria, while it is a method of specifying and testing for requirements, was never positioned as a mechanism for the development of secure software. It was positioned as a way to specify the security requirements for a system and evaluate whether they have been met.

That said, I can't find any fault with their analysis of the flaws of the "enough eyeballs" approach. We've seen again and again in regular products, open source or not, that lifetime of product and number of people working on it doesn't necessarily reduce bugs except in the presence of a methodology and requirement/goal to specifically do so.

Other than their potentially flawed analysis on the Common Criteria (and I'm willing to admit I'm not the expert on CC intent/design) I can't say I took much away from this chapter. We know that current software development practices are flawed, and I'm even willing to believe the MS-SDL is better - I wouldn't be reading the book otherwise.

No comments: