Risks Digest 24.65

[RISKS List Owner <risko () csl sri com>]

RISKS-LIST: Risks-Forum Digest  Tuesday 24 April 2007  Volume 24 : Issue 65

ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks)
Peter G. Neumann, moderator, chmn ACM Committee on Computers and Public Policy

***** 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/24.65.html>
The current issue can be found at
  <http://www.csl.sri.com/users/risko/risks.txt>

  Contents:
A new book on risks by Charles Perrow, The Next Catastrophe (PGN)
Gov't Straining to Secure Computer Systems (PGN)
Don't let your navigation system fool you (PGN)
KPMG profile of a fraudster (Rob Slade)
US Dept of Agriculture & Census Bureau have long contained SSNs
  (Kenneth C Knowlton)
Automatic translation leads to ethnic slur (Jeremy Epstein)
Prisoner freed by fax (Bob Morrell)
"System problems" on a departing airline flight? (A.E. Siegman)
Elections bring down foreign Web sites (Bertrand Meyer)
Netcraft Data for Ohio Secretary of State Web site (McGrude)
Audit Finds Many Faults in Cleveland's 2006 Voting (David Lesher)
Re: Philippine Internet voting system challenge (David Lesher)
Re: Washington DC Metro replacing software that causes fires (Barry Gold)
RIM cites upgrade glitch for BlackBerry outage (Robert Israel)
Re: US Daylight Saving Issues (Larry Jones, Charlie Shub)
Re: Risks of relying on systems to file taxes late (Rex Black, Ross Oliver)
REVIEW: "Information Security Awareness Basics", Fred Cohen (Rob Slade)
Abridged info on RISKS (comp.risks)

----------------------------------------------------------------------

Date: Tue, 24 Apr 2007 12:05:47 PDT
From: "Peter G. Neumann" <neumann () csl sri com>
Subject: A new book on risks by Charles Perrow, The Next Catastrophe

  Charles Perrow,
  The Next Catastrophe:
  Reducing Our Vulnerabilities to
  Natural, Industrial, and Terrorist Disasters
  Princeton University Press, 2007, viii+377

Charles Perrow's earlier book, Normal Accidents: Living with High-Risk
Technologies (Basic Books, New York, 1984), was an enormously important
inspiration for many early RISKS readers.  His latest book is likely to be
even more important, and certainly very timely.  From the jacket: This book
is "a penetrating reassessment of the very real dangers we face today and
what we must do to confront them."

On a personal note, when I called him out of the blue in the late 1980s and
asked him if he would keynote one of the COMPASS conferences (predecessors
to the ACM ACSAC conferences), he demurred -- saying he was not a computer
expert.  And yet his message was completely on the mark for that audience
and for RISKS back then.  Twenty years later, there is no question that his
writing is absolutely relevant to the huge set of technological and social
problems we face today.  The message of his new book is very clear: we must
do much more to reduce the vulnerabilities across the board.  "Rather than
laying exclusive emphasis on protecting targets, we should reduce their size
to minimize damage and diminish their attractiveness to terrorists."  His
analyses of FEMA, DHS, 9/11, and Katrina are incisive.  He makes a very
strong case for the need to make major changes in what has seemingly become
a rather business-as-usual response to past catastrophes and a pervasive
unwillingness to adequately anticipate future catastrophes.  I consider this
book essential reading for all RISKS readers.

