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 25 Issue 69

Sunday 24 May 2009

Contents

Another Boston subway crash with cell-phone implications
PGN
HIV patients sue after records left on MBTA
Elizabeth Cooney
NZ bank lends $10M instead of $10K; couple takes the money and runs
Ian Wells
Re: NY voter voted absentee, then died; ballot ruled invalid
Paul Wallich
Harvey Fishman
Fragility of telephone system
Jim Haynes
SANS NewsBites gets it very wrong, fails to post a correction
Jonathan Kamens
Re: Nielsen Ratings
Rupert Moss-Eccardt
How to make memorable but secure passwords
Phil Colbourn
Re: A Lesson in Internet Anatomy: The World's Densest Meet-Me Room
Jidanni
Re: FAA ATC shutdown
Walter Roberson
Chris Drew
Gene S. Berkowitz
Al MacIntyre
Fred Cohen
Re: On Government IT competence
Pete Kaiser
eCrime Researchers Summit CFP
Monty Solomon
Info on RISKS (comp.risks)

Another Boston subway crash with cell-phone implications

"Peter G. Neumann" <neumann@csl.sri.com>
Sat, 23 May 2009 20:52:13 PDT

At 7:18pm on 8 May 2009, one inbound subway train rear-ended another train
in the Green Line in the Boston MBTA at 25 mph.  The driver of the offending
train (24-year-old Aiden or Aidan Quinn [both spellings appear in the same
article from the *EDGE*], who reportedly had three auto speeding violations)
was allegedly texting his girlfriend at the time.  49 passengers were
injured and taken to the hospital, and three cars were crushed.  This
incident followed another similar case in 2008 in which another driver had
allegedly been on her cell phone just before that train collided with the
preceding one.  [Source: PGN-ed from various news reports.  Please browse the
Web if want some of the background, which is way beyond the scope of RISKS.]


HIV patients sue after records left on MBTA (Elizabeth Cooney)

Monty Solomon <monty@roscom.com>
Sat, 23 May 2009 23:36:12 -0400

Four HIV-positive patients whose records were left behind on an MBTA train
by a Massachusetts General Hospital employee are suing the hospital,
contending their privacy was breached.  In March 2009, the hospital notified
66 patients who received care at its Infectious Disease Associates
outpatient practice that billing records bearing their names, Social
Security numbers, doctors, and diagnoses had been lost by a manager who was
riding the Red Line. She had brought the paperwork home for the weekend, but
left it on the train when she returned to work Monday morning, March 9,
according to a hospital security report.  [Source: Elizabeth Cooney, HIV
patients sue after records lost; Hospital worker left files on MBTA, *The
Boston Globe*, 21 May 2009]

http://www.boston.com/news/local/massachusetts/articles/2009/05/21/hiv_patients_sue_after_records_lost/


NZ bank lends $10M instead of $10K; couple takes the money and runs

Ian Wells <familywells@gmail.com>
Sat, 23 May 2009 16:40:51 +1200

It is not public yet how this error occurred.  Couple is being charged with
fraud, who decided to be fugitives when a bank error gave them a $10,000,000
loan instead of $6,000,000.

http://www.stuff.co.nz/national/crime/2428243/Couple-missing-after-10m-bank-bungle

Ian Wells, Christchurch, New Zealand


Re: NY voter voted absentee, then died; ballot ruled invalid (R-25.68)

Paul Wallich <pw@panix.com>
Sat, 23 May 2009 21:16:39 -0400

It gets even more complicated than that. In some jurisdictions, one actually
votes during early voting (at a machine or with whatever other tools the
site uses), while in others one fills out what is effectively an absentee
ballot and hands it to the clerk for storage until election day. (In the
latter case, there's a double envelope, with the inner one unmarked and the
outer one signed and named, and the name used by the clerk to cross a voter
off the main register.) So someone who voted early by machine and then died
would have their vote count, whereas someone who voted by the accurately but
oddly-named in-person absentee ballot could in principle be culled. Here's a
case where reusing existing methods for a new purpose actually improves
accuracy compared to inventing new methods.


Re: NY voter voted absentee, then died; ballot ruled invalid (R-25.68)

Harvey Fishman <fishman@panix.com>
Sat, 23 May 2009 21:06:37 -0400 (EDT)

