:: extra ::

Part 3: Patch and Pray
(see “Mom’s Warning” and “The Defender’s Dilemma” for parts 1 and 2)

By now we know that though in the broadest definition security issues can be defined as “quality issues”, many issues that would be recognized as a quality problem simply cannot be leveraged by an attacker for gain and many security vulnerabilities would never show up on a defect list were the attacker not present to manifest the undesireable result. We also know that security and quality are both emergent properties of a system, but that quality is usually much more self evident, particularly if you are not an expert adversary (in our case a hacker). We also recognize that there are dedicated “security features” that can complicate the assessment of security by minimizing the more subtle emergent property. Finally, we also realize that a system can be mostly “high quality” and still rank high for quality, but we can never say a system is “secure” if we can show any major vulnerability that is not adequately defended for the risk it exposes. I would call this pretty far from the exact same thing.

So imagine this: I am a developer sitting in my office/cube building great/new features for the next release of the product. Just as I am figuring out a complex algorithm and about to start coding, an information security person (I gotta be politically correct here and can’t say “guy”) walks in and says “Hey dude, are you checking your code for security vulnerabilities? You know we just bought a great set of tools that can “help” you find and fix them”. Now, the big dilemma… Would the developer totally and completely embrace this or would this be yet another step that (s)he has to perform, on top of the other 10 management mandated steps to be able to ship a product?

Word is that next year Toyota will sell more vehicles than General Motors (link). This really shouldn't come as too much of a surprise; Toyota has been turning a larger profit than GM for quite a while now. Still, it will be the first time in 80 years that GM hasn't been on top, and that might give you pause. The world is a little different than it once was.

It turns out that something very similar has happened with software vulnerabilities.

I just returned home from three weeks of hard travel covering nine cities in seven countries in a little over 14 days. Along with an acute case of jet lag, I find myself enjoying the unique perspective that one can only gain from such a trip. As a semi-reluctant blogger (I thoroughly enjoy writing these once I am finished but usually dread them up to that point), I figured this would be an ideal time to share some thoughts while the perspectives and the jetlag are at their peak.

Overwhelming would be a good description for the broad range of viewpoints and strategies that I came across meeting dozens of organizations at various stages of implementing software security initiatives – thankfully most all of the companies I met are evaluating our products in the process. (Due to the great work of our international sales teams and many global partners our customer count overseas will rival that of the US by year end, although the implementations here at home tend to be much larger and generally deeper into the development organizations). In spite of the many different approaches, I am starting to clearly see the great divide that separates the successful programs from the train wrecks and in a word it is “accountability” - lets explore this a bit.

The PCI Security Standards Council, which maintains a set of security requirements for nearly every type of organization involved in credit card transactions, recently updated their Data Protection Standards to include a mandate that all regulated applications either have software security experts perform a code review for security vulnerabilities or use an application firewall to protect web-facing applications. This guideline is only a best practice for now, but on June 30th, 2008 it will become a mandatory requirement.

It's fantastic that a standard as impactful as PCI, which already included language that addressed software security concerns, is progressing to include accountability in the form of code review. However, it's concerning that the standard calls for an either/or choice between an activity and a technology that are not at all parallel. Application firewalls are effective at preventing certain kinds of attacks, but they are not an adequate substitute for building secure software. Code review is an essential part of secure development and should be mandatory for sensitive applications, like the ones governed by the PCI standards.