The Security Snooze Button

Share it on Twitter  
Share it on Facebook  
Share it on Google+
Share it on Linked in  
The other day, I read a comment in an article that said something like, “this latest break-in should serve as a wake-up call to the banks.”

I laughed at this statement, of course, because of all the times I’ve read something just like it, but without any real indications that anyone actually had “woken up.” It's as though someone just keeps hitting the metaphorical snooze button — and not just at the banks.

So that was exactly what went through my mind when I recently read some statistics from ISS that predicted we’d see some 7,500 published software vulnerabilities this year, a 41% increase over last year. That old snooze button is seeming way too convenient.

More Ken van Wyk Columns
The Rise of Patch Vigilantism

Don't Ignore Device-Driver Dangers

Getting to the Root of Rootkits

IT Must Help Developers Build in Security

Let's Practice What We Preach

But then I thought about these numbers a bit more, and I think the answer isn’t all that simple. Yeah, anyone who reads this column from time to time has probably heard me complain about how bad the general state of software security is these days. We clearly need to make some significant and fundamental changes there, but there’s more to it than that.

For one thing, for a 41% increase in published software vulnerabilities to exist at all means there must be some big forces in play. Case in point: If the people who look for software vulnerabilities continue to do their work at more or less a status quo level, then there’d have to be a corresponding 41% increase in the amount of software out there, right? Or, there are 41% more people looking for vulnerabilities. Or something in between. That stands to reason.

Assuming we didn’t see an overall increase of 41% in the amount of deployed unique software out there in a single year, then it seems logical that somehow we’re looking for the weakness differently. More “researchers” out there looking for weaknesses, perhaps? But that explanation falls short in my view.

A far more realistic conclusion regards the shift in profit motive that we’ve seen in the past three (or so) years. Phishing, Trojan horses and other malware are like the great white sharks in the ocean, constantly looking for new as-yet undiscovered vulnerabilities to exploit. Their appetite for these nasties is endless. Indeed, it is their livelihood — however ill-conceived and illegal — at stake.

What else can possibly explain such a massive increase in published vulnerabilities? I sure don’t think it’s just the software developers somehow getting better at finding weaknesses in their code base. I also don’t think it’s rational to conclude that the security product and service vendors that spend time ferreting out weaknesses in software are getting that much better at their work.

That’s the real message that we should be reading in stats like this. As my colleague Gary McGraw says, “Build it and they will break it.” I suppose there’s somewhat of a corollary here in the form of, “If there’s money in it, they’ll break it vigorously.”

Gone are the days when software developers could safely write code in the absence of a keen understanding of what their adversaries might do to the code they write. We have to assume — at every step along the way — our software will face a determined and profit-motivated adversary who will go to great lengths to find even the most subtle of weaknesses in our software. And that goes for server as well as desktop software.

We information security folks need to get involved in our respective organizations’ software development efforts and help ensure that security is being represented at every stage. We need to help ensure that secure development practices like those described in Gary McGraw’s “Software Security” book or on DHS’s “Build Security In” portal are being followed in our organizations. We need to be as integral to the software development process as the software developers are now.

That’s not going to be easy, and there will be a major learning curve for us as well as for the software developers, but we’ve got to find ways of getting it done.

Regardless of how we approach it, I sure hope it’s evident to all of us that it’s time to stop hitting the snooze button with regard to secure software. Otherwise, all we’re doing is reacting to every alarm that comes along. And that’s a horrible way of doing business.


Loading Comments...