Tales of Ordinary Madness

I have always held Verizon’s Business Security division in rather high regard, primarily because over the last several years I’ve found their Data Breech Investigations report a useful and very telling document. I’m often in the situation in my career of explaining the “real” threat that X poses. This document has always provided something for me to point at and say here is why you, Mr. BusinessMan need to care about securing your enterprise. Having Verizon’s name tied to it gave it some additional weight.

However, this morning I read the article entitled “Redefining Security Researcher” by Wade Baker. In this blog posting the author suggests that the InfoSec community suffers from the “ridiculous yet long-standing inability to distinguish the good guys from the bad guys”. I have several issues with Wade’s terminology and his logic.

First, as Wade suggests the headlines do often read “Security Researcher Breaks This” and “Security Researcher Exposes That”. However, the author of the article or his/her editor picks that headline not the “Security Researcher”. Just like the television reporter gets to decide if the term “World’s Number One Hacker” appears underneath Gregory D. Evans when he mugs for CNN. We in the industry have only limited influence over the terminology used. A perfect example of this is death of the term “cracker” and the changing of the word “hacker” to be synonymous with criminal.

Also, let’s not forget that even the Narcissistic Vulnerability Pimp is doing research. It’s not like they have some secret vulnerability hole where they can pull vulnerabilities from. While you might object to their methods of disclosure, that doesn’t mean that their efforts are due anything less than being called a “Security Researcher”. They are in fact researching security issues.

Finally, as Wade points out in his later comments on the post, several analogies do fall flat when used to further explain disclosure. Admittedly no analogy is destined to be a perfect fit; however I do feel that I’ve found an analogy that works well enough – Bullet-Proof vests. Imagine someone discovered that a certain brand of 9mm ammunition could easily pierce a standard bullet proof vest. They contact the manufacturer and inform them that the vest fails to stop this particular brand of bullet. The manufacturer says “we don’t believe that to be a real issue”. How should this be handled? Hundreds perhaps thousands of vests with this vulnerability are deployed in military, police, and civilian circles. If the bad guys get wind of this, you can be sure this brand of bullet will become the round of choice. I think the only responsible thing to do is go public with this information. This allows each person to make an educated decision when they put on a vest – like wearing some additional layer of protection. Hopefully the public outrage will force the vendor to look into the problem and fix the issue.

Vulnerability disclosure is a touchy subject and will always be a balancing act between being responsible and doing what is best to protect the consumer, allowing the consumer to make an educated decision about what software provides the level of security and functionality necessary to get the job done.