The book very clearly addresses the computer-related risks as well as many
others.  The holistic view of the book is absolutely essential if we are
going to confront the next catastrophe(s).  I recommend it highly.  PGN

  [I note an ambiguity in the subtitle that most of you will probably miss.
  In addition to the intended emphasis on Reducing Our Vulnerabilities,
  there is an unintended secondary interpretation (as in "Reducing a complex
  problem to a simpler problem"), suggesting that if (for example) we could
  get rid of all of the computer-related risks that result from flawed
  designs, buggy implementations, human errors in operations, and so on (and
  which are so prevalent in RISKS), we could reduce our vulnerabilities to
  only a much smaller subset, namely, just natural, industrial, and
  terrorist disasters -- and nothing else.  This may seem obscure to
  nonEnglish speakers, and is clearly not what is meant by the title, and
  thus I include it here as a squarely parenthetical aside.]

------------------------------

Date: Tue, 24 Apr 2007 10:22:13 PDT
From: "Peter G. Neumann" <neumann () csl sri com>
Subject: Gov't Straining to Secure Computer Systems

Federal computer networks are being targeted on an unprecedented scale and
recent high-profile compromises at the Departments of Commerce and Sate are
likely just the most visible symptoms of a government-wide security
epidemic, government security experts told a House Homeland Security
Committee hearing.  [Source: Hackers Increasingly Gaining Access to
Networks, Congress Is Told, Brian Krebs, *The Washington Post*, 19 Apr 2007]

------------------------------

Date: Tue, 24 Apr 2007 10:22:28 PDT
From: "Peter G. Neumann" <neumann () csl sri com>
Subject: Don't let your navigation system fool you

Two Italian hackers have figured out how to send fake traffic information to
navigation systems that use a data feature of FM radio for real-time traffic
information. Using cheap, off-the-shelf hardware, they can broadcast traffic
data that will be picked up by cars in about a one-mile radius, the hackers
said during a presentation at the CanSecWest event here.

"We can create queues, bad weather, full car parks, overcrowded service
areas, accidents, roadwork and so on," Andrea Barisani, chief security
engineer at Inverse Path, a security company. "Traffic information
displayed on satellite navigation systems is trusted by drivers.  Normal
people do not think that you can do nasty things."

Barisani and hardware hacker Daniele Bianco discovered that the system used
by many navigation aides to get traffic data isn't secured. The data is sent
using the Traffic Message Channel (TMC) of the Radio Data System (RDS), a
standard way of transmitting data over FM radio also used to display station
names and program titles.  [Source: Joris Evers, CNET News.com, 20 Apr 2007:
PGN-ed]

------------------------------

Date: Thu, 19 Apr 2007 11:56:50 -0800
From: Rob Slade <rMslade () shaw ca>
Subject: KPMG profile of a fraudster

KPMG UK has produced a report to help us identify people who would defraud
our companies.  It is interesting, mostly in terms of the questionable
nature of the conclusions.

http://www.kpmg.co.uk/pubs/ProfileofaFraudsterSurvey(web).pdf

The profile is based on 360 cases of detected and investigated fraud, in
Europe, South Africa, and the Middle East.

The 38 page report is initially long on platitudes, although is does provide
data in the later stages.  The "personal" profile (on page 8) is probably
the most interesting part:

70% of fraudsters were between the ages of 36 and 55 years old, and so in
    the later stages of their career.

85% male.

68% acted independently.

89% insiders.  (We knew that ...)

60% senior management. An additional 26 % of frauds involve management level
    persons bringing the total to 86 % of profiles involving management.

87% employed 2 years or more at the company defrauded.  (Highest proportion
    in the 3-5 year range.)

The internal fraudster most often works in the finance department followed
by operations/sales or as the CEO.

The response suggested by the report is vague.  The recommendations are the
same that we've all heard, with a heavy emphasis on "internal controls."
However, the data in the profile doesn't necessarily support this advice:
internal controls are not terribly effective, according to the reports.

confession of perpetrator 2%
negligence of perpetrator 2%
complaints by suppliers 4%
accidentally 8%
complaints by customers 9%
suspicious superior 9%
internal controls 10%
external controls 10%
management review 21%
whistle blowing 25%

(The type of fraud is also interesting:

counterfeit 1%
insider trading 1%
money laundering 2%
breach of secrets 2 %
other fraud 9%
embezzlement 10%
theft of other assets 10%
false financial reporting 20%
theft of cash 22%
corruption 23%

This is the data from Europe.  Theft of cash and "corruption" are higher in
South Africa and the Middle East figures.)

rslade () vcn bc ca     slade () victoria tc ca     rslade () computercrime org
http://victoria.tc.ca/techrev/rms.htm

------------------------------

Date: Sun, 22 Apr 2007 09:46:23 EDT
From: Kenneth C Knowlton <KCKnowlton () aol com>
Subject: US Dept of Agriculture & Census Bureau have long contained SSNs

The U.S. Department of Agriculture has for many years publicly been listing
Social Security numbers of about 30,000 people who received financial aid
from two of its agencies, raising concerns about identity theft and other
privacy violations, apparently unbeknownst to DoA and Census Bureau
officials -- until an Illinois farmer stumbled onto the data via Google at
FedSpending.org.  [Source: U.S. Database Exposed Social Security Numbers,
Ron Nixon, *The New York Times*, 21 Apr 2007; PGN-ed]
  http://www.nytimes.com/2007/04/21/washington/21data.html?th&emc=th

------------------------------

Date: Fri, 20 Apr 2007 10:24:33 -0400
From: Jeremy Epstein <jepstein () webmethods com>
Subject: Automatic translation leads to ethnic slur

The automated translation of a color description by a Chinese manufacturer
into English resulted in an ethnic slur (which I'm not repeating here due
both to its being offensive and to avoid tripping inappropriate word
filters).  While there are periodic lists circulated around of
mistranslations, this one wasn't funny but rather quite offensive.  There's
the usual level of finger-pointing between the retailer, wholesaler, and
manufacturer of who is responsible.

Some lessons learned:
- Translations should be checked by a native speaker to ensure both accuracy
  and appropriateness.
- Relying on automated translations as a cost saving measure isn't a good
  idea, for anything other than getting the gist of an idea.

http://www.cnn.com/2007/WORLD/americas/04/19/canada.couch.ap/index.html

  [Also noted by several others.  PGN]

------------------------------

Date: Mon, 23 Apr 2007 12:13:38 -0400
From: "Bob Morrell/Cancer Center" <bmorrell () wfubmc edu>
Subject: Prisoner freed by fax

A prisoner was wrongly released after a fax was received from a grocery
store stating that the Kentucky Supreme Court had demanded his release:
http://www.cnn.com/2007/US/04/21/wrongly.freed.ap/index.html

I have always complained that network security is held to a standard
that other technologies do not have to meet.  Apparently others are
noticing this as well...

------------------------------

Date: Sun, 22 Apr 2007 12:07:30 -0700
From: "A.E. Siegman" <siegman () stanford edu>
Subject "System problems" on a departing airline flight?

While waiting to board a different flight in the United Terminal at JFK
Friday evening, April 20, I was bemused to hear an announcement repeated
perhaps 20 times in a two-hour period:

"Attention passengers on British Airways flight 1502 to Manchester: Due to
system problems on this aircraft, there will be no inflight entertainment
and no overhead lighting during the flight.  We apologize for this
inconvenience; passengers who have questions may come to Gate xxx."

I guess my own question would have been: Do I want to head out over the
Atlantic in an aircraft that's having "system problems" and especially
electrical ones?  (Maybe it would depend on whether I'd gotten an upgrade or
not . . .)

A. E. Siegman, McMurtry Professor of Engineering Emeritus, Stanford University
(650) 326-4360  siegman () stanford edu

  [This seems to be a not uncommon failure mode, which I presume the repair
  folks believe is unrelated to the flight controls.  On the other hand,
  RISKS readers are generally suspicious of such beliefs.  I suppose that if
  this particular problem cannot be fixed quickly enough, the airline might
  prefer not to delay the flight, which of course can have propagational
  effects on international schedules.  PGN]

------------------------------

Date: Sun, 22 Apr 2007 21:05:15 +0200
From: Bertrand Meyer <Bertrand.Meyer () inf ethz ch>
Subject: Elections bring down foreign Web sites

The current French presidential election provides rich material for RISKS,
in particular many stories related to the somewhat botched introduction of
voting machines.  Here is a report on the Web consequences, as seen by one
"Internaute", of today's (22 April 2007) first round of balloting.

French law prohibits any publication of estimates in the last two days and
until the closing of the polls at 8 PM; in recent years it was extended to
cover the Internet. Partly because penalties for breaking the ban are
serious, and partly because the rule enjoys broad support, no reputable
French Web site was tempted to publish any estimate before the deadline
(although lemonde.fr reported at 18:46 that the mood at one of the principal
candidate's headquarters was "not ebullient", a rather blatant
giveaway). Neither was it easy to find a list of links to the sites of
foreign news media, to which the rule cannot apply.

Several of these foreign sites, especially those of French-language papers
in Belgium and Switzerland, had announced that they would start giving out
estimates at 6 PM, when exit polls provide a credible picture. *La Libre
Belgique*, for example, explicitly invited Web readers to come at 6.

Starting in the afternoon, most of these sites (*La Libre Belgique*, *Le
Soir* from Brussels, *Le Matin* from Lausanne...) were, for me at least,
impossible to reach; they were timing out. It looked like all of wired
France (Internet penetration per Nielsen: 50.3% in late 2006) was trying to
access them, and either the servers or the bandwidth couldn't follow.  Long
into the evening I still couldn't reach lalibre.be.

I got my first taste of the results around 6:30 through an Italian site,
*Corriere della Sera*; other Italian newspapers such as *La Repubblica* had
estimates shortly thereafter. One of these reports pointed to Swiss
French-speaking TV (I hadn't checked tsr.ch earlier but it was working
properly when I did). The Swiss German-language newspaper sites (NZZ,
*Tagesanzeiger*) published the estimates a few minutes later. In stark
contrast with foreign French-language sites, none of the non-French-language
sites showed any sign of stress.

At some point in the afternoon someone at *Le Temps* (Geneva), whose site
had been slow but reachable, had the good sense to replace the site's usual
home page -- with the usual combination of ads, photographs, cartoons,
links, tables, CSS and other complicated layout -- by a text-only page
entirely devoted to a concise report about the French election, with a note
that traffic was unusually high and that the normal page would be restored
later. As a result one could find estimates there too. Le Soir eventually
did the same.

If this experience is representative, it would seem that the infrastructure
for many newspapers' online editions isn't ready to withstand a steep surge
in visits. True, today's situation was exceptional because of the news
blackout about an event that has generated considerable passion (the turnout
was the highest ever, and the outcome was hard to predict) in a large
country whose language is spoken by much smaller neighboring
communities. Scaling up a site to accommodate millions of foreign visitors
on a couple of afternoons every few years probably doesn't sound like an
attractive investment; it is unlikely to yield many new advertisers or
subscribers. Still, one can wonder about the effect on these sites of the
next major news event.

It is surprising to see how few sites had *Le Temps*'s reaction of providing
a pared-down, text-only version of the site with the key information that
visitors are seeking. Granted, such sites are there to sell advertisements,
not provide a public service; but a site that no one can access doesn't do
much for advertisers or anyone else. It seems that other media sites didn't
have any contingency planning, or didn't even realize what was going on.

The second round, of only two candidates, is two weeks from now, with the
same law in force and presumably even higher stress and eagerness to
know. It's going to be interesting to see if the sites are better prepared
this time.

One site, cnn.com, was as usual available all the time without any delay;
until shortly before 8 all that one could find on the home page was a link
to older material about the campaign. The text of the link was expressing a
world philosophy more eloquently than many a long speech: "French polls
open; candidates differ on U.S.".

Bertrand Meyer ETH Zurich http://se.ethz.ch  Eiffel http://www.eiffel.com

------------------------------

Date: Tue, 24 Apr 2007 13:15:10 -0700
From: McGrude <McGrude () gmail com>
Subject: Netcraft Data for Ohio Secretary of State Web site

"Netcraft is showing that an event happened in the Ohio 2004 election that
is difficult to explain. The Secretary of State's website, which handles
election reporting, normally is directed to an Ohio-based IP address hosted
by the Ohio Supercomputer Center. On Nov. 3 2004, Netcraft shows the website
pointing out of state to a server owned by Smartech Corp. According to the
American Registry on Internet Numbers, Smartech's block of IP addresses
64.203.96.0 - 64.203.111.255 encompasses the entire range of addresses owned
by the Republican National Committee. Smartech hosted the recently notorious
gbw43.com domain used from the White House in apparent violation of the
Presidential Records Act, from which thousands of White House e-mails
vanished. Can anyone suggest a good explanations for this seemingly dubious
election-eve transfer?"
  http://www.alternet.org/story/50941
  http://politics.slashdot.org/politics/07/04/24/1735213.shtml
  http://toolbar.netcraft.com/site_report?url=http://election.sos.state.oh.us

------------------------------

Date: Thu, 19 Apr 2007 23:35:02 -0400 (EDT)
From: David Lesher <wb8foz () panix com>
Subject: Audit Finds Many Faults in Cleveland's 2006 Voting

An audit of the November 2006 general election in the Cleveland area has
found that hundreds of votes were lost, others were recorded twice, and
software used to count the ballots was vulnerable to data problems.
[Source: Bob Driehaus, *The New York Times*, 20 Apr 2007; PGN-ed]

------------------------------

Date: Thu, 19 Apr 2007 20:42:21 -0400 (EDT)
From: David Lesher <wb8foz () panix com>
Subject: Re: Philippine Internet voting system challenge (RISKS-24.64)

  [David's note refers to the major inherent problem with Internet
  voting, coercion/vote selling.  PGN]

a) Go to voter's house ahead of time.

