mailing list archives
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
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.
Full-Disclosure - We believe in it.
- [Poor-Disclosure] batz (Dec 06)