Re: Sv: Call to arms - INFORMATION ANARCHY

From: Florian Weimer (Florian.Weimer@RUS.UNI-STUTTGART.DE)
Date: 11/03/01


Message-ID:  <tgitcr35u0.fsf@mercury.rus.uni-stuttgart.de>
Date:         Sat, 3 Nov 2001 22:25:11 +0100
From: Florian Weimer <Florian.Weimer@RUS.UNI-STUTTGART.DE>
Subject:      Re: Sv: Call to arms - INFORMATION ANARCHY
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM

microshit.product.security@HUSHMAIL.COM writes:

> Let's get an independent party, Governmental or Private, acting in
> an oversight and authoritative focal point to stamp their approval
> on software. Forget about fining Microsoft, have this independent
> stamp "FIT FOR HUMAN CONSUMPTION" on the software or "REJECTED!"

Current software development methods for COTS software cannot possibly
result in products which can be certified in any reasonable way.
Writing software is already expensive, but writing secure software is
too costly for most organizations and business models. If you want to
have certified COTS software, you have to lower certification
requirements so much that it's meaningless.

Look at all the web site privacy certificates! Do they have any
meaning in pratice? No, certified sites violated the privacy of their
users in the past. What about SSL CA certification
(i.e. certification for CA themselves, not certificates issued by the
CA)? All major players are certified, of course, but hardly anyone
sticks to the fundamental principles for running a CA (wide
publication of the CA root certificates on different media, a clear
and publicly documented policy, and so on). Until recently, these CAs
were certified despite the fact that certificate revocation just
didn't work at all!

You can easily install just another certification facility for COTS
software, but I doubt this would change anything (except for the
certifiers, who can make a fortune just by signing a few papers).

In addition, quite a few software companies need to release new,
slightly incompatible versions of their software on a regular basis in
order to generate a constant revenue stream through updates. Under
such conditions, software does not converge to a practically
defect-free state, as it should. Long before the current version can
be considered stable, the next version is already released, with new,
shiny features and new defects (and there wasn't even time to fix the
old ones).

Until some vendors which provide essential software start to take
defects seriously, favor fixing defects over introducing new features,
and trade complexity for reliability, we have to cope with
defect-laden software, including security defects.

(And no, defects are not due to the complexity of software. This is
just propaganda of software vendors which want to refuse to take
responsibility for their products. Any sane person who discovers that
a situation is no longer manageable due to its complexity tries to
reduce complexity as much as necessary to regain control. Why can't
software vendors do the same? )

--
Florian Weimer                    Florian.Weimer@RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898