b) "See my gun? You will vote as I tell you, while I watch; or I'll
take your daughter with me... and sell her, if she's still alive."

c) Voter decides that Gov. Dewey is not a bad choice after all.

Repeat as needed.

I can't recall who coined the phrase "rubber-hose cryptanalysis" but it also
applies to voting. There IS a reason we have the secret ballot.

The RISK? Worrying about only one RISK, and ignoring the others...

------------------------------

Date: Thu, 19 Apr 2007 22:28:17 -0700
From: Barry Gold <barrydgold () ca rr com>
Subject: Re: Washington DC Metro replacing software that causes fires
  (Rieden, RISKS-24.64)

> ... when designing ANY software change, the qualification of the hardware
> (and the required test cases) should ALWAYS at least be formally reviewed
> and repeated where necessary.

Well, the NSA is well aware of this, and I'm a little surprised that the
people who design aircraft -- especially military aircraft -- aren't.  If
you look at DCID 6/3 and supporting material you will see a pretty good set
of specifications.

This applies especially to systems designed for Protection Level 7 --
systems that will handle data spanning from unclassified/general public to
Top Secret with one or more Special Access Need-to-Know Compartments.  Such
systems would need to be built to EAL-7 (formerly called A-1 in the old
Orange Book).  This requires a full mathematical specification of the
software, mathematical proof that the specification preserves security, and
a line-by-line correspondence between the specification and the code.

