I must admit, I'm a big fan of Halley's blog. Her recent post invoked a question that I've been asking a lot about the security industry of late:
If you're searching for data -- are the results true, valid, credible? ... Will we pay a premium in the future for clean, pristine data?"
This is a key issue in the vulnerability management space. I dare say that it's the key issue - how good is your data? Can you trust it to make decisions on?
We often talk about the "may be" vulnerability reports that a lot of our competitors use - I think that's the ultimate example of bad, un-credible data. These are the vulnerabilities that report:
"You may be vulnerable to this condition".
Obviously, these come from the old days of vulnerability assessment, where the administrator was scanning a box or two, and knew exactly what they were scanning (or could know at a moment's notice through logging in to the box). However, now that vulnerability management tools scan thousands or hundreds of thousands of devices, it's really hard to deal with these "may be vulnerable" issues.
Some look at this as a "geek" level issue, but I think that's missing the point. With security issues being driven to the top of the organization by regulations such as Sarbanes-Oxley, HIPPA and GLBA, we're seeing an increased importance on the results of security tools. And these regulations don't accept the answer "Maybe."
To me, that lack of integrity is what will kill this market in the long term. Either that, or, as Halley suggests, we'll see customers begin to demand the type of integrity of data that they can make sound decisions on.
Comments (3)
I agree with the thrust of the point - no one wants to hear 'maybe' when they have alot of money, or more importantly, reputation on the line.
Not everything is black and white though, sometimes things *are* or will be a 'maybe' type of situation. Then what do we do?
When I think about this, I approach it as if I were a customer. And if I were a customer I'd rather hear a 'you may be vulnerable' then 'you are not vulnerable' if we or the company provisioning the service isn't sure. Of course, this just moves the issue into the realm of "We're paying you to be sure, so why aren't you sure?". In which case, a strong argument can be made for not incorporating those vuln checks into a product.
Perhaps we need to create a 'surety' metric? ;)
Posted by bsonne | April 18, 2005 7:32 AM
Posted on April 18, 2005 07:32
I don't know that I agree that there's ever a grey. Especially not in the generalized case.
Here's the difference:
"Your 500,000 machines may be vulnerable."
OR
"Some of your 500,000 machines may be vulnerable if they are running version 6.0.4 to 6.0.7, as we are unable to determine the vulnerability on THOSE SPECIFIC VERSIONS. Regardless, we suggest upgrading to the most current version".
One's a very tightly quantified maybe. The other's a complete lack of information.
The number of real, unquantified situations are incredibly small, in my experience.
Posted by mmurray | April 18, 2005 12:54 PM
Posted on April 18, 2005 12:54
I don't know that I agree that there's ever a grey. Especially not in the generalized case.
Here's the difference:
"Your 500,000 machines may be vulnerable."
OR
"Some of your 500,000 machines may be vulnerable if they are running version 6.0.4 to 6.0.7, as we are unable to determine the vulnerability on THOSE SPECIFIC VERSIONS. Regardless, we suggest upgrading to the most current version".
One's a very tightly quantified maybe. The other's a complete lack of information.
The number of real, unquantified situations are incredibly small, in my experience.
Posted by mmurray | April 18, 2005 2:25 PM
Posted on April 18, 2005 14:25