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 39

Thursday 24 August 2006

Contents

Pull the Plug on Touchscreens
R. Mercuri
Re: Pull the Plug on Touchscreens
Avi Rubin
More on Diebold, Ohio, and Touchscreens
PGN
Search Engine Privacy Dilemmas, and Paths Toward Solutions
Lauren Weinstein
Centrelink staff busted invading Australians' privacy
David Shaw
TiVo Is Watching When You Don't Watch, and It Tattles
Monty Solomon
The SAFEE Project
Peter B. Ladkin
Re: LA power outages
Kent Borg
At least the extension cord worked
Mike Albaugh
Re: ... Your Dell laptop battery must be OK!
Dave Blake
Brent Kimberly
"IT Security Project Management", Susan Snedaker
Rob Slade
Info on RISKS (comp.risks)

Pull the Plug on Touchscreens

<"R. Mercuri" <notable@notablesoftware.com>>
Tue, 22 Aug 2006 13:34:21 -0400

Forbes Magazine (9/4/6) included a commentary by Aviel Rubin where he
complains about the "Help America Vote Act, which handed out $2.6 billion to
spend on voting machines."  Avi's recent recommendation is that voters cast
only optically scanned ballots that will be randomly audited. But does he go
so far as to suggest that voters be allowed to prepare these ballots by
hand? Absolutely not. Although I have publicly recommended the adoption of
only scanned paper systems since at least 2003, Avi continues to recommend
electronic ballot preparation methods, such as described in his Forbes
piece, that require all voters to "make their selections on a touchscreen
machine."

