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 22 Issue 47

Monday 6 January 2003


Bruce Schneier: Counterattack and vigilantism
Monty Solomon
Risks of diverse identification documents
Markus Kuhn
Over 160,000 join Massachusetts list to block telemarketers
Monty Solomon
Automakers block crash data-recorder standards
Monty Solomon
Re: O Big Brother, where are thou?
Jerrold Leichter
Re: Caller ID untrustworthy
Danny Burstein
Jerrold Leichter
REVIEW: "Minimizing Enterprise Risk", Corinne Gregory
Rob Slade
REVIEW: "Enterprise Information Security", Peter Gregory
Rob Slade
REVIEW: "Enterprise Security", David Leon Clark
Rob Slade
Info on RISKS (comp.risks)

Bruce Schneier: Counterattack and vigilantism

<Monty Solomon <>>
Mon, 6 Jan 2003 08:38:53 -0500

Excerpt from
	CRYPTO-GRAM, December 15, 2002
              by Bruce Schneier


This must be an idea whose time has come, because I'm seeing it talked about
everywhere.  The entertainment industry floated a bill that would give it
the ability to break into other people's computers if they are suspected of
copyright violation.  Several articles have been written on the notion of
automated law enforcement, where both governments and private companies use
computers to automatically find and target suspected criminals.  And
finally, Tim Mullen and other security researchers start talking about
"strike back," where the victim of a computer assault automatically attacks
back at the perpetrator.

The common theme here is vigilantism: citizens and companies taking the law
into their own hands and going after their assailants.  Viscerally, it's an
appealing idea.  But it's a horrible one, and one that society after society
has eschewed.  ...

Risks of diverse identification documents

<Markus Kuhn <>>
Sun, 05 Jan 2003 01:09:40 +0000

The Home Office is currently running a consultation exercise on the
introduction of an identity infrastructure for Britain. This would consist
of a biometric database with basic records of the entire population. Anyone
in the database would be able to get an identity card, which would
essentially enable the holder to grant easily read access to his or her
record to any peer who needs some form of assurance about one's
identity. Details on the consultation are on

The system proposed is nothing unusual and quite similar to what most
European and many Asian countries have used successfully for several

Such identity infrastructures are generally widely accepted in these
countries, where most people consider them today to be a desirable and
effective protection against what has become known in some countries that
still lack them as "identity theft".

Nevertheless, there is fierce opposition to the proposals from various
British privacy advocacy groups. Similar discussions can be observed at the
moment in the US and Japan.

While much of the opposition is of a somewhat religious/tinfoil-hat nature
and therefore difficult to address, some of it has been voiced by notable
computer-security experts and therefore deserves some serious response.

The probably most commonly recurring theme is that the introduction of a
national identity card would lead to over-reliance on a single document. The
need to corrupt only the issuing procedures of a single mechanism — so the
often expressed concern — would ultimately make identity theft easier
rather than harder. This is probably based on the implicit assumption that
independent identity systems perform independent checks with statistically
independent failure probabilities. Therefore their security should increase
exponentially with the number of verification systems and more would be

Defense-in-depth and its use of multiple diverse security mechanisms is in
general a feature of sound security engineering. However, applying this
general idea in the context of government infrastructures against identity
theft this way is in my opinion horribly wrong and naive for a number of
reasons, which I'd like to address very briefly.

The most obvious problem is that the UK's present alternative --
identification based on multiple documents and issuing procedures — adds
very little as none of the currently widely available documents is protected
by controls of desirable strength. This is just illustrated again by recent
media demonstrations on how easily it is to abuse UK birth certificates:

In practice, anyone wishing to verify an identity gets only the *minimal*
protection of all the ID schemes in common use, because as soon as you break
one of them, you can quite easily proliferate your fake identity into
several other systems. Get a fake UK birth certificate (fairly easy) and
apply with it for a fake UK drivers license (therefore also not much more
difficult), use both to get a fake UK passport and all three to comfortably
get fake account access, education degrees, travel documents, security
clearances, etc. etc.  Most of the existing systems depend on each other,
which leads easily to circular verification (A thinks B knows I and B thinks
A knows I).  They all lack the somewhat more expensive direct checks of
non-document evidence that for example a properly protected distributed
add-only database of the biometric long-term history of those registered
could support economically and effectively.

