Message-ID: <Pine.BSF.4.21.0212051933080.18252-100000@vapour.net>
From: batsy at vapour.net (batz)
Subject: [Poor-Disclosure]

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

Powered by blists - more mailing lists