The Verizon Business Security Blog has drawn the line in the sand of the kitty litter box they're apparently playing in, labeling those who irresponsibly disclose "information that makes things less secure" as narcissistic vulnerability pimps.
Wow.
Time to pull those iPhone wannabes from betwixt the Verizon lily whites and dial 1-866-GET-CLUE.
I love it when risk "experts" start sounding off about that of which they know nothing.
As members of the Verizon Risk Intelligence group, clearly an oxymoron, Wade Baker and Dave Kennedy must be the same guys who describe risk level in the cloud as .4.
What?
Here's a secret.
Vulnerability disclosure is, as Robert Graham says, rude at its core.
"Hey Mr. Vendor, your code sucks, fix it."
But what about when Mr. Vendor decides to blow off the security researcher who tried on numerous occasions, via numerous channels to disclose a vulnerability?
So when that security researcher goes public after vendor FAIL, he's now a narcissistic vulnerability pimp?
Is Charlie Miller a security researcher or a narcissistic vulnerability pimp?
Attrition.org (d2d) recently summed this conundrum up succinctly:
"So what is actually responsible or ethical? The lines are blurred quite a bit. The "responsible" method is also the "painful", "expensive", and often "ineffective" method that gets little resolved for exponentially more work, time and money. Is all that waste not irresponsible? What about all of the other organizations unknowingly affected by things I've found, organizations who never got a heads-up, no less a patch, because my attempts at "responsible" disclosure failed?"
No matter how you define it, disclosure drives vendors to repair code they would otherwise neglect and leave vulnerable for the real criminals to exploit.
Yes, risk may be elevated in the time period between disclosure and repair, as well as repair and patch deployment. But if researchers wait on the likes of Oracle to fix their kluges, nothing would ever get fixed.
Dan Goodin says in his writeup, "as the recent Pwn2Own contest made abundantly clear, software makers can't be counted on to secure their products, at least not on their own."
Dan clearly be styling some bling of his own.
I at Holisticinfosec.org do hereby resolve to faithfully ignore Verizon Risk Intelligence dreck forthwith.
Cheers.
del.icio.us | digg | Submit to Slashdot
Please support the Open Security Foundation (OSVDB)
1 comment:
Indeed, the economics and decision processes are different from traditional software, but so too are the exposure levels.
A SQLi vulnerability in the likes of Salesforce.com resulting in a data breach would of very different significance than a Windows Media player vuln that could result in privilege escalation on victimized systems (where victimization requires stupid user tricks, i.e. URL clicks).
All the victims in the imaginary Salesforce scenario are entirely innocent. They're simply the victims of an exploited web application code flaw (no interaction required on their part).
When I refer to incidents I mean specifically one of two things.
As an example, consider an major name-branded, 3rd party developed site in an EU market. The site was developed for the major brand by the 3rd party, and was subject to less security review as a result.
The site is extremely popular and as such is always under scrutiny by security researchers or criminals.
Either way, should said researcher or criminal discover and/or exploit a vulnerability, the net result is likely to be a declared incident.
One scenario, where the researcher responsibly or irresponsibly discloses the vulnerability, there is an immediate incident response and the vulnerability is mitigated and remediated.
The criminal scenario could result in a defacement, and/or compromise of the server and db contents, depending on the vulnerability exploited.
Again, there is an immediate incident response and the vulnerability is mitigated and remediated.
Linearly, this is best represented as: vulnerability-->exploit/discovery-->incident-->remediation/mitigation.
As a result of either of these scenarios, should the 3rd party development team then resolve to, or be required to employ an SDL or its equivalent, their incident count starts an immediate downward trend, as vulns are identified and eliminated proactively.
I have seen the 75% or better reduction as part of job duties with just such scenarios.
Linearly, the SDL modified representation is: vulnerability-->proactive discovery-->remediation/mitigation/prevention.
Does that clarify?
Post a Comment