[22204] in bugtraq

home help back first fref pref prev next nref lref last post

Re: Can we afford full disclosure of security holes?

daemon@ATHENA.MIT.EDU (Bill Arbaugh)
Fri Aug 10 21:22:55 2001

Message-Id: <5.1.0.14.0.20010810163223.047e03e8@localhost>
Date: Fri, 10 Aug 2001 17:01:31 -0700
To: aleph1@securityfocus.com, "Richard M . Smith" <rms@privacyfoundation.org>
From: Bill Arbaugh <waa@cs.umd.edu>
Cc: bugtraq@securityfocus.com
In-Reply-To: <20010810131538.G15017@securityfocus.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Elias,

You raise some very good points, and they are the reasons why nothing
has really happened in a positive way for some time. I agree with you that
full disclosure is good in many ways. However, I believe that the potential
damage that it can create is larger than the good that it can do.

At the end of your note, you say:


>   What it boils down to is this: disclosure of detailed vulnerability
>information benefits security conscious people, while, in the short them,
>hurts people that do not keep up with security, with the hope that it
>also helps them in the longer term.

I disagree here.  I found that the release of the scripts hurt people for a
very long time- in some cases years.  You are, however, onto a possible
solution to the problem. This problem is all about time and the windows
in which people must operate. It's a classic military command and control
problem- first discussed by John Boyd in his OODA loop theory. In essence,
Boyd says that who ever can react faster in a non-conventional 
confrontation will win.
Right now the attackers are reacting faster than the vast majority of the 
people trying to protect
their systems. Ideally, we'd have perfect management systems that downloaded
patches automagically as soon as a vulnerability is reported (and of course
everyone used such a system- NOTE: this is the ultimate virus vector which 
is a problem
onto itself). Unfortunately, we don't have something like that now.

I think the best idea is for people to follow something along the lines of 
RFP's
policy. But, don't release the source code. Release enough information such
that other experts can verify your results and develop counter-measures / 
scanners.

Will vulnerabilities still get scripted without release of the source? 
Sure- but it's all about
time, and the time to react and protect yourself. Over the last few years, I've
been coming to the conclusion that any vast improvement in security will come
from improvements in management- not some new security widget. Right now, I 
believe
the biggest opportunity for improving security rests in finding ways to 
shrink the window of time
that an attacker can successfully exploit a vulnerable system. Not 
releasing the source code to attacks in this
case doesn't help shrink that window, but it does limit the size of the 
population who
can take advantage of the window.

Bill


At 01:15 PM 8/10/2001 -0600, aleph1@securityfocus.com wrote:
>   Without detailed information:
>
>   How should third-parties develop countermeasures? In essence you are
>arguing that only the vendor should be capable of fixing the vulnerable
>software.
>
>   How should authors of vulnerability scanners and intrusion detection
>systems obtain information to produce new signatures? You may answer that
>only qualified security vendors should have access to the information.
>Who qualifies them? Who enforces these rules? What about non-commercial
>or open source tools?
>
>   How should academics obtain information for research purposes? You may
>answer that only qualified security vendors should have access to the
>information. Who qualifies them? Who enforces these rules?
>
>   How should users verify the vendor fix works as described? Some vendors
>have a history of requiring a few revisions of a patch to get it right.
>
>   What do you do if the vendors is not cooperating, does not maintain
>the product any longer, or no longer exist?
>
>   Unless you can answer all this question successfully you will continue
>to see detailed disclose of vulnerabilities.
>
>   What it boils down to is this: disclosure of detailed vulnerability
>information benefits security conscious people, while, in the short them,
>hurts people that do not keep up with security, with the hope that it
>also helps them in the longer term.
>
>   Will security conscious people give up the benefits of detailed disclosure
>of vulnerability information to help mitigate the short term risk of people
>that are not keeping up with security? Doubtful.
>
>--
>Elias Levy
>SecurityFocus.com
>http://www.securityfocus.com/
>Si vis pacem, para bellum


home help back first fref pref prev next nref lref last post