In practice, this takes a lot of time.  Just building a system of any size
takes time, and then you need to add effort _and time_ to write and prove
the formal specification and the code correspondence.  And then the whole
thing has to be reviewed by a certifying authority.

So the usual result is that you have built an EAL-7 boat anchor.  By the
time you've done all this, your system is two years out of date -- too old
to be useful in today's rapidly evolving world.  The best you can do is keep
the same software and match it with newer, more modern hardware.  But then
the new hardware has to go through the certification process too.

The only commercial product I'm aware of that meets EAL-7 is the Data Diode
-- magnificent in its simplicity.  It keeps data from flowing the "wrong"way
(from more classified to less classified) by the simple technique of not
providing a hardware path for that data flow.  At its heart is a fiber-optic
cable, one end has (only) transmitters, and the other end has (only)
receivers.  There is simply no way to move data the other way.

------------------------------

Date: Sun, 22 Apr 2007 10:17:36 -0700 (PDT)
From: Robert Israel <israel () math ubc ca>
Subject: RIM cites upgrade glitch for BlackBerry outage (RISKS-24.64)

http://www.globeinvestor.com/servlet/story/GAM.20070421.RRIM21/GIStory/
A few excerpts:

RIM co-chief executive Jim Balsillie dismissed those worries, telling
Reuters News Agency that "systems are in place so that this kind of thing,
as incredibly unlikely as it is to happen, is all the more unlikely to
happen again." [where have we heard that one before?]

