The RISKS Digest
Volume 23 Issue 47

Monday, 2nd August 2004

Forum on Risks to the Public in Computers and Related Systems

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

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…

Contents

Computer Failure Grounds and Delays Flights on 2 Airlines
Monty Solomon
E-voting critic issues challenge to hackers
PGN
VoIP — Voyeurism over Internet Protocol?
NewsScan
Russian extortionists: each did his bit of work
NewsScan
The Mr Micawber Syndrome
Michael Bacon
Implementing Information Security: Risks vs. Cost
Gideon T. Rasmussen
Re: Cosmic ray hits Brussels election — really?
Peter B. Ladkin
Dirk Fieldhouse
Sergio Gelato
REVIEW: "Official [ISC]^2 Guide to the CISSP Exam", Hansche et al.
Rob Slade
Info on RISKS (comp.risks)

Computer Failure Grounds and Delays Flights on 2 Airlines

<Monty Solomon <monty@roscom.com>>
Sun, 1 Aug 2004 23:39:46 -0400

A computer problem grounded American Airlines and US Airways flights from
coast to coast on Sunday morning, causing delays that lasted all day. A
computer company official said human error was the likely cause.  American
had its planes back up after two hours, while US Airways flights resumed
after about three.  [Source: Associated Press, 2 Aug 2004]
  http://nytimes.com/2004/08/02/national/02delay.html


E-voting critic issues challenge to hackers

<"Peter G. Neumann" <neumann@csl.sri.com>>
Sun, 1 Aug 2004 13:44:40 PDT

At the annual Black Hat convention in Las Vegas last week, Rebecca Mercuri
[who will be a Radcliffe Fellow at Harvard in the coming academic year]
challenged computer hackers to test whether it is possible to rig an
election held using the unauditable paperless electronic voting machines
that have been a frequent subject of discussion in RISKS.  She suggested the
VoteHere software would be a good system to consider.  She also urged other
voting system companies to make their software available for scrutiny.
``I'm tired of hearing members of the election community say that no
problems have occurred with electronic voting systems when every election
there's plenty of newspaper reports of `glitches.' ''  (Vendors have made
such analyses difficult by keeping their software proprietary.)  [*San Jose
Mercury News*, 30 Jul 2004; PGN-ed]
  http://www.siliconvalley.com/mld/siliconvalley/9278952.htm


VoIP — Voyeurism over Internet Protocol?

<"NewsScan" <newsscan@newsscan.com>>
Mon, 02 Aug 2004 10:03:45 -0700

With businesses and individuals flocking to Internet telephony as a cheap
alternative to pricey landline phones, hackers are discovering new
opportunities for eavesdropping and making mischief. Tapping phones by
hacking into servers and hard drives is much easier than conventional
wiretapping and analysts say even though very few incidents have been
reported to date, it's just a matter of time. "Once you are running an
Internet phone network, all those threats you worry about in the data world
will be transferred to the voice world," says one security consultant.
"Voice over Internet phones are not in the spotlight of hackers yet, but in
this voyeuristic world, if someone can listen in on people's conversations
and get a thrill, they will." In addition, voice packets offer new
opportunities for disguising and distributing malignant code. "You can spoof
a packet and insert myself into a communications flow," says a systems
engineer for Mirage Networks. "This kind of threat has been around for a
while for data, but now it will move into voice. As you see a broader
acceptance of voice over Internet, you'll see more spoofs."  [*The New York
Times*, 2 Aug 2004; NewsScan Daily, 2 Aug 2004]
  http://www.nytimes.com/2004/08/02/technology/02virus.html


Russian extortionists: each did his bit of work

<"NewsScan" <newsscan@newsscan.com>>
Thu, 29 Jul 2004 08:56:38 -0700