If humans are deemed capable enough to audit ballot counts, they should also
be allowed to directly prepare their own ballots without the intervention of
a computer. Most voters already do this, since some 60% of US counties and a
steadily increasing number of mail-ins (such as in CA, FL and NJ where any
voter can register as a permanent absentee) use hand-prepared paper
ballots. Sure, modern technology must be available to provide assistance for
voters who need or want it, but this does not necessarily have to be limited
to "touchscreen machines."  Tactile ballots (endorsed by the United Nations,
see <http://www.electionaccess.org/Bp/Ballot_Templates.htm>) and mechanical
devices (such as the Vote Pad <http://www.vote-pad.us/>) offer inexpensive
alternatives that do not require electricity.

So, will this advice help America's voters avoid the use of unreliable or
insecure voting equipment in 2006, 2007, or even 2008? No, because purchases
(costing in excess of $5B, including state allocations and associated
long-term service contracts) are already in place. Avi's change of heart
(he's previously supported vote-tabulating DREs, see
<http://avirubin.com/vote/eac2.pdf>) now favoring optically scanned ballots
is simply too little, too late, and his ongoing endorsement of touchscreen
voting has made him part of the problem, not its solution.

Rebecca Mercuri


Re: Pull the Plug on Touchscreens (Mercuri, RISKS-24.39)

<Avi Rubin <rubin@jhu.edu>>
Wed, 23 Aug 2006 13:42:21 -0400

I need to set the record straight on one point. Towards the end of
her posting, Rebecca states that

  "[Avi has] previously supported vote-tabulating DREs, see 
  avirubin.com/vote/eac2.pdf"

I urge anyone who is interested to have a look at what I wrote in my EAC
testimony that she references.  It is a scathing critique of DREs.  I feel
that accusing me of having supported DREs is like accusing Erin Brockovich
of having supported water pollution.  I have done nothing but argue and
fight against DREs from day one.  If you read my new book, Brave New Ballot
(Random House, 2006), you will see that I have maintained a steady position
on this all along.

Avi Rubin


More on Diebold, Ohio, and Touchscreens

<"Peter G. Neumann" <neumann@csl.sri.com>>
Wed, 23 Aug 2006 16:08:56 PDT

A report questioning the accuracy of Diebold Election Systems' e-voting
equipment in a recent Ohio election gives more ammunition to critics who
doubt the viability of electronic voting technology.  A study of 467 of
5,407 e-voting machines used in the 2 May 2006 primary election in Cuyahoga
County, Ohio, found that one-third of the booth workers had problems setting
up the machines. 45% had problems closing out machines. 38% had problems
with printers or spools. 90% of the voters liked the new systems. 10% of the
voters reported problems with the machines.  [Source: Marc Songini, Paper
Trail Flawed in Ohio Election, Study Finds *Computerworld*, 21 Aug 2006]
http://www.computerworld.com/action/article.do?command=viewArticleBasic&taxonomyId=13&articleId=9002610


Search Engine Privacy Dilemmas, and Paths Toward Solutions

<Lauren Weinstein <lauren@vortex.com>>
Mon, 21 Aug 2006 21:51:46 PDT

An item in *The New York Times*, 22 Aug 2006 neatly encapsulates the overall
state of search engine query data retention issues.
  http://www.nytimes.com/2006/08/22/technology/22aol.html

The observant reader will note that despite the rising tide of concerns
regarding search query privacy, the industry as a whole is still pretty much
in a state of denial, made all the more confusing by various signals from
the U.S. Department of Justice.

This is turning into such a mess that it's becoming difficult to even keep
the various participants and their positions completely clear.  There is
every reason to believe that without heroic action by the players involved,
we may be heading toward a privacy, legislative, and judicial nightmare.
But maybe there's a way out.

Let's review:

AOL's release of search query data made obvious to everyone what many of us
knew all along -- that such data contains all manner of personal
information, even when the identity of the party making the query is not
immediately known directly from usage logs.  In the AOL case, the individual
query entries were linked by "anonymized" user IDs, but even without such
linkages the query items alone can be highly privacy-invasive.  The AOL
release triggered (as did DoJ vs. Google) broad calls for mandated search
query data destruction policies.

The personal nature of the AOL query data serves nicely to liquidate the
DoJ's arguments (again, as in DoJ vs. Google) that such data is not
privacy-invasive so long as the query source is unidentified.  The expressed
DoJ reasoning is this regard is obviously faulty.

Search engine companies have been reluctant to voluntarily dispose of query
data on a regular basis.  This data has considerable R&D, marketing, and
other value.  Since the incremental cost of keeping all queries archived
forever is so low, there is little incentive within the normal business
structure to dispose of this resource, absent overriding considerations.

Even while laudably expressing concerns about the potential for third-party
misuse of query data, search engine firms (e.g. Google) have proclaimed
their intention to keep collecting and saving this data indefinitely.  If
AOL actually sets in place an aggressive data destruction schedule, it will
be something of a watershed event that may (or may not) have broad impacts
across the search engine industry.  Fears of being placed at a competitive
disadvantage will tend to make unilateral moves toward query data
destruction difficult to propose or implement.

Meanwhile, DoJ is moving in exactly the opposite direction, apparently
preparing to propose long-term (perhaps measured in years) mandated data
retention schedules, requiring the saving of the very data for which
destruction demands are being made in other quarters.  DoJ is using child
abuse (and as of late anti-terrorism efforts) as their hooks to justify such
legislation (please see: http://lauren.vortex.com/archive/000186.html ).

This situation has all the elements of a painful and wasteful deadlock,
potentially triggering years of litigation while the overall search engine
issues continue to fester and become even bigger privacy, business, and
political problems.

If we wish to avoid this scenario -- or at least have a good shot of
avoiding it -- we need to act now, and we need to do so cooperatively.
There are policy and technological approaches to the search query dilemma
that can be applied in ways that will serve the interests of all
stakeholders.  Cooperation and compromise mean that nobody is likely to get
everything that they'd ideally want, but to paraphrase the great philosopher
Mick Jagger, perhaps we can all get much of what we need.

Therefore, I propose the formation of a high-level Internet working
group/consortium dedicated specifically to the cooperative discussion of
these issues and the formulation of possible policy and technology
constructs that can be applied toward their amelioration.  Such a working
group would be as open as possible, though proprietary concerns would likely
necessitate some closed aspects if progress is to be accelerated as much as
possible.

Participation by all stakeholders would be invited.  Representatives of the
major search engine firms and concerned government agencies, outside
technologists and other persons involved in privacy and search issues, and
other entities as appropriate would all play important roles.

Of course, it's easy -- especially for large corporate enterprises -- to
simply ignore such efforts and just plow ahead independently.  Obviously,
without the participation of the key players, the effort that I'm proposing
would be useless, and I will not continue to promote it if that situation
ensues.

However, I suggest that it will be in the long-term best interests, both
financially and in terms of corporate and organizational responsibility, for
major stakeholders to actively join such a project, since the alternative
seems ever more likely to be somewhere between highly disruptive and
extremely draconian.

Interested?  Please let me know.  All responses will be treated as
confidential unless the sender indicates otherwise.

Thank you for your consideration.

Lauren Weinstein <lauren@vortex.com> +1-818-225-2800 http://www.pfir.org/lauren
Lauren's Blog: http://lauren.vortex.com Co-Founder, PFIR http://www.pfir.org


Centrelink staff busted invading Australians' privacy

<"Shaw, David \(David\)" <dshaw@avaya.com>>
Wed, 23 Aug 2006 10:31:06 +1000

Centrelink (www.centrelink.gov.au) is the Australian federal government's
social security and welfare agency. Staff have access to a wide range of
information about Australians.

Following a two-year investigation nineteen staff have been sacked for
inappropriately accessing the personal information of family, friends and
ex-lovers. More than 100 staff resigned when confronted with similar
allegations. Five cases have been referred to the Australia Federal
Police. The privacy invasions were detected using "specially designed
spyware software."

While highlighting the risk that sometimes the greatest security threats
come from within, at least it's encouraging to see a government department
making an effort to crack down on invasions of privacy.

More info at: http://www.abc.net.au/news/newsitems/200608/s1721505.htm

David Shaw, Senior Software Engineer dshaw@avaya.com


TiVo Is Watching When You Don't Watch, and It Tattles

<Monty Solomon <monty@roscom.com>>
Sun, 20 Aug 2006 04:47:40 -0400

TiVo is starting a research division to sell data about how its 4.4 million
users watch commercials - or, more often, skip them: TiVo users spend nearly
half of their television time watching programs recorded earlier, and
viewers of those recorded shows skip about 70 percent of the commercials.
[Source: Saul Hansell, TiVo Is Watching When You Don't Watch, and It
Tattles, *The New York Times*, 26 Jul 2006; PGN-ed]
http://www.nytimes.com/2006/07/26/technology/26adco.html?ex=1311566400&en=143cb4893c1c45a9&ei=5090


The SAFEE Project (was: Anti-hijack Software, Sanders, RISKS-24.38)

<"Peter B. Ladkin" <ladkin@rvs.uni-bielefeld.de>>
Sun, 20 Aug 2006 14:44:06 +0200

Nickee Sanders reports from Yahoo that:

  A joint European effort is working on software that would enable remote
control of an aircraft that could override any attempts by hijackers to
control the plane, and force a safe landing.........  The project is
budgeted for 36m Euros.

Please let us try to get this straight. This comment suggests that the EU is
putting 36m Euros into developing control SW for commercial aircraft. This
is not so, as far as I can tell. The SAFEE project is a *research* project
which is focused on the implementation of onboard threat detection systems
and the provision of reliable threat information to the flight crew. In the
decision making and response management process, secured air/ground exchange
of threat level information is foreseen. SAFEE also anticipates the future
use of the European Regional Renegade Information Dissemination System
(ERRIDS) by all organizations involved in response to acts of unlawful
interference on-board aircraft.

( http://www.safee.reading.ac.uk/about.htm )

Notice that there is no mention of control SW here, but rather of detection
systems and reliable information systems. According to the information
brochure which one may download at
http://www.safee.reading.ac.uk/SAFEE_brochure.pdf there are five
sub-projects. One of the five subprojects is "flight reconfiguration:
includes an Emergency Avoidance System (EAS) and a study of an automatic
guidance system to control the aircraft for a safe return". Notice the
wording: a *study*, not writing control SW.

One of the other subprojects is concerning with secure air-ground
communication.  About time. Data exchange between aircraft and ground has
been clear-text-based without effective authentication, and it is about time
this was changed (I regard authentication as essential).

I see one academic partner in the project (the University of Reading) and a
lot of commercial partners. Research work by commercial project partners is
subsidized to a level of 50%, which means that of this 36m (again note: I
haven't checked this figure), roughly half of it will be paid by the
participants themselves (the Uni Reading will get 100%).

So the risk highlighted by this note turns out not to be the reported
one. How to avoid it: check sources before distributing rumors.

Peter B. Ladkin,  Causalis Limited and University of Bielefeld
www.causalis.com    www.rvs.uni-bielefeld.de


Re: LA power outages (RISKS-24.37,38)

<Kent Borg <kentborg@borg.org>>
Tue, 22 Aug 2006 15:41:11 -0400

It is *so* hard to do redundancy on an industrial-scale.  I.e., for a large
data center.  One reason the attempt is so frequently doomed is that is is
*SO* hard to test a critical system.

Here is a true story of such a failure.

I know of a facility has a diesel generator, and even plenty of diesel,
enough for easily powering critical systems for a long time.  Wanting to be
safe they test their generator every month.

Time passes.  Something goes wrong with the utility power, so the generator
fires up.  All is running as expected--until the generator stops.

Problem: All that diesel.  It can't all sit in a gravity-fed tank on top of
the generator, most of it is in the big tanks, some distance off, and fed
with a pump.

Specific Problem: The pump was powered off the utility power not the
generator power; works great during monthly tests, but doesn't work well at
all when the utility is down.


At least the extension cord worked (Weinstein, RISKS-24.38)

<Mike Albaugh <albaugh@perilin.com>>
Fri, 18 Aug 2006 17:00:31 -0700

Lauren Weinstein pointed out the risks of power-failure to "bleeding edge"
tech such as VoIP over cable-modem in "Your Cable Company -- powered by the
guy with the extension cord".

Lately AT&T (re-branded SBC) has been running a lot of advertising making the
same point, and pretty much suggesting that you are putting your life in
danger by switching away from them.

Maybe yes, and maybe no. I recently had a 36-hour (_after_ I got home and
reported it) service outage on my POTS (Plain Old Telephone Service), as
provided by SBC. Clear weather, No power outage. Several of my neighbors had
much the same problem, at about the same time, but SBC denied that the truck
they had parked over the neighborhood cable vault had _anything_ to do with
it. It had to be in my internal wiring (yeah, unable to cope with "no
battery", let alone "no dialtone" at the demarcation point).

RISK: Assuming that the risk a competitor tells you about is the only one
that exists.  Why any sane person would go for "Triple Play" is beyond me.
Reality: The old "public service" attitude (don't laugh, many PacBell folks
did indeed have it) is dead and buried.


Re: ... Your Dell laptop battery must be OK! (Miller, RISKS-24.38)

<Dave Blake <dave.blake@tiscali.co.uk>>
Mon, 21 Aug 2006 16:25:30 +0100

Dan Miller asks what happens when you do enter (correctly) an ID for a
potentially faulty battery into the dellbatteryprogram.com site. The answer
is that the site takes you directly to an order page so that you can request
a replacement battery. At least there is no "Are you sure that you want to
replace your potentially explosive battery" step.

More annoying from my point of view is that I raised a support call with
Dell late last month (21 Jul to be precise) as the battery light on the
laptop which was normally green had begun to flash an intermittent red
light. After a week or so of emails I was basically fobbed off with a
normal-operation-for-a-year-old battery story. I now find that this issue
had already been made public in a number of sources, and I find it
incredible that Dell has been so slow to react.

http://www.signonsandiego.com/news/tech/20060712-1221-cargoplanefire.html
http://www.boingboing.net/2006/07/28/dude_your_dell_just_.html

The BoingBoing story relates how a Dell laptop burst into flames in an
office. So far so frightening, but as I work mainly at home and often leave
the machine on overnight unattended running AV scans or downloads, in the
room next to my daughter's bedroom that I use an office (which of course
does not benefit from any of the anti-fire devices that a normal commercial
office might have) I find the thought of what might have happened absolutely
bloody terrifying.

Then, whilst checking the URLs for this note, I come across the story that
the batteries were manufactured by Sony and that they knew of these
potential problems 10 months ago. Well, after the music CD rootkit fiasco
earlier in the year we all know that Sony seems to have a certain contempt
for its customers but I think that this latest story takes the
biscuit. There's a whole world of difference between compromising the
security of a customer's PC , and potentially killing or maiming
someone. Furthermore Sony management could perhaps be forgiven for failing
to grasp the rootkit issue; they can have no such defence over the rather
simple issue that their product might burst into flames or explode.

http://www.macworld.com/news/2006/08/21/battery/index.php

Lastly, the Macworld story contains the following statement;-

  "Fujitsu, Toshiba and Hewlett-Packard (HP) said on Thursday that they use
  Sony Li-ion batteries with their systems, but that the batteries are
  different from those being recalled by Dell. The companies said they did
  not see a fire risk for customers and did not plan on doing a battery
  recall."

Anyone feel comforted by that?


Re: ... Your Dell laptop battery must be OK! (Miller, RISKS-24.38)

<Brent Kimberley <brent_kimberley@rogers.com>>
Tue, 22 Aug 2006 21:23:11 -0400 (EDT)

I enjoyed reading Dan Miller's "Your Dell laptop battery must be OK!"
  http://catless.ncl.ac.uk/Risks/24.38.html .

A new disclaimer has been added to the Dell battery program website:
  https://www.dellbatteryprogram.com/

  Please verify you entered your PPID correctly before submitting
  Common errors include distinguishing between alphanumeric characters:
    letter "O" from the number "0"
    letter "S" from the number "5"
    letter "l" from the number "1"

  [This disclaimer nibbles off a little of the pain.  But the battery model
  number situation reminds me of license-plate confusions, where similar
  caveats are presumably issued to police officers.  Or, if this ever became
  connected with a serious law-enforcement case, might we expect Congress to
  seek legislation that makes certain confusion-causing characters illegal,
  such as in O0S51I?]


"IT Security Project Management", Susan Snedaker

<Rob Slade <rmslade@shaw.ca>>
Mon, 21 Aug 2006 13:43:45 -0800

BKITSCPM.RVW   20060808

"IT Security Project Management", Susan Snedaker, 2006, 1-59749-076-8,
U$59.95/C$77.95
%A   Susan Snedaker info@virtualteam.com
%C   800 Hingham Street, Rockland, MA   02370
%D   2006
%E   Russ Rogers
%G   1-59749-076-8
%I   Syngress Media, Inc.
%O   U$59.95/C$77.95 781-681-5151 fax: 781-681-3585 www.syngress.com
%O  http://www.amazon.com/exec/obidos/ASIN/1597490768/robsladesinterne
  http://www.amazon.co.uk/exec/obidos/ASIN/1597490768/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/1597490768/robsladesin03-20
%O   Audience i- Tech 1 Writing 1 (see revfaq.htm for explanation)
%P   612 p.
%T   "IT Security Project Management"

Chapter one is an introduction, but also something of a preface to the book.
In terms of the intended audience, the author states that it is assumed
readers know the basics of project management and also network security.
The text, therefore, is proposed to be an operational framework for
designing an information technology security project plan.  However, as the
material goes on to describe the components of such a plan only network
items are listed: physical security, applications security, databases,
business continuity, and a host of other considerations are notable by their
absence, and even the vital element of policy is buried as a minor
ingredient.  There is a vague and verbose outline of risk and cost/benefit
analysis, and a list of success factors that range from the glaringly
obvious (management support) to the counterproductive (standard
off-the-shelf infrastructure is recommended even though this practice is
known to increase the likelihood of attacks).

Chapter two defines security projects, but mostly in terms of the sections
of a proposal.  Organizing the project, in chapter three, lists various
project management factors, probably the most significant being the
composition of the team that will define the project.  (Didn't we do the
definition in chapter two?)  Ensuring quality, in chapter four, seems to
consist of knowing requirements and metrics.  Chapter five sees the
formation of the project team, which is not the same as the team that
defined the project in chapter three.  Standard project planning advice is
provided in chapter six.  Chapter seven is supposed to be about managing the
project, but there is little or no mention of the mechanics of management,
with the content concentrating on initiation and changes of specifications.
The termination phase is reviewed in chapter eight.

Chapter nine, entitled "Corporate IT Security Project Plan," is supposed to
be the promised overarching framework.  However, after twenty-two pages of
legal advice (and two warnings about giving or taking unauthorized legal
advice), we find a project outline (missing some of the usual steps) and a
haphazard aggregation of project elements, many of which have been covered
previously.  (Contrary to the recommendation in chapter six, the outline
lists a number of items of quite different importance all at the same
level.)  A random and unstructured collection of security topics makes up
the bulk of chapter ten, which is nominally about general IT security
planning.  The lack of pattern and hodgepodge of subjects seems to confuse
even Snedaker: figure 10-1 on page 265 ("Layered Approach to Network
Security") and figure 10-5 on page 327 ("Elements of IT Security
Requirements") are duplicates.  Much the same description is true of IT
infrastructure, in chapter eleven, and it also repeats a good deal of the
content.  Wireless security, in chapter twelve, does have more substance
that is specifically related to wireless technology and risks, although it
is strange, given the immediacy of other items in the work (there is a
reference to an event that happened on May 24, 2006), that the list of
802.11 protocols does not list 802.11i, which is probably the most secure.
Chapter thirteen, about operations security, does have a bit more
organization, but is fairly standard advice about incident response,
security awareness, and policy.

If it is expected that the reader is thoroughly familiar with project
management, the primacy and amount of space dedicated to the basic project
operations (chapters two to eight, 158 pages) is odd.  It turns out that the
limiting of the technical content to network areas is of no particular
importance, since this volume is really only generic project management
advice anyway (and not overly complete, at that).  Page 445 notes that
"[o]ur goal is not to push you to use outside consultants," but Snedaker is
a consultant, and owns a consulting firm.  The writing in this book is
turgid, the content banal, and the advice incomplete.  Given that I am a
selfprofessed professional paranoid, I may perhaps be forgiven for imagining
that someone might write a bad book in the hopes that readers, attempting to
figure out how to do it themselves, would give up in disgust and look around
for someone to make sense of the process for them.

Just a thought.

copyright Robert M. Slade, 2006   BKITSCPM.RVW   20060808
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