Essentially, he said, "it was an outage overnight when there was an
upgrade."

But the outage has also raised concerns about the way RIM handles e-mail
data, Mr. Levy said, given that all traffic is routed through a single
communication centre.

Robert Israel, Department of Mathematics, University of British Columbia
Vancouver, BC, Canada  http://www.math.ubc.ca/~israel

------------------------------

Date: Fri, 20 Apr 2007 21:30:36 -0400 (EDT)
From: Larry Jones <lawrence.jones () ugs com>
Subject: Re: US Daylight Saving Issues (Bonner, RISKS-24.64)

> In running log files from the past few weeks I've noticed that the times
> seem to be an hour off from what I remember the time would have been when
> the data was taken.

When converting between local time and UTC, Microsoft has long held the
peculiar philosophy that whether Daylight Saving Time is *currently* in
effect should be used to determine the offset to be applied rather than
whether DST was (or will be) in effect at the time being converted.  This
has caused no end of problems, but they insist that that is how it's
supposed to work and refuse to fix it.

------------------------------

Date: Thu, 19 Apr 2007 22:19:28 -0600 (MDT)
From: Charlie Shub <cdash () ludell uccs edu>
Subject: Re: US Daylight Saving Issues (Bonner, RISKS-24.64)

The solution seems rather obvious.  Instead of using software to account for
all the idiosyncracies in time calculation, the process should be data
driven, through a configuration file.  When will we ever learn?