> [Source: Tiebreaking Vote Cast by Dead Man; Runoff Required, AP item, PGN-ed.

I do not believe that we have in-person early voting in New York State.
Certainly we do not have it in New York City (understandably, as polls are
generally in places like schools which are dedicated to other uses except on
election days), but I only assume that voting rules are state-wide.  [Yes. PGN]


Fragility of telephone system

Jim Haynes <jhhaynes@earthlink.net>
Sat, 23 May 2009 20:52:23 -0500 (CDT)

It's now been a while since the fiber optic cable cuts in the S.F.  Bay
Area.  I've been waiting for an explanation of why cutting 3 or 4 fiber
cables completely killed telephone service in all or part of three counties.


SANS NewsBites gets it very wrong, fails to post a correction

Jonathan Kamens <jik@kamens.brookline.ma.us>
Sat, 23 May 2009 23:17:45 -0400

I thought the following might be of interest to RISKS readers, both because
I'm sure many of us also read (http://www.sans.org/newsletters/newsbites/)
SANS NewsBites, and because this deals with misrepresenting computer-related
risks in a very real way.

In a recent NewsBites issue (11.39), the following item appeared as the
headline story:

 >TOP OF THE NEWS
 > --One In Five Teenagers Claim to Have Used Hacking Tools
 >(15th May 2009)
 >A recent survey of 4,000 teenagers between the ages of 15 to 18 years
 >of age states that 17% of those surveyed know how to find hacking tools
 >online with one third of that group admitting that they have used the
 >tools....

In this little blurb, the editors of SANS make two statistical errors, one
small and one very, very large.

Here's the actual press release contents: "The survey also revealed that 17
percent of adolescent users claim to have advanced technical knowledge and
are able to find hacking tools on the Internet. Of these, 30 percent claim
to have used them on at least one occasion."

The minor error is that 30% is less than one third.  While a 3.33%
difference might seem insignificant, it's little "telephone-game" changes
like this that over time result in seriously divergences from reality.  Note
that one of the articles which SANS cited used the phrase "nearly a third,"
which is accurate, and SANS apparently saw fit to drop the "nearly."

The second, much more serious error, is that the percentage of teenagers who
admitted that they have used the tools is not "one in five," but rather 30%
of 17%, which comes out to 5%, or ONE IN TWENTY, a huge difference from what
SANS reported.

I emailed the editors of SANS the same day this issue came out, pointed out
both errors, and asked them to post a correction.  The next issue was
published three days later with no correction included.  This is rather
unfortunate.

I find it just a bit disturbing that none of the editors of NewsBites,
supposedly experts in the field, found the "one in five" statistic
sufficiently surprising to dig deeper and discover the truth of the matter.
I certainly did.


Re: Nielsen Ratings (RISKS-25.68)

Rupert Moss-Eccardt <r.moss-eccardt@computer.org>
Sun, 24 May 2009 08:35:33 +0100

I must say I was surprised to see the assertion that the Nielsen server
failures were directly attributable to the outsourcing.

Firstly, I thought this was a moderated list and the assertion is a rather
bald one.

Secondly, and this is more of a risk, it appears from this and the comments
posted to The New York Times article referenced that the real problem was
that Nielsen had a set of systems with no real business continuity.
According to former staff, if the comments are to be believed, the systems
were fragile enough to be prone to failure if not cared for in special ways
that weren't documented fully, or at all.

  [Rupert, Many TNX for the comment.  PGN]


How to make memorable but secure passwords

phil colbourn <philcolbourn@gmail.com>
Sun, 24 May 2009 20:42:51 +1000

Some people, perhaps most, have a system for making passwords. Some systems
involve the use of the same password everywhere - easy to remember but if
discovered their online life is easily accessed. Others have different
passwords and write them down.

My system is to maintain long, virtually unique passwords which I never need
to commit them to paper or electronic note.

My goals are:

* at least 8 characters
* the use uppercase, lowercase, digits and symbols/punctuation
* the discovery of the system should not compromise my passwords
* no need to record any password
* be able to quickly work-out my password for any site

The System

* Make up a memorable code with preferably uppercase, lowercase, numbers and
  symbols/punctuation.
* For each site, consistently use some aspect of the site such as 3 or 4
  letters/numbers of the site URL - modified in some systematic way - and add
  it to your memorable code. Add it using any rule you like.

There is a problem with this system: sometimes sites change their name
which, for me, has happened once. In this case I have not needed to change
my password but since most sites will send your password to you, should you
forget, you can easily have your old password recovered and then you can
change your password - it doesn't happen often.

Examples

Assume your memorable code is Ab19#z.

Example 1: Use the first, second, second-last and last characters of the
site, added in reverse order, first and last capitalized, insert after the
4th character of your memorable code.

So a password for google.com would be Ab19EloG#z.

And for ibm.com it could be Ab19MbbI#z. (You should have some way to handle
site names that 'fail' your system or require longer passwords than that of
your system).

Example 2: Insert the memorable code into the first and last characters of
the site name.

So the password for google.com would be gAb19#ze.

It goes without saying (hopefully) that you should make up your own system
and you should probably not use my examples.

Ideas:

