[risks] Risks Digest 22.52

From: RISKS List Owner (riskoat_private)
Date: Mon Jan 27 2003 - 15:09:33 PST

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

    RISKS-LIST: Risks-Forum Digest  Monday 27 January 2003  Volume 22 : Issue 52
    
       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.52.html>
    and by anonymous ftp at ftp.sri.com, cd risks .
    
      Contents:
    Special notice to certain .MIL/.GOV subscribers (PGN)
    Identity thefts doubled last year (NewsScan)
    Crooks harvest bank details from Net kiosk (Fuzzy Gorilla)
    Planned obsolescence of current games (Cody Boisclair)
    Computer virus writer gets two years in prison (NewsScan)
    SQL Slammer worm slows Net, grounds S.Korean surfers (Monty Solomon)
    Bank of America ATMs hit by Slammer worm (Fuzzy Gorilla)
    SQL Slammer: Are Admins really to blame? (Chris Leeson)
    The worm turned back: Slammer damage contained (NewsScan)
    'Slammer' Feared to Strike Again (Monty Solomon)
    SQL Slammer in Canada (M Taylor)
    MS SQL Server worm info (Monty Solomon)
    Re: Keep it secret, stupid! (anonymous, Fred Cohen)
    Matt Blaze is a Hero (Robert Ellis Smith)
    Re: Trouble with Prime Numbers: DeCSS, DVD, ... (Bill Bumgarner)
    REVIEW: "Auditing Information Systems", Mario Piattini (Rob Slade)
    REVIEW: "Internet and Intranet Security Management", Lech Janczewski 
      (Rob Slade)
    Abridged info on RISKS (comp.risks)
    
    ----------------------------------------------------------------------
    
    Date: Mon, 27 Jan 2003 14:07:03 PST
    From: "Peter G. Neumann" <neumannat_private>
    Subject: Special notice to certain .MIL/.GOV subscribers
    
    Dennis Rears will no longer be providing his very valuable .mil/.gov
    redistribution service.  For many years, he has minimized the traffic flow
    from CSL to those domains, allowing me to send just ONE message for all of
    his subscribers.  MANY THANKS to Dennis.
    
    Those of you who were thusly subscribed have now been moved to CSL's
    majordomo server, as of this issue.  This change may entail some new
    problems.  Two people were unable to receive mail sent to a list, and I have
    given them individual one-of-a-kind subscriptions.  Several dozen people had
    addresses that bounced when sent from SRI.  Some of those bounces were
    apparently already blacklisted even from Dennis's .mil site, and other
    bounces may be due to sites blocking RISKS from SRI as a result of overly
    aggressive spam filtering.  
    
    If you have friends and colleagues who complain that they are no longer
    getting RISKS, please show them this message, and suggest that they
    resubscribe at risks-requestat_private  The majordomo server still has a
    few problems with its challenge-response mechanism, mostly due to
    upper/lower case incompatibility problems and also to certain noncompliant
    mailers.  If you experience any difficulties, please let me know.
    
    ------------------------------
    
    Date: Thu, 23 Jan 2003 08:40:35 -0700
    From: "NewsScan" <newsscanat_private>
    Subject: Identity thefts doubled last year
    
    The number of identity thefts doubled in 2002, with 162,000 reports of
    identity theft compared to 86,000 the previous year. However, the Federal
    Trade Commission says that the rise in identity theft complaints does not
    necessarily mean an increase in actual crimes -- it may simply reflect an
    increasing public awareness of the problem and a greater likelihood that
    such incidents are now being reported. But an official of the Michigan State
    Police points out that many former violent criminals are now using the
    Internet for identity theft: "They are switching over to white-collar crime
    because it's more lucrative and they know they will get less time.  Identity
    theft is not necessarily a sophisticated crime." [*The New York Times*,
    23 Jan 2003; NewsScan Daily, 23 Jan 2003]
      http://partners.nytimes.com/2003/01/23/politics/23THEF.html
    
    ------------------------------
    
    Date: Mon, 27 Jan 2003 16:09:01 -0500
    From: "Fuzzy Gorilla" <fuzzygorillaat_private>
    Subject: Crooks harvest bank details from Net kiosk
    
    Crooks, operating in the Birmingham (England) area, are preying on people
    using public access terminals for Internet banking.  The scam came to light
    after a *Register* reader discovered to his horror an authorised transfer of
    6,300 pounds from the joint account he and his wife hold with Lloyds TSB. ...
    
    "Lloyds have advised me that there is a large-scale Internet banking fraud
    taking place, affecting customers in the Birmingham area, and has been
    ongoing for several weeks. Apparently branches have been alerted," the
    victim, a company director of a West Midlands Net services firm, told us.
    "It appears that account details are being harvested from public access 
    points (such as Internet Cafes, and more worryingly, Internet Kiosks)."
    [Source: John Leyden, *The Register*, 27 Jan 2003; PGN-ed]
      http://212.100.234.54/content/6/29054.html
    
    ------------------------------
    
    Date: Sun, 26 Jan 2003 16:37:55 -0500
    From: CodeMan38 <codyat_private>
    Subject: Planned obsolescence of current games (Re: Arrogance, RISKS-22.46)
    
    The "/Trivial/ Risks of Technical Arrogance" post in RISKS-22.46 reminds me
    of a personal frustration, related to a game which *should* work on a recent
    operating system, but which, due to some apparent oversight by the
    programmers, simply refuses to run.
    
    A certain popular video game, originally released on a rather failing
    console system but later re-released on the PC-- I won't mention it by name,
    but let's just say that its main character is a blue, spiny, fleet-footed
    anthropomorphic animal-- can even now be found in the discount racks of many
    software stores for $10 US.
    
    I bought this game before I upgraded to Windows XP; it was quite fun, and
    under Windows 98, it played exactly like the console version.
    
    However, after I upgraded to XP, I discovered a sad truth about the game: it
    DOES NOT work on that operating system at all.  Anywhere beyond the title
    screen, it causes a General Protection Fault in one of the old, obsolete
    DLLs used by the game, *even in the strictest compatibility mode that XP
    provides*.  Technically, this is covered on the system requirements-- which
    state "Windows 95/98"-- but there is nothing on the manufacturer's site
    mentioning an incompatibility with XP (something one generally wouldn't
    expect, given that every other Win98 game I've played works almost
    flawlessly in the new OS).
    
    If the game in question were so-called abandonware -- that is, having gone
    out of production years ago -- I'd excuse it.  But, as I mentioned, it can
    be found on store shelves at this very moment, and if I recall correctly,
    was also re-released in unaltered form either last year or the year before
    in a compilation.
    
    And yet "Earthworm Jim", whose PC version was released even *earlier*, 
    works absolutely fine in XP.  Go figure...
    
    ------------------------------
    
    Date: Fri, 24 Jan 2003 09:30:24 -0700
    From: "NewsScan" <newsscanat_private>
    Subject: Computer virus writer gets two years in prison
    
    Simon Vallor, from Llandudno, Wales, was sentenced two years in prison by a
    London magistrate who said that Vallor's actions "cried out for the
    imposition of a deterrent sentence." The judge brushed aside Vallor's
    request for leniency, saying: "These offenses were planned and very
    deliberate. Frankly, when you go to this trouble to make a sophisticated
    virus, programmed to leave damage this week, next week and the week after,
    it is absurd to claim you do not intend to do harm. These were by no means
    isolated offenses and they were committed over a period of time." Vallor
    wrote the viruses called Admirer, Redesi B, and Gokar, and was judged to be
    responsible wreaking damage in at least 46 countries.  [*The Western Mail*,
    Wales, 22 Jan 2003; NewsScan Daily, 24 Jan 2003]
      http://shorl.com/hydragryhogrebro
    
    ------------------------------
    
    Date: Sat, 25 Jan 2003 12:27:33 -0500
    From: Monty Solomon <montyat_private>
    Subject: SQL Slammer worm slows Net, grounds S.Korean surfers
    
    A rapidly spreading computer worm infested networks and bogged down Internet
    traffic across the globe on Saturday, crippling online services in one of
    the world's most wired countries, South Korea.  Called "Sapphire" or "SQL
    Slammer," the worm carries a self-regenerating mechanism that enables it to
    multiply quickly across the web, said Mikko Hypponen, manager of anti-virus
    research at F-Secure, a Helsinki-based computer security firm. 
    [Source: Jane Macartney and Bernhard Warner, Reuters, 25 Jan 2003]
      http://finance.lycos.com/home/news/story.asp?story=31132872
    
    ------------------------------
    
    Date: Mon, 27 Jan 2003 16:07:10 -0500
    From: "Fuzzy Gorilla" <fuzzygorillaat_private>
    Subject: Bank of America ATMs hit by Slammer worm
    
    The bandwidth-crunching Slammer worm caused all manner of damage since its
    appearance on the Net in the early hours of Saturday morning.  The spread of
    the worm was so severe that the majority of Bank of America's 13,000
    automatic teller machines "were unable to process customer transactions",
    according to *The Washington Post* -- which quotes the bank saying it was
    able to restore services on Saturday evening but a Seattle-based Reg reader
    tells us he was "unable to make a deposit to my Bank of America Account on
    Sunday at about noon Pacific time".
    
    [*The Washington Post* article is not explicit about why the worm disrupted
      the ATM network.  Whether the ATMs are attached to the Internet or whether
      the BoA server used by the ATM was infected, this does not sound very
      comforting.]
    
    REFERENCES: 
      ATMs, ISPs hit by Slammer worm spread, by John Leyden, 27 Jan 2003
        http://www.theregister.co.uk/content/6/29054.html
      http://www.washingtonpost.com/wp-dyn/articles/A43267-2003Jan25.html
    
    ------------------------------
    
    Date: Mon, 27 Jan 2003 12:37:33 +0000
    From: "LEESON, Chris" <CHRIS.LEESONat_private>
    Subject: SQL Slammer: Are Admins really to blame?
    
    Over the weekend the SQL Slammer worm wreaked havoc across the Internet.
    
    As usual the two most common responses are:
         1. Blame Microsoft for producing code with holes in.
         2. Blame the sysadmins for not patching systems.
    [and 3. Nobody blames the anti-social [deleted] who wrote it]
    
    Of course, (1) is a little unfair as Microsoft patched the hole
    six months ago. (2) seems to be a more reasonable response.
    
    At risk of being flamed, I would like to suggest that it isn't.
    
    We are frequently reminded in RISKS that we need to balance our
    viewpoint. There are risks in using technology, and risks in not using
    technology, and we need to accept that there is a tradeoff between the two.
    
    This is a case in point. When a Service Update is applied to a system, a
    number of things are introduced:
    
     - Bug Fixes
     - New Bugs (due to changes in the system)
     - New Code Behaviour (also due to changes in the system)
    
    In theory, when a Service Update is applied to a computer, the Applications
    that are affected by the Service Release need to be re-tested to make sure
    that the Application still works correctly with the new level of the
    Operating System/DBMS.
    
    Because Service Releases have such a wide scope this can be difficult in a
    development environment and near impossible in the live environment. In any
    case, testing takes time.
    
    The requirement to maintain a "Stable Production Environment" may mean that
    some Service Releases cannot be applied, regardless of what holes they fix.
    
    This is not just a vague generalisation. I have seen systems I maintain
    brought down by DBMS Service Releases. There are also many examples that
    have appeared in the Risks Digest.
    
    Our current system is held at a very old release because the next Service
    Release WILL break the application. This will require extensive work to find
    out all the places where code fixing is required.
    
    Note that I am not saying that Service Releases should never be applied, I
    am saying that they should never be applied blindly.
    
    ------------------------------
    
    Date: Mon, 27 Jan 2003 10:17:08 -0700
    From: "NewsScan" <newsscanat_private>
    Subject: The worm turned back: Slammer damage contained
    
    It's unlikely that there will be much additional destruction from the
    so-called Slammer computer worm that wreaked damage on the Internet over the
    weekend, by infecting more than a quarter of a million computer servers and
    clogging networks throughout the world. The worm targeted a known virus in
    Microsoft's 2000 SQL server database server; the company had issued software
    security patches in July 2002, but many network administrators had failed to
    install them. But now the worst appears to be over, says an executive at the
    security firm Symantec.  [*USA Today*, 27 Jan 2003; NewsScan Daily, 27 Jan
    2003] 
      http://www.usatoday.com/tech/news/2003-01-26-networm_x.htm
    
    ------------------------------
    
    Date: Mon, 27 Jan 2003 14:23:10 -0500
    From: Monty Solomon <montyat_private>
    Subject: 'Slammer' Feared to Strike Again
    
    'Slammer' Feared to Strike Again 
    Michelle Delio, Wired.com, 26 Jan 2003
    
    The global worming attack that fried much of the Internet this weekend may
    return on Monday as unpatched systems and applications boot up at the start
    of the workweek.  The worm can attack a multitude of Microsoft applications
    as well as applications distributed by other companies including
    administration, helpdesk, corporate antivirus and assorted security
    applications.  Network administrators may not even be aware that their
    systems harbor programs that need to be patched.  ...
    
    http://www.wired.com/news/infostructure/0,1377,57409,00.html
    
    ------------------------------
    
    Date: Mon, 27 Jan 2003 15:03:30 +0000
    From: M Taylor <mctaylorat_private>
    Subject: SQL Slammer in Canada
    
    By one account, some Canadian government agencies were embarrassed to have 
    been caught off guard by the so-called SQL Slammer, a string of 
    self-replicating computer code spread through data servers using Microsoft 
    SQL [Server]. 
    
    Royal Bank of Canada, Bank of Montreal and Canadian Imperial Bank of 
    Commerce all reported virus-related glitches on Saturday. RBC's telephone 
    and on-line banking systems were down for hours, and some CIBC and BMO cash 
    machines worked sluggishly or not at all. Toronto-Dominion Bank also had 
    problems but gave no details. Bank of Nova Scotia said its systems were 
    unaffected.
    
    [*The Globe and Mail*, 26 Jan 2003]
    http://www.globeandmail.com/servlet/ArticleNews/front/RTGAM/20030126/winterna
    
    M Taylor  http://www.mctaylor.com/
    
    ------------------------------
    
    Date: Sun, 26 Jan 2003 01:35:03 -0500
    From: Monty Solomon <montyat_private>
    Subject: MS SQL Server worm info
    
    CERT Advisory CA-2003-04 MS-SQL Server Worm
    http://www.cert.org/advisories/CA-2003-04.html
    
    Cisco Security Advisory: MS SQL "Sapphire" Worm Mitigation Recommendations
    http://www.cisco.com/warp/public/707/cisco-sn-20030125-worm.shtml
    
    SQL Sapphire Worm Analysis
    http://www.eEye.com/html/Research/Flash/AL20030125.html
    
    Microsoft SQL Slammer Worm Propagation
    http://bvlive01.iss.net/issEn/delivery/xforce/alertdetail.jsp?oid=21824
    
    Unauthenticated Remote Compromise in MS SQL Server 2000
    http://www.nextgenss.com/advisories/mssql-udp.txt
    
    Sapphire SQL Worm Analysis
    http://www.techie.hopto.org/sqlworm.html
    
    Sapphire SQL Worm Scanner Tool
    http://www.eeye.com/html/Research/Tools/SapphireSQL.html
    
    Slammer slugs Internet, down but not out
    http://www.infoworld.com/articles/hn/xml/03/01/25/030125hnsqlnetupd.xml
    
    ------------------------------
    
    Date: Mon, 27 Jan 2003
    From: [name withheld by request]
    Subject: Re: Keep it secret, stupid! (Blaze, RISKS-22.51)
    
    Matt Blaze has recently written (in http://www.crypto.com/masterkey.html 
    and http://www.crypto.com/papers/mk.pdf) about
    his discovery of a vulnerability in master-keyed mechanical lock systems.
    
    The paper is a well-written and detailed exposition of the technique, and
    will serve well to educate readers both about the workings of mechanical
    locks and about this particular attack. However, the attack may not be as
    exciting and ground-breaking as claimed. For example, a friend and I figured
    out how to do this in high school, but we realized that it would be much
    more time-consuming and persnickety than other attacks that were practical
    in that environment. As for whether the attack uses "cryptanalytical
    techniques", that claim is hard to justify unless you consider
    "cryptanalytical" the most appropriate term for recursive exhaustive search.
    
    It's hardly surprising that the technique is not widely covered in
    locksmithing texts. That's because it isn't particularly useful in
    legitimate contexts. No locksmith would ever bother going through all that
    rigmarole when he could instead disassemble the lock and read the master key
    directly--which is almost always possible if one has both a legitimate
    purpose and a legitimate key.
    
    Given the generally low quality of original work in the underground
    community, I'm not very surprised that it's not well-known there, either.
    Most techniques I've gleaned from there have fairly clear origins in the
    adult world. That's not to say that execution by the underground isn't
    clever--but finding the 99th new buffer overflow in Internet Explorer is
    more a matter of persistence, I think, than it is of original thinking.
    After all, buffer overflows have been well-understood as a security flaw for
    over 30 years.  The "MIT Guide to Lockpicking", for instance, is a clear and
    educational exposition of lockpicking, but doesn't present anything that
    hasn't been well-known in the locksmithing trade since before the invention
    of computers.
    
    The basic vulnerability--that there are many more keys which will open the
    locks in a masterkeyed system than are ever actually delivered with such a
    system--IS well-understood and publicized to the trade. Locksmithing texts
    (some, at least) explicitly warn about deploying different masterkey systems
    in the same geographic area that use the same kind of keys, for that very
    reason. Lock manufacturers sell recommended keying patterns that are
    explicitly designed to avoid the problem, and I'm sure there is computer
    software that locksmiths use today for the same purpose.
    
    A more interesting question is how to deduce the master key when you *don't*
    have a legitimate change key. That, too, is something we understood in high
    school, and it involves deducing patterns from several (temporarily)
    disassembled locks. Here, there's something resembling a geniune (although
    not especially difficult) cryptanalytical problem, in that one must deduce
    the pattern the lock manufacturer (or installer) used to assign the keys,
    and the manufacturer in turn can try to make that pattern difficult to
    deduce. That's the technique we used in actual practice, and it was an
    absorbing intellectual challenge at age 16.
    
    The observation that customers aren't warned about this problem, well,
    that's hard to assess. One could make the same complaint about not warning
    customers that most mechanical locks can be picked in a few seconds.
    Fortunately, a lot of contexts where this is an issue (such as hotels) have
    already converted to different technologies that may be more secure.
    
    ------------------------------
    
    Date: Sun, 26 Jan 2003 19:56:56 -0800 (PST)
    From: Fred Cohen <fcat_private>
    Subject: Re: Keep it secret, stupid! (Blaze, RISKS-22.51)
    
    When the original paper on Computer Viruses was sent to CACM for possible
    publication, they spent a year debating whether it should be considered for
    publication because of the potential harm that could be caused by people
    knowing about the vulnerability.  I was so disgusted that I have not sent a
    paper to the ACM since that time.
    
    Fred Cohen - http://all.net/ - fcat_private - fcat_private 
    tel/fax: 1-925-454-0171 Fred Cohen & Associates - University of New Haven
    
    ------------------------------
    
    Date: Mon, 27 Jan 2003 14:11:27 -0500
    From: "Robert Ellis Smith" <ellis84at_private>
    Subject: Matt Blaze is a Hero
    
    Congratulations to Matt Blaze for his extraordinary discovery about the
    vulnerability created by many master keys and especially for his forthright
    decision to publish his findings - after carefully weighing all of the
    consequences. The usual responses have been to keep findings like this a big
    'secret' or to disclose the findings without any responsible planning or
    precautions.The critical messages he is receiving from the ostriches in the
    business are variations on a theme we have seen in other contexts. Matt
    tells it like it is, and he's a hero for doing so.
    
    Robert Ellis Smith, Privacy Journal, PO Box 28577, Providence RI 02908
    ellis84at_private 401/274-7861 http://www.privacyjournal.net fax 401/274-4747
    
    ------------------------------
    
    Date: Mon, 27 Jan 2003 11:28:18 -0500
    From: Bill Bumgarner <bbumat_private>
    Subject: Re: Trouble with Prime Numbers: DeCSS, DVD, ... (Guadamuz, R-22.51)
    
    A slight clarification.
    
    CSS-- the encryption used on DVDs-- was not designed to prevent the
    duplication of DVDs, illegal or otherwise.  One can easily perform an 'image
    copy' of a DVD and the resulting copy will play just fine.  On a Macintosh,
    it is trivial to create a disk image-- a virtual piece of media-- of any
    filesystem, including a DVD.  The "virtual DVD" plays just fine and has the
    added advantage of lowering power usage on portable systems.
    
    CSS is intended to prevent unlawful access to the content in three ways.
    
    First, it makes it possible to enforce region codes in that it is [was]
    impossible to decode the content without a licensed-- and likely region
    locked-- decoder.  Region locking prevents a DVD targeted for the Japanese
    market from being played on a DVD player sold into the US market.  The
    motivation behind this is to supposedly prevent cannibalization of sales
    between different units of large distribution companies.  That is, Capital
    Records' US division does not want folks in the US purchasing something from
    Capital Records' UK division.
    
    Second, it hinders direct lossless access to the contents of the DVD.  This
    prevents folks from directly stealing the content and producing a derivative
    work.  It also hinders digital to digital conversion to other, smaller,
    formats such as Video-CD (VCD's are hugely popular in the far East).
    
    Finally, CSS provides a much greater degree of control over the distribution
    of content.  This allows the content producers to tightly tune release
    cycles, marketing, etc.. to the business climate in a particular market.
    That is, they can charge what the market will bear in the target region.  It
    also allows the media companies to control the production of the playback
    devices-- the content decoders.  If you want to market and sell a DVD
    player, you have to buy a very expensive decryption key from the agency that
    controls CSS decryption keys [I believe it is the MPAA, but I'm not sure].
    
    ------------------------------
    
    Date: Fri, 10 Jan 2003 08:17:30 -0800
    From: Rob Slade <rsladeat_private>
    Subject: REVIEW: "Auditing Information Systems", Mario Piattini
    
    BKAUINSY.RVW   20020825
    
    "Auditing Information Systems", Mario Piattini, 2000, 1-878-28975-6,
    U$139.95
    %E   Mario Piattini
    %C   1331 E. Chocolate Ave., Hershey, PA   17033-1117
    %D   2000
    %G   1-878-28975-6
    %I   IRM Press/Idea Group
    %O   U$139.95 717-533-8845 fax: 717-533-8661 cust@idea-group.com
    %O  http://www.amazon.com/exec/obidos/ASIN/1878289756/robsladesinterne
    %P   246 p.
    %T   "Auditing Information Systems"
    
    Chapter one is a general overview of auditing, with few details. 
    COBiT is not being used as intended by the majority of purchasers, we
    are told in chapter two.  There is a rather random discussion of some
    security (and some network) concepts in chapter three, which changes
    format rather abruptly towards the end.  Chapter four notes that
    software maintenance has dangers and a structured process would help. 
    It also suggests a COBiT style list of objectives.  All kinds of
    things it would be nice to have in the perfect data warehouse are
    described in chapter five.  Chapter six looks at a few legal issues
    with respect to information.  The theme of chapter seven seems to be
    that databases should do what they are supposed to.  (I suppose Gene
    Spafford could sympathize: his definition of a secure computer is one
    that does what it is supposed to.)  Chapter eight attempts to recreate
    ISO 9000 as a COBiT table.  Task analysis by another name (audit
    function points) is described in chapter nine.
    
    Even though the name of COBiT is repeatedly invoked in this book it is
    really hard to say what it has to do with auditing.
    
    copyright Robert M. Slade, 2002   BKAUINSY.RVW   20020825
    rsladeat_private  rsladeat_private  sladeat_private p1at_private
    http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade
    
    ------------------------------
    
    Date: Thu, 9 Jan 2003 08:05:45 -0800
    From: Rob Slade <rsladeat_private>
    Subject: REVIEW: "Internet and Intranet Security Management", Lech Janczewski
    
    BKIISMRS.RVW   20020825
    
    "Internet and Intranet Security Management", Lech Janczewski, 2000,
    1-878-28971-3, U$69.95
    %E   Lech Janczewski
    %C   1331 E. Chocolate Ave., Hershey, PA   17033-1117
    %D   2000
    %G   1-878-28971-3
    %I   IRM Press/Idea Group
    %O   U$69.95 800-345-432 fax: 717-533-8661 cust@idea-group.com
    %O  http://www.amazon.com/exec/obidos/ASIN/1878289713/robsladesinterne
    %P   302 p.
    %T   "Internet and Intranet Security Management: Risks and Solutions"
    
    There is a heavy emphasis, in the preface, on the book's being up to date.
    Yet the very first article relies on survey data that was three years old at
    the time the essay was written.
    
    Part one supposedly talks about the state of the (security, one assumes)
    art.  Chapter one is a vague and superficial look at random topics and
    technology related to security, plus results of the aforementioned opinion
    poll.  A list of Internet security problems, and solutions that are not
    connected to the difficulties, make up chapter two.
    
    Part two deals with managing Internet security.  Chapter three has terse
    descriptions of a number of theories of trust, related to some generic
    security concepts.  There are brief overviews of the TCSEC (Trusted Computer
    System Evaluation Criteria), Common Criteria, and not-really-the-BS7799 in
    chapter four.  Out of thirty three pages in chapter five, three discuss the
    general subject of Web security, while there is almost nothing on the
    titular topic of management of Web security.
    
    Part three reviews cryptographic and technical security standards.  (There
    are a great many grammatical errors, and the authors use almost-but-not-
    quite standard terminology.)  Chapter six is an opinionated piece, but does
    touch on some basic cryptographic ideas.  Myths and limitations of
    cryptography are listed in chapter seven.  Chapter eight has descriptions of
    ISO cryptographic standards, both overly technical and incomplete.
    
    Part four talks about law and security.  Chapter nine discusses privacy, but
    only in regard to employer monitoring of employee email.  The weaknesses of
    the New Zealand privacy law are commented on in chapter ten.
    
    It is difficult to say that any audience would benefit from this vague
    collection of unfocused ideas.
    
    copyright Robert M. Slade, 2002   BKIISMRS.RVW   20020825
    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 Majordomo balks when you send your accept, please forward to risks.
     [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.52
    ************************
    



    This archive was generated by hypermail 2b30 : Mon Jan 27 2003 - 15:50:45 PST