Message-ID: <05B4910E0216D411B14F00508B6A67A902941C40@renexch5.rennes.thmulti.com>
From: OgleR at thmulti.com (Ogle Ron (Rennes))
Subject: RE: it's all about [timing] responsibility

This is a call to go the other direction because I personally believe that
we've gotten it all wrong.  What we need is "Responsible Software
Development", but what we are asking is for "Responsible Disclosure".  Or
put in another way, truly responsible (and professional) disclosure should
be an immediate disclosure to all or "0 days".

Now before you go all ballistic, let's examine my beliefs.

Here are some facts/axioms that I think we can all agree:
1.  The bug was created (or at least used) by the developing vendor.
2.  Commercial vendors who may create or use software in their products are
there to make a profit.
3.  De-bugging software through either better development, testing, or
fixing after the fact costs money (i.e. less profit for a commercial
vendor).

Here are some statements that I believe to be facts but others may argue:
1.  Building better software development processes can increase software
quality (less bugs).  I point to the work at the Software Engineering
Institute Capability Maturity Model and work by Mitre.
2.  Commercial vendors will take the road to what ever costs them less to
put out a product.  If it is less expensive to fix bugs after the fact, then
to adopt better development processes, then the commercial vendor will fix
bugs after the fact.
3.  The general user community for a vendor's products doesn't really care
about bugs so long as the bugs don't cost them much in resources (time,
money, etc.).
4.  One of the many reasons for hackers/ vulnerability researchers to find
bugs is to influence software vendors in creating better software.
5.  A hacker/ researcher/ user who finds a bug and reports it will cost the
commercial vendor money even if it is to just answer the phone or email.

Here's the analysis:

Many people (users) use software to do their jobs whether that software is
run directly on a PC or indirectly in an embedded system.  Commercial
vendors provide this software to users in order to make a profit, and the
vendor will try to give users the features and services that the users need
or perceive to want.  This is free enterprise at its best.

Now the hacker or researcher finds a bug and publicizes it.  This costs the
commercial vendor in direct money and potential reputation and future loss
revenue due to users questioning the software's quality.  The commercial
vendor will fix bug.  After one or more bug fixes, vendor will normally try
to find way to reduce costs for bug fixes.

There seem to be three ways to fix bugs.  First, fix them as they come.
Second, don't create them.  Third, eliminate or reduce publicizing bugs.
The third fix is predicated on the old saying about if a tree falling in a
forest makes a sound but no one is around to hear it (i.e. did the bug
actually exist?).

So what's wrong with Steve's proposal?  I believe that Steve's "Responsible
Disclosure" is all about the third way to fix bugs and to a lesser extent
about the first way.  Why?  The more ways to block exposing a bug increases
the commercial vendor's profit, pure and simple.  Most of the responsibility
is bound to the discoverer of the bug and not the vendor.  The more
roadblocks/ hurdles that are put in the way will decrease the amount of bugs
discovered but NOT the amount of bugs.

Now I believe that this type of bug fixing is totally counter to being a
professional in this industry, and I do MEAN professional.  The real purpose
for us as professionals in this business should be to make software better.


I'm sure that everyone knows that systems with software are becoming more
complex, and complex systems tend to have more bugs.  Critical systems that
can do real harm to people are using commercial software and are being
placed on the Internet.  The US Government believes that real damage could
be done if terrorists attacked these systems.

Now what does that have to do with anything?  As a professional, I believe
that the best way to make software better is to fix bugs by not creating
them in the first place (second option above), and I believe that it is our
duty to improve the quality of software.

How do we do that?  Most options that are effective basically motivate the
commercial vendor by costing them profit by building software the wrong way.
This can be done many ways such as legislation, insurance, litigation, etc.
I think that OUR most effective way is by disclosing vulnerabilities
immediately.

Remember that the typical user doesn't really care about this which
translates into the vendor doesn't really care.  The commercial vendors
sells most of their products to these users not hackers and researchers.  So
we have to make the user care about vulnerabilities.  If exploits bring down
the user's systems and/or the bad press irritates them enough about
potential security issues, then the user will start to request better
software or switch to another vendor.  Either way, the commercial vendor
will get the requirement to build better software.

Aren't we doing that today, and it doesn't seem to be working?  We aren't
doing this today to the effectiveness that it could be done.  If hackers and
researchers made it easier for "script kiddies" to do their job, then the
business people would be all over software developers to make it stop.  And,
it looks like we may be having some affect (maybe), look at Bill's efforts
at M$.

So, my personal approach would be to advocate reducing time for announcement
to 0 days AND include exploit code!  I know this sounds like insanity.  But
I really do believe that this is what WE can do to HELP the software
industry and it makes the point to commercial vendors that poor software
quality cannot be tolerated any longer.

This is my personal opinion and not that of my employer either.
Ron Ogle

> -----Original Message-----
> From: Steven M. Christey [mailto:coley@...us.mitre.org]
> Sent: Thursday, August 01, 2002 07:46
> To: full-disclosure@...ts.netsys.com; bugtraq@...urityfocus.com
> Subject: Re: it's all about timing
> 
> 
> 
> The Responsible Disclosure Process draft specifically allows for
> researchers to release vulnerability information if the vendor is not
> sufficiently responsive.  Some people may disagree with the delay of
> 30 days between initial notification and release, but I don't think
> there are good stats on how long it really takes vendors to fully
> address vulnerability reports - open or closed source, freeware or
> commercial.  Let's take a recent example - how much coordination had
> to happen for the zlib vulnerability?  It seems reasonable to assume
> that it took more than a day.  And the controversial "grace period"
> has the interesting distinction of being used by both Microsoft and
> Theo de Raadt.
...
> This email is my personal opinion, not my employer's.
> 
> - Steve
> (co-author of the aforementioned Responsible Disclosure proposal,
> which is presently quiet but not dead, but will always be subject to
> public feedback)
> 

Powered by blists - more mailing lists