RISKS-LIST: Risks-Forum Digest Tuesday 5 December 2006 Volume 24 : Issue 48
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.48.html>
The current issue can be found at
<http://www.csl.sri.com/users/risko/risks.txt>
Contents:
Still more on the European power outage (PGN)
Another power outage brings down German TV station (Debora Weber-Wulff)
The UK NHS IT plan (Brian Randell)
Rebooting airplanes (Douglas W. Jones)
Mascalls, Manchester, what's the difference? (Mark Brader)
Three guilty of identity fraud which netted millions (Brian Randell)
Identity theft made easy (John Haselsberger)
Federal Reserve E-Banking System Outages: Brian Krebs (PGN)
How To Tell If Your Cell Phone Is Bugged (Lauren Weinstein)
Firefox flaw causes engagement to break off (Mark Lutton)
Critical Firefox hole allows password theft (Monty Solomon)
REVIEW: "Phishing: Cutting the Identity Theft Line", Liniger/Vines (Rob Slade)
REVIEW: "The Security Risk Assessment Handbook", Douglas J. Landoll (Rob Slade)
Abridged info on RISKS (comp.risks)
----------------------------------------------------------------------
Date: Mon, 4 Dec 2006 14:16:53 PST
From: "Peter G. Neumann" <neumann@private>
Subject: Still more on the European power outage
More details have emerged on the EON Austria-to-Spain power outage since in
RISKS-24.47 (which erroneously stated rather absurdly that 82 million
Germans were affected, instead of the previously noted 10 million
Europeans).
Axel Eble cited the original German text of the E.ON Netz report:
http://www.eon-energie.com/php/pressemitteilungen/download.php?id=49602
Jaap Akkerhuis <jaap@private> cited the E.ON report in English:
http://www.eon-energie.com/php/pressemitteilungen/download.php?id=54598
The upshot is that the initial calculations for the planned shutdown showed
the link over the Ems River could be compensated for by rerouting
alternative power. The so-called "N-1 criterion" for stability was
correctly applied initially, but not reapplied after the reconfiguration.
Thus, the second-order effects of the shutdown were ignored -- namely the
increased loads that would result from the rerouting -- and the Norwegian
Pearl was allowed to pass.
>From the English language version of the report (which explicitly notes that
the German version shall prevail in case of any discrepancies), the summary
states that "the determination of demands that can actually be met and which
the market participants demand of the grid must be continuously be reviewed
in a close dialogue between grid operators, grid customers, regulating
authorities and political forces." [*]
Continuing from the summary, "Finally, it also remains to be stated that the
concrete incident has no connection with issues of grid investments. It
must, however, be clearly stated that the growing demands on the grid can
only be met -- in the long run -- by a corresponding expansion of the grids."
Once again, we are confronted with the risks of short-term/global
optimization.
[* NOTE: As a rather PGN-ish aside, Webster maintains that a "dialogue" can
be BETWEEN N entities, where N may be two or more. However, when I learned
English, it was customary to make a distinction between "between" and
"among" (for N=2 and N>2, respectively). This seems to have fallen by the
wayside over time. On the other hand, German uses one word ("zwischen") to
cover both, as do French/Spanish ("entre") and Russian ("myeshdu"). At any
rate, the concept of a CLOSE DIALOGUE BETWEEN (or even AMONG) N entities
seems suspect when N is considerably greater than 2, as it is in the
European community, and when communication is inherently NOT CLOSE. I think
that the choice of the German text ("im engen Dialog von ...") is itself
misleading, and that the English translation could have been more accurately
rendered as "in close multipartite communication among ...". Why do I
engage in such semantic blather? Because the lack of CLOSER COMMUNICATION
is often a serious source of risks in many RISKS episodes, and Conway's Law
and generalization thereof keep resurfacing as representative of fundamental
problems that arise from restricted communications. (Wikipedia has a nice
discussion of Conway's Law, which relates difficulties in communication
specifically to corresponding flaws in software developments. However,
certainly someone must have cited its obvious generalization to other types
of systems. Surprisingly, I don't think I've mentioned Conway's Law
previously in RISKS, although I have been referring to it explicitly and in
its generalized forms for many years. Melvin, not John.) PGN]
------------------------------
Date: Sun, 26 Nov 2006 18:31:56 +0100
From: Debora Weber-Wulff <D.Weber-Wulff@fhtw-berlin.de>
Subject: Another power outage brings down German TV station
Sunday morning, Nov. 26, 2006 there was a power outage in Hamburg-Lokstedt,
where the German TV station NDR has its headquarters.
This time it was Vattenfall, not EON that was responsible for the power-out.
Both the regular medium voltage and the emergency power system
were knocked out. It took about 90 minutes for broadcasting
to be completely resumed.
http://www.netzeitung.de/medien/455451.html with links to other reports
This is the second time in one week that a TV station has dropped out of the
ether, last week both Hamburg 1 and ZDF were offline after a power outage in
Hamburg-Rothenbaum.
NDR itself explains at
http://www1.ndr.de/ndr_pages_std/0,2570,OID3392462,00.html that it was not
actually a power outage. Ivo Banek, a speaker for Vattenfall, said that
there were numerous short-circuits in the 50 km long cable in Lokstedt. It
happened in the span of a few milliseconds, and normal electrical customers
will not have noticed anything. This brought down the electricity for the TV
station, however, and a ground fault brought the emergency power system to
its knees.
It is still not clear what caused the shorts.
Prof. Dr. Debora Weber-Wulff, FHTW Berlin, Internationale Medieninformatik,
10313 Berlin http://www.f4.fhtw-berlin.de/people/weberwu/ +49-30-5019-2320
------------------------------
Date: Tue, 5 Dec 2006 11:37:00 +0000
From: Brian Randell <Brian.Randell@private>
Subject: The UK NHS IT plan
MPs will hold an inquiry into 12-billion-pound NHS IT plan after some MPs
expressed concerns that the scheme may be foundering. The decision reverses
a resolution taken by the parliamentary committee only weeks ago not to hold
an inquiry, and vindicates a campaign led by leading academics. [Source:
Tony Collins, *Computer Weekly*, 28 Nov 2006; PGN-ed]
http://www.computerweekly.com/Articles/2006/11/28/220206/mps-will-hold-inquiry-into-12bn-nhs-it-plan.htm
[Brian has been involved in this campaign to get an inquiry held into the
problems arising in connection with the National Health Service National
Programme for IT ("NPfIT", which strangely reminds me of Tom Lehrer's
Boston subway song punchline -- "HCKC-PW"). He is pleased to report that
they have had some success. PGN]
[Brian also reports that the public dossier (http://nhs-it.info/) that
he edits on this subject continues to grow. This is an extraordinarily
good analysis, and well worth reading. The RISKS-related lessons are
profound, although unfortunately not unusual. PGN]
------------------------------
Date: Tue, 28 Nov 2006 13:29:42 -0600
From: "Douglas W. Jones" <jones@private>
Subject: Rebooting airplanes
In the last few weeks, I've done quite a bit of flying, and twice, now, I've
been on planes where they had to reboot.
The first trip where this happened, as we were scheduled to leave the gate,
there was a delay, and then the pilot said over the intercom: "We're having
trouble with some of the cockpit instruments, so I'm going to force a hard
reboot by switching off all the power for a bit." The lights and all other
power on the plane then went off, and after a fifteen second pause, on
again. A minute later, the pilot said: "That seems to have fixed the
problem," and we were off.
I wasn't impressed. As far as I am concerned, this is clear evidence of a
genuine design error somewhere in the system.
The second problem happened on Sunday, on a flight back from Amsterdam. On
that flight, they had serious problems with the in-flight video on demand
system. They tried a "soft reboot" of some kind, and it didn't work, so
they then tried two "hard reboots," their term, and after the second try, it
worked fine. Their instructions were "until the system comes all the way
up, please don't touch any buttons." That alone suggests poor design. The
system ought to come up with interrupts disabled on any devices that it's
not ready to listen to, after all.
The reboot process took close to half an hour, and watching the displays in
the seat backs that were visible from my seat, I could see that they were
being rebooted in sequence, about one per second. Furthermore, as each
in-seat display was rebooted, it showed the Linux penguin and then a Linux
boot script, revealing that each seat-back display was a little Linux
system, suggesting that they were all networked to a video server for the
plane.
Again, the need for these global reboots is strong evidence that the systems
were not well designed,
I wonder if both of these stories illustrate problems with the kinds of
graduates we are turning out these days. CS programs across the country are
emphasizing high-level courses in web programming, but fewer and fewer
students know anything about the fundamentals of parallel programming that
underly things. So, in constructing the kinds of distributed applications
that show up in contexts like streaming video and cockpit instrumentation,
they are working without the theoretical underpinnings needed to understand
the problems they encounter.
------------------------------
Date: Sat, 2 Dec 2006 04:36:21 -0500 (EST)
From: msb@private (Mark Brader)
Subject: Mascalls, Manchester, what's the difference?
A British ambulance crew, transferring a patient to a hospital where they
had never gone before, drove 200 miles out of their way before realizing
that their satellite navigation device had given them the wrong directions.
These reports
http://www.timesonline.co.uk/article/0,,2-2482605,00.html
http://www.dailymail.co.uk/pages/live/articles/news/news.html?in_article_id=419836&in_page_id=1770
mention other incidents of sat-nav gaffes, but don't say what the actual
error was this time; this shorter one
http://www.thesun.co.uk/article/0,,2-2006551015,00.html
says that the system showed their destination's address as being in
Brentwood in Manchester instead of Brentwood in West London.
The patient was not harmed, and the crew has been told they should have
known better.
Mark Brader, Toronto, msb@private
------------------------------
Date: Fri, 1 Dec 2006 15:37:45 +0000
From: Brian Randell <Brian.Randell@private>
Subject: Three guilty of identity fraud which netted millions
On the eve of "Black Thursday", the Russian banks' liquidity crisis of
August 1995, Anton Dolgov, the head of the Moskovsky Gorodskoi Bank,
disappeared leaving debts of around $100m. Since then he had been hiding
under many aliases. On 30 Nov 2006, he appeared in a London court,
reportedly the head of an international identity theft gang that had
defrauded thousands of account holders out of millions of pounds over a
period of 10 years, using compromised credit cards, false documents, and a
bogus law firm. Dolgov pleaded guilty to four conspiracy charges.
[Source: David Pallister, 1 Dec 2006, *The Guardian* (UK); PGN-ed]
http://www.guardian.co.uk/crime/article/0,,1961441,00.html
School of Computing Science, Newcastle University, Newcastle upon Tyne,
NE1 7RU, UK http://www.cs.ncl.ac.uk/~brian.randell/ +44 191 222 7923
------------------------------
Date: Sun, 29 Oct 2006 09:26:34 -0500
From: John Haselsberger <jhasels99@private>
Subject: Identity theft made easy
My large eastern bank abandoning the vendor servicing their Visa credit
cards and bringing the task in-house. They sent out forms which we must fill
out and sign in order to accept this situation. The top of the form says
"For your Visa card ending in 9999". The form has out name and address and
an "acceptance code" pre printed. Yet they ask for the end user to manually
fill in: SSN, date of birth, mothers maiden name, and home phone, plus they
want you to enter your existing (still valid) credit card number!!!! So on
one small piece of paper, they create the perfect identity-theft kit, with
information they already have on file. While one piece of information might
be necessary for me to prove who I am to accept this offer, I am sure their
fraud department will be busier than need be in the near future.
------------------------------
Date: Sun, 3 Dec 2006 09:44:18 PST
From: "Peter G. Neumann" <neumann@private>
Subject: Federal Reserve E-Banking System Outages: Brian Krebs
A system widely used by U.S. banks to process large volumes of payroll,
credit and debit card transactions experienced intermittent outages on 27-28
Nov 2006, possibly due to some sort of malfunction or communications failure
in portions of the Federal Reserve's "automated clearing house" (ACH)
network, according to Security Fix -- which received an anonymous tip from
an individual who claimed to work at a mid-sized bank that experienced
trouble transferring ACH files across the Fed's network. [Source: Brian
Krebs on Computer Security, *The Washington Post*, 28 Nov 2006; PGN-ed with
thanks to Jim Horning for spotting Brian's blog, which gives further details.]
http://blog.washingtonpost.com/securityfix/2006/11/federal_reserve_ebanking_syste.html
------------------------------
Date: Tue, 5 Dec 2006 12:15:54 -0800 (PST)
From: Lauren Weinstein <lauren@private>
Subject: How To Tell If Your Cell Phone Is Bugged
Greetings. A story is making the rounds right now regarding FBI use of cell
phones as remote bugs (e.g. http://news.com.com/2100-1029-6140191.html). I
originally wrote about this concept in my PRIVACY Forum in 1999 ("Cell
Phones Become Instant Bugs!" - http://www.vortex.com/privacy/priv.08.11) so
the issue is real, but we still need to bring the current saga back down to
earth.
This discussion doesn't only relate to "legal" bugs but also to the use of
such techniques by illegal clandestine operations, and applies to physically
unmodified cell phone hardware (not phones that might have had separate,
specialized bugs physically installed within them by third parties) ...
[ Full article at: http://lauren.vortex.com/archive/000202.html ]
------------------------------
Date: Fri, 1 Dec 2006 12:54:32 -0500
From: <Mark.Lutton@private>
Subject: Firefox flaw causes engagement to break off
You can read the whole thing here:
https://bugzilla.mozilla.org/show_bug.cgi?id=330884
In a nutshell, the password manager can save or not save passwords for
individual sites. He secretly visited many dating sites and wisely
selected "don't save password." She happened to see the list of "don't save
password" sites in the configuration. They are no longer engaged.
Mark Lutton, Business Intelligence Services, a Thomson Business
------------------------------
Date: Tue, 28 Nov 2006 14:07:33 -0500
From: Monty Solomon <monty@private>
Subject: Critical Firefox hole allows password theft
http://www.computerworld.com/action/article.do?command=viewArticleBasic&taxonomyId=17&articleId=9005379
http://www.info-svc.com/news/11-21-2006/
http://secunia.com/advisories/23046
------------------------------
Date: Fri, 01 Dec 2006 13:49:39 -0800
From: Rob Slade <rmslade@private>
Subject: REVIEW: "Phishing: Cutting the Identity Theft Line", Liniger/Vines
BKPHSHNG.RVW 20061014
"Phishing: Cutting the Identity Theft Line", Rachael Liniger/Russell
Dean Vines, 2005, 0-7645-8498-7, U$29.99/C$38.99/UK#18.99
%A Rachael Liniger
%A Russell Dean Vines
%C 5353 Dundas Street West, 4th Floor, Etobicoke, ON M9B 6H8
%D 2005
%G 0-7645-8498-7
%I John Wiley & Sons, Inc.
%O U$29.99/C$38.99/UK#18.99 416-236-4433 fax: 416-236-4448
%O http://www.amazon.com/exec/obidos/ASIN/0764584987/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/0764584987/robsladesinte-21
%O http://www.amazon.ca/exec/obidos/ASIN/0764584987/robsladesin03-20
%O Audience i+ Tech 2 Writing 2 (see revfaq.htm for explanation)
%P 309 p.
%T "Phishing: Cutting the Identity Theft Line"
The introduction to the book provides a good, and very realistic, prologue
to the topic of phishing. The audience for the work is said to consist of
executives and incident response teams for banks and large corporations,
information security professionals, and general Internet users.
Chapter one furnishes the reader with a solid overview of the subject,
although it would seem to be aimed primarily at individual Web and email
users. "Phishing Emails," in chapter two, explains various spam hiding and
URL obfuscation technologies. The list is not exhaustive, but is sufficient
to illustrate the basic concepts clearly. (The writing, in this chapter by
Rachael Liniger, is delightful. Wit and humour are used extensively, and to
good effect.) Chapter three presents information on false or obfuscated
URLs, as well as useful detail on pop-ups: the content is much superior to
other sources on the same topic. (There is also an oddly placed section on
public key encryption.) Spyware is reviewed in chapter four.
You cannot stop phishing completely, notes chapter five, examining various
players in the fight against identity theft and the limitations of the
action they can take. Chapter six is supposed to be about helping the
organization to avoid phishing, and sets forth some policies in regard to
email and Websites that are very practical in preventing abuse. (The
section on authentication schemes is less so, and eventually the chapter
devolves into random topics.) A generic and sometimes terse outline of
incident response and network forensics makes chapter seven poor in relation
to other parts of the book. In terms of consumer education, chapter eight
has a number of recommendations for safer computing, with lots of "avoid
Microsoft" advice, but also configuration settings, a bit of email analysis
material, and an admonition to check your home finance statements carefully.
Chapter nine deals with actions to take if you, personally, are the victim
of identity theft. (Most of the agencies mentioned are based in the United
States, but the resource list does have some additional contacts for the UK
and Germany.)
Identity theft (and, by extension, phishing) is a major problem, and not
enough is being done to address the issue. This book lays out the risks and
threats clearly, and proposes practical solutions for a variety of actors in
the drama. The text is readable and the concepts are clear. I can
recommend this work to almost anyone involved in a security role,
particularly those in the financial or online industries, law enforcement,
or working in the field of security awareness.
copyright Robert M. Slade, 2006 BKPHSHNG.RVW 20061014
rslade@private slade@private rslade@private
http://victoria.tc.ca/techrev/rms.htm
------------------------------
Date: Wed, 15 Nov 2006 10:32:14 -0800
From: Rob Slade <rMslade@private>
Subject: REVIEW: "The Security Risk Assessment Handbook", Douglas J. Landoll
BKSCRAHB.RVW 20060919
"The Security Risk Assessment Handbook", Douglas J. Landoll, 2006,
0-8493-2998-1
%A Douglas J. Landoll
%C 920 Mercer Street, Windsor, ON N9A 7C2
%D 2006
%G 0-8493-2998-1
%I Auerbach Publications
%O +1-800-950-1216 auerbach@private orders@private
%O http://www.amazon.com/exec/obidos/ASIN/0849329981/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/0849329981/robsladesinte-21
%O http://www.amazon.ca/exec/obidos/ASIN/0849329981/robsladesin03-20
%O Audience a Tech 2 Writing 1 (see revfaq.htm for explanation)
%P 473 p.
%T "The Security Risk Assessment Handbook"
Chapter one is an introduction. Landoll's text is initially rather preachy
and biased. The first couple of sections appear to take the position that
industry has failed in its responsibility to secure information systems, and
therefore (the United States federal) government has had to take charge. He
then lists (although does not describe in any detail) various security
frameworks and guidelines, and argues that, simply on the basis of a lack of
congruence between these documents, "best practices" are a myth. His
conclusion, that risk-based security planning is better, seems oddly gleeful
in the context of such an otherwise dour piece of writing.
Unfortunately, the author does not seem to do any better with risk-based
security planning, right off the top. We are told (on page four) that "the
establishment of an information security program is not the topic of this
book. The topic of this book is how to perform and review an information
security program," which statement(s) must surely rank highly in terms of
self-contradiction and confusion.
Were the reader to quit after this inauspicious, muddled, and verbose
beginning, however, it would be to miss a work of some value. Within pages,
Landoll clarifies the rationale for, and types of, risk assessment, as well
as explaining the purpose of this volume in light of other existing
assessment tools and documents. (To his credit, where other authors tend to
denigrate alternative references, Landoll notes their respective strengths,
and then states the extension that his book provides.)
It is frustrating to attempt a single assessment of the book. The text has
value, but also annoyances. Chapter two provides a useful guide to the
basic components of the risk assessment process (which forms the structure
for much of the rest of the book). At the same time, where Landoll has been
using the business-oriented breakdown of control types (into administrative,
technical, and physical), when discussing safeguards he suddenly switches to
the categories of preventive, detective, corrective, et cetera, that are
more familiar to those in the government and military. (Interestingly, for
someone from a strongly governmental background, Landoll does not fill out
the list with recovery, compensating, deterrent, and directive.) In
addition, when reviewing the concept of residual risk, two new terms of
"static" and "dynamic" risk are introduced. Although the terms are poorly
defined, "static" seems simply to refer to residual risk, while "dynamic"
appears to mean nothing more than risk itself. Therefore, these two new
entries provide no distinct value to the discourse, and only serve to
confuse the issues.
Again, chapter three covers the vital topic of the definition of objectives
and scope of a risk assessment project. When discussing the "customer" for
a review, "Risk Assessment Method" and "Objective Review" seem to be
presented as potential clients. While the question of quality of work would
certainly appear to be a legitimate concern in dealing with project extent,
Landoll includes a great deal of material relevant only to the final report,
such as grammatical correctness and visually pleasing presentation. On the
other hand, there is a good deal of very practical content addressing issues
of realistic scope and reasonable budgeting. The preparation phase is
covered in chapter four, dealing both with practical issues such as letters
of introduction, more esoteric concerns of system and asset criticality, and
also reviewing a number of methodologies and approaches to risk assessment
(although primarily at a conceptual level).
Chapter five starts a string of chapters on various types of data
collection. It leads off with general discussions on the topic, examining
questions of sampling and related issues. (Landoll is not always careful
about explaining terms before starting to use them: neither the index nor
any part of the text notes that the RIIOT method, which is used extensively
in the chapter, is merely an acronym for the phases of review, interview,
inspect, observe, and test.) The gathering of data on administrative
safeguards, in chapter six, has good checklists of items to assess, and uses
the RIIOT format to structure the areas and phases of the elements to
consider. (There is a rather odd reluctance to discuss policy, and an even
stranger overemphasis on two-man controls.) Moving into technical
countermeasures, chapter seven starts off with a section on attacks and
controls. There are very odd errors in the text: the distinction between
SPAM (the Hormel food product) and spam (bulk unsolicited commercial or
fraudulent messages) may be subtle but every security specialist should know
it and yet Landoll uses SPAM throughout. The section on antivirus
protection is weak, cross-references are spotty, and Landoll uses an old
(and generally abandoned) type of firewall (session-level, which is an
amalgamation of stateful and circuit-level proxy). Intriguingly,
authentication is not addressed with technical controls, but (rather weakly)
with physical protection, in chapter eight. Most of the discussion of
physical security outlines particular safeguards, and there is little
deliberation on risk assessment or the factors that can influence it. (For
example, various power supply alternatives are discussed, including the
rather esoteric flywheel generator, but the idea of requesting information
from the utility on past power outages doesn't seem to have occurred to the
author.)
Chapter nine does turn to security risk analysis, briefly, but with
some helpful pointers for the evaluation process. Risk mitigation, in
chapter ten, looks rather tersely at choice of controls, and does an
oddly complicated review of cost/benefit analysis. Styles for
different types of reports resulting from risk assessment are outlined
in chapter eleven. Chapter twelve presents a fairly standard look at
project management (with extra emphasis on reporting). Chapter
thirteen lists, but does not adequately describe, various risk
assessment methodologies.
Despite the weaknesses, oddities, and gaps in the book, it does provide a
decent overall guide, and some very useful practical suggestions. It is not
quite complete in all areas, and therefore likely unsuitable as the sole
source of advice on the risk assessment process for the novice, although the
newcomer would not go far wrong in following the counsel of this work. The
experienced security or risk assessment professional will still find
valuable recommendations and advice. For anyone in the security or risk
analysis field, the book is well worth considering.
copyright Robert M. Slade, 2006 BKSCRAHB.RVW 20060919
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.48
************************
This archive was generated by hypermail 2.1.3 : Tue Dec 05 2006 - 15:12:00 PST