* Consider using the organisation type or country code.
* Consider using multiple systems. One for important sites and a simpler
  system for ad-hoc, single-use and other sites not containing personal data
* Consider a version of the system for your home PC accounts

Your should assume that your system could be discoverable, so you need to
choose a memorable code that is secure by itself.

If you want to document your system, do so with care. You should not write
it down verbatim - try to obscure it ;-)


Re: A Lesson in Internet Anatomy: The World's Densest Meet-Me Room

<jidanni@jidanni.org>
Sun, 24 May 2009 21:17:20 +0800

"without incurring local loop fees" mentioned in
http://en.wikipedia.org/wiki/Meet-me-room is a factor encouraging putting so
many eggs in one basket Re:
http://catless.ncl.ac.uk/Risks/25.68.html#subj5.1


Re: FAA ATC shutdown (Kaiser, RISKS-25.67)

"Walter Roberson" <roberson@hushmail.com>
Fri, 22 May 2009 14:35:51 -0500

Pete Kaiser, in suggesting reasons why IT might be bad in government,
including the possibility of "where underfunded entities are asked to
perform miracles on inadequate budgets".

I used to be a systems administrator for a government (outside the USA) in
an underfunded situation. I instrumented and measured and compared published
Fortunate 500 surveys: our 2/3-person equivalent networking staff was
achieving uptimes slightly better than the average 12-person dedicated
network staff reported for the F500 companies -- and was doing so with
equipment that was mostly already declared End Of Life by the respective
manufacturers.

We worked, underfunded, in government, but we were quite dedicated -- as
were the co-workers in other sites that I interacted with.


FAA ATC shutdown & Gov't IT Competence (Kaiser, RISKS-25.67).

"Chris Drew" <e767pmk@yehaa.co.uk>
Sat, 23 May 2009 22:37:02 +0100

> Businesses have many ways of concealing their IT incompetence that aren't
> available to government, especially the option of simple secrecy; and we
> write our laws to protect (if not always guarantee) their ability to make a
> profit even when they screw up.

Yebbut...   As I see it from a UK perspective:

* If a company's IT project is ineffective or costs too much it will damage
  the company financially and may even put it out of business.  In the case
  of a Government IT project, it can throw taxpayers' money at it until it
  either works, sort-of, or it is quietly abandoned (or dies of shame).

* If a company's customers or suppliers feel that the company is storing or
  using their information improperly, they can take their business
  elsewhere.  Citizens don't have any choice about dealing with and handing
  data to the Government.

* If a company's IT project violates laws concerning, say, data protection
  or security of storage, then the company will likely find itself in big
  legal trouble.  If a Government IT project is illegal..?  Well there may
  be some sound and fury, but that's as far as it goes (e.g. "Private
  details/UK Government disks" saga, RISKS-24.92 on).

Looks to me like the nature of RISKS of IT projects can vary a lot depending
on who is the final customer and who is paying the bill.


Re: FAA ATC shutdown (Gorman, RISKS-25.66)

"Gene S. Berkowitz" <first.last@verizon.net>
Sun, 24 May 2009 01:30:16 GMT

"The cheapest and most effective remedy for induced anxiety is to ignore
those who profit from it.  Easily spotted, they are the ones who continue to
repeat what has been soundly discredited in the course of the public debate,
and those who continue to grossly misrepresent the true state of affairs."
Linda Gorman, Independence Institute, Golden, CO, Extremists Create Stress
for Gain, 21 Mar 2000.  http://www.i2i.org/main/article.php?article_id=294

Methinks Ms. Gorman should heed her own advice.


Re: FAA ATC shutdown (Cohen, RISKS-25.68)

"Al MacIntyre" <macwheel99@wowway.com>
Sat, 23 May 2009 20:50:25 -0500

Subject: Is "security through obscurity" being called for in RISKS?

> It is important for government to be open to the people in identifying
> problems, but some stuff needs to be kept confidential from potential
> trouble makers.

The IG report included a road map to what security has been installed, what
has not been installed, what vulnerabilities exist, at which FAA sites, and
what any troublemakers can do right now.  If the FAA ever gets caught up
implementing standard security advice and patches, the security will be
pretty darn good, but based on past track records, that may be a fantasy.
The purpose of the inspection was to identify what needed to be fixed, but
we know darn well that with government inspections that it can be years
between problems identified, and them actually getting fixed.

Before the report, I am sure many troublemakers already knew this stuff.

After the report, an army of me-toos also know.  The effect, of the IG
report, included magnifying the risk the FAA has put itself into.

