[risks] Risks Digest 21.95

From: RISKS List Owner (riskoat_private)
Date: Tue Mar 12 2002 - 14:40:34 PST

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

    RISKS-LIST: Risks-Forum Digest  Tuesday 12 March 2002  Volume 21 : Issue 95
    
       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/21.95.html>
    and by anonymous ftp at ftp.sri.com, cd risks .
    
      Contents:
    ATTBI / Eudora / SSL (Jock Gill via Dave Farber)
    'Phantom Menace' typing is just a Microsoft speech feature (Dale Hawkins)
    Re: Yet another case of a program changing your input (Gene Wirchenko)
    Re: Air Force seeks better security from Microsoft (Tom Poe, Jei)
    Disclaimers (Michael Bacon)
    Re: Loosing It's Grammer Skill's (Michael Bacon, Klaus Brunnstein, 
      Mike Albaugh, Merlyn Kline, Dave Williams)
    Re: The RISK of ignoring permission letters (Rob Slade, Greg Searle,
      George C. Kaplan, Michael Bacon)
    Re: Welland Canal Bridge runs into ship (Dave Gillett)
    Re: LED lights can reveal computer data (Nick Simicich, Peter B.)
    REVIEW: "Incident Response", Kevin Mandia/Chris Procise (Rob Slade)
    Abridged info on RISKS (comp.risks)
    
    ----------------------------------------------------------------------
    
    Date: Tue, 12 Mar 2002 10:03:52 -0500
    From: Jock Gill <jockat_private>
    Subject: ATTBI / Eudora / SSL
    
      [From Dave Farber's IP list.]
    
    Eudora users who are ATTBI customers might want to know this.
    
    As Eudora users will know, ATTBI Broadband [formerly Road Runner or
    MediaOne] does NOT support Eudora -- only MS products.  What they may not
    know is that ATTBI's instructions for re-configuring Eudora to work with
    ATTBI contain a very peculiar instruction in lines 10 and 17 = suggesting
    that you MUST select SECURE SOCKETS WHEN RECEIVING.
    
    This is in fact NOT TRUE, as David Reed helped me to discover last night.
    If you do follow their instructions and select the SSL feature, you will
    discover that your RETURN address MUST be the same as your LOGIN name.
    This, obviously prevents a return address other than the ATTBI domain.  So,
    if you have your own domain and wish to use it in the RETURN field in
    Eudora, do NOT select the SSL functions in steps 10 & 17 of ATTBI's online
    instructions -- see their web site.
    
    Trying to be a good dooby, I explicitly followed ATTBI's online
    instructions, only to discover the above problem.  When ever I tried tied to
    use <,jockat_private> as my return address, I got error 553 from the
    ATTBI servers.
    
    Calls with very long wait times to ATTBI, and chats with them online, were
    fruitless to the point of their suggesting the 553 error message was an
    Eudora problem.  The ATTBI techs had no idea what so ever about the
    relationship between the so called SSL requirement and is effect to force
    you to use your ATTBI login in name for your return address.
    
    Makes you wonder why we ever trust large organizations.  As David might say,
    the power of the edges to collectively organize around problems solved this
    problem in very short order -- once I gave up on the old notion of turning
    to the central authority.
    
    Jock Gill < jockat_private > <www.jockgill.com <http://www.jockgill.com/> >
    Interactive Digital Studies
    
      [For Dave's IP archives see:
        http://www.interesting-people.org/archives/interesting-people/
      ]
    
    ------------------------------
    
    Date: Tue, 12 Mar 2002 13:30:48 -0800 (PST)
    From: Hawkins Dale <rhdaleat_private>
    Subject: 'Phantom Menace' typing is just a Microsoft speech feature
    
    Slashdot (slashdot.org) and others are reporting that "some Windows XP users
    are finding random words inserted into their text as they write. The problem
    is caused by XP's speech recognition system, which is turned on by default
    by some manufacturers. It's listening to the random noise you get even when
    the mic is turned off."
    
    Microsoft is blaming the problem on some computer manufacturers who enable
    this feature by default in their installation of the operating system.
    
    Draw your own conclusions regarding the risks of adding powerful features
    that users are unaware of.
    
    Hawkins Dale
    
    ------------------------------
    
    Date: Tue, 12 Mar 2002 08:16:44 GMT
    From: genewat_private (Gene Wirchenko)
    Subject: Re: Yet another case of a program changing your input (RISKS-21.94)
    
    Funny.  On Sunday, I was doing an Excel tutorial as part of an accounting
    course.  The tutorial was setting up a grades spreadsheet system.  I ran
    into the same problem of short grades being overridden by longer ones!
    
    Then there was Word miscorrecting a word in an e-mail address for me
    recently.  Unfortunately, the lab computers at my college have the Word
    settings set so that spelling corrections are automatically accepted.  While
    this can be turned off, it must be done every login.  What a bother.
    
    My college is University College of the Cariboo.  The domain is
    cariboo.bc.ca.  Word miscorrected "cariboo" to "caribou".  I'm glad that I
    noted it as it happened as this was on my resume for co-op.
    
    Just to add to the fun, Word does some substitutions.  Try typing a line
    with a number of asterisks.  Word will replace it with blocks.  Sometimes,
    you can delete this line.  Sometimes, you can't.  I have also had horizontal
    lines inserted that I couldn't get rid of.  I had a draft for a report that
    I had to retype, because I couldn't get rid of the lines.
    
    Gene Wirchenko
    
    ------------------------------
    
    Date: Tue, 12 Mar 2002 10:14:54 -0800
    From: tom poe <tompoeat_private>
    Subject: Re: Air Force seeks better security from Microsoft (Jei, RISKS-21.94)
    
    > "The military and the government don't really have too much choice at
    > this point except to start to put pressure on Microsoft and others to
    > improve software security," Erbschloe says.
    
    Hi: Well, Erbschloe, you're wrong.  You have an easy, easy choice to make.
    If $13 Billion in taxpayer losses isn't enough to switch OS and tighten
    security for the Air Force, there's something terribly wrong in the Computer
    Economics workshop?!!  Thanks, Tom
    
    ------------------------------
    
    Date: Tue, 12 Mar 2002 19:25:58 +0200 (EET)
    From: Jei <jeiat_private>
    Subject: Re: Air Force seeks better security from Microsoft (Jei, RISKS-21.94)
    
    Sounds to me like we need a law that empowers the consumers to demand their
    money back if the products prove to be faulty.
    
    But didn't the US lawmakers just make a law that empowers the software
    makers to enforce whatever licences they like?
    
    Software quality will not only get worse, but it will be impossible to
    publicly state that it sucks.  Publishing security holes will also likely be
    equal to legal suicide.
    
    The only thing we'll get is a public mirage of better security and
    functionality, while in reality things will actually be a lot worse.
    
    Oh well.
    
    ------------------------------
    
    Date: Tue, 12 Mar 2002 07:47:47 -0000
    From: "Michael (Streaky) Bacon" <streakyat_private>
    Subject: Disclaimers
    
    A friend sent me the following disclaimer at the end of an e-mail he
    received from a contact in the BBC (British Broadcasting Corporation).  It
    reads (in part):
    
      "Please note that the BBC monitors e-mails sent or received. Further
      communication will signify your consent to this."
    
    Now this presents a dilemma because, merely by responding, you consent to
    the monitoring - making it challenging to refuse whilst keeping a convenient
    and effective communication channel open.
    
    Anyway, if the external correspondent uses (say) telefax and the internal
    correspondent uses e-mail -- is that "communication".
    
    If one does not consent (and can successfully communicate this without
    compromising one's position), can one's internal correspondent continue to
    send me e-mails - without them being monitored?
    
    Further, since the first part of the 'disclaimer' says that, "the BBC
    monitors e-mails sent", there is the unanswered question, "Was the original
    e-mail monitored - WITHOUT the recipient's consent?"
    
    Additionally, what constitutes a 'response'?  If the original message had
    requested a 'read' or even 'received' response - often automatically sent --
    would this be a 'consent' to the monitoring?
    
    Differences between 'opt-in' and 'opt-out' are exploited by marketeers (see
    several other threads, most recently Knox, RISKS 21.94), but RISKS arise
    when those who write disclaimers are ignorant of the technology involved.
    
    Also, why pick on only one form of communication?  How long before the
    'thought police' in the BBC extend their monitoring to the telephone,
    telefaxes and letters?
    
    Michael (Streaky) Bacon
    
    ------------------------------
    
    Date: Tue, 12 Mar 2002 07:18:22 -0000
    From: "Michael (Streaky) Bacon" <streakyat_private>
    Subject: Re: Loosing It's Grammer Skill's (Searle, RISKS 21.94)
    
    I recently reviewed some pages on the Web site of a major computer
    manufacturer and, among other issues, found several solecisms, grammatical
    errors, strange and tortuous phraseology, mixed persons, typographical
    errors and differences in how separate hypertext links to the same 'off
    site' page were treated.  A particular classic was: "...  challenges of
    reliability, scalability, and manageability that are needed ..." -- I hadn't
    realised that anyone *needed* challenges!
    
    On enquiry I was told that no-one reviewed for content, as the pages were
    written by subject matter experts.  Any reviews were to check conformance
    with corporate presentation style.  But even that alleged check missed the
    incorrect presentation of the company name in one instance.
    
    SMEs may know their subject, but clearly that isn't grammar, law or risk
    management.
    
    The risks are manifold, and include: inappropriate material being
    accidentally or deliberately posted; the company being committed to do
    something they never intended to do; corporate liability being attracted in
    a manner that is not properly (risk) managed; any corporate commitment to
    quality being thereby degraded.
    
    Michael (Streaky) Bacon
    
    ------------------------------
    
    Date: Tue, 12 Mar 2002 09:54:21 +0100
    From: Klaus Brunnstein <brunnsteinat_private-hamburg.de>
    Subject: Re: Loosing It's Grammer Skill's (Searle, RISKS 21.94)
    
    Concerning Greg's complaint about some impact of contemporary publication
    support software qw cause in reducing the quality of English (or AmGlish?)
    writing, another -- possibly more serious -- cause may be related to what I
    call the "imperialism of English": when multi-million non-native English
    speakers and writers are forced to use English as communication vehicle, how
    can someone assume that "quality English" may result? Moreover, differences
    between "island English" and "American English" may also contribute to bad
    grammar (as well as manuals even from English companies).
    
    On the other side, we observe that German students use publication software
    to produce better looking papers though at significantly lesser grammatical
    quality. This tendency which is also observable in schools may not only be
    attributed to usage if IT!
    
    My 2 cents (yes, we have also cents in Germany now), with my apologies for
    possibly bad grammar and expression :-)
    
    Klaus Brunnstein (March 12, 2002)
    
    ------------------------------
    
    Date: Tue, 12 Mar 2002 08:25:13 -0800 (PST)
    From: albaughat_private
    Subject: Re: Loosing It's Grammer Skill's (Searle, RISKS-21.94)
    
    > ... "Driver's Wanted" 
    
    I believe Greg has misunderstood. They are trying to warn you that they are
    a "family business", and that there are outstanding warrants for the driver
    of this cab.  Perhaps you will choose this cab for a sense of adventure.
    Perhaps you will decide that arriving at the airport with a half-dozen
    police cars in hot pursuit is not your cup of tea.  Either way, you have to
    applaud their honesty.
    
    ------------------------------
    
    Date: Tue, 12 Mar 2002 10:25:35 -0000
    From: "Merlyn Kline" <merlynat_private>
    Subject: Re: Loosing It's Grammer Skill's (Searle, RISKS-21.94)
    
      [I omitted a comment on "Driver's Wanted" similar to Mike Albaugh's 
      preceding message.  PGN]
    
    [...] as you point out:
    
    > Sure, I know what they really mean,
    and
    > English is defined by its common usage over an extended period of time.
    
    So what's the problem? Sure[1], it's annoying when the language drifts away
    from the dialect you had hammered in to you at school, but that's life. It's
    not wrong; just different. If you want annoying, you should try being a
    British English speaker reading Risks![2] In fact, as has been mentioned on
    Risks before, there are actual risks here: e.g. American English has lost
    the distinction between "ensure" and "insure". Here in Britain, I'm happy to
    deal with someone who ensures risks won't be realised, but not so happy to
    deal with someone who just insures. In America, I can't tell which is
    which. One of my favourite examples of this type of error is a notice in a
    local music store that says "CDs cannot be returned for a refund. This does
    not effect your statutory rights." (No, I bet it doesn't!). I'm not sure
    this is even an error in America, let alone funny[3].
    
    The evolution of language is driven by a fantastically complex and
    ultimately self-correcting system. If (e.g.) the taxi firm starts to suffer
    because everyone thinks their drivers are wanted criminals, eventually there
    will be another drift in the language to enhance the distinctions between
    possession, plurals and elision.
    
    Anyway, isn't your complaint really about the failings of an education
    system that is apparently incapable of helping its clients understand the
    simple rules related to the use of apostrophes in English?
    
    >  Are we doomed to accept bad grammar as the official standard?
    
    We are :(
    Chaucer, even Shakespeare, would be horrified by what we call English.
    
    Merlyn Kline
    
    [1] Arrgh! I'm drifting into American English idiom! The power of context!
    
    [2] Perhaps you are. See [1].
    
    [3] OTOH perhaps I am mislead by the ever increasing abuse of these two
    words, and the distinction remains in American English as well as
    British. I'm not sure.
    
    ------------------------------
    
    Date: Tue, 12 Mar 2002 14:31:28 +0000
    From: Dave Williams <dave_williamsat_private>
    Subject: Re: Loosing It's Grammer Skill's (RISKS-21.94)
    
    You are talking about the rise of the Apostrophe Virus (also known in the
    UK as the Greengrocers' Virus, because the misplaced apostrophe only used
    to appear on hand lettered signs in fruit and vegetable shops)
    
    The rise of DIY publishing, in print and on the Web, has propagated this
    virus to the point that it now appears in national newspapers,
    advertisements, and on major Web sites; all published by people who ought to
    know better. The problem is compounded by the long-term shift to a less
    literate culture, where words are less cared for, and spellcheckers are
    assumed to handle all grammar issues.
    
    As people see the misplaced apostrophe more and more in established
    media, the virus becomes legitimised, and so they are more likely to use
    an apostrophe, on the principle that it's best to put it in just in case
    
    The probable future is that in time, the use of the apostrophe-s will become
    the default for all occurrences of the letter s at the end of a word. So we
    are soon likely to assume it's normal to see apostrophe's at the end of
    word's, even though reader's of mature year's might think it suck's.
    
    Dave Williams (or should that be William's?)
    
      [DIY = Do-it-yourself, a.k.a. samizdat, which might inspire a
      self-publishing outfit called Sammy's.Dot.com?  PGN]
    
    ------------------------------
    
    Date: Tue, 12 Mar 2002 11:18:53 -0800
    From: Rob Slade <rsladeat_private>
    Subject: Re: The RISK of ignoring permission letters (Knox, RISKS-21.94)
    
    Our recommendation in regard to spam, for those who did not want to expend
    the time and effort required to track down the spammer and his upstream
    provider, has always been to ignore it.  This new style of spam is rather
    more problematic.  The United States now has a slew of legislation in regard
    to spam: various states have their own, and I believe that there is federal
    legislation as well.  The legal questions boggle the mind.  Is this just
    another address harvesting scheme, like the old "reply to this message if
    you want off the list" types?  Does a failure to respond to this type of
    message constitute a legitimate "acceptance" on my part?  (Particularly for
    those of us from outside the US?)
    
    > This is NOT requesting permission. This is warning you that by NOT
    > responding, you are implicitly consenting to them sending you spam. With
    > UCITA, this might even become legally acceptable (like click-wrap licenses).
    
    Yet another twist to the legal questions.  Would this kind of thing be legal
    in Virginia?
    
    > Finally, note how they try to play it cool in the last paragraph, talking
    > about how I 'requested' to be notified of special offers. 
    
    Apparently I've done all kinds of things on the net that I've never actually
    done.  I've even been signed up in some weird kind of pyramid/mlm scam that
    I've never heard of ...
    
    rsladeat_private  rsladeat_private  sladeat_private p1at_private
    http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade
    
    ------------------------------
    
    Date: Tue, 12 Mar 2002 08:34:58 -0500
    From: "Greg Searle" <greg_searleat_private>
    Subject: Re: The RISK of ignoring permission letters (Knox, RISKS-21.94)
    
    The best thing that you can do when you receive this type of message is to
    REPORT IT.  This message itself is unsolicited e-mail.  If you report it to
    the ISP that it was sent through, then the ISP may enforce its Acceptable
    Use Policy, and make the offending company think twice about this practice.
    Spammers are good liars.  Call the lie and report the abuse, pointing out
    that you DID NOT request the message.
    
    ------------------------------
    
    Date: Mon, 11 Mar 2002 16:38:34 -0800
    From: "George C. Kaplan" <gckaplanat_private>
    Subject: Re: The RISK of ignoring permission letters (Knox, RISKS-21.94)
    
    > With UCITA, this might even become legally acceptable ... 
    
    I don't know about whether UCITA makes this legal, but it's commonly
    accepted that such "opt-out" links don't actually remove you from the
    spammer's mailing list.  Instead, they confirm that there's a real person
    reading e-mail sent to your address, thus ensuring that you'll end up on
    *more* mailing lists.
    
    > Finally, note how they try to play it cool in the last paragraph, talking
    > about how I 'requested' to be notified of special offers. This is an
    > outright lie. 
    
    If they lie to you about this, don't you think they'll lie to you about 
    what their opt-out link does?
    
    George C. Kaplan, Communication & Network Services, University of California
    at Berkeley  1-510-643-0496  gckaplanat_private
    
    ------------------------------
    
    Date: Tue, 12 Mar 2002 07:27:05 -0000
    From: "Michael (Streaky) Bacon" <streakyat_private>
    Subject: Re: The RISK of ignoring permission letters (Knox, RISKS 21.94)
    
    This presents a compound RISK.  On the one hand, not replying appears to
    give consent to continuing to receive e-mail; on the other hand, replying
    confirms your e-mail address - which can then be resold as a legitimate,
    active, human-attended address.
    
    Michael (Streaky) Bacon
    
    ------------------------------
    
    Date: Tue, 12 Mar 2002 14:08:06 -0800
    From: Dave Gillett <dgillettat_private>
    Subject: Re: Welland Canal Bridge runs into ship (RISKS-21.61)
    
    The freighter Windoc, which was hit by a lift bridge last summer, losing its
    wheelhouse and funnel and catching fire, has made the news again.
    
    Windoc was apparently one of twelve freighters wintering over in Hamilton
    harbor, and one of three of those to break loose from their moorings in 130
    kph winds last week.  The ship drifted for about 5 km before grounding close
    to a major highway.
    
    No obvious computer connection, just follow-up on an old item....
    
    ------------------------------
    
    Date: Mon, 11 Mar 2002 22:07:41 -0500
    From: Nick Simicich <njsat_private>
    Subject: Re: LED lights can reveal computer data (NewsScan, RISKS-21.94)
    
    It is not quite true that no one has looked at reading computer data from
    LEDs before.  In the 1990 timeframe, there was a brand of scuba computer
    called the Orca Delphi that would dump recordings of your depth profiles to
    a LED which normally functioned as a decompression warning LED.  You put it
    in dump mode by disconnecting the power (9v lithium or alkaline battery) and
    reconnecting it within a few seconds.
    
    As you can imagine, most diving computers are designed on the "KISS"
    principle.  Errors in these computers could cause a life threatening
    condition - by incorrectly calculating your decompression obligation, they
    could put you at risk.  An inexperienced diver might not detect that the
    answers that the computer was calculating was wrong. But they are purposely
    simply devices. They may not even have an "on" button, for example---they
    may turn on in response to water pressure, conductivity, or, in the case of
    this computer, the fact that you turned on your air (this computer also
    tried to estimate how much air you had left in minutes based on how rapidly
    you were using it, so it had a high pressure air connection).  This frees
    you from the task loading of having to remember to turn the computer on.
    Many do not have an off switch - once they determine that you have
    "completely decompressed" according to their mathematical model, they turn
    off automatically.  The point here was that the engineers did not want to
    add the complexity of an extra electrical interface to this computer for
    dumping - they wanted two inputs, the water pressure and tank pressure
    transducers, one power input, and the lcd panel for output.  And the LED to
    call your attention to warning issues.  The point was to try and get a
    second use out of this LED as a data output device.
    
    In any case, the company had promised a dump device for the computer and
    never delivered.  The method of memory dumping was not initially announced,
    although they eventually mentioned, at a lecture, that it was going to be a
    "light pen". Someone noted that under some circumstances, disconnecting and
    reconnecting the power to the computer (it was a nine volt battery) caused
    the LED to light up for a few seconds at half brightness.  I made a call to
    the engineer and he admitted that yes, that was their planned dump method --
    they flashed the LED at 2400-8-N-1, and simply dumped the memory.  The dump
    was in this format:
    
     >000 C7 FF C0 48 C0 01 8D A5 8D A0 C7 FF C0 47 C0 07
     >010 89 97 8D 9A 84 40 84 33 80 2E 80 2B 80 2C 80 2D
    
    ...and so on.  That is, it dumped in ascii characters, complete with offsets
    at the beginning of each line, and a crlf at the end.
    
    There was a checksum for some of the memory, but not much of it.
    
    I'm not an electronics person, and, whereas there were circuits published
    (on rec.scuba), we were never able to get anything that worked reliably.  We
    tried the approach of reading the LED directly, and it was difficult to hold
    the detector in the exact alignment required for the duration of the dump.
    It was actually so difficult to get a good dump by reading the light from
    the LED that we built a circuit that measured battery voltage instead.  The
    company engineers had the same problem, I heard.  I also heard that they had
    problems getting consistent readings because of LED brightness differences
    and positioning under the faceplate.  The engineer suggested the battery
    method to me - and whereas I was able to breadboard a circuit and get a dump
    with it, I was not enough of an electronics person to be able to build one
    that would adapt to various battery voltages - mine would only work with a
    fresh lithium battery and an oscilloscope for tuning.
    
    Obviously, Loughry has a great deal more skill than we did in reading these
    LEDs.
    
    Search google in rec.scuba for the words "orca delphi dive dump device".
    There are some posts from 1990.
    
    Nick Simicich - njsat_private
    
    ------------------------------
    
    Date: Mon, 11 Mar 2002 15:53:49 -0800
    From: peter@whirled-routers.com
    Subject: Re: LED lights can reveal computer data (NewsScan, RISKS-21.94)
    
    I'll believe it when I see it.
    The articles actually state, that no one got it to work yet.
    Until then : FUD !
    
    Peter B.
    
    Whirled Routers, 200 Pier Ave. Suite 39, Hermosa Beach, CA 90254 USA
    310 376 8755 / fax 8785
    
    ------------------------------
    
    Date: Tue, 12 Mar 2002 07:49:30 -0800
    From: Rob Slade <rsladeat_private>
    Subject: REVIEW: "Incident Response", Kevin Mandia/Chris Procise
    
    BKINCDRS.RVW   20020108
    
    "Incident Response", Kevin Mandia/Chris Procise, 2001, 0-07-213182-9,
    U39.99
    %A   Kevin Mandia mandiakat_private
    %A   Chris Procise authorsat_private
    %C   300 Water Street, Whitby, Ontario   L1N 9B6
    %D   2001
    %G   0-07-213182-9
    %I   McGraw-Hill Ryerson/Osborne
    %O   U$39.99 905-430-5000 fax: 905-430-5020
    %P   509 p.
    %T   "Incident Response: Investigating Computer Crime"
    
    Part one is supposed to provide us with the basics of incident
    response.  Despite the assertion, in the introduction, that such
    response deals with much more than computer crime and that incidents
    can vary widely, chapter one details a deliberate and malicious
    intrusion into a computer system, by an incredibly inept attacker,
    using inside information.  Chapter two provides a definition of
    incident response, but it does lean heavily towards crimes, law
    enforcement involvement, and directed attacks.  The material also
    assumes that an incident response team can be called upon or formed at
    short notice.  The suggestions for advance preparation, in chapter
    three, do cover a broad range, but the writing is not always
    organized, and the material has gaps and covers many topics
    superficially.
    
    Part two purports to deal with technical issues.  Chapter four deals
    with guidelines for investigations, but, again, concentrates only on
    directed attacks from outside the organization.  The computer forensic
    process, in chapter five, is limited to retention and copying of
    evidence.  There is a rather terse review of Internet Protocol header
    information in chapter six.  Chapter seven lists some information
    related to network monitoring and logging.  "Advanced Network
    Surveillance" (chapter eight) examines a few of the more convoluted
    exploits.
    
    Part three describes operating system functions associated with system
    investigation.  Chapters nine to twelve list a number of utility
    programs that can be used to obtain system information.
    
    Part four is a grab bag of material dealing with special topics,
    chapter thirteen dealing with routers, fourteen the Web, and fifteen
    various servers.  A number of security and security breaking tools are
    enumerated in chapter sixteen.
    
    The emphasis in this book is adversarial: seeing incident response as
    primarily a matter of active defence against an active attacker.  Most
    companies will probably see incident response as a matter related to
    technical support: an endless stream of incidents, most of which are
    trivial, and a select few of which indicate serious problems.  As
    such, the book does, occasionally, point out some matters to consider,
    and possibly new practices to adopt in order to deal with those
    isolated events that are important enough to turn over to law
    enforcement agencies.  However, overall, the text does not provide
    much guidance in preparing for and responding to serious incidents.
    
    copyright Robert M. Slade, 2002   BKINCDRS.RVW   20020108
    rsladeat_private  rsladeat_private  sladeat_private p1at_private
    http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade
    
    ------------------------------
    
    Date: 12 Feb 2001 (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 20" for volume 20]
     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 21.95
    ************************
    



    This archive was generated by hypermail 2b30 : Tue Mar 12 2002 - 15:14:58 PST