Charlie Shub, University of Colorado at Colorado Springs (719) 262-3492
http://cs.uccs.edu/~cdash cdash () cs uccs edu

------------------------------

Date: Thu, 19 Apr 2007 19:43:30 -0500
From: Rex Black <rexblack () ix netcom com>
Subject: Re: Risks of relying on systems to file taxes late (RISKS-24.64)

> "Don't wait until the last minute is the moral of the story."

Actually, the moral of the story is:

1. Save money by not bothering to load test your software.
2. Blame your customers for the performance and reliability bugs you
   didn't find and shift the costs off to them should any costs occur.
3. Convince--somehow or other--the Federal government that you shouldn't be
   fined or at least stripped of your privilege to process taxes online.

Since they seem to have pulled off this little trifecta, the title of this
story is: "Software Quality Doesn't Matter: Part 11,765 in a Continuing
Series."

Rex Black, President, American Software Testing Qualif. Board; Pure Testing,
31520 Beck Road, Bulverde, TX 78163 1-830-438-4830 www.rexblackconsulting.com

------------------------------

Date: Fri, 20 Apr 2007 15:41:47 -0700 (PDT)
From: Ross Oliver <ross599 () yahoo com>
Subject: Re: Risks of relying on systems to file taxes late

I am not a tax professional, but I think it is worth pointing out that the
April 15th (17th this year) date is the deadline to pay any income tax owed
without penalty.  If the government owes you a refund, there is no penalty
for filing a return after this date.  The IRS is more than happy to remain
caretaker of your money. I believe a widespread misunderstanding of the
deadline was contributing factor to the filing frenzy and resulting online
meltdown.  Perhaps Intuit should add this information to its "try again
later" messages.

------------------------------

Date: Fri, 20 Apr 2007 12:35:58 -0800
From: Rob Slade <rMslade () shaw ca>
Subject: REVIEW: "Information Security Awareness Basics", Fred Coheno

BKINSCAB.RVW   20070119

