[iwar] [fc:Is.Disclosing.Vulnerabilities.A.Security.Risk.In.Itself?]

From: Fred Cohen (fc@all.net)
Date: 2001-11-26 06:10:44


Return-Path: <sentto-279987-3938-1006783745-fc=all.net@returns.groups.yahoo.com>
Delivered-To: fc@all.net
Received: from 204.181.12.215 [204.181.12.215] by localhost with POP3 (fetchmail-5.7.4) for fc@localhost (single-drop); Mon, 26 Nov 2001 06:12:08 -0800 (PST)
Received: (qmail 8435 invoked by uid 510); 26 Nov 2001 14:09:32 -0000
Received: from n25.groups.yahoo.com (216.115.96.75) by all.net with SMTP; 26 Nov 2001 14:09:32 -0000
X-eGroups-Return: sentto-279987-3938-1006783745-fc=all.net@returns.groups.yahoo.com
Received: from [10.1.4.53] by n25.groups.yahoo.com with NNFMP; 26 Nov 2001 14:08:35 -0000
X-Sender: fc@red.all.net
X-Apparently-To: iwar@onelist.com
Received: (EGP: mail-8_0_0_1); 26 Nov 2001 14:09:04 -0000
Received: (qmail 28890 invoked from network); 26 Nov 2001 14:09:04 -0000
Received: from unknown (216.115.97.167) by m9.grp.snv.yahoo.com with QMQP; 26 Nov 2001 14:09:04 -0000
Received: from unknown (HELO red.all.net) (65.0.156.78) by mta1.grp.snv.yahoo.com with SMTP; 26 Nov 2001 14:09:05 -0000
Received: (from fc@localhost) by red.all.net (8.11.2/8.11.2) id fAQEAiw24227 for iwar@onelist.com; Mon, 26 Nov 2001 06:10:44 -0800
Message-Id: <200111261410.fAQEAiw24227@red.all.net>
To: iwar@onelist.com (Information Warfare Mailing List)
Organization: I'm not allowed to say
X-Mailer: don't even ask
X-Mailer: ELM [version 2.5 PL3]
From: Fred Cohen <fc@all.net>
X-Yahoo-Profile: fcallnet
Mailing-List: list iwar@yahoogroups.com; contact iwar-owner@yahoogroups.com
Delivered-To: mailing list iwar@yahoogroups.com
Precedence: bulk
List-Unsubscribe: <mailto:iwar-unsubscribe@yahoogroups.com>
Date: Mon, 26 Nov 2001 06:10:44 -0800 (PST)
Reply-To: iwar@yahoogroups.com
Subject: [iwar] [fc:Is.Disclosing.Vulnerabilities.A.Security.Risk.In.Itself?]
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Is Disclosing Vulnerabilities A Security Risk In Itself?

By BRUCE SCHNEIER, Internet Week, 11/20/01
<a href="http://www.internetweek.com/graymatter/secure111901.htm">http://www.internetweek.com/graymatter/secure111901.htm>

We'd all be a lot safer if security experts and researchers would stop
publishing details about security vulnerabilities, according to a recent
essay by Scott Culp, manager of the security response center at
Microsoft. Culp's argument that disclosing each security flaw that's
discovered arms hackers with offensive tools makes some valid points,
but I disagree with his overall claim that such disclosures are bad.

First, this wouldn't be an issue if software were engineered properly. A
security vulnerability is typically the result of a programming mistake:
either an out-and-out error like a buffer overflow, which should have
been caught and prevented, or an opening introduced by a failure to
understand the interactions in a complex piece of code.

Software vendors uniformly produce shoddy software--the sheer complexity
of modern software and networks means that lots of vulnerabilities are
inevitable. They're in every major software package. Each time Microsoft
releases an operating system, it crows about how extensive the testing
was and how secure the OS is; and every time, the OS contains more
security vulnerabilities than the previous one. I don't believe this
trend will reverse itself anytime soon.

Vendors don't take security seriously because there's no market
incentive for them to. I have long argued that the product liability
laws that govern the rest of commerce should be applied to software
vendors. When this happens, vendors will do more than pay lip service to
security vulnerabilities; they'll fix them as quickly as possible. But
until then, full disclosure is the only way we have to motivate vendors
to act responsibly.

Microsoft's motives in promoting bug secrecy are obvious: It's a whole
lot easier to squelch security information than it is to fix problems or
design products securely in the first place. Microsoft's steady stream
of public security vulnerabilities has led many people to question the
security of future products. And with analysts such as Gartner advising
people to abandon Microsoft IIS because of all its security holes,
Microsoft knows it's better off giving customers less security
information about its products.

In Culp's essay, he didn't say, "Hey guys, if you have a bug, send it to
me and I'll make sure it gets fixed pronto." What he did was rail
against the publication of vulnerabilities and ask researchers to keep
details under their hats. Otherwise, he threatened, "vendors will have
no choice but to find other ways to protect their customers." That's the
attitude that makes full disclosure the only viable way to reduce the
window of vulnerability.

Culp compares the practice of publishing vulnerabilities to shouting
"fire" in a crowded movie theater. He calls it "information anarchy."
What he forgets is that there actually is a fire and the vulnerabilities
exist regardless. Disclosure doesn't create security vulnerabilities;
programmers create them, and they remain until other programmers find
and remove them. Everyone makes mistakes; they're natural events in the
sense that they inevitably happen. But that's no excuse for pretending
that they're caused by forces out of our control and mitigated when we
get around to it.

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Universal Inkjet Refill Kit $29.95
Refill any ink cartridge for less!
Includes black and color ink.
http://us.click.yahoo.com/ltH6zA/MkNDAA/ySSFAA/kgFolB/TM
---------------------------------------------------------------------~->

------------------
http://all.net/ 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 



This archive was generated by hypermail 2.1.2 : 2001-12-31 20:59:59 PST