RISKS-LIST: Risks-Forum Digest Sunday 10 December 2006 Volume 24 : Issue 49
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.49.html>
The current issue can be found at
<http://www.csl.sri.com/users/risko/risks.txt>
Contents:
Health Hazard: Computers Spilling Your History (Milt Freudenheim and
Robert Pear via Monty Solomon)
Re: Mascalls, Manchester, what's the difference? (Chris D.)
The risks of relying on Online Directions: Death? (Paul Ferguson)
Re: Yet another canceled public sector IT project (Richard Karpinski)
Trig routine risk: an oldie (Doug McIlroy)
Vulnerability in Microsoft Word Could Allow Remote Code Execution
(Monty Solomon)
Risks of driving a car that uses plastic parts in critical areas
(Kent Hartfield)
Research based on RISKS forum data at UBC, Canada (Hafiz Abdur Rahman)
Computers, Freedom, and Privacy, CFP 2007 (Stephanie Perrin)
REVIEW: "Incident Response", E. Eugene Schultz/Russell Shumway (Rob Slade)
REVIEW: Sarbanes-Oxley IT Compliance Using COBIT and Open Source Tools
(Rob Slade)
REVIEW: "Kim", Rudyard Kipling (Rob Slade)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Sat, 2 Dec 2006 21:14:22 -0500
From: Monty Solomon <monty@private>
Subject: Health Hazard: Computers Spilling Your History
Bill Clinton's identity was hidden behind a false name when he went to
NewYork-Presbyterian Hospital two years ago for heart surgery, but that
didn't stop computer hackers, including people working at the hospital, from
trying to get a peek at the electronic records of his medical charts.
The same hospital thwarted 1,500 unauthorized attempts by its own employees
to look at the patient records of a famous local athlete, said J. David
Liss, a vice president at NewYork-Presbyterian.
And just last September, the New York City public hospital system said that
dozens of workers at one of its Brooklyn medical centers, including doctors
and nurses, technicians and clerks, had improperly looked at the
computerized medical records of Nixzmary Brown, a 7-year-old who prosecutors
say was beaten to death by her stepfather last winter.
Powerful forces are lobbying hard for government and private programs that
could push the nation's costly and inefficient health care system into the
computer age. President Bush strongly favors more use of health information
technology. Health insurance and medical device companies are eager
supporters, not to mention technology companies like I.B.M. and
Google. Furthermore, Intel and Wal-Mart Stores have both said they intend to
announce plans this week to embrace electronic health records for their
employees. ...
[Source: Health Hazard: Computers Spilling Your History, by Milt Freudenheim
and Robert Pear, *The New York Times*, 3 Dec 2006]
http://www.nytimes.com/2006/12/03/business/yourmoney/03health.html?ex=1322802000&en=b2c0f7946b4e3d9d&ei=5090
------------------------------
Date: Sat, 09 Dec 2006 22:54:07 +0000
From: "Chris D." <e767pmk@private>
Subject: Re: Mascalls, Manchester, what's the difference? (Brader, R-24.48)
> says that the system showed their destination's address as being in
> Brentwood in Manchester instead of Brentwood in West London.
Looks like another navigational error -- the correct destination was
Brentwood, Essex, about 25 miles/40km north-east of downtown London;
BrentFORD is the suburb in west London. Probably fortunate that the
ambulance wasn't headed for Edmonton, north London, or they may have ended
up in Alberta! The UK has plenty of traps like this, such as St Ives,
Cornwall, being about 270 miles/430km from St Ives, Cambridgeshire. Then
there are Tunbridge Wells and Tonbridge, only 5 miles/8km apart but
different towns, and not far from Leeds Castle, which is nowhere near the
city of Leeds, Yorkshire. Of course localities may have a colloquial name
not shown on maps as well.
This sort of thing makes for amusing news items, but it can have serious
consequences. It reminded me of reported problems with a computer-based
despatching system for ambulances in London some years ago, and a quick
Google search came up with RISKS-14.48, which included this item:
> London Ambulance Service Inquiry Report (long)
> <Brian.Randell@private>
> a) a need for near perfect input information in an imperfect world;
As I understand it, part of the problem was ambiguous or imprecise locations
given for incidents; in an emergency situation, callers may just yell out
the name of the nearest landmark, or their own name for an area, which may
well not match the computer's database.
Also this week (7 Dec) came the story of the Kim family who were stranded on
remote Bear Camp Road in Oregon, possibly after using an on- line map which
did not show the road as unsuitable for winter use, unlike some other paper
and on-line maps. Temptation is to blame the map compilers for inadequate
warnings.
As ever, looks like the way to minimise RISKS when traveling in unfamiliar
areas is to get hold of as much information as you can from different
sources first, and run a sanity check before you start (what sort of
distance/time/hazards are involved?).
Cheers, Chris Drewe, not far from Brentwood, Essex County, UK.
------------------------------
Date: Thu, 7 Dec 2006 06:56:15 GMT
From: "Fergie" <fergdawg@private>
Subject: The risks of relying on Online Directions: Death?
This is a very, very tragic story, which perhaps could have been compounded
by the possibility that the Kim family may have indeed relied upon bogus
online directions in the travels in Oregon over the Thanksgiving Day
holidays.
http://fergdawg.blogspot.com/2006/12/some-disturbing-news-online-directions.html
Thanks to Jon. O. for pointing this out.
Our hearts go out to Katie Kim and her family.
"Fergie", a.k.a. Paul Ferguson, Engineering Architecture for the Internet
fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
------------------------------
Date: Wed, 22 Nov 2006 22:04:21 -0800
From: Richard Karpinski <dick@private>
Subject: Re: Yet another canceled public sector IT project (Thomas, R-24.47)
> 11m pounds wasted because no-one did a decent requirements analysis?
This is one tiny aspect of a clearly major problem. The high fraction of
huge IT projects which get canceled, often after the entire budget has been
spent, is an outrageous failing of the entire IT industry. In fact a
significant cause is our time honored approach to requirements analysis.
We expect to get the entire set of requirements fixed before the multi year
contract is signed. This is absurd. One does not head from St. Louis to New
Orleans on the Mississippi River by pointing the boat in the right direction
and tying the rudder. Instead we make constant course corrections to stay in
the navigable parts of the river.
See instead how Tom Gilb approaches such problems in his book, "Competitive
Engineering".
What we should be addressing is delivering value to (all) the
stakeholders. We need to determine the purposes the system is intended to
serve and establish some ten or twelve critical and measurable goals. Then
we engineer a general approach and find and evaluate a modest set of
improvements to address those goals. Finally we pick the lowest cost,
highest value phases to implement and test next. Rinse and repeat. Each such
phase should be constrained to consume at most a few percent of the project
resources before it is delivered to end users (or their proxies) for testing
and evaluation.
The conventional requirements analysis delivers a shopping list of more than
a hundred specific functions for the system. Each function is something that
someone thought was a good idea and others signed off without very much
analysis and without measurable quality objectives. This results in systems
where a large fraction of the required functions, typically thirty to fifty
percent, never even get used. What a waste.
With the requirements all fixed in advance, there is no opportunity to
accommodate the inevitable changes in the world or even to learn from the
early efforts in building the system. Experienced project managers learn to
control the requests for changes to the specifications by establishing
committees to impede their acceptance. Such requirements changes are seen
as annoyances instead of being welcomed as course corrections which will
yield a more useful and valuable final system.
Gilb calls his approach evolutionary delivery, but I prefer to call it
extreme incrementalism. In addition to completely eliminating these
horrendous massive failures, the method even eliminates the incredible debt
burden imposed by denying the users any access to the benefits of the
intended system until the completion of the entire years long project. What
foolishness.
Of course, contractors with experience will claim that their project cannot
be done in such tiny pieces. They are wrong, but then they see no need to
change their ways since they get paid even for systems which are canceled
before they are finished or worse, get completed and then abandoned.
The better incremental methods are proven by repeated successes which you
can discover at gilb.com and malotaux.nl or by contacting the companies
which have adopted their approach in the last thirty some years. Despite
these successes, the evolutionary method is still considered radical and
risky by almost everyone who has not studied under the masters who developed
it and actually applied it to their own projects.
Without such radical changes to the way things are done in IT, we can
guarantee that RISKS will never run out of such disaster stories.
Richard Karpinski, World Class Nitpicker 707-546-6760 dick@private
NOTE: "nitpicker" in the subject line gets past my spam filters.
------------------------------
Date: Sat, 9 Dec 2006 11:14:18 -0500
From: Doug McIlroy <doug@private>
Subject: Trig routine risk: an oldie
Sometime around 1961, a customer of the Bell Labs computing center
questioned a value returned by the sine routine. The cause was simple: a
card had dropped out of the assembly language source. Bob Morris pinned
down the exact date by checking the dutifully filed reversions tests for
system builds. Each time test values of the sine routine (and the rest of
the library) had been printed out. Essentially the acceptance criterion was
that the printout was the right thickness; the important point was that the
tests ran to conclusion, not that they gave right answers. The trouble
persisted through several deployed generations of the system.
BTW, I may have committed a sin 'cos I wrote "reversion" instead of
"regression", but neither word was current then -- so I seek not remission
for going off on a tangent.
[This clearly needed an overseeing SineCure. Arc the hair-old
angles swing. PGN]
------------------------------
Date: Wed, 6 Dec 2006 08:38:11 -0500
From: Monty Solomon <monty@private>
Subject: Vulnerability in Microsoft Word Could Allow Remote Code Execution
Microsoft Security Advisory (929433), 5 Dec 2006
Microsoft is investigating a new report of limited "zero-day" attacks
using a vulnerability in Microsoft Word 2000, Microsoft Word 2002,
Microsoft Office Word 2003, Microsoft Word Viewer 2003, Microsoft
Word 2004 for Mac, and Microsoft Word 2004 v. X for Mac, as well as
Microsoft Works 2004, 2005, and 2006.
In order for this attack to be carried out, a user must first open a
malicious Word file attached to an e-mail or otherwise provided to
them by an attacker.
As a best practice, users should always exercise extreme caution when
opening unsolicited attachments from both known and unknown sources. ...
http://www.microsoft.com/technet/security/advisory/929433.mspx
------------------------------
Date: Fri, 08 Dec 2006 07:55:59 -0600
From: "Hartfield, Kent" <kent.hartfield@private>
Subject: Risks of driving a car that uses plastic parts in critical areas
I drive a 1990 Honda Accord that was purchased used 8 years ago. It's had
it's share of minor failures and repairs but has overall been a great car.
Yesterday, and at first unknown to me, it had a whopper of a failure.
On my way to work a little plastic doohickey that spans the gap between the
brake pedal and the brake light switch disintegrated and fell to the
floorboard. In normal operation the switch is open when the brake pedal
presses against it through the plastic doohickey. When the brake pedal is
pressed, it moves away from the switch and that movement causes the switch
to close, thus activating the brake lights.
So, unbeknownst to me (and I truly dislike being in a state of unbeknowing)
the brake lights were in a state of constant on. And furthermore, deepening
my state of unbeknowing, the brake lights will operate when the key is not
in the ignition. And so they did when I parked my car at my wonderful place
of employment, as I was also in a state of inobservance and there were no
bells in the car to ring for this particular occurrence as there are for
unbuckled seatbelts, as well as headlight switch and key in ignition
oversights.
At the end of the workday I was relieved of my state of unbeknowing when I
approached my car and saw what I thought were tail lights illuminated on the
car, signaling apparent stupidity to all who wandered by that day. As I saw
the headlights were not on, my state became one of confusion and then of
dismay as I tested the ignition and found I would have to beg a jump from a
fellow, but smirking, engineer (as I would smirk myself, no doubt, had the
situation been reversed).
That being done and the car being made to run, on the long ride home I
puzzled out that it must be the brake lights that had remained on and not
the tail lights. So now I suffer the indignity of appearing to ride the
brakes, as though I need two feet to accomplish a chore when one foot will
do quite nicely. When home I performed the investigation that revealed the
defective part and immediately replaced it with a metal doohickey of similar
design and exact function.
So a plastic piece breaks on my car and causes the battery to run down?
Who'd a thunk of such a risk?
Kent Hartfield, Electro Optic Engineering,
Lockheed Martin Missiles and Fire Control
------------------------------
Date: Sat, 9 Dec 2006 05:50:48 -0800
From: "Hafiz Abdur Rahman" <rahmanha@private>
Subject: Research based on RISKS forum data at UBC, Canada
We have conducted a study on origin of critical infrastructure failures
using 12 years (1994-2005) of RISKS forum data. In this study, we tried to
find the causes of critical infrastructure failures and their impacts in
different dimensions, such as origin of failures, impacts of failures in
spatial and temporal dimensions, their effect on public safety; and how
failures propagate from one infrastructure to another. The results obtained
from the analysis of real life failure cases, which happened over a
considerable time span, should be interesting and useful for RISKS forum
readers. Findings of this study have been documented in the following paper:
H. A. Rahman, K. Beznosov, J. R. Marti', "Identification of Sources of
Failures and their Propagation in Critical Infrastructures from 12 Years of
Public Failure Reports", CRIS, Third International Conference on Critical
Infrastructures, Alexandria, VA, September 2006. This can be found from the
following link:
http://www.ece.ubc.ca/~rahmanha/cris2006_CS2_paper.pdf
This paper has been selected for publication in the International Journal of
Critical Infrastructures. We are presently working on the journal
version. We welcome your suggestions/comments about possible improvements
(focused more on theoretical aspects). Please send your comments to Hafiz
Abdur Rahman <rahmanha@private> before January 15, 2007.
Hafiz Abdur Rahman, PhD Student, ECE, University of British Columbia, Canada
Room # 3085 Kaiser Building, Vancouver, B.C. Canada V6T 1Z4 1-604-822-2552
------------------------------
Date: Fri, 8 Dec 2006 17:50:38 -0500
From: "Stephanie Perrin" <sperrin@private>
Subject: Computers, Freedom, and Privacy, CFP 2007
The Seventeenth Computers, Freedom, and Privacy CFP 2007
will take place in Montreal CANADA, 1-4 May 2007.
Proposals are due 20 Jan 2007.
See the website for details:
http://www.cfp2007.org
[Stephanie is the Chair this year. I've been to about half of the past
CFPs, and it is usually a very thought-provoking meeting, with many
RISKS-related issues typically on the program. PGN]
------------------------------
Date: Fri, 17 Nov 2006 15:21:49 -0800
From: Rob Slade <rmslade@private>
Subject: REVIEW: "Incident Response", E. Eugene Schultz/Russell Shumway
BKIRSGHS.RVW 20060906
"Incident Response", E. Eugene Schultz/Russell Shumway, 2002,
1-57870-256-9, U$39.99/C$59.95/UK#30.99
%A E. Eugene Schultz
%A Russell Shumway
%C 201 W. 103rd Street, Indianapolis, IN 46290
%D 2002
%G 1-57870-256-9
%I Macmillan Computer Publishing (MCP)/New Riders
%O U$39.99/C$59.95/UK#30.99 800-858-7674 317-581-3743 info@private
%O http://www.amazon.com/exec/obidos/ASIN/1578702569/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/1578702569/robsladesinte-21
%O http://www.amazon.ca/exec/obidos/ASIN/1578702569/robsladesin03-20
%O Audience i- Tech 2 Writing 1 (see revfaq.htm for explanation)
%P 384 p.
%T "Incident Response: A Strategic Guide to Handling System and
Network Security Breaches"
Beyond saying that security breaches occur, and that we need to respond to
them, the introduction doesn't tell us much about either the topic or the
book.
Chapter one contains a good deal of material with which security
professionals will agree, but it does not provide helpful guidance. The
attempt to define "incidents" is not wrong in any particular, but is
tautological and of limited utility. "Risk Analysis," in chapter two,
briefly repeats the usual procedures, but expends most of its text in
details of specific (mostly network) system attacks. A suggested
methodology for incident response is provided in chapter three, along with a
justification for the use of a formal process. (Many may find it ironic
that much of the rationale for formal methods has to do with expecting the
unexpected.) (The process is given in the acronym PDCERF; which stands for
preparation, detection, containment, eradication, recovery, and followup;
but the text, rather unsettlingly, presents a number of variations on the
acronym throughout the chapter.) Chapter four deals with forming and
managing an incident response team, and the content is mostly concerned with
communications, corporate culture, and management. This material is
extended in chapter five, which covers other factors involved with
organizing for incident response.
Chapter six turns to a slightly more technical topic, regarding the tracing
of network attacks. This is an overview, with only limited technical
content, but even so a few items are suspect (such as the implication that
MAC [Media Access Control] addresses are permanent and fixed). Legal issues
related to incident response are reviewed in chapter seven. Chapters eight
and nine provide an overview of computer forensics, as well as good advice
on the handling and management of evidence, but at a conceptual, rather than
technical, level. Insider attacks are difficult to determine and protect
against, and chapter ten tacitly admits this by spending a lot of time just
telling stories. Chapter eleven (written by an outside author) examines
criminal profiling and other incident response factors related to social
sciences. Honeypots and other types of deception aimed at the attacker are
the subject of chapter twelve. Chapter thirteen finishes off with a look at
emerging tools and directions.
While still flawed, this work is probably more practical than Mandia and
Procise's law enforcement oriented volume (cf. BKINCDRS.RVW), van Wyk and
Forna's somewhat less detailed work (cf. BKINCRES.RVW), or Schweitzer's
basic and wordy tome (cf. BKINCRSP.RVW) (all, of course, are entitled
"Incident Response").
copyright Robert M. Slade, 2006 BKIRSGHS.RVW 20060906
rslade@private slade@private rslade@private
http://victoria.tc.ca/techrev/rms.htm
------------------------------
Date: Wed, 29 Nov 2006 21:07:16 -0800
From: Rob Slade <rMslade@private>
Subject: REVIEW: Sarbanes-Oxley IT Compliance Using COBIT and Open Source Tools
Christian B. Lahti/Roderick Peterson
BKSOITCU.RVW 20061013
"Sarbanes-Oxley IT Compliance Using COBIT and Open Source Tools",
Christian B. Lahti/Roderick Peterson, 2005, 1-59749-036-9,
U$49.95/C$69.95
%A Christian B. Lahti
%A Roderick Peterson
%C 800 Hingham Street, Rockland, MA 02370
%D 2005
%G 1-59749-036-9
%I Syngress Media, Inc.
%O U$49.95/C$69.95 781-681-5151 fax: 781-681-3585 www.syngress.com
%O http://www.amazon.com/exec/obidos/ASIN/1597490369/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/1597490369/robsladesinte-21
%O http://www.amazon.ca/exec/obidos/ASIN/1597490369/robsladesin03-20
%O Audience a- Tech 1 Writing 1 (see revfaq.htm for explanation)
%P 333 p. + CD-ROM
%T "Sarbanes-Oxley IT Compliance Using COBIT and Open Source Tools"
"This book is essentially a technical book, with as much applicable content
as we could muster by way of open source technologies and how they fit into
the Sarbanes-Oxley sphere of influence." Thus speaketh the authors in
chapter one (page 4), giving us, almost immediately, fair warning that there
may be problems in this book. For one thing, the Sarbanes-Oxley (SOX) law
is *not* technical (if it were, the drafters would have known not to give
the central point related to information technology section number 404).
The authors seem to be intent on listing off all manner of open source
programs, using the magic title of SOX to add legitimacy to an otherwise
aimless catalogue. (The use of vague buzzwords is also supposed to increase
the perceived erudition of the work, although the authors seem to stumble
occasionally, such as when they confuse the French "voila" with the musical
"viola" on page 5.) If the authors were truly to answer some of the
questions that they pose (for example, is open source software compliant
with the law, and can it reduce the costs of achieving and monitoring
compliance) then the text might have some utility. However, there is no
introduction to the legislation as such, and the list of roles within an
organization has little specific relevance to the issues underlying the
analysis, integrity, and reporting of financial data. Most of the space in
the initial chapter is devoted to screenshots of Knoppix, a poorly explained
installation section, and a list of the programs in the eGroupware
application.
SOX and COBIT are supposed to be defined in chapter two. SOX gets almost no
exegesis, while there is a list of some of the COBIT objectives. Chapter
three lists various open source security tools, has some random notes on
policy and auditing, and a "sample" policy on password change. The usual
promotional piece for open source software makes up chapter four, with the
standard arguments for using open source, but no new rationale for the
application to this particular topic.
Chapters five through eight are based on four domains from COBIT (loosely
based on the Deming plan-do-check-act cycle). In sequence, we have planning
and organization, acquisition and implementation, delivery and support, and
monitoring. Each of the chapters has a section entitled "What does [name of
domain] mean?" but these questions are not answered in any useful way. Each
chapter has an extensive (but not comprehensive) list of tasks that might be
undertaken, and each delves deeply into the technical minutia of one or more
isolated topics.
Chapter nine finishes off with miscellaneous advice in random areas.
If you have no experience with security, and are scared stiff of even
approaching SOX, this book may get you working on some areas that will
probably be useful. Mind you, if you don't get information from other
sources, you may find that there are gaps in your security that you never
considered. If you are experienced in security, and want to know about SOX
or COBIT, and what you should do about them, you will be very disappointed
with what you find in this text. If you want to know about open source
security tools, you will be even more frustrated.
(Having a Knoppix boot CD around might be handy, if you know how to use it.)
copyright Robert M. Slade, 2006 BKSOITCU.RVW 20061013
rslade@private slade@private rslade@private
http://victoria.tc.ca/techrev/rms.htm
------------------------------
Date: Fri, 08 Dec 2006 09:25:34 -0800
From: Rob Slade <rMslade@private>
Subject: REVIEW: "Kim", Rudyard Kipling
BKKIM.RVW 20061124
"Kim", Rudyard Kipling, 1901, 0-812-56575-4
%A Rudyard Kipling
%C 49 West 24th Street, or 175 Fifth Avenue, New York, NY 10010
%D 1901 (no, it isn't a Y2K joke)
%G 0-812-56575-4
%I Tor Books/Tom Doherty Assoc.
%O pnh@private www.tor.com
%O http://www.amazon.com/exec/obidos/ASIN/0812565754/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/0812565754/robsladesinte-21
%O http://www.amazon.ca/exec/obidos/ASIN/0812565754/robsladesin03-20
%O Audience n+ Tech 3 Writing 3 (see revfaq.htm for explanation)
%P 307 p.
%T "Kim"
Kipling packed a great deal of information and concept into his stories, and
in "Kim" we find The Great Game: espionage and spying. Within the first
twenty pages we have authentication by something you have, denial of
service, impersonation, stealth, masquerade, role- based authorization (with
ad hoc authentication by something you know), eavesdropping, and trust based
on data integrity. Later on we get contingency planning against theft and
cryptography with key changes.
Beyond all this, and repeatedly throughout the story, we have social
engineering: misdirection, analysis of situations and characters, the
maneuvering and manipulating of people so that they do what you want, all
the while thinking that it was their idea. The explanation given is at once
subtle and lucid, and is both more useful and much more entertaining than
that given by Mitnick in "The Art of Deception" (cf. BKARTDCP.RVW).
Kipling is, perhaps, too gentle a writer for the thriller genre. He is,
though, a better wordsmith than most of those who work in that idiom. His
command of dialogue is unparalleled: in "Kim" there is no need to identify
the individual speakers, for they are as instantly distinguished in the text
as they would be by speech.
I heartily recommend "Kim" to anyone in the security field, or anyone
who wants a decent read.
copyright Robert M. Slade, 2006 BKKIM.RVW 20061124
rslade@private slade@private rslade@private
http://victoria.tc.ca/techrev/rms.htm
------------------------------
Date: 2 Oct 2005 (LAST-MODIFIED)
From: RISKS-request@private
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@private
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@private or risks-unsubscribe@private
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@private>.
=> SPAM challenge-responses will not be honored. Instead, use an alternative
address from which you NEVER send mail!
=> SUBMISSIONS: to risks@private 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 [subdirectory i for earlier volume i]
<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.49
************************
This archive was generated by hypermail 2.1.3 : Sun Dec 10 2006 - 11:59:44 PST