Why ‘Black Hats’ are winning app security war

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 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;

And 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 non-technical people,” and that the proliferation of CIOs with non-technical 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?

Would you recommend this article?

Share

Thanks for taking the time to let us know what you think of this article!
We'd love to hear your opinion about this or any other story you read in our publication.


Jim Love, Chief Content Officer, IT World Canada

Featured Download

Featured Articles

Cybersecurity in 2024: Priorities and challenges for Canadian organizations 

By Derek Manky As predictions for 2024 point to the continued expansion...

Survey shows generative AI is a top priority for Canadian corporate leaders.

Leaders are devoting significant budget to generative AI for 2024 Canadian corporate...

Related Tech News

Tech Jobs

Our experienced team of journalists and bloggers bring you engaging in-depth interviews, videos and content targeted to IT professionals and line-of-business executives.

Tech Companies Hiring Right Now