[ISN] Security patches: The solution or the problem?

From: InfoSec News (isnat_private)
Date: Tue Sep 04 2001 - 02:17:33 PDT

  • Next message: InfoSec News: "[ISN] Did FBI Ignore Code Red Warning?"

    UNIX SECURITY --- August 30, 2001
    Published by ITworld.com -- changing the way you view IT
    * Code Red once again showcased the dangers of failing to apply 
      security patches. Or did it? Carole digs a little deeper to uncover 
      the real problem that was being exploited.
    * Webcast: Create robust, efficient e-business applications on the fly 
    Need to protect your portal from access violation? Users tired of
    multiple password log-ons to your portal? Fed up with cookies and system
    agents? Learn how to deploy Web access control, while leveraging your
    current applications. FREE white paper and personalized online demo at:
    Worm Droppings
    By Carole Fennelly
    "While the angels, all pallid and wan,
    Uprising, unveiling, affirm
    That the play is the tragedy, 'Man,'
    And its hero the Conqueror Worm."
    -- Edgar Allan Poe, "The Conqueror Worm," Graham's Magazine,
       January 1843.
    Every time I go on vacation, I come back to a mailbox full of dire 
    warnings about an exploit that will "bring the Internet to its knees." 
    Like tired remakes of a classic movie, the Code Red Worm events were 
    boringly predictable. Without even opening my mail, I knew the script 
    that would be followed by the usual suspects: Vendors, the Media, and 
    various Security Pundits.
    The Media played the part of "Chicken Little Crying Wolf" perfectly, 
    hyping the threat in order to sell more advertisements. The frantic 
    search for updated information and patch downloads (necessary or not) 
    probably contributed to slowing down Net traffic more than the Worm.
    Next, of course, were the Security Vendors issuing press releases and 
    updating their sales presentations to assure prospective clients that 
    their product or service would have provided protection. "Don't wait 
    for the next Code Red!" many warned. I sat through one presentation 
    where the vendor intimated that they had "inside information" before 
    the CERT announcement. My pointing out that everyone had "inside 
    information" since the company that discovered the vulnerability, eEye 
    Digital Security, made this same information publicly available wasn't 
    too popular.
    Security Pundits seized the opportunity to jump on their ever-ready 
    soap boxes and point fingers at their favourite targets. Ironically, 
    eEye Digital Security was a popular target for making the vulnerability 
    public knowledge. The Full Disclosure can of worms flared into debate 
    on many security lists with proponents arguing that Full Disclosure is 
    the only way to compel vendor action and opponents countering that Full 
    Disclosure provides too much information to would-be attackers. The 
    upshot of all this bickering was that no one changed position. What a 
    surprise. Incidentally, many legitimate firms contacted eEye looking 
    for a copy of the exploit so they could test their systems. Somehow, 
    they lacked faith in the patch process. I suppose this makes them Full 
    Disclosure advocates.
    Well, we can finally get back to business as usual now that the Code 
    Red fiasco appears to be ebbing. Battle-scarred but wiser, we have seen 
    the importance of applying security patches as soon as they are 
    available. Damn lazy administrators should keep up with this stuff. 
    When are we going to wake up and realise that patching systems is a 
    *lousy* security mechanism? Sure, software bugs happen and must be 
    fixed, but we have turned a last-ditch mechanism into a standard 
    security practice.
    Patching a production system is risky and requires regression testing. 
    One company, St. Bernard software, (taking advantage of the Code Red 
    hype) offers an automatic patching mechanism. Sounds great, but 
    patching systems isn't always so straightforward. The interdependencies 
    of many modules can cause a patch for one application to break 
    something else and, quite often, the patch cannot be backed out. Anyone 
    remember trying to back out of a Windows 95 upgrade?
    Unless a particular bug had a serious impact on production, patching 
    systems used to be a scheduled event. We've come to rely on patching as 
    an emergency security response. That's like rushing into brain surgery 
    to cure a headache -- sure, it could be a tumor but let's do some tests 
    When are we going to stop reacting to symptoms and start looking at the 
    root cause of security problems? Put simply, software is not properly 
    tested before being released. The solution, of course, is not so 
    simple. How can software vendors be compelled to employ better quality 
    control methods? Manufacturers of consumer products, such as cars, are 
    held accountable for their products' performance and safety. Can you 
    imagine going to your car dealer for a patch kit that repairs a faulty 
    fuel regulator affecting several models? Of course, as the owner of the 
    vehicle, you should know how to repair it. Automobile consumers would 
    never tolerate such an attitude and neither should consumers of 
    software products who are forced to accept one-sided license agreements 
    because they have no choice.
    Yes, there will always be bugs that need to be patched, but they 
    shouldn't be the *same* bugs over and over and over again. We would not 
    tolerate a builder using materials that are known to be sub-standard 
    and there are requirements that new materials be proven to meet basic 
    safety requirements. No such requirements exist for software.
    But, we will wait for the next "Code Red" or "Melissa" or "Pope Fathers 
    Child!" event and re-use the same old tired plot with just a few 
    changes in the script. When will we stop settling for tired re-makes?
    Unfortunately, I have to announce that I am taking a sabbatical from 
    the ITworld.com newsletter for the next couple of months. I will be 
    working on a book project and I also need to devote some time to 
    migrating my archives onto my site (http://www.wkeys.com). If anyone 
    would updates on my future work or just want to say "hi", I'd love to 
    hear from you. Email me at cfat_private
    Visit METAgroup.com for free access to daily IT and E-business news 
    analysis, analyst insights, research reports and much more.
    About the author(s)
    Carole Fennelly is a partner in Wizard's Keys Corp., a company 
    specializing in computer security consulting. She has been a Unix 
    system administrator for almost 20 years on various platforms, and 
    provides security consultation to several financial institutions in the 
    New York City area. Visit her site at http://www.wkeys.com.
    St. Bernard Software's UpdateEXPERT
    I could have saved myself the effort and recycled an article I wrote 
    last year about another security scare. Things haven't changed much:
    A certain poetic justice here. "iDefense Files for Bankruptcy":
    Attorney General asks Qwest to credit users for virus outages:
    FTC proposes new laws "Thou Shalt Patch"
    LCLint Home Page
    New Visual C++.NET Option Tightens Buffer Security (lots of good 
    resources here for secure programming practices):
    Good article by Richard Forno "Code Red is Not the Problem"
    Software developers looking to create robust, efficient and flexible 
    E-business applications look no further. Tune into this free educational
    webcast series on the WebSphere Software Platform sponsored by IBM 
    - Go to: http://www.itworld.com/newsletters
    - Click on "View my newsletters" to log in and manage your account
    - To subscribe, check the box next to the newsletter
    - To unsubscribe, uncheck the box next to the newsletter 
    - When finished, click submit
    Questions? Please e-mail customer service at: mailto:supportat_private
    * Editorial: Andrew Santosusso, Associate Editor, Newsletters, 
    * Advertising: Clare O'Brien, Vice President of Sales, 
    * Recruitment advertising: Jamie Swartz, Eastern, Regional Sales 
      Manager, jamie_swartzat_private or Paul Duthie, Western Regional 
      Sales Manager, paul_duthieat_private
    * Other inquiries: Jodie Naze, Senior Product Marketing Manager, 
    Copyright 2001 ITworld.com, Inc., All Rights Reserved.
    ISN is currently hosted by Attrition.org
    To unsubscribe email majordomoat_private with 'unsubscribe isn' in the BODY
    of the mail.

    This archive was generated by hypermail 2b30 : Tue Sep 04 2001 - 08:00:34 PDT