The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 24 Issue 48

Tuesday 5 December 2006

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
Info on RISKS (comp.risks)

Still more on the European power outage

<"Peter G. Neumann" <neumann@csl.sri.com>>
Mon, 4 Dec 2006 14:16:53 PST

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@NLnetLabs.nl> 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]


Another power outage brings down German TV station

<Debora Weber-Wulff <D.Weber-Wulff@fhtw-berlin.de>>
Sun, 26 Nov 2006 18:31:56 +0100

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


The UK NHS IT plan

<Brian Randell <Brian.Randell@ncl.ac.uk>>
Tue, 5 Dec 2006 11:37:00 +0000

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]


Rebooting airplanes

<"Douglas W. Jones" <jones@cs.uiowa.edu>>
Tue, 28 Nov 2006 13:29:42 -0600

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.


Mascalls, Manchester, what's the difference?

<msb@vex.net (Mark Brader)>
Sat, 2 Dec 2006 04:36:21 -0500 (EST)

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@vex.net


Three guilty of identity fraud which netted millions

<Brian Randell <Brian.Randell@ncl.ac.uk>>
Fri, 1 Dec 2006 15:37:45 +0000

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


Identity theft made easy

<John Haselsberger <jhasels99@fast.net>>
Sun, 29 Oct 2006 09:26:34 -0500

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.


Federal Reserve E-Banking System Outages: Brian Krebs

<"Peter G. Neumann" <neumann@csl.sri.com>>
Sun, 3 Dec 2006 09:44:18 PST

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


How To Tell If Your Cell Phone Is Bugged

<Lauren Weinstein <lauren@vortex.com>>
Tue, 5 Dec 2006 12:15:54 -0800 (PST)

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 ]


Firefox flaw causes engagement to break off

<<Mark.Lutton@thomson.com>>
Fri, 1 Dec 2006 12:54:32 -0500

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


Critical Firefox hole allows password theft

<Monty Solomon <monty@roscom.com>>
Tue, 28 Nov 2006 14:07:33 -0500

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


REVIEW: "Phishing: Cutting the Identity Theft Line", Liniger/Vines

<Rob Slade <rmslade@shaw.ca>>
Fri, 01 Dec 2006 13:49:39 -0800

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@vcn.bc.ca     slade@victoria.tc.ca     rslade@computercrime.org
http://victoria.tc.ca/techrev/rms.htm


REVIEW: "The Security Risk Assessment Handbook", Douglas J. Landoll

<Rob Slade <rMslade@shaw.ca>>
Wed, 15 Nov 2006 10:32:14 -0800

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@wgl.com orders@crcpress.com
%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@vcn.bc.ca     slade@victoria.tc.ca     rslade@computercrime.org
http://victoria.tc.ca/techrev/rms.htm

Please report problems with the web pages to the maintainer