Police authorities in Russia have broken up a hacker ring that extorted
money from British bookmakers by flooding online betting sites with false
requests for information in "denial-of-service" attacks and then sending
e-mail demanding money for stopping the attacks. Investigators said that
bookmaker companies were the most convenient prey because the attacks could
be timed to major sport events. The ring consisted of well-educated people
in their early 20s who had found each other on the Internet and agreed to
work together in the extortion. A Russian police official said: "There was
no chief organizer in plain terms, each of them did his bit of work. And
they didn't consider themselves criminals."  [AP 29 Jul 2004; NewsScan
Daily, 29 Jul 2004]
  http://apnews.excite.com/article/20040728/D843R7EG1.html


The Mr Micawber Syndrome

<michael_bacon@synigystic.com>
Fri, 30 Jul 2004 07:22:49 +0100

Once again (in RISKS-23.46), we have examples of what I call the, "Mr
Micawber Syndrome".  This syndrome was exhibited very strongly in the
stories about the problems of the *Chicago Tribune* and the DC Metro, and
also to a certain extent in those about the tethered balloon operator in
Baltimore, NASA, Microsoft, and the operators, regulators and promoters of
electronic voting systems.

For the "bibliophilically-challenged", Charles Dickens' Mr Micawber was a
man living on the bread-line for whom, always, "Something will turn up."

It appears that this mantra has become the de facto standard when things go
wrong with technology today.  My experience suggests that this very phrase
(or one conceptually synonymous) is often contemporary with the "incident"
becoming a "disaster" and, indeed, is probably the trigger for that disaster
though its reinforcement of a belief-system.

However, the belief that the causation will be resolved in some short, and
often very tightly stated, time-frame is seldom, if ever, factored into risk
calculations, either beforehand or at the time.  I have lost count of the
number of times I have seen this behaviour — and readers of these pages
will have many more stories of a similar ilk.

The RISKS stem from: (1) not considering every "incident" as a potential
"disaster"; (2) not pre-establishing a definite time following the
recognition of an incident at which its severity will be escalated to that
of a "disaster"; (3) not having a Regression Plan that has been tested and
can be trusted; (4) not having a pre-set time at which the "Disaster
Recovery" or "Business Continuity" plan is put into operation — regardless
of what else is happening; (5) not having senior managers who have been
properly informed of the RISKS (both of doing something and of doing
nothing); (6) having a belief in one's own abilities and those of one's
suppliers that transcends the reality of past experience; (7) continually
demonstrating an inability to learn from one's and others' mistakes; and (8)
too boldly going where everyone has gone before ... and met the same fate!

Michael (Streaky) Bacon, Principal, Synigystic Ltd.


Implementing Information Security: Risks vs. Cost

<"Gideon T. Rasmussen" <lists@infostruct.net>>
Thu, 29 Jul 2004 18:26:14 -0400

http://www.cyberguard.com/news_room/news_newsletter_040628security.cfm

Implementing Information Security: Risks vs. Cost
Gideon T. Rasmussen - CISSP, CISM, CFSO, SCSA

As a security professional who understands how the business world works, I
wrote this article to convey the imperative need for security professionals
and senior management to see eye-to-eye. Being motivated by business, senior
management focuses on productivity and the bottom line. It is sometimes
difficult to calculate a return on investment for security, but the damage
caused by the absence of efficient controls is far greater than the cost of
implementing them.