It would be like you having a combination lock to your front door, and that
combination being blasted on the Internet.  Previously, the only people who
knew the combination, were you, your family, some friends, some of their
friends, some frequent vendors, and whoever has the hidden camera pointed at
the touch pad where the secret pin code is keyed in.  In your case, changing
the password is fast & easy.  The FAA does not have the funds, or expertise,
to fix their almost total lack of cyber security.  We are going to lose some
aircraft full of passengers before this gets fixed.  Thanks to the IG
report, this will happen sooner rather than later.

I think that all *we* the people need to know is that hackers can take over
99% of the Air Traffic Control in America, take down 75% of the public
utilities, whatever the figures are, without spelling out step by step how
to do it, for the next home grown idiot terrorists who right now can be
caught by FBI confidential informant witnesses, but with this kind of
report, don't need to use communications tapped by NSA to implement a plot.


Re: FAA ATC shutdown (MacIntyre, RISKS-25.69)

Fred Cohen <fc@all.net>
Sat, 23 May 2009 20:26:55 -0700

I think that security through obscurity is a key component of the overall
security plan of any real enterprise. I just get a bit annoyed when people
act like it's somehow inappropriate to have/use it.  Operations Security is
all about deciding when and how to use obscurity, and deception is a part
and parcel of any really good overall protection program I have seen.

Fred Cohen & Associates 572 Leona Drive    Livermore, CA 94550
http://all.net/  1-925-454-0171


Re: On Government IT competence (Miller, RISKS-25.68)

PK <djc@resiak.org>
Sun, 24 May 2009 12:06:02 +0200

Scott Miller's note is a partisan rant which, arguably, belongs in part in
RISKS as commentary on what belongs in RISKS.  Its partisanship lies where
it departs from fact, and from informed technical opinion, to express
unsupported political opinion about the motivation of US political parties.
(I use "partisan" here not in the narrow context of a particular two
American political parties, but in its wide sense.)

Here's a factual question related to RISKS in computing, one I touched in
light of my own experience: is government -- not just US government -- worse
at computing than private industry?  (Not in my experience.)  I'd welcome
seeing some good data, though it's hard to imagine what it would be in light
of the complexity of how large organizations actually operate, and of the
large differences among businesses, and agencies of government, and
governments, and fields of endeavor.

 > Further, how is the opinion expressed in Ms. Gorman's post less
 > appropriate to this list than the many others that I have read here on
 > various topics suggesting that government is uniquely competent?

Unsupported opinion that government is uniquely [in]competent at technical
work is as worthless as any unsupported opinion, and isn't a risk of
computing.  Let's go elsewhere for our unsupported opinion.  I'd prefer it
to be omitted from discussion here, or perhaps presented only as speculation
when accompanied by facts that relate to risks of computing.  Miss Gorman's
examples also fail the sniff test, in a partisan way.

 > Electronic voting systems are IT projects largely contracted by
 > government exclusively to favored private (some would write
 > "mercantilist") contractors (Diebold, Sequoia, etc.)

What does "contracted" mean here?  I take it as a weasel word.  Are current
commercial electronic voting products designed and developed under contract
to governments with accountability to the contractor?  Or are they simply
commercial products developed and sold, in the usual way, to meet a
perceived market among public officials ignorant or desperate enough to be
induced to buy them?  In this venue I believe we know how badly most
electronic voting products fail important criteria that representative
governments should attend to for voting.

We -- the world, not just the USA -- are only now undertaking serious
discussion of what we need for non-paper balloting to be useful and
trustworthy.

My final point was, of course, to say that we needn't go far to find
atrociously bad software, some of it in very wide use, that was inarguably
developed entirely by private industry.


eCrime Researchers Summit CFP

Monty Solomon <monty@roscom.com>
Sat, 23 May 2009 23:49:55 -0400

The fourth annual APWG eCrime Researchers Summit will be hosted in Oct 2009,
in Tacoma, WA.

Original papers on all aspects of electronic crime are solicited for
submission to eCrime '09. Topics of relevance include but are not limited
to:

* Phishing, rogue-AV, pharming, click-fraud, crimeware, extortion and
  emerging attacks.
* Technical, legal, political, social and psychological aspects of fraud and
  fraud prevention.
* Malware, botnets, ecriminal/phishing gangs and collaboration, or money
  laundering.
* Techniques to assess the risks and yields of attacks and the success rates
  of countermeasures.
* Delivery techniques, including spam, voice mail and rank manipulation; and
  countermeasures.
* Spoofing of different types, and applications to fraud.
* Techniques to avoid detection, tracking and takedown; and ways to block
  such techniques.
* Honeypot design, data mining, and forensic aspects of fraud prevention.
* Design and evaluation of user interfaces in the context of fraud and
  network security.
* Best practices related to digital forensics tools and techniques,
  investigative procedures, and evidence acquisition, handling and
  preservation.

http://www.ecrimeresearch.org/2009/cfp.html

Please report problems with the web pages to the maintainer

Top