[risks] Risks Digest 22.03

From: RISKS List Owner (riskoat_private)
Date: Mon Apr 15 2002 - 16:51:56 PDT

  • Next message: RISKS List Owner: "[risks] Risks Digest 22.04"

    RISKS-LIST: Risks-Forum Digest  Monday 15 April 2002  Volume 22 : Issue 03
    
       FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
       ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
    
    ***** See last item for further information, disclaimers, caveats, etc. *****
    This issue is archived at <URL:http://catless.ncl.ac.uk/Risks/22.03.html>
    and by anonymous ftp at ftp.sri.com, cd risks .
    
      Contents:
    Bank merger in Japan causes numerous problems (Jeremy Epstein)
    Online banking system failure in a big way (Ishikawa)
    Computer crime way up, says FBI (NewsScan)
    Can you trust a "trusted traveler"? (NewsScan)
    SMS, Net voting to be used in local UK elections in May (Anura Samara)
    Patient overflow avoided: P1M, not Y2K (David Shaw)
    More UK air traffic control failures (Mich Kabay)
    Interface simplification (Devon McCormick)
    Re: Just because it's funny doesn't mean it isn't real (Michael Walsh,
      Achim Nolcken Lohse)
    Re: When is fail-safe not fail-safe? (Anthony W. Youngman)
    Is your e-mail watching you? (Stefanie Olsen via Monty Solomon)
    The Risks of using the wrong address (Dan Birchall)
    Re: Yahoo Groups spam alert (Jim Horning)
    Ray Bradbury's Fahrenheit 451, revisited (Marc Rotenberg)
    REVIEW: "Hacker's Challenge", Mike Schiffman (Rob Slade)
    Abridged info on RISKS (comp.risks)
    
    ----------------------------------------------------------------------
    
    Date: Mon, 8 Apr 2002 14:52:15 -0400
    From: "Jeremy Epstein" <jepsteinat_private>
    Subject: Bank merger in Japan causes numerous problems
    
    Three of the twelve largest banks in Japan merged.  The results weren't
    pretty, including "more than 30,000 transaction errors and 2.5 million
    delayed debits" and "2.5 million of the 3 million automatic debits scheduled
    to be processed on 1 Apr 2002, including utility and credit card bills,
    couldn't be made on that day".
    
    The problem was that each of the banks ran a different system (Hitachi, IBM,
    and Fujitsu, although no software was mentioned).  They build some
    integration glue, but it didn't work.
    
    http://www.computerworld.com/storyba/0,4125,NAV47_STO69943,00.html
    
    ------------------------------
    
    Date: Sat, 06 Apr 2002 18:16:32 +0900
    From: Ishikawa <ishikawaat_private>
    Subject: Online banking system failure in a big way
    
    This news seems to be reported over foreign wire services, and so may have
    been reported already but here it goes in any way.
    
    Japan's Mizuho Financial group that operates the Mizuho Bank, which has been
    born out of the merger of three large banks, Dai-Ichi Kangyo bank, Nihon
    Kogyo bank, and Fuji bank, has started its merged new operation starting on
    1 Apr 2002.  (There is also another holding bank, but the Mizuho bank is the
    one where ordinary people have accounts carried over from the three banks.)
    
    Since that day, the online banking transaction system of the new bank has
    been plagued with problems.  On 1 Apr, the ATM malfunctioned and many users
    of the new bank could not withdrawal or deposit money. That continued until
    the next day.
    
    I thought this was a labor pain often found in a new operation, but no the
    problem persisted and the cause seems to run much deeper than I originally
    thought.
    
    Now for the last few days, the online banking transactions for payment of
    utility bills such as gas, electricity, water, and credit company payments
    are delayed heavily due to problems of unknown cause.
    
    This morning's Asahi Shimbun newspaper (Yokohama edition) carried a top
    article that stated the management of Mizuho FG admitted the back log of
    transactions amounts to more than 2.5 million.
    
    About three million such payments expected to take place on the 1 Apr
    could not be finished on time and 105,000 transactions remains unfinished
    even as of 5 Apr. The delay affected the subsequent processing of other
    transactions and the unfinished count exceeded 2.5 million on April 5th.
    (The fifth day of each month is the payment day of credit companies and thus
    there were many transactions to take place yesterday.)
    
    About 30,000 incorrect double withdrawals, and about 5,000 double deposits
    were found and corrected.  (Not all of them, it seems, to the evening NHK
    news I just heard.)
    
    According to the bank, the current accumulation of delayed transaction would
    need the whole next week to finish.
    
    The completion notification of utility bills payment to utility companies is
    also delayed very much.  Such delayed notices are believed to be more than 5
    million cases.  (It seems as if the bank don't know exactly the status of
    the payment...)
    
    The bank management admitted that although they have tested the integrated
    online transaction systems many times before the complete merger and the
    start of operation on 1 Apr, their expectation of the workload was not
    accurate enough.  (Above is my own translation.)
    
    Since many Japanese companies have its fiscal year ends at the end of March,
    and starts a new fiscal year in April, the Monday being the first week day
    of April had more workload than expected according to the statement found in
    the newspaper article.
    
    I noticed that the three banks closed the banking systems on Friday evening
    of the previous week and so I thought they took the time to move to the
    unified operation smoothly.
    
    But, after the fact, some articles in newspapers suggested the previous
    testing period of the whole merger and unified operation was not long enough
    for the large scale operation at all.  Also, there seems to have been a long
    period of discussion as to how the operations were to be unified and thus
    the implementation period became shorter than expected.  Dai-ich Kangin used
    Fujitsu, Fuji used IBM, and Nihon Kogyo used Hitachi computers.  The unified
    system seems to have been designed by Hitachi. The computes seem to be the
    mainframe UNIX types. As of now, it is not clear where/whether the problem
    lies in the integrated system hardware components and vendor supplied
    software or is in the application programmed by Mizuho.
    
    I have an account at Dai-ichi and so is now a Mizuho customer.  One solace
    is that the bank responded to the customer concern quickly and opend
    telephone hot line to track one's payment status, etc.. I have not tried the
    telephone number yet.  The bank stated publicly it will cover the cost
    incurred due to the delayed transactions. A big financial loss to the bank,
    I guess.
    
    A failure in a spectacular manner. This will remain in Japanese banking
    history.
    
    ------------------------------
    
    Date: Mon, 08 Apr 2002 09:19:51 -0700
    From: "NewsScan" <newsscanat_private>
    Subject: Computer crime way up, says FBI
    
    Eighty-five percent of respondents report having been victims of computer
    crime, costing them millions of dollars, according to a survey by the
    Computer Security Institute and the FBI. The study, which polled 583
    computer security experts in business, government agencies, medical
    institutions and universities, concluded that the most serious losses
    stemmed from theft of proprietary information. In addition, almost all of
    the organizations had suffered from computer virus attacks last year, and
    90% said they had been victims of Web site defacement in 2001, up from 64% a
    year earlier. "Organizations that want to survive in the coming years need
    to develop a comprehensive approach to information security, embracing both
    the human and technical dimensions," says Patrice Rapalus, director of the
    Computer Security Institute. In response to the growing threat of
    cybercrime, the FBI has set up the National Infrastructure Protection Center
    and has formed regional Computer Intrusion Squads in several offices
    throughout the U.S.  [BBC Online 8 Apr 2002; NewsScan Daily, 8 Apr 2002]
    http://news.bbc.co.uk/hi/english/sci/tech/newsid_1916000/1916655.stm
    
    ------------------------------
    
    Date: Tue, 09 Apr 2002 09:32:41 -0700
    From: "NewsScan" <newsscanat_private>
    Subject: Can you trust a "trusted traveler"?
    
    One proposal for improving airport security has been the creation of
    hard-to-counterfeit "trusted traveler" ID cards for frequent travelers, but
    software developer Richard P. Eastman asks the obvious question: "What makes
    a trusted traveler? The guy who travels all the time; who travels on
    business; who has a reason to travel. Does that mean the terrorist can't
    penetrate that group? Of course he can." Beyond objections of that sort,
    civil libertarians have been arguing that ID cards for travelers will set a
    dangerous precedent. Barry S. Steinhardt of the American Civil Liberties
    Union predicts, "Quickly enough, policy makers are going to say, 'If this
    works, let's require everyone to go through background checks before they get
    on a plane.'" [*The New York Times*, 9 Apr 2002; NewsScan Daily, 9 Apr 2002]
      http://www.nytimes.com/2002/04/09/technology/09PASS.html
    
    ------------------------------
    
    Date: Wed, 10 Apr 2002 09:30:54 +1000
    From: Anura.Samaraat_private
    Subject: SMS, Net voting to be used in local UK elections in May
    
    Local U.K. governments in Liverpool and Sheffield are gearing up to allow
    citizens to vote using SMS (Short Message Service) text messages and the
    Internet in elections 2 May 2002.
    
      [http://www.computerworld.com.au/idg2.nsf/All/E7E9EB212B30B99FCA256B960079B1B2!OpenDocument&NavArea=Home&SelectedCategoryName=News]
    
    ------------------------------
    
    Date: Wed, 10 Apr 2002 09:00:22 +1000
    From: "David Shaw" <David.Shawat_private>
    Subject: Patient overflow avoided: P1M, not Y2K
    
    The 2 Apr 2002 edition of *The Australian IT* (australiait.com.au) ran a
    story about the Royal Children's Hospital in Melbourne, Australia.
    
    They've just finished upgrading their patient administration software. The
    software hasn't yet replaced the need for paper records but provides the
    foundation to do so. It uses a browser front-end.
    
    Four years in the implementation, one of key drivers was the old software
    was unable to support patient numbers of more than six digits. The software
    went live on February 11. The 1,000,000th patient arrived in March.
    
    ------------------------------
    
    Date: Wed, 10 Apr 2002 08:50:06 -0400
    From: Mich Kabay <mkabayat_private>
    Subject: More UK air traffic control failures
    
    On 10 Apr 2002 at 0605 BST, air-traffic control computers failed at the West
    Drayton control center near Heathrow Airport, causing subsequent failures at
    the control center in Swanwick, Hampshire.  Disruptions lasted up to two
    hours, with controllers working by hand to track planes.  According to a BBC
    report http://news.bbc.co.uk/hi/english/uk/newsid_1920000/1920527.stm this
    is the second breakdown in ATC in Britain in two weeks.  Although the
    current failure is being attributed to "creaky" old systems that are
    unstable, the previous incident was attributed to a data-input error.
    
      [Comments from MK: The comment on data-input error conveys a belief that
      having a system crash because of incorrect inputs is understandable and
      acceptable.  It isn't.  Good design includes edit checks on inputs,
      especially inputs that can cause kernel panics.  When there are forbidden
      combinations of inputs, table-driven checks can exclude such combinations
      before they are sent for further processing.]
    
    M. E. Kabay, PhD, CISSP -- AssocProf Information Assurance
    Dept CompInfoSys, Norwich University, Northfield VT
    http://www2.norwich.edu/mkabay/index.htm
    
    ------------------------------
    
    Date: Fri, 5 Apr 2002 09:17:35 -0800 (PST)
    From: Devon McCormick <devonmccat_private>
    Subject: Interface simplification (was Re: Computers to Cars)
    
    An example of the risk of "simplifying" an interface: while on vacation
    recently, I rented a new-model car. One reason I rented it was to take my
    daughter to a drive-in movie since these are rapidly disappearing and I
    wanted her to have this experience.
    
    This drive-in, in Tucson, Arizona, does not have the speakers you attach to
    your car window.  Instead, you tune your radio to a specified FM channel to
    get the sound for the movie.
    
    As I started up the car to drive to the movie that night, I noticed that the
    headlights came on by themselves, presumably because it was dark out.  We
    got to the movie, parked, found the radio station with the movie's
    soundtrack, and discovered that there is no way to turn off the headlights
    while keeping the power on to the radio!
    
    One can imagine the (overly) clever engineer thinking "why would anyone want
    to sit in a car with the lights off and the power on?"  Whereas some of us
    could come up with at least a couple of reasons for doing this, evidently
    Detroit isn't that imaginative.
    
    Devon H. McCormick, CFA  devonat_private
    
    ------------------------------
    
    Date: Fri, 5 Apr 2002 11:50:44 +0300 
    From: Walsh Michael <michael.walshat_private>
    Subject: Re: Just because it's funny doesn't mean it isn't real
    
    Like Donald A. Norman, BMW's announcement of their intelligent 7 Series sent
    a shiver up my back.
    
    In my case this was based on my experiences with an early version of one of
    their intelligent cars (a 1986 520 injection I was still using in 2001).
    
    When BMW transfered (in connection with the Rover disaster) their dealership
    in Finland to a different company, they lost all expertise among their
    mechanics of the era before "computer-based" maintenance. This led to such
    funnies as my car refusing to start once in the middle of summer after a
    break of about 10 minutes in use; then me getting it to start after a couple
    of hours of leaving it alone and taking it to the dealership only to be told
    that by starting it it meant they were unable to download the details of why
    it went wrong.
    
    What should I have done ? Bring it immediately next time the same thing
    happens. I then pointed out that this meant waiting to be stranded and
    getting a tow truck. Yes, they replied.
    
    The very next day, that did in fact happen and I was towed all the way to
    the BMW dealership who then discovered that my model didn't have this
    download functionality as it was too old ...
    
    You can perhaps see why relying on a BMW's intelligence is not appealing !
    
    (A further funny was with the BMW extra I bought in Germany to enable me to
    pre-warm the car before using it. You set a clock in the car to the time
    this pre-warming should start (using petrol from the tank) and it warms the
    motor and inside of the car until you get into it. This worked perfectly
    when the temperature was around zero but at a few degrees less refused to
    click into action - not much use in Finland then. On the other hand at
    temperatures at around +25 degrees Centigrade it did jump into operation
    when you were driving along (and were in desperate need of more heat, NOT
    !)! )
    
    Mike Walsh, Helsinki, Finland  englantilainenat_private
    
    ------------------------------
    
    Date: Sat, 6 Apr 2002 02:00:59 -0700
    From: "Achim Nolcken Lohse" <lohseat_private>
    Subject: Re: Just because it's funny doesn't mean it isn't real (RISKS-22.02)
    
    Volkswagen has also thrown prudence to the winds in its rush to adopt high
    tech.
    
    We bought a 2002 VW Golf earlier this year, and within a week, the alarm
    system malfunctioned.  The first symptom was the unprovoked appearance of
    the "open door" icon on the dash. The next symptom was the sounding of the
    alarm some time after locking the car in the normal manner - ie. by clicking
    the remote or turning the key in the driver's lock.
    
    The only way to prevent the alarm from going off was to lock the 
    car manually, a procedure the misplaced confidence of the cars 
    designers had made fiendishly difficult:
    
    1. close the driver's door
    
    2. lock all doors with remote
    
    3. unlock the driver's door only with remote and reopen it
    
    4. reach back to the rear door and unlock it with the handle latch
    
    5. close the driver's door
    
    6. open the rear door
    
    7. reach forward from the rear and lock the front door  by 
    depressing the mechanical lock button
    
    8. depress the mechanical lock button on the rear door and close it.
    
    This is the only way to lock the car without arming the alarm.
    
    Of course, the problem was intermittent. And the designers had not provided
    any diagnostics for the system. So on the first trip in to get the problem
    fixed, the dealership was unable to identify or solve it.
    
    The solution had to wait until the problem had escalated to the point where
    the hatchback could not be opened (in ANY manner! - there is no purely
    mechanical way to operate the hatchback latch).  At this point the
    technicians' suspicion fell on the lock mechanism of the hatchback, which
    they then replaced, apparently fixing the problem.
    
    The potential problems are actually worse than appears from above, as the
    car has only two keylocks, that in the driver's door, and the one in the
    hatchback.  The hatchback lock (when it's working) can only be operated by
    the battery-operated master key (the valet key won't work on it).  So it
    would seem that if you have only the valet key and the driver's lock jams,
    there's no way to get into the car, other than breaking a window.
    
    Volkswagen supplies two of the master keys with the vehicle, and 
    of these, the battery of one died in the first month.  You're allowed 
    to buy up to two more, but they cost more than CDN$200 each!
    
    ------------------------------
    
    Date: Mon, 8 Apr 2002 11:46:50 +0100 
    From: "Anthony W. Youngman" <Anthony.Youngman@ECA-International.com>
    Subject: Re: When is fail-safe not fail-safe? (Rose, RISKS-22.02)
    
    > The risks -- fail-safe modes must be carefully designed for the system
    > application: don't rely on the component default fail-safe mode.
    
    Surely, for them to fail any other way would be life-threatening? Okay, the
    prison needs an outer containment mechanism (and should have a backup
    generator), but if the power failed due to a fire within the prison, and all
    the doors failed locked, the prisoners would be trapped in their cells.
    
    Given the design of those cells, death due to smoke inhalation could happen
    extremely quickly - from what I've seen typical design is cells opening onto
    walkways round a central "courtyard" - this would fill with lethal smoke in
    short order, should the fire be in the accommodation block. (And don't
    forget, many prisoners may well be "innocents" awaiting trial...)
    
    Always think of the consequences of "safety" modifications. Like one
    incident I remember. An HSO demanded that a unprotected pulley belt be
    enclosed "for safety", despite the company concerned protesting most
    strongly that they'd never had anybody hurt, and it was a safety feature
    that it *wasn't* enclosed. Within months of doing as ordered, they'd had a
    serious accident, and the security housing was blamed in no uncertain terms
    as the cause of a minor incident turning into a major catastrophe. When one
    employee had an accident, his colleague had been unable to stop the machine
    by yanking the belt off the pulley, and by the time he'd run the length of
    the hall to the emergency stop button the trapped employee had been
    seriously injured.
    
    ------------------------------
    
    Date: Sat, 6 Apr 2002 15:39:42 -0500
    From: Monty Solomon <montyat_private>
    Subject: Is your e-mail watching you?
    
      [Stefanie Olsen, CNET News.com, 4 Apr 2002]
    
    Watch out--the spam choking your e-mail in-box may be loaded with software
    that lets marketers track your moves online, and you may not even be aware
    that you've been bugged.  Web sites have long planted bits of code called
    "cookies" on consumers' hard drives to tailor Internet pages for returning
    visitors and better target ads. Now, enhanced messages that share the look
    and feel of Web pages are being used to deliver the same bits of code
    through e-mail, in many cases without regard for safeguards that have been
    developed to protect consumer privacy on the Web.
    
    "All of the security and privacy issues on the Web now relate to e-mail,"
    said Adam Shostack, director of technology at Zero-Knowledge Systems, a
    Montreal-based privacy and security company. "The shame about this behavior
    is that it's going on surreptitiously and people are not given an obvious
    way to opt out."  [...]
    
    http://news.com.com/2100-1023-875992.html
    
    ------------------------------
    
    Date: 10 Apr 2002 20:47:48 GMT
    From: Dan Birchall <i_charge_100_bucks_per_spamat_private>
    Subject: The Risks of using the wrong address
    
    As a longtime spamfighter, I've learned to be a little careful about who
    gets my various e-mail addresses.  If I wouldn't let someone call me
    collect... maybe they don't really deserve my personal e-mail address
    either.
    
    As a longtime human, I make mistakes.  A few months back, for example, I
    submitted a piece to RISKS from... my personal e-mail address.  Whoops.
    Now it's available on the web at no fewer than 8 URLs.
    
    Thus far, it's only gotten one piece of spam... I'll just hope other
    spammers and address-scraping 'bots are smart enough not to scrape addresses
    from a RISKS archive.
    
    Dan (using the correct address this time) 
    
    ------------------------------
    
    Date: Fri, 5 Apr 2002 14:24:09 -0800 
    From: Jim Horning <horningat_private>
    Subject: Re: Yahoo Groups spam alert (RISKS-22.02)
    
    Turns out you can't even log in to Yahoo to turn the options off unless you
    accept a cookie whose Compact Privacy Policy is unacceptable (to me, anyhow,
    your mileage may differ).  At least I couldn't.
    
    ------------------------------
    
    Date: Thu, 11 Apr 2002 13:54:31 -0400
    From: Marc Rotenberg <rotenbergat_private>
    Subject: Ray Bradbury's Fahrenheit 451, revisited
    
    It seemed both appropriate and ironical to review Ray Bradbury's
    Fahrenheit 451 at this point in time. Earlier this month the US
    Congress began consideration of a bill that would ban the
    unauthorized reproduction of digital works.  At almost the same
    time, federal prosecutors urged a court in Philadelphia to require
    technology in public libraries that would block access to
    information that some consider offensive.
    
    There is no kerosene dripping from the pages of books in Washington
    or Philadelphia, but digital words would not burn. The methods of
    eradication must be more subtle, the technique more sophisticated.
    
    It is tempting when reading Bradbury's classic work on censorship to
    draw parallels to book burnings from an earlier era, to make the
    obvious connection between the firemen in Bradbury's novel who set
    aflame houses that contained the printed word and those who gathered
    not so long ago to burn the words of Albert Einstein, Thomas Mann,
    Marcel Proust, Margaret Sanger, and H.G. Wells.
    
    But Fahrenheit 451 is not simply about book burning. This is a world
    where the culture of censorship has permeated the public and the
    private. There is no intellectual life. There is no political life.
    Interactive broadband technology provides endless entertainment
    through the full-screen images that appear on the walls of a parlor
    room. Words of meaning cannot be transmitted in any physical media.
    They must be memorized and passed on as they were before the
    printing press, before the written word.
    
    The protagonist Guy Montag, a fireman who will disavow his
    profession, confronts this reality in a series of encounters. First
    with a young woman who asks questions he cannot answer. Then with an
    old teacher who recalls a past that cannot be recorded. And finally
    with his boss, the Chief Firefighter who can quote Pope, Milton and
    Shaw, and then smile as a house and its contents are engulfed in
    flames.
    
    Montag's future is not without hope. He will fare better than
    Orwell's Winston, Kafka's K, or the Prisoner before Dostoevsky's
    Grand Inquisitor. Still, the reconstruction of culture, literature,
    and history once recorded words are banished cannot be assumed. When
    a single person can recall only one essay of Thoreau's or a chapter
    from Bertrand Russell, the unique quality of information -- its
    ability to flow without bounds -- is effectively exterminated.
    
    Perhaps it is unfair to compare the current legislative efforts to
    protect copyright interests or to prevent children from being
    exposed to images and words that are beyond their years with the
    unambiguous horror of burning a book because of the ideas contained
    inside. But technology does not make such distinctions, and
    capability creates opportunity. Already software filters have been
    turned on controversial ideas and unpopular organizations. And new
    copyright techniques will digitally incinerate recorded words that
    might otherwise be widely available.
    
    In this year when many city mayors are urging residents to share the
    experience of reading a common book, Los Angeles Mayor Jim Hahn has
    asked those in L.A. to read Fahrenheit 451. And Ray Bradbury's
    presence last week at a new mid-Wilshire bookstore, more than fifty
    years after the first publication of Fahrenheit 451, is a powerful
    reminder of the value of the written word.
    
    Marc Rotenberg
    
    http://www.epic.org/bookstore/powells/redirect/alert907.html
    
    ------------------------------
    
    Date: Tue, 2 Apr 2002 08:32:57 -0800
    From: Rob Slade <rsladeat_private>
    Subject: REVIEW: "Hacker's Challenge", Mike Schiffman
    
    BKHKRCHL.RVW   20020221
    
    "Hacker's Challenge", Mike Schiffman, 2001, 0-07-219384-0, U$29.99
    %A   Mike Schiffman
    %C   300 Water Street, Whitby, Ontario   L1N 9B6
    %D   2001
    %G   0-07-219384-0
    %I   McGraw-Hill Ryerson/Osborne
    %O   U$29.99 +1-800-565-5758 +1-905-430-5134 fax: 905-430-5020
    %P   355 p.
    %T   "Hacker's Challenge"
    
    Initially, I was skeptical of the title, considering the wording to be
    simply jumping on the current security bandwagon, with "hacker" this
    and "hacker" that on every bookshelf.  In an odd way, however, the
    title is quite appropriate.  This volume contains a series of twenty
    tests that are supposed to challenge your ability to analyze network
    data (most of the scenarios are network based) in order to identify
    and assess intrusions.  Unfortunately, there are some problems in the
    implementation.
    
    The book is divided into two parts.  First come the twenty scenarios,
    with varying types and degrees of detail about the problems.  Then
    come twenty "solutions," which are supposed to point out how you
    should have approached the situation, and what indicators should have
    tipped you off to the intrusion and intruder.  This physical division
    is rather meaningless: it isn't as if the solutions were short phrases
    that had to be printed upside down at the bottom of the page so that
    the reader doesn't inadvertently read the answer to the riddle while
    thinking about it.  There is no reason that the solutions could not
    immediately follow the stories.
    
    Actually, the pieces were written by thirteen different authors, and
    the amount of detail varies tremendously.  Therefore, all the possible
    mistakes that could be made in a work of this type are represented. 
    Sometimes the audit logs presented to us in the scenario contain the
    relevant details and very little else, but the explanation is very
    sparse.  In other pieces readers are presented with huge amounts of
    log data, and the relevant points are lost.  There are scenarios which
    are not complete, and the data necessary to solve the problem is not
    given until the solution write-up.  A few pieces contain almost no
    data for the reader in the problem section, while the solution
    presents almost no detection information or forensic exegesis.  In one
    case we are given pages of log data and almost no analysis at all in
    the solution.  There are articles that simply reproduce earlier
    situations with different characters.  One solution makes no sense in
    terms of the data given in the problem outline.  Some pieces are
    unclear, some simplistic, and some can only be described as
    misleading.
    
    The occasional scenario is written up almost poetically, and isolated
    solutions do have tutelary explanations of how to read network audit
    logs.
    
    If you are very good at forensic network analysis, you might enjoy
    pitting yourself against these challenges.  Of course, if you are good
    at forensic network analysis you have more work than you can handle,
    and no time for games.  If you are weak at network analysis, this book
    doesn't have very much to help you out.
    
    copyright Robert M. Slade, 2002   BKHKRCHL.RVW   20020221
    rsladeat_private  rsladeat_private  sladeat_private p1at_private
    http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade
    
    ------------------------------
    
    Date: 29 Mar 2002 (LAST-MODIFIED)
    From: RISKS-requestat_private
    Subject: Abridged info on RISKS (comp.risks)
    
     The RISKS Forum is a MODERATED digest.  Its Usenet equivalent is comp.risks.
    => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)
     if possible and convenient for you.  Alternatively, via majordomo,
     send e-mail requests to <risks-requestat_private> with one-line body
       subscribe [OR unsubscribe]
     which requires your ANSWERing confirmation to majordomoat_private .
     [If E-mail address differs from FROM:  subscribe "other-address <x@y>" ;
     this requires PGN's intervention -- but hinders spamming subscriptions, etc.]
     Lower-case only in address may get around a confirmation match glitch.
       INFO     [for unabridged version of RISKS information]
     There seems to be an occasional glitch in the confirmation process, in which
     case send mail to RISKS with a suitable SUBJECT and we'll do it manually.
       .MIL users should contact <risks-requestat_private> (Dennis Rears).
       .UK users should contact <Lindsay.Marshallat_private>.
    => The INFO file (submissions, default disclaimers, archive sites,
     copyright policy, PRIVACY digests, etc.) is also obtainable from
     http://www.CSL.sri.com/risksinfo.html  ftp://www.CSL.sri.com/pub/risks.info
     The full info file will appear now and then in future issues.  *** All
     contributors are assumed to have read the full info file for guidelines. ***
    => SUBMISSIONS: to risksat_private with meaningful SUBJECT: line.
    => ARCHIVES are available: ftp://ftp.sri.com/risks or
     ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks
       [volume-summary issues are in risks-*.00]
       [back volumes have their own subdirectories, e.g., "cd 21" for volume 21]
     http://catless.ncl.ac.uk/Risks/VL.IS.html      [i.e., VoLume, ISsue].
       Lindsay Marshall has also added to the Newcastle catless site a
       palmtop version of the most recent RISKS issue and a WAP version that
       works for many but not all telephones: http://catless.ncl.ac.uk/w/r
     http://the.wiretapped.net/security/info/textfiles/risks-digest/ .
     http://www.planetmirror.com/pub/risks/ ftp://ftp.planetmirror.com/pub/risks/
    ==> PGN's comprehensive historical Illustrative Risks summary of one liners:
        http://www.csl.sri.com/illustrative.html for browsing,
        http://www.csl.sri.com/illustrative.pdf or .ps for printing
    
    ------------------------------
    
    End of RISKS-FORUM Digest 22.03
    ************************
    



    This archive was generated by hypermail 2b30 : Mon Apr 15 2002 - 18:25:05 PDT