"Information Security Awareness Basics", Fred Cohen, 2006,
1-878109-39-1
%A   Fred Cohen
%C   572 Leona Dr, Livermore, CA   94550
%D   2006
%G   1-878109-39-1
%I   Fred Cohen and Associates
%O   U$24.00/C$27.97 925-454-0171 all.net
%O  http://www.amazon.com/exec/obidos/ASIN/1878109391/robsladesinterne
  http://www.amazon.co.uk/exec/obidos/ASIN/1878109391/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/1878109391/robsladesin03-20
%O   Audience n+ Tech 2 Writing 3 (see revfaq.htm for explanation)
%P   46 p.
%T   "Information Security Awareness Basics"

This booklet is written as an employee security awareness manual.  It can be
purchased and used as such (by a small business), or customized and
augmented by other materials (for a large enterprise).  (If you intend using
the primer "as is" for your employee manual, note that you should read it
first, and ensure that you do, in fact, provide the services, and have the
policies, that Cohen recommends.  This should not be onerous, as the
procedures outlined are quite reasonable, for any but the smallest
business.)

The content is well-written, readable and clear, and covers a number of
basic points that are often neglected (such as the importance of reading and
understanding the contract with the employer, and, by extension, the
employer's policies.)  (The topics are approximately one page in length, or
less, and are all, with one exception, on separate pages.)  A significant
portion of the early material is concerned with personal physical (rather
than information) security.  This is a very good arrangement, not only
because it demonstrates concern for the well-being of the employee, but also
since it starts with the more familiar (less esoteric) matters, and is a
good lead-in to the concepts of information security.

Well thought out, well written, and clear.  This is a useful item for those
who do not have the time to create their own security awareness materials,
and a model for those who do.

copyright Robert M. Slade, 2007   BKINSCAB.RVW   20070119
rslade () vcn bc ca     slade () victoria tc ca     rslade () computercrime org
http://victoria.tc.ca/techrev/rms.htm

------------------------------

Date: 2 Oct 2005 (LAST-MODIFIED)
From: RISKS-request () csl sri com
Subject: Abridged info on RISKS (comp.risks)

 The ACM RISKS Forum is a MODERATED digest, with Usenet equivalent comp.risks.
=> SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent)
 if possible and convenient for you.   The mailman web interface can
 be used directly to subscribe and unsubscribe:
   http://lists.csl.sri.com/mailman/listinfo/risks
 Alternatively, to subscribe or unsubscribe via e-mail to mailman your
 FROM: address, send a message to
   risks-request () csl sri com
 containing only the one-word text subscribe or unsubscribe.  You may
 also specify a different receiving address: subscribe address= ... .
 You may short-circuit that process by sending directly to either
   risks-subscribe () csl sri com or risks-unsubscribe () csl sri com
 depending on which action is to be taken.

 Subscription and unsubscription requests require that you reply to a
 confirmation message sent to the subscribing mail address.  Instructions
 are included in the confirmation message.  Each issue of RISKS that you
 receive contains information on how to post, unsubscribe, etc.

=> The complete INFO file (submissions, default disclaimers, archive sites,
 copyright policy, etc.) is online.
   <http://www.CSL.sri.com/risksinfo.html>
 The full info file may appear now and then in RISKS issues.
 *** Contributors are assumed to have read the full info file for guidelines.

=> .UK users should contact <Lindsay.Marshall () newcastle ac uk>.
=> SPAM challenge-responses will not be honored.  Instead, use an alternative
 address from which you NEVER send mail!
=> SUBMISSIONS: to risks () CSL sri com with meaningful SUBJECT: line.
 *** NOTE: 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: ftp://ftp.sri.com/risks for current volume
     or ftp://ftp.sri.com/VL/risks for previous VoLume
 <http://www.risks.org> redirects you to Lindsay Marshall's Newcastle archive
 http://catless.ncl.ac.uk/Risks/VL.IS.html gets you 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/> .
==> 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 24.65
************************