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