Full Disclosure mailing list archives
[Poor-Disclosure]
From: batz <batsy () vapour net>
Date: Thu, 5 Dec 2002 19:45:37 -0500 (EST)
Ergh, I really didn't want to get involved in this discussion, or any really, but I had this kicking around, and I couldn't sell it. It's a possible alternative to all this black and white posturing. Poor Disclosure the Real Problem. The debate, if one can call it that, over the vulnerability disclosure practises of various companies, researchers and hackers hasn't changed much in the last 5 years. Software and consulting companies have banded together into various information sharing alliances, claiming that their collective discretion will protect users against (what amounts to) other information sharing alliances among other groups of varying talent and modes of incorporation. In their respective quests to leave their mark in the annals of hacker lore, or to be credited with the coining one of the increasingly ridiculous buzzwords that are sanctimoniously brandished by both "consultants" and "researchers" alike, they have consistently overlooked the quality of the information they present to the public. Rumours get repackaged as advisories, which in turn are leveraged by all these groups as a platform to sound off on whatever crusade they imagine themselves on. Either on behalf of their customers, or a naive notion of "better security", or to mock both sides, all in an attempt to insinuate themselves as authorities in IT security. The people opposed to fully disclosing technical information about software vulnerabilities, charge that all this practise does is put weapons in the hands of criminals, while forcing those who actually have time to track this information to desperately implement untested (but suddenly critical) patches. All to the detriment of the business of keeping things running securely. The proponents of fully disclosing technical information about software vulnerabilities posit that it is the most efficient, cost effective and above all, comprehensive way of ensuring that all concerned parties patch their systems whether they were intending to or not. The machines are vulnerable whether there is an exploit published or not, and even if a few sites get hacked, more sites will get patched if the full full scope of the problem has been demonstrated. The rationale being that due to the interconnectedness of the Internet, individually vulnerable sites expose everyone to risk, and thus some lame sites will be sacrificed to protect the rest of the herd. If this conflict wasn't enough, the crux of the problem is that neither side ever provides comprehensive enough information to allow stakeholders to assess their level exposure on a persistant basis. The most common example of this is that someone from the full disclosure camp will post details of a vulnerability in a software package, then a consulting firm or response team will churn out an advisory to their clients and the public, hopefully verifying the information first. With a few exceptions, discovering the implications of the vulnerability to other operating systems, environments, or even other software packages that use it, is generally left as an exercise for the person who actually has to apply the patches. At the risk of coining another ridiculous buzzword, both sides of the debate suffer from poor disclosure practises. Neither side of the debate would matter if one of them would think about the quality of the information they were providing and not simply its accuracy. While both sides of the debate accuse software vendors of rushing to market with untested and poorly designed code, the same could be said for the quality of the advisories that consulting firms, hackers (Who am I kidding? They are the same people, anyone who tells you different is selling something.) and other researchers are producing. The trend of trying to keep information within these alliances and the forming of breakaway communities undermines the ability of users to get any information reliably. Users have to spend more time going to more sources to get the same information that used to be available by participating in a single mailing list. Asking users to go to a website to view one persons discovery and accompanying editorial, then having to go to another only to endure the same pedantic ramblings is enough for most people to simply wait for the patch cluster. All they have to do is initialize their incident response plans if they get hacked before it comes out. The time to respond to an incident can now be lowered below the aggregate time it takes to sift through the daily accumulations of cruft from the "community" 5 days a week. Poor disclosure practises make it more cost effective (from a risk standpoint) to deal with an incident if it occurs, than to spend valuable employee hours finding and sifting through incoherant screeds interspersed with code snippets. It really wouldn't matter if exploit scripts were advertised during saturday morning cartoons, as long as comprehensive information about the scope of the vulnerability, including its effect on other environments and regression tested patches were readily available. It is the poor quality of advisories that causes the imbalance between the difficulty to exploit a vulnerability and the difficulty to patch it, not the relative availability of the information itself. The solution isn't Selective Disclosure, Responsible Disclosure, Full Disclosure or No Disclosure. The solution is to up the standard of information and bring an end to what can only be described as a widespread practise of of piss poor disclosure. -- batz _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Current thread:
- [Poor-Disclosure] batz (Dec 05)
- <Possible follow-ups>
- Re: [Poor-Disclosure] Steven M. Christey (Dec 05)