[risks] Risks Digest 22.93

From: RISKS List Owner (risko@private)
Date: Tue Oct 07 2003 - 15:55:41 PDT

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

    RISKS-LIST: Risks-Forum Digest  Tuesday 7 October 2003  Volume 22 : Issue 93
    
       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/22.93.html
    The current issue can be found at
      http://www.csl.sri.com/users/risko/risks.txt
    
      Contents:
    Walter Cronkite: The New Inquisition (Chuck Messall via Dave Farber)
    Re: Spam abounds (PGN)
    California spammin' (NewsScan)
    Worm FAQ (Stuart Staniford)
    Jury convicts man in DMCA case (Paul Festa via Monty Solomon)
    Broward considers dumping $17 million in touch voting machines 
      (Kim Alexander)
    Diebold voting machines in Volusia County FL (Brent M.P. Beleskey)
    Identity Denial really exists (Roger Clarke)
    Difficulties with Census Bureau income data among wealthiest (George Mannes)
    Fun with stolen credit-card numbers (Jonathan Kamens)
    Credit cards as ID (Ben Laurie)
    REVIEW: "Intrusion Detection with Snort", Jack Koziol (Rob Slade)
    Abridged info on RISKS (comp.risks)
    
    ----------------------------------------------------------------------
    
    Date: Tue, 07 Oct 2003 13:58:43 -0400
    From: Dave Farber <dave@private>
    Subject: Walter Cronkite: The New Inquisition
    
      [The last sentence is right on. djf]
    
    From: CMESSALL <CMESSALL@private>
    
      Walter Cronkite: "...Unfortunately, security and liberty form a zero-sum
      equation. The inevitable trade-off: to increase security is to decrease
      liberty and vice versa.  In the past, such trade-offs have been temporary
      -- for the duration of the crisis of the moment.  But today, we cannot see
      an end to the War on Terrorism, and that forces us to decide how secure we
      have to be and how free we want to be."
    
    Wow, have we already forgotten Ben Franklin's statement: "People who are
    willing to trade security for freedom soon find out that they have
    neither."?  In all fairness to Walter (who, I would have thought, might have
    actually *heard* Ben say those magic words ;-)), the trade-off might be
    correct at any given point in time, for the technology that applies at that
    instant.  The secret of course is to change the rules (i.e., the technology)
    so that we can have more security AND retain our liberty. - Chuck Messall
    
    IP Archives at: http://www.interesting-people.org/archives/interesting-people/
    
    ------------------------------
    
    Date: Tue, 7 Oct 2003 11:16:28 PDT
    From: "Peter G. Neumann" <neumann@private>
    Subject: Re: Spam abounds (RISKS-22.92)
    
    Thanks to many of you who responded thoughtfully to my plaintive cries of
    Spam-woe.  The simplest approach something that I have been contemplating
    for some time is to suggest that, if you want to significantly raise the
    probability that your message to RISKS will not be ignored, use the current
    string to include in the subject line.  "RISKS" itself in the subject line
    is less than ideal, because a surprising number of spams actually include
    that.  But for the foreseeable future, to radically improve my well-being
    and ability to separate the wheat from the chaff, let's try the string
      notsp: 
    in the subject line followed by a meaningful subject, or perhaps "notsp"
    appended to the subject line (CASE INSENSITIVE).  This pass-string will
    remain relatively stable unless it gets abused, in which case I will
    announce a phased-in change.  Many thanks for putting up with this
    inconvenience.
    
    Other remedies were suggested by RISKS readers (although some of them
    are not really suitable for RISKS-types of operations):
    
      * Greylisting 
        <http://projects.puremagic.com/greylisting/>
      * Spambayes 
        <http://spambayes.sf.net>
        (following the inspiration of Graham, extensively tested and improved) 
      * Indirection to a Web page that has the CURRENT valid address that
        changes as needed, plus procmail filters
      * TMDA anti-spam challenge-response software 
        <http://tmda.net>
      * Client-side POPFile proxy (open source, cross-platform)
        <http://popfile.sourceforge.net>
      * Bogofilter and various other filters
      * Just change your e-mail address as often as desired, and notify your
        regular communicators (clearly not applicable for RISKS, which 
        graciously receives e-mail from first-time contributors and needs
        the stability of a permanent address).
    
    An important concept in any such approach is that YOU should have flexible
    control over it, rather than some third-party who tells you what you should
    be willing to accept or reject.  There is no one-size-fits-all.  However,
    
      * Tripoli is a flexible approach that could help significantly.
        <http://www.pfir.org/tripoli-overview>
    
    ------------------------------
    
    Date: Thu, 25 Sep 2003 06:31:25 -0700
    From: "NewsScan" <newsscan@private>
    Subject: California spammin'
    
    California's new anti-spam law may face the same fate as a similar law in
    Utah earlier this year.  Kevin Johnson of the e-mail marketing company
    Digital Impact warns: "Hard-core spam will still come through, but
    legitimate companies will be more hesitant to send e-mail"; he also warns
    that when companies try to determine whether e-mail recipients live in
    California, spammers and advertisers may be forced to learn more about
    consumers, thereby reducing privacy.  E-mail marketer Trevor Hughes suggests
    that the only answer is national legislation to harmonize spam laws in more
    than 30 states.  [*USA Today*, 24 Sep 2003; NewsScan Daily, 25 Sep 2003]
      http://www.usatoday.com/tech/news/2003-09-24-spam_x.htm
    
    ------------------------------
    
    Date: Mon, 6 Oct 2003 15:34:48 -0700
    From: Stuart Staniford <stuart@private>
    Subject: Worm FAQ
    
    I just finished a first cut at a FAQ on worms and worm containment (my
    obsession for the last couple of years).  It may be of interest to RISKS
    readers:
      http://www.NetWorm.org/faq/
    
    Stuart Staniford, President    Tel: 707-445-4355 x 15
    Silicon Defense - The Cyberwar Defense Company
    
    ------------------------------
    
    Date: Thu, 25 Sep 2003 01:51:39 -0400
    From: Monty Solomon <monty@private>
    Subject: Jury convicts man in DMCA case (Paul Festa)
    
    Paul Festa, Staff Writer, CNET News.com, 23 Sep 2003
    
    A federal jury has convicted a Florida man of violating the Digital
    Millennium Copyright Act, in the first jury-trial conviction under the
    controversial law, according to a U.S. attorney's office.  The Los Angeles
    jury found 38-year-old Thomas Michael Whitehead guilty on Friday of selling
    hardware that could access DirecTV satellite broadcasts without paying for
    them, according to the U.S.  attorney's office in Los Angeles.  Whitehead,
    who was also known by his computer name "JungleMike," was convicted on one
    count of conspiracy, two counts of selling hardware that unlawfully
    decrypted the broadcasts, and three counts of violating the DMCA.  With the
    six felony convictions, Whitehead faces up to 30 years in federal prison and
    fines of as much as $2.75 million. Sentencing is scheduled for Jan. 26,
    2004.  ...
      http://news.com.com/2100-1025-5080807.html
    
    ------------------------------
    
    Date: Thu, 25 Sep 2003 08:39:48 -0700
    From: Kim Alexander <kimalex@private>
    Subject: Broward considers dumping $17 million in touch voting machines
    
    Here's some good news out of Florida.  Broward County is lobbying for
    approval of printers for touchscreens, and one of their election officials
    expresses regret for purchasing them in the first place.  Here's an excerpt:
    
    The touch-screen machinery accounted for part of the problems in the 2002
    elections in Broward.
    
    During the September primary, election workers found more than 1,000 votes
    that had not been reported in initial tallies to the state because machines
    had not been shut down properly.  And then in the November election,
    officials botched the numbers by not including in the tallies ballots cast
    by English-speaking early voters.
    
    "Hindsight is 20/20, but I wish we had stayed with optical scan,"
    Commissioner Kristin Jacobs said.
    
      Source: Broward considers dumping $17 million in touch voting machines,
      Scott Wyman, 24 Sep 2003, *South Florida Sun-Sentinel* <Sun-Sentinel.com>
    
    Kim Alexander, President, California Voter Foundation
    kimalex@private, 916-441-2494, http://www.calvoter.org
    
    ------------------------------
    
    Date: Wed, 24 Sep 2003 09:57:44 -0400
    From: "Brent M.P. Beleskey" <voterscoalition@private>
    Subject: Diebold voting machines in Volusia County FL
    
    ELECTION THEFT 2000! A NEW BOMBSHELL!: A Diebold Voting Machines in Volusia
    County, Florida, Tallied a Vote-Count of -16,022. That's NEGATIVE 16,022:
    When will this all-important story break out in the US mainstream press?
    When will the Democrats confront the issue? What is at stake here is the
    future of democracy.
    
    Diebold Internal Support Memos
    
    [The original article to which this post refers was originally published on
    29 Nov 2000 in *USA Today* by Philip Meyer. When I did a search for the
    article on the www.usatoday.com website I came up with this page which
    clearly provides the details of the article and even offers a link to a free
    preview of the article. However, when you click on the link, it gives you a
    page void of the article. What happened to it? One can only speculate.
    Nevertheless, I have obtained the original article.  BMPB]
    
      [Contact Brent Beleskey <voterscoalition@private> for the article,  PGN]
    
    A remarkable exchange concerning Diebold's voting machines in Volusia
    County, Florida: On January 17, 2001, Lana Hines, a county elections
    official sends out an inquiry as to how Al Gore ended up with a vote-count
    of -16,022. That's NEGATIVE 16,022 -- which just happens also to have been
    the total number of votes cast for various independent and third-party
    candidates who also ran.  (It was the largest number of such votes cast in
    Volusia County's history.)
    
    Pay close attention to the final entry, from "Tab" (Talbot) Iredale,
    Vice President of Research & Development at Global/Diebold:
    
      ...The error could only occur in one of four ways:
    
      1.Corrupt memory card. This is the most likely explanation for the problem
      but since I know nothing about the 'second' memory card I have no ability
      to confirm the probability of this.
    
      2.Invalid read from good memory card. This is unlikely since the
      candidates['] results for the race are not all read at the same time and
      the corruption was limited to a single race.  There is a possib[ili]ty
      that a section of the memory card was bad but since I do not know anything
      more about the 'second' memory card I cannot validate this.
    
      3.Corruption of memory, whether on the host or Accu-Vote.  Again this is
      unlikely due to the localization of the problem to a single race.
    
      4.Invalid memory card (i.e., one that should not have been uploaded).
      There is always the possib[i]lity that the 'second memory card' or 'second
      upload' came from an unauthorised source.
    
    And that's only the tip of the iceberg.
    
    ------------------------------
    
    Date: Sat, 27 Sep 2003 11:17:22 +0800
    From: Roger Clarke <Roger.Clarke@private>
    Subject: Identity Denial really exists
    
    [Admittedly this is a story from mainlaind China, and stories from there are
    often mistranslated linguistically and culturally when they reach English-
    language papers.  But it appeared in the quality Hong Kong daily.  It would
    seem reasonable to assume that their staff can read the original, and not
    make too many mistakes in the translation.]
    
    Woman wins case against in-law for ID cancellation
    
    A 98-year-old woman will be paid damages for psychological injury inflicted
    by her daughter-in-law, a Beijing court has ruled.  The *Beijing Daily*
    reports that the elderly woman discovered her relative cancelled her
    identity registration card seven years ago.  The defendant claims she
    cancelled the card to ensure her mother-in-law would not be cremated after
    she died.  Cancelling the card made the woman non-existent in the eyes of
    the law.
    
    Source: *South China Morning Post*, dateline Beijing, 26 Sep 2003 
    [They have a closed web-site, so I can't find the URL]
    
    Roger Clarke  http://www.anu.edu.au/people/Roger.Clarke/  +61 2 6288 1472
    Xamax Consultancy Pty Ltd, 78 Sidaway St, Chapman ACT 2611 AUSTRALIA
    
    ------------------------------
    
    Date: Tue, 7 Oct 2003 14:46:24 -0400
    From: George Mannes <George.Mannes@private>
    Subject: Difficulties with Census Bureau income data among wealthiest
    
    The Five Dumbest Things on Wall Street This Week
    By George Mannes, Senior Writer, 3 Oct 2003
    http://www.thestreet.com/markets/dumbestgm/10117038.html
    
      [George sent RISKS an excerpt, namely, the FIRST of five dumbest things.  
      I had difficulty trying to abridge it for RISKS, and decided to include
      it in its entirety.  See the URL for the other four.  PGN]
    
    1. I Dream of the Gini Index
    
    We at the Five Dumbest Things Research Lab hate to go all anti-academic on
    you, but here's a little advice: The next time you see a statistic in the
    newspaper, don't believe it. It's wrong.  OK, OK. That's overstating our
    case a little. It's not necessarily wrong.  But it's not right, either.
    
    Exhibit A: The 2002 household income figures released last Friday by the
    U.S. Census Bureau.
    
    The takeaway from the report, as you may have read in *The Wall Street
    Journal*'s Monday account, was that the poverty level rose, but income
    inequality didn't, because rich folk's income took a beating, too.
    
    But something further down in the write-up caught our eye. "Difficulties in
    recording seven-figure incomes," reported the Journal, might have resulted
    in underreported income among the wealthiest Americans.
    
    In other words, the rich may be richer.
    
    That's odd, we thought. People pay a lot of attention to these annual
    income-disparity figures. How come no one's getting worked up about
    inaccurate data from such a key segment of the surveyed population? This
    can't be true.
    
    We called up Edward Welniak, chief of the Census Bureau's income survey, to
    check.
    
    Indeed, there are difficulties with high-income data, Welniak told us.
    
    Here's why: Starting with the 1993 numbers, the bureau's staff -- which
    interviews a sample of 78,000 households for the income survey either in
    person or over the phone -- has been entering people's responses directly
    into portable or desktop PCs. As part of the survey, respondents are asked
    to report how much money they made the previous year from numerous sources
    -- stuff like the job held the longest, interest and dividends.
    
    And here's the catch: In each category, the highest dollar amount one can
    enter is $999,999.
    
    So let's say a Census employee had dropped by the $15,000-umbrella-stand-
    festooned apartment of ousted Tyco Chairman Dennis Kozlowski in 2001. And
    let's say the then-executive wanted to report the $50 million or so in
    undisclosed compensation the Securities and Exchange Commission says he
    received in 2000.
    
    Well, Kozlowski couldn't have done it. The Census would have recorded his
    salary at a mere million bucks.
    
    "The fact that we're not recording the full dollar value is going to
    understate the share of income controlled by households at the highest
    levels," says Welniak.
    
    But, says Welniak, there's a good reason for capping monetary entries at six
    digits: It limits the potential for error. One extra digit at the high end,
    and you're talking about, say, a $9 million paycheck instead of a $900,000
    payout. Errors at the high end of the income scale have a much larger impact
    than errors at the bottom. The increased accuracy introduced by more
    possible digits, says Welniak, would be more than offset by the decreased
    accuracy from newly enabled errors.
    
    Welniak has even investigated the exact effect of rounding all
    multimillion-dollar income sources down to a megabuck. According to his
    analysis of numbers from 1999 -- a year for which 26 respondents reported
    employment compensation of at least $1 million in at least one category --
    data-entry limitations effectively understated income inequality by 1%,
    using a standard measure of income distribution known as the Gini Index.
    
    But, given that the error appears to be constant year after year, says
    Welniak, "Measuring changes in income inequality from one year to the next
    is not going to be affected." In other words, ignore the absolute number and
    look at the trend.
    
    Mindful of that, we point out that over the past decade, the Census Bureau's
    Gini Index has been creeping upward -- implying increased income
    inequality. Starting at 45.4 in 1993, it peaked at 46.6 in 2001 but
    retreated to 46.2 last year. (For purposes of comparison, the United Nations
    Development Program -- which puts the U.S. at 40.8 -- says Japan is a 24.9
    and Brazil is a 60.7.)
    
    In fact, someone has gotten worked up about the low-balled high incomes: the
    Center on Budget and Policy Priorities, a D.C.-based research group.  The
    CBPP has been complaining about the Census data for years, griping not only
    about the $999,999 cap but also about the Bureau's exclusion of capital
    gains from household income.
    
    "The census data has useful information," says Isaac Shapiro, a CBPP senior
    fellow. "But at the high end, it's not useful."
    
    Based on Congressional Budget Office data, the CBPP says the average
    household after-tax income in the top 1% of the population tripled from
    $286,000 in 1979 to $863,000 in 2000, while the lowest fifth of the
    population saw household income rise a mere $1,100 to $13,700 over the same
    time period.
    
    Put that in your Gini Index and smoke it.
    
    George Mannes, 14 Wall Street - 15th Floor / New York, NY  10005
    phone: 212-321-5208 / mobile: 646-641-2093
    http://find.thestreet.com/cgi-bin/texis/author/?au=A0000332
    
    ------------------------------
    
    Date: Fri, 5 Sep 2003 11:31:57 -0400
    From: Jonathan Kamens <jik@private>
    Subject: Fun with stolen credit-card numbers
    
    Yesterday, I got an e-mail message from Amazon.com which I am including here
    in full (word wrapped and with some details obscured but otherwise
    unmodified) because I believe it will be of interest to RISKS readers.
    Additional comments from me follow the message.
    
      X-AMAZON-TRACK: <jik@private>
      Date: Thu, 4 Sep 2003 16:01:07 -0700
      From: charge-inquiries@private
      To: jik@private
      Cc: charge-inquiries@private
      Subject: Your Credit Card Account
    
      Greetings from Amazon.com.
    
      We perform routine reviews of orders to protect our customers. During one
      of these reviews we discovered that an account was opened with a card used
      by you on another account.  For your reference the card in question is a
      American Express card with the last five digits of [deleted].
    
      As it appears the card was used without your authorization, we have closed
      this new account and cancelled any outstanding orders.  If the account is
      indeed yours, we apologize for any inconvenience caused and ask that you
      notify us by replying to this email message as soon as possible.  If the
      card was used without your authorization, we recommend you cancel the card
      immediately by contacting the financial institution that issued the card.
      Unfortunately, if this is the situation, you should know that a charge in
      the amount of $556.94 was processed by us.
    
      You should review all recent charges made to this card, reporting any
      unauthorized charges, including those mentioned above, to your financial
      institution.  The financial institution, in turn, will send you forms to
      formally dispute the unauthorized charges, the applicable merchants will
      be notified and charged back, and your account subsequently credited.
      Additionally, you may wish to report this matter to the applicable law
      enforcement agency.
    
      We were able to verify that your card was not compromised from our site.
      Our credit and debit card data is stored on a computer that is not
      connected to the Internet.  When data is received it is sent to a
      dedicated computer via a proprietary one-way interface across a simple
      serial connection.  The information is stored no other place, access to
      the data is restricted and, when accessed, logged.
    
      Although we are not permitted to provide you with any details about the
      unauthorized use, we will provide this information to any law enforcement
      agency investigating this matter as well as to the financial institution.
      Please don't hesitate to contact us if you have any further questions or
      concerns.
    
      Sincerely,
    
      Ben
      Investigation Specialist
      Amazon.com
      http://www.amazon.com
      Earth's Biggest Selection
      =========================
    
    I went to the American Express Web site and checked the unbilled activity on
    the card, and, indeed, found a charge of $556.94 to Amazon.com on August 31
    which I did not make.  I also found another charge I did not make of over
    $500 to Amazon.com on August 27.
    
    I called the telephone number on the back of my card, navigated through
    voice-mail for several minutes and then spoke to three representatives.  The
    first deactivated my card, issued me a new one, and transferred me to the
    customer service department.  The customer service rep transferred me to the
    fraud department.  The fraud rep ask me a few questions that were probably
    from a script ("Was your card ever out of your possession?" "Did you make
    these charges?", etc.).  Then she said that the charges would be removed
    from my account and investigated.
    
    Some things here worked very well.  It's good that Amazon caught the bogus
    charges relatively quickly and notified me about them.  It's good that
    American Express was polite and was able to deactivate my card, issue me a
    new one, and remove the bogus charges from my account quickly.
    
    Some things did not work so well.  Why didn't Amazon stop the perpetrators
    in real-time from making a purchase using a card already registered to
    another account, as opposed to only detecting the situation after the fact?
    Since I assume that the fraudulent purchase was shipped to an address other
    than mine, why didn't Amazon require additional verification before shipping
    over $500 of merchandise to an address other than the card's billing
    address?
    
    There are some questions whose answers I do not know, and neither Amazon nor
    American Express is telling.  Did the perpetrator use my name?  Did s/he
    know my correct billing address?  Did s/he know the security code printed on
    the front of the card?  And if the answer to any of these questions is "no,"
    why did Amazon allow the charge?  And the biggest question, to which I'll
    probably never know the answer, is, how did the perpetrator steal my info?
    Even if they catch him/her and find out, it's unlikely that the information
    will trickle back to me.
    
    Today I'll be contacting all the credit-reporting agencies to put a fraud
    alert on my report and ask them for free copies so that I can verify that
    this is merely a case of isolated credit-card number fraud as opposed to
    full-scale identity theft.  Who knows, this may be the start of a very bumpy
    ride.
    
    Jonathan Kamens
    
    ------------------------------
    
    Date: Fri, 03 Oct 2003 12:50:21 +0100
    From: Ben Laurie <ben@private>
    Subject: Credit cards as ID
    
    About a week ago, our front door was broken down at 3 in the morning.  The
    burglars took my wife's handbag from the hall and ran (luckily, it didn't
    contain her car keys, because a common strategy is to return in a few hours
    and take the car, too).
    
    Today, we received a number of phone contracts. These may or may not have
    been paid for with the stolen credit cards [1], but (we are informed) the
    credit cards were used for ID.
    
    This got me thinking. My credit cards are often used for ID, too. But they
    never check whether the card has been stolen - all they check is that it has
    the right name on it.
    
    Now, given that the most common case of this occurring is when I take
    internal flights in the UK, I'm suddenly worried. The risk is obvious.
    
    Incidentally, the incidents also show the lack of value of photo ID - at
    least one of the contracts requires proof of address, and the only proof in
    the handbag was my wife's driving licence. Which has a photo on it.  So I
    guess we can add that as a second risk (i.e. relying on photo IDs for fraud
    prevention).
    
    [1] Since my wife spent the time waiting for the police cancelling all
    her cards, they may not have been used.
    
    http://www.apache-ssl.org/ben.html       http://www.thebunker.net/
    
    ------------------------------
    
    Date: Mon, 6 Oct 2003 21:22:12 -0800
    From: Rob Slade <rslade@private>
    Subject: REVIEW: "Intrusion Detection with Snort", Jack Koziol
    
    BKINDTSN.RVW   20030901
    
    "Intrusion Detection with Snort", Jack Koziol, 2003, 1-57870-281-X,
    U$45.00/C$69.99/UK#32.99
    %A   Jack Koziol
    %C   201 W. 103rd Street, Indianapolis, IN   46290
    %D   2003
    %G   1-57870-281-X
    %I   Macmillan Computer Publishing (MCP)
    %O   U$45.00/C$69.99/UK#32.99 800-858-7674 info@private
    %O  http://www.amazon.com/exec/obidos/ASIN/157870281X/robsladesinterne
        http://www.amazon.co.uk/exec/obidos/ASIN/157870281X/robsladesinte-21
    %O   http://www.amazon.ca/exec/obidos/ASIN/157870281X/robsladesin03-20
    %P   340 p.
    %T   "Intrusion Detection with Snort"
    
    Chapter one is a good introduction to the basics of intrusion detection,
    although it is odd that the list of detection methods is missing some
    important entries, such as heuristic rule-based and statistical methods.
    The background overview of Snort, in chapter two, describes alerts, related
    applications, and even has recommendations for sensor net architecture.
    Most of the content in regard to the components of Snort, in chapter three,
    deals with the preprocessors, and various attack signatures.  Chapter four's
    advice about planning for the installation of Snort is broadly based,
    addressing policy, architecture, and even incident response, but the
    material is quite abstract, and could have benefitted from more practical
    examples.  Some of these missing considerations are dealt with in chapter
    five, which looks at hardware and operating system factors.  The text
    concentrates on server and sensor performance, but also addresses the
    network connection.  Directions on building a Snort server under Red Hat
    Linux version 7.3 are given in chapter six.  The sensor and console
    instructions are provided in chapters seven and eight, respectively.  A few
    optional architectures are described in chapter nine.
    
    Chapter ten deals with tuning various rulesets and components in order to
    reduce the level of false alarms.  Creating real-time alert systems is
    discussed in chapter eleven.  Chapter twelve is a major one, outlining the
    creation and modification of rules for filtering and analyzing traffic.
    Chapter thirteen is supposed to be about upgrading and maintaining Snort,
    but concentrates on ancillary management tools.  Advanced or unusual
    configurations of Snort are described in chapter fourteen.
    
    The book is generally lucidly written and easy to study, but it contains
    many typographical errors and a great deal of clumsy wording in the text.
    Better copy editing word have improved readability, as well as confidence in
    the reliability of various commands and settings.  However, the meaning is
    usually clear, even if the expression is sometimes jarring.  For those
    planning to use Snort, this should be a serviceable introduction.
    
    copyright Robert M. Slade, 2003   BKINDTSN.RVW   20030901
    rslade@private      slade@private      rslade@private
    http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade
    
    ------------------------------
    
    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.
    => 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 22.93
    ************************
    



    This archive was generated by hypermail 2b30 : Tue Oct 07 2003 - 16:34:29 PDT