Multiple documents? Unfortunately, the world of fake ID documents currently
works more like "Buy one, get three more free!" The number of systems
doesn't count much after all.

But this is not the only reason why it is so crucial to have at least one
identification scheme that is seriously difficult to break, while having
more than one of these is unlikely to be worth the cost and hassle.

There is first of all also the problem that within a single infrastructure,
it is far easier for those in charge of its integrity to verify and ensure
that the overall policies such as the separation of duties for critical
checks really leads to checks that are independent by design, and not by

Another reason is that the costs for the training/equipment/time/etc.
necessary for the adequate verification of security documents increases at
least linearly with the number of different document types accepted. And the
risk of fraudsters finding by brute-force search one accepted type of
identification for which a particular verifier is not well prepared to
recognize comparatively simple fakes increases even exponentially with the
overall number of different identification forms accepted.

Hence I am not surprised by the desire in the UK government to finally also
offer its tax payers one single simple cheap properly engineered and run
identity infrastructure. It is needed to replace all the existing often
ridiculously weak alternatives (including old birth certificates, old
driving licenses, magstripe-cards, knowing mother's maiden name or showing a
laser-printed utility bill) that are all currently used by especially the UK
financial industry as acceptable means for gaining access to critical
personal information and property.

Perhaps the discussion should first of all be driven by comparing actual
practical identity-theft versus privacy-violation statistics in countries
with and without proper government-provided identification infrastructures,
instead of naively applying generic security recipes such as
more-mechanisms-are-better to an application area with far more specific

Markus Kuhn, Computer Lab, Univ of Cambridge, GB

Over 160,000 join Massachusetts list to block telemarketers

<Monty Solomon <>>
Fri, 3 Jan 2003 19:38:03 -0500

