Application Security: The Turning Point?

I wanted very much to write a column about how we’ve reached a turning point regarding application security.

It wasn’t that I thought one particular cataclysmic event has changed our course for the better. Rather, it was an accumulation of smaller observations and developments:

• Writers and bloggers like Jeremiah Grossman, Hugh Thompson, Gary McGraw (and many others) have done great work shedding light on the topic.
• OWASP, the open Web application security project, has established chapters around the world, and its Top Ten Vulnerability list is ever more widely disseminated.
• (ISC)2 recently set forth a new certification covering application lifecycle security issues.
• Both source-code analysis tools and application vulnerability scanners and services can help find flaws on either end of development and deployment. These technologies are maturing quickly.
• And if there is a big one, it would be the application security requirements in version 6.6 of the PCI Data Security Standard, which went into effect this past June and essentially calls for you to use the two approaches mentioned in the preceding paragraph (if not both).

That’s a good bit of app sec activity. Taken together, I thought, maybe it constitutes a quorum of some sort? Alas, as I tried to kindle the flames of a warm and fuzzy analysis of these signs of progress, James McGovern was standing by with a bucket of cold water. McGovern is leader of the Hartford chapter of OWASP. His simple response to my hypothesis: “I think the black hats are winning.”

McGovern gives three reasons. One, companies tend to work toward consensus, which takes time. Even if an application security vulnerability becomes visible to attackers and defenders at the same time, he argues, the attackers are much quicker on the draw while the defenders go through the process of discussion and prioritization. Two, he says outsourced application development creates some obstacles; offshore shops in particular are governed by the rule of margins, so they are discouraged from adding security steps (and therefore time, and therefore cost) to the development process.

Reason three is a bit of a kick in the seat of the pants: McGovern says that technical security is “a hard thing to participate in for nontechnical people,” and that the proliferation of CIOs with nontechnical backgrounds has made it harder to communicate technical risk.

Can’t wait to hear from CIOs on that one. Actually, I’d argue that reason three is really a problem with the communication skills of technical security people; the world isn’t going to grind to a halt so everyone can learn the ins and outs of SQL injection and cross-site request forgery, so the security community is going to have to keep working on nontechnical analogies and other ways of explaining problems.

But at any rate, perhaps McGovern is right, and we haven’t hit an inflection point. Yet. So what’s it going to take?