Over the past few years, there have been several highly publicized security
incidents ranging from fraud to terrorism. These events demonstrated the
need for disaster recovery plans and checks and balances within accounting
systems. Many threats present themselves internally in the form of
disgruntled or dishonest employees or as the result of social
engineering. Human error and neglect are also examples of internal
threats. New threats emerge daily. For more information, refer to the
CSI/FBI Computer Crime and Security Survey
(http://www.gocsi.com/forms/fbi/pdf.jhtml).

The U.S. is beginning to mandate information security based on the concepts
of due diligence and the prudent man principle. The most recent examples are
the Sarbanes-Oxley Act (SOX), the Gramm-Leach-Bliley Act (GLBA) and the
Health Insurance Portability and Accountability Act (HIPAA). Compliance with
government regulations represents a threat of a sort. Under SOX, senior
management is responsible for the accuracy of financial statements. Criminal
penalties include fines of $1-5 million and prison terms of 10-20 years. A
popular international standard is the Code of Practice for Information
Security Management (ISO 17799).

A variety of control frameworks have been developed to meet financial and IT
security concerns. Two of the leading standards are the Internal Control -
Integrated Framework - Committee of Sponsoring Organizations of the Treadway
Commission (COSO) and Control Objectives for Information and related
Technology (CobiT).

IT governance and compliance must be addressed with a formal information
security program. Basic elements include security policies, an annual audit
and internal controls to mitigate threats and vulnerabilities.  Nothing can
take the place of an information security audit
(http://www.sans.org/score/ISO_17799checklist.php).  It is critical to take
a snapshot of each site's security posture and work against the findings.

Senior management should be aware of the state of the information security
program. Usually this is facilitated through an annual security audit report
and monthly security status reports.

In the absence of current information, it is a good exercise to ask the
following questions of information security management:

* Are employees required to sign off on the general security policy and
specific policies in their functional area as well?

* How have applicable security standards been met (e.g. SOX, GLBA and
HIPAA)?

* Which control frameworks are in use (e.g. COSO, CobiT and/or ISO 17799)?

* How are logical and physical perimeters defined? Please provide rationale
and diagrams.

* Is security built into custom applications from the design phase?

* Are all systems routinely patched and hardened?

* Are strictly controlled development environments in place (e.g.,
  development, quality & user acceptance)?

* What is the maturity level of business continuity and disaster recovery
planning?

* Are accesses systematically rescinded when an employee leaves or their
role changes?

* In general, are internal controls layered (i.e., defense-in-depth
measures)?

* How are the concepts of least privilege and separation of duties
addressed?

* Is a tactical incident response program in place?

* What are the details of the security awareness program?
(http://www.cyberguard.com/news_room/news_newsletter_030926threatwithin.cfm)

* How recently have each of these topics been addressed? Are they truly
maintained?

Establishing a culture of security is critical. Information security
managers must be well versed in the breadth of the IT career field and other
disciplines as well (e.g. physical security, accounting and human resources
management). In addition, a security manager must be a passionate advocate
and an effective communicator. Interpersonal skills should include the
ability to communicate in non-technical terms.

Many small organizations lack a dedicated information security
professional. This practice should be avoided. As you can see, an effective
security program requires constant care and feeding. A dedicated information
security professional will reduce the high cost associated with unmanaged
risk.

Consider the impact on an organization if it does not adequately mitigate
risks. In the end, how an organization approaches security depends on its
appetite for risk. A healthy dose of paranoia is warranted here. After all,
the stakes are extremely high.


Re: Cosmic ray hits Brussels election — really? (RISKS-23.46)

<"Peter B. Ladkin" <ladkin@rvs.uni-bielefeld.de>>
Fri, 30 Jul 2004 09:19:49 +0200

Dirk Fieldhouse (RISKS-23.46) asks whether it has ever been confirmed
that a cosmic ray has caused a terrestrial computer malfunction.

I looked at the issue of what are called Single Event Effects (SEEs) in
2000-2001. Basically, cosmic rays are particles, gamma rays (which are also
particles — everything is a particle) and so on which come from outside the
earth's atmosphere (primary) or which are generated from primary rays by
atmospheric reactions (secondary). Cosmic radiation also keeps us alive -
thanks to all those photons which make it through from the sun.

Cosmic rays can cause bits to flip, latch up, or burn out in computer
memories. As far as I could tell, no one had recorded a processor fault due
to radiation by 2001. The problems were first noticed with the advent of
SRAMS in 1978 when the bits got small enough to be affected by alpha
particles (helium nuclei) of around 5-10 MeV (Mega-electron-Volts. Mass and
energy are identical, measured in electron-Volts). Alpha particles with
these energies can produce up to 3 million electron-hole pairs in silicon,
and 1978 was apparently when SRAMs became sensitive to noise bursts of about
that size. These alpha particles were caused by the decay of thorium, a
trace element in the silicon substrate. Refine it out, and the noise bursts
disappear. Alpha particles of these energies could also come from uranium
decay. Classic references are Ziegler and Lanford, Science 206(16):776-88,
16 November 1979, and Journal of Applied Physics 52(6): 4305-12, June 1981.

These so-called Single Event Effects (SEEs) in computer memory are a whole
branch of avionics research. Satellites and other spacecraft have to worry
significantly about them and their processors and memories are designed to
tolerate faults so caused. SEEs have been observed and measured in aircraft
avionics. Current estimates of the rate of SEEs in aviation at 30-50,000 ft
altitude are around O(10^(-9)) to O(10^(-8)) per bit per hour. That is a
single bit per 1M of memory per one hundred to one thousand hours
exposure. Radiation intensity of the same energy levels on the ground are
some two orders of magnitude lower. See Eugene Normand, Single Event Effects
in Avionics, IEEE Transactions on Nuclear Science 43, 1996, also available
from the Boeing Radiation Lab WWW site. So we are talking O(10^(-11)) to
O(10^(-10)) events per bit per hour, which is a rate of one bit per Gigabyte
(1 Byte = O(10) bits) per hour to ten hours.

Of course, it is theoretically possible that a hugely energetic particle
could come blasting through your memory and take out multiple bits. All
sorts of things are theoretically possible, but the question is whether
people have ever seen them occurring.

There was some worry in the 1990's about SEEs in power MOSFETs
(semiconductors that operate at thousands of volts, such as used in engine
control for electric railway locomotives).

Now, it is extremely difficult to determine what the causes of these SEEs
are. The SEE-and-avionics people seem convinced that the effects at altitude
are primarily due to neutrons. My particle physicist colleagues at Bielefeld
were somewhat sceptical. So I researched the literature and found only some
very indirect and questionable evidence for this oft-repeated claim. I am
inclined to be sceptical also. But this is an aside. That SEEs occur is
clear, as is the phenomenon that they are single-bit problems.

So how does one know that a particular SEE is caused by a cosmic ray?
Basically, one doesn't. It took until 1992 for people to find what they
believed to be incontrovertible evidence of an SEE in a spacecraft caused by
a cosmic-ray proton, for example. It was a publishable discovery.

Fieldhouse finds "... the possibility of a cosmic ray causing a computer
malfunction [to be] an obvious threat for space-borne systems".  My
impression is that it isn't so much of a threat because people spend a lot
of time on SEE-tolerant architectures for spacecraft. You don't want to
spend large amounts of money launching a spacecraft only to get bits
predictably fried and lose data. So you use standard bit-error correction
coding techniques implemented in silicon, and put up with the extra resource
consumption of all those extra bits. These are not mass-production chips,
after all.

I find many reasons to question a claim that a cosmic ray trashed the
results of a computer vote-counting program. First, I find it implausible
that anyone knows that flipping or latching one bit caused a miscount of
4,100 votes. I doubt whether anyone analysed the program or the hardware
architecture thoroughly enough to determine that. Show me the chip and the
latched bit. And show me the causal chain between that flipped bit and the
4,100 miscounted votes. Anything other than an SEE is a purely theoretical
possibility that one can ignore. Second, I presume no one has determined
whether the SEE in question was caused by a cosmic ray or by a noise burst
in the silicon, or by a thermal problem in the computer, or by the results
of a manufacturing error. We have had memory and processors go wrong on us,
and nobody ever knows the reasons why.  The chip or board just gets swapped
and life continues. You need large numbers of SEE events to trace their
cause, and you need large numbers of particles to correlate with the large
numbers of SEE events and a not insignificant number of competent particle
physicists and nuclear engineers to analyse the evidence to conclude that it
was a radiation event.

I wouldn't call it an urban legend, for that means a tall tale that did not
come to pass, and terrestrial SEEs caused by cosmic rays can come to pass.
But I would suspect that someone is shooting their mouth off on evidence
that is so meagre as not to come close to supporting any assertion of this
type.

I would question any results generated by a program which is claimed to be
sensitive to one SEE. Whoever determined that a cosmic ray might have caused
the problem should also have concluded that the program was so obviously
untrustworthy that none of its results should ever be believed.

Peter B. Ladkin, University of Bielefeld, Germany
http://www.rvs.uni-bielefeld.de


Re: Cosmic ray hits Brussels election — really? (RISKS-23.46)

<"Dirk Fieldhouse" <fieldhouse@gmx.net>>
Fri, 30 Jul 2004 20:27:55 +0100

To summarise the responses to this item, I have now been able to confirm the
story [4100 votes given to candidate in local Brussels election by computer
error due to cosmic ray]. It was of course actually 4096 = 2^12 votes, as
correspondent Robson and I expected.

Correspondents Coggins, Leavitt and Ladkin (see also his RISKS post 'Cosmic
Rays and Computers') confirmed that, as expected, such a malfunction could
be experienced by a terrestrial computer. The primary known effect is on RAM
and the likelihood of a 'soft error' increases with the amount of RAM and
the density of components on the chip. Even PCs nowadays, having 1Gb or more
RAM, could be noticeably (say, weekly) affected if ECC memory is not used --
unless they are located in tunnels!  Presumably this would only be noticed
if users expected the running software itself to be stable.

Correspondent Cole recalled a mini-supercomputer system in the mid-80s that
had frequent parity errors in the instruction cache because "the memory
manufacturer had omitted a mask in the memory chip packaging that protected
the memory circuits from low-level radiation due to radioactive heavy-metal
elements in the ceramic outer packaging layer".

Correspondent Baeck (special thanks) provided the election's exact location,
Schaerbeek, in his post to RISKS, and that led me to
  http://wiki.ael.be/index.php/ElectronicVotingRandomSpontaneousBitInversion
and finally to
  http://www.poureva.be/article.php3?id_article=32 (en Francais)

The event occurred in the election held on 18 May 2003. An expert review
determined that as no software defects had been found on inspecting the
source code and no test had been able to reproduce the error, it was
probably attributable to a spontaneous inversion of a bit in the RAM of the
PC (no explicit mention of cosmic rays). However the report concluded that
even if the voting system under review was not perfect the totality of
controls was sufficient to be confident in the overall result. I wonder.

To a colleague's fundamental question — how was it known that the result
was wrong — the answer is that the count was not consistent with the
proportional representation rules in the election.

So it looks like I'll have to carry on testing my software.  Thanks to all.

Dirk Fieldhouse, London, UK


Re: Cosmic ray hits Brussels election — really? (RISKS-23.46)

<Sergio.Gelato@astro.su.se>
Sun, 1 Aug 2004 16:16:50 +0200

An English-language Google search may have failed to confirm the story
of a cosmic ray being blamed for a 4096-vote error in Schaerbeek during
the 2003-05-18 Belgian parliament election, but a French-language search
was more successful, and led me to the following very informative link:
  http://www.poureva.be/article.php3?id_article=36
from which one learns that the investigation, having failed to find a
software bug, and considering the internal structure of the program,
concluded that the error was "very likely" due to a spontaneous, random bit
flip---for which cosmic rays are a possible cause. They provide a link to
  http://www.research.ibm.com/journal/rd/401/tocpdf.html
on "Terrestrial cosmic rays and soft errors" (in English).

The problem, as I (and others) see it, is not that cosmic rays are blamed
(that may be correct) but that insufficient safeguards appear to be in place
to reliably detect such errors. (Cheap hardware without ECC memory?  No
other checksums to protect the integrity of the data?) From that same web
page, translation mine:

  "The experts' report underlines that the problem is known, that solutions
  do exist, but that nothing has been done to protect oneself or to detect,
  other than by chance or from the absurdity of the results, that such a
  phenomenon has taken place."


REVIEW: "Official [ISC]^2 Guide to the CISSP Exam", Hansche et al.

<Rob Slade <rslade@sprint.ca>>
Fri, 30 Jul 2004 07:54:11 -0800

BKOIGTCE.RVW   20040618

"Official (ISC)^2 Guide to the CISSP Exam", Susan Hansche/John
Berti/Chris Hare, 2004, 0-8493-1707-X, U$69.95/C$101.50
%A   Susan Hansche susan.hansche@pec.com
%A   John Berti jberti@deloitte.ca
%A   Chris Hare chare@chris-hare.com, chare@nortelnetworks.com
%C   920 Mercer Street, Windsor, ON   N9A 7C2
%D   2004
%G   0-8493-1707-X
%I   Auerbach Publications
%O   U$69.95/C$101.50 800-950-1216 orders@crcpress.com
%O  http://www.amazon.com/exec/obidos/ASIN/084931707X/robsladesinterne
  http://www.amazon.co.uk/exec/obidos/ASIN/084931707X/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/084931707X/robsladesin03-20
%P   910 p. + CD-ROM
%T   "Official (ISC)^2 Guide to the CISSP Exam"

Once again I have to state a bias in regard to this book.  I've known about
this book since its inception, I've known and advised the authors, I
provided bits of the material, and even contributed one appendix.  (The
annotated bibliography and references--surprise, surprise.)

I was asked to review the chapters while the book was in production.  The
reason was, of course, that I had reviewed all the other CISSP (Certified
Information Systems Security Professional) guides.  Specifically, the intent
was to ensure that this manual, prepared and supported by (ISC)^2
(International Information Systems Security Certification Consortium) was
"head and shoulders" above all the other published works.  This volume is
not perfect, by any means, but it is the best of the current bunch.

Taking material from one source is copying, taking material from two sources
is plagiarism, and taking material from many sources is research.  This
volume has not only research but direct input from a great many sources.
Some are mentioned in the acknowledgements, a number of others are to be
found on the title page, since sections of major articles from the venerable
"Information Security Management Handbook" (cf. BKINSCMH.RVW) were included
or used as the basis for parts of the guide.  Even this doesn't exhaust the
contributions, since much of the work is informed by the material in the
(ISC)^2 CBK (Common Body of Knowledge) Review Seminar, and over a hundred
individuals have had the chance to augment that content.  The result is a
breadth and currency of information that exceeds any other guide on the
market.

Sample questions and exams are eagerly sought by candidates for the CISSP
exam.  This guide has a significant advantage in this regard: not only do a
number of the contributors produce questions for the exam itself (therefore
being more than passingly familiar with the style and level of difficulty
required), but the CISSP exam committee was also approached for advice and
input.  No source is able to provide "actual" CISSP exam questions, but the
examples provided in this volume are very close in form, mix, degree of
difficulty, and concept.

The book is not without its faults.  The sheer volume of the contributors
ensured that topics were covered multiple times, and not all duplicated
areas have been amalgamated.  In addition, the variety of writing styles can
make the text disjointed in places, as it moves from section to section and
subject to subject.  These factors can make the work difficult and demanding
to read and follow.

The CISSP exam, as the security field itself, is a changing target, and no
book can expect to provide the "best" coverage of the topic indefinitely.
As well, security is an immense discipline, and touches on an inordinate
number of other areas.  This work, however, has come closest to spanning the
range of subject matter necessary to challenge the CISSP exam, and is
currently the best of the guides.

copyright Robert M. Slade, 2004   BKOIGTCE.RVW   20040618
rslade@vcn.bc.ca      slade@victoria.tc.ca      rslade@sun.soci.niu.edu
http://victoria.tc.ca/techrev    or    http://sun.soci.niu.edu/~rslade

Please report problems with the web pages to the maintainer

x
Top