The brand-new Massachusetts anti-telemarketing Do-Not-Call Registry had
20,000 people enroll even before it opened officially on New Year's Day, and
then 140,000 more in its first two days of official existence.  State
officials anticipate that one-third of Massachusetts' 3 million residential
customers will sign up in the first month.
  [Sources: Bruce Mohl, *The Boston Globe*, 3 Jan 2003; and Signup begun to
  ward off telemarketers, Associated Press, 1 Jan 2003' PGN-ed]

Automakers block crash data-recorder standards

<Monty Solomon <>>
Mon, 30 Dec 2002 00:16:03 -0500

Highway safety could be vastly improved if black boxes that record
information about car crashes were standardized, experts say, but they
contend that vehement objections from the automobile industry are thwarting
efforts to set a standard.  About 25 million late-model cars and trucks,
most built by General Motors and Ford, carry the boxes, which record crash
information including how fast a vehicle was moving, whether the seat belts
were buckled and how big a jolt the occupants suffered at impact. ...
[Source: Matthew L. Wald, *The New York Times*, 29 Dec 2002; PGN-ed]

Re: O Big Brother, where are thou? (Nilges, RISKS-22.45)

<Jerrold Leichter <>>
Sat, 4 Jan 2003 10:53:08 -0500 (EST) (Edward G. Nilges) notes that TIA — which he doesn't
like — will apparently be based on the commercial Groove software product
and notes that those TIA is targeting will thus have access to the same
software and can modify what they do to avoid being spotted by it.
Preventing this, he claims, is equivalent to the Halting Problem.  The
politicians, as usual, are ignoring "the facts" because they are

Nonsense.  The Halting Problem has nothing whatsoever to do with the use of
off-the-shelf software, with TIA, or with anything I've seen proposed.  I
have many doubts about TIA myself, but the last thing we need is
pseudo-science — scientific words used inappropriately to give an
imprimatur of "objective, scientific fact" to an unrelated argument.  (See
the use of "energy" in any ad for crystals or other new-age, hmm, product.)

Why does the Halting Problem have nothing to do with this?  Does Mr. Nilges
seriously believe that Groove, whatever it might do, comes out of the box
configured to search for terrorist activity?  Let's get real here: Any
product of this sort is a framework; you tune it to look for what you think
is of interest.

Let's apply Mr. Nilges's argument to a simpler setting.  I propose to scan
mail messages for the use of various terms of interest using my secret,
proprietary perg program.  You wish to send messages that won't trip my
detector.  Does it help you in your attack if you find out that perg is
actually grep, which you have a copy of?  What you need to know is what
keywords I'm looking for — not *how* I'm searching for them.  Sure, maybe
knowing that I'm using regular expressions will help you in theory, but
unless you are willing to use messages of unbounded length, there actually
isn't any difference between regular languages and even unrestricted

Now, no one would propose using grep, or any such simple-minded search, for
this kind of thing today — whatever jokes Mr. Nilges makes about
"hackerz". If we start at the lexical level, the existence, for many years
now, of text-to-speech converters with human-level performance means that
alternate spellings that have recognizable pronunciations can be readily
recognized.  But a few minutes with even a program that's way behind the
state of the art — the grammar checker in Word — shows that programs these
days do a reasonable job of recognizing fairly deep syntactic and semantic
aspects of natural language.  Or try some of the translators out there -
they can produce some hilarious results, but look at how often they get the
basics right.  If what you are looking for is a system that stands a good
chance of picking up "suspect" text, and you are willing to accept false
positives — the technology is probably there.

Beyond all this, like the silly MIT paper about random vs. targeted
searching at airports, Mr. Nilges ignores the fact that, while any search
system will probably end up looking at many "incidental" aspects of (say)
terrorism (e.g., buying one-way tickets), some are fundamental (if you want
to produce a bomb, you need explosives, and while there are a variety of
explosives around, but not an unlimited variety), and some are incidental
but difficult to change (you *could* receive terrorist training anywhere,
but in practice there are only so many places in the world where there are
training camps; visiting those areas is a pretty good indicator).  And even
the "pure incidentals" can be valuable as long as they are secret.

There are many legitimate complaints to be made about TIA on social and
political grounds.  There are also practical issues of implementability,
though many have more to do with scaling than anything else — data mining,
difficult as it is to justify on theoretical grounds, seems to work well
enough that many businesses are spending — and saving — questions to

Re: Caller ID untrustworthy (Lodge, RISKS-22.46)

<danny burstein <>>


On the other hand, if you call from your work number then the service rep
will ask quite a few more questions.

Now the key thing here is, as the original poster pointed out, the validity
and accuracy of the displayed phone number.

And yes, standard "caller id" (more officially known as "calling party
number" or CPN) can be spoofed. Or, for that matter, be inaccurate. Or
wrong. Sometimes maliciously, sometimes for good reason.

A legitimate purpose, for example, would be at a hospital. When a nurse
calls out from the fourth floor intensive care unit the CPN might be sent
over as the main hospital number. On the other hand, a telemarketer may have
other reasons for making you think a call is local...

However, when you call a 1-800/888/877/866 (and soon 855) toll-free "area
code" [a] number such as in this case, the phone number showing up on the
display is NOT the CPN, but rather is courtesy of Automatic Number
Identification (ANI). This number is generated and sent across by the telco,
NOT by your equipment, and is much, much, harder to falsify.

(ANI is used internally by the telcos and the long distance carriers and
similarly connected groups for, among other things, billing purposes.) [b]

While these two numbers (CPN and ANI) are often the same, and in the case of
residential users and small businesses are almost always identical, this is
not always the case.

But again, the key point for RISKS is that spoofing ANI takes a lot more
knowledge, equipment, and access, than commonly available.

[a] 800/888/877/866 "area codes" are technically called "service access
codes" since they don't have geographic distinctions. In the Old Days the
first three digits of the phone number following the 800 did provide
destination routing — for example, 800-225-.... was the Boston area, but
that hasn't been the case for a long, long, time.

[b] since the company you're calling pays the charge, they have the right to
get a full detailed listing of the phone numbers reaching out to them.  In
the case of AMEX, etc., this is a realtime display on the service rep's
screen — which will also pull up your account info with them. The local
tow-truck company, on the other hand, may simply get it as a printout in the
monthly bill.

Re: Caller ID untrustworthy (Lodge, RISKS-22.46)

<Jerrold Leichter <>>
Sat, 4 Jan 2003 09:43:22 -0500 (EST)

  [Much of the content of Danny's message (above) was also noted in detail
  by Jerrold Leichter.  In order to avoid duplication, I have omitted part
  of Jerry's message, but included his last paragraphs, where CLID refers to
  Calling Line ID, also known as Calling Number ID, and incorrectly as
  Caller ID.  Apologies if I left out something nonduplicative.  PGN]

By its nature, ANI must be difficult to forge.  (Also by its nature, it may
not point to a number that would make sense to the average person: It
identifies the line that should be billed, which may or may not correspond
to a dialable telephone number.)  Telephone companies want to be paid, and
won't let someone into a position where they can specify ANI unless they are
sure they will be good for the charges.  PBX users can specify CLID, but ANI
is set at "the other end of the link".  Does this mean ANI can't be faked?
Certainly not, but the massive fraud *against them* that such fakery would
allow would certainly drive the Telcos to fight it vigorously.

Just to complete the picture: *Receiving* ANI isn't cheap.  Commercial-scale
800 services from the major Telcos deliver true ANI.  Consumer 800 number
services have no way to deliver ANI, since consumers have to direct way to
receive it.  But there's an intermediate level: Some of the cut-rate 800
providers sell services that deliver what looks like ANI information, but is
actually derived from CLID (since that way they don't have to pay to get the
ANI from the Telco they connect to).  Obviously, you as a customer have no
way of knowing if the company you called is fooling itself by buying el
cheapo 800 service — but on the list of things to worry about, that
certainly can't be all *that* high.  — Jerry

REVIEW: "Minimizing Enterprise Risk", Corinne Gregory

<Rob Slade <>>
Mon, 6 Jan 2003 08:09:27 -0800

BKMIENRI.RVW   20020916

"Minimizing Enterprise Risk", Corinne Gregory, 2003, 0-273-66158-2,
%A   Corinne Gregory
%C   London, UK
%D   2003
%G   0-273-66158-2
%I   Prentice Hall/Financial Times
%O   UK#156.99/C$319.99 +1-201-236-7139 fax: +1-201-236-7131
%P   120 p.
%T   "Minimizing Enterprise Risk: A practical guide to risk and

Chapter one defines four types of risks--and immediately contradicts itself
with tables of other types of risks.  The basic point seems to be that risks
exist.  Chapter two looks at the new product development process and
reputation management (after all, one type of risk is bad publicity).  There
is a look at risk mitigation, but not risk acceptance or avoidance, a
cost/benefit analysis that is not very detailed, and a contrived use of the
"9/11" World Trade Center disaster (but no mention of the brokerage firm
that survived) that undercuts the ultimate message about having a disaster
plan.  Enterprise continuity, in chapter three, has, like other chapters,
good ideas mixed in with a random collection of topics from business
continuity planning, disaster recovery, incident response, contingency
planning, and other areas.  Business impact analysis is proposed as a
justification for planning, in chapter four, although it should be part of
risk analysis itself.  Otherwise this material is pretty basic; get a
committee, list the risks, think of what to do about them; the type of thing
you would see in any decent article on risk management.  Chapter five states
that Internet use is risky, and has a (short) list of some precautions.

Anyone who thinks that they understand risk management or business
continuity planning from reading this book is seriously misled, and possibly
a liability to the company.

copyright Robert M. Slade, 2002   BKMIENRI.RVW   20020916    or

REVIEW: "Enterprise Information Security", Peter Gregory

<Rob Slade <>>
Fri, 3 Jan 2003 08:09:33 -0800

BKENINSE.RVW   20020916

"Enterprise Information Security", Peter Gregory, 2003, 0-273-66157-4,
%A   Peter Gregory
%C   London, UK
%D   2003
%G   0-273-66157-4
%I   Prentice Hall/Financial Times
%O   C$19.99/UK#156.99 +1-201-236-7139 fax: +1-201-236-7131
%P   145 p.
%T   "Enterprise Information Security: Information security for
      non-technical decision makers"

The executive summary states that this book is intended to present
information security to executives.  The introduction certainly shows that
it isn't intended for technical people, who would ask what the difference
was between access over the Internet and remote access, or a network using
TCP/IP and the Internet.

Chapter one asserts that the events of September 11, 2001 woke executives up
to the importance of security.  (Yeah, right.)  However, there is a good
analysis of the reasons that the Code Red/Nimda worm was successful.  The
definition of a threat, in chapter two, is pretty bad, and the definitions
of various types of malicious software are really bad.  The section on
hacking lists a variety of attacks (heavy on social engineering), the
"hacker profiles" concentrate on system exploits, there is a random list of
security problems, and then an surprisingly good definition of
vulnerability.  Authentication and authorization are reasonably handled, but
confused with extraneous details in chapter three.  Access control is
equated with firewalls, and the discussion of cryptography is all right but
full of minor errors.  (RC 2 and RC 4 have been compromised, Skipjack has
been released for limited review, a digital signature does need a key but
not necessarily an additional password, the loss of a key is not sufficient
to repudiate a digital signature, and the ping-of-death does not compromise
integrity.)  The material on antivirus protection refers only to scanning,
and the material on audit deals only with logs.  Chapter four is supposed to
be about policies, but actually concentrates on procedures, containing
random thoughts and many gaps.  People are the weak link in security, we are
told in chapter five, and, as with other sections it uses non-standard terms
in the discussion.  More haphazard thoughts are in chapter six, while
chapter seven has a poor definition of privacy and a grab bag of topics.  In
chapter eight a casual list of topics seem to be indiscriminately assigned
to the standard important/urgent quadrant chart.

OK, this is not intended for professionals; it is intended for managers.
But, even if we give full reign to the usual jokes — those who can't, do;
those who are incapable of mastering anything, go into management — it's
still bad form to deliberately mislead them this way.

copyright Robert M. Slade, 2002   BKENINSE.RVW   20020916    or

REVIEW: "Enterprise Security", David Leon Clark

<Rob Slade <>>
Thu, 2 Jan 2003 08:22:00 -0800

BKESTMDG.RVW   20020916

"Enterprise Security", David Leon Clark, 2003, 0-201-71972-X,
%A   David Leon Clark
%C   P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario  M3C 2T8
%D   2003
%G   0-201-71972-X
%I   Addison-Wesley Publishing Co.
%O   U$39.99/C$62.99 416-447-5101 fax: 416-443-0948
%P   264 p.
%T   "Enterprise Security: The Manager's Defense Guide"

The preface is heavy on buzzwords (and a few spelling errors) with little
attention paid to concepts and structure.  Part one would like us to think
of the forging of a new economy.  Chapter one asks "what is e-business,"
and, with a little re-interpretation of history (the Internet had been in
existence for twenty two years and had five million users, a significant
number private and commercial, before it "became available to the public"
according to this book) and ignoring of inconvenient facts (the
hyperinflation of dot com IPO stocks is stated to prove the success of
e-business just before we are told that the dot com failure was inevitable
because of stock hyperinflation) tells us that e-business uses the net and
makes money.  Some security jargon is introduced in chapter two.  A confused
recycling of trade press myths about blackhats, in chapter three, seems to
state that these are the only malicious opponents of e-business: there is no
mention of insider attacks.

Part two looks at protecting information assets in an open society.  Chapter
four demonstrates an amazingly consistent failure to understand the
technologies supposedly being explained: a De-Militarized Zone (DMZ) is, by
definition, not abandoned outside the firewall, and Simple Key Management
for IP (SKIP) is not a virtual private network (VPN) product.  There are
more buzzwords, miscellaneous security concerns, and more mistakes (ActiveX
is *not* multi-environment) in chapter five.

Part three talks about waging war for control of cyberspace.  Chapter six
looks at attacks by syntax, and demonstrates more TCP/IP errors.  (Packet
filtering is not exactly built into IP: the ability to handle a packet based
on destination is central to the idea of networking.  The ping-of-death has
nothing to do with fragmentation offsets since it is a single packet, and it
is not too small, but too large.)  There is a confusion of attack scripts
and script viruses (and cookies, too, for good measure) in chapter seven.
Countermeasures and attack prevention, in chapter eight, actually looks
(tersely) at incident response.  The material isn't too bad, but has very
little detail.  Having talked about DDoS (Distributed Denial of Service) in
chapter six, the attack now gets more pages, but little more detail.
Chapter ten is a grab bag of random safeguards and countermeasures, as is

Part four deals with active defense mechanisms and risk management.  Chapter
twelve, entitled vulnerability management, suggests collecting alerts.
Given what we've seen so far, it is strange that chapter thirteen *does*
address the nominal subject of risk management, albeit not very well.

This confused collection of random concepts adds nothing of value to the
security literature.

copyright Robert M. Slade, 2002   BKESTMDG.RVW   20020916    or

Please report problems with the web pages to the maintainer