Forum on Risks to the Public in Computers and Related Systems

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

Volume 2: Issue 39

Friday, 11 Apr 1986

Contents

$36 million accounting mistake

Graeme Hirst

Admissability of computer files as evidence?

Kathryn Smith

"Rapid advance" of SDI software

Walt Thode

Blame-the-computer syndrome

JAN Lee

Hackensack Phone Snafu

Dirk Grunwald

Info on RISKS (comp.risks)

$36 million accounting mistake

Graeme Hirst <gh%utai%toronto.csnet@CSNET-RELAY.ARPA>

Thu, 10 Apr 86 12:10:32 est

[From the [Toronto] Globe and Mail, 10 April 1986]

BLUNDER BY ALBERTA COMPUTER LEADS TO $36 MILLION MISTAKE

A botched computer operation jeopardized the [Canadian province of] Alberta
Government's ability to keep track of vehicle licence revenue, causing
$36 million too much to be reported in a bank balance, the province's
Auditor-General reported yesterday.

  The Solicitor-General Department's new motor vehicles computer system was
designed with little help from department accounting staff, an omission which
``undoubtedly'' led to many of its weaknesses, said Auditor-General Donald
Salmon.

  The division's bank balance was shown at $48 million on March 31, 1985, when
it was actually $12 million.

  In addition, the vehicles division lost track of accounts which could not
be immediately processed, and unearned revenues were misstated by $2 million in
March of 1985.

  ``These and other ancillary problems were caused largely by insufficent
direction and control by senior financial management,'' the report said.

  The Auditor-General picked up similar problems in 1981-82 in a massive new
computer system developed to keep track of about $2 billion a year in natural
gas royalties.

  Oil revenues were miscalculated in a confused federal-provincial transfer of
information involving three different price categories under the old regulated
pricing system.

  The governments later agreed to forget it rather than try to sort out the
mess.

  ``The province didn't lose money,'' Mr Salmon said.  ``You could probably say
the producers lost some . . . but we did not quantify.''

Admissability of computer files as evidence?

Kathryn Smith <kathy%gsg.UUCP@harvard.HARVARD.EDU>

Thu, 10 Apr 86 12:02:39 est

    This arises out of a discussion in mod.legal over the meaning of UNIX
as a trademark, and how it (the name) might/might not pass into the public
domain by becoming a generic descriptive term for a type of operating system
rather than refering to a specific product of AT&T.  One of the postings
which I quote below raised the broader question of the use of postings to
a computer network as evidence.

    In a recent posting (Message-ID: <8604011618.AA15083@bu-cs.ARPA>),
Barry Shein said the following:

    "What immediately occurs to me is that if I were an ATT lawyer I
    would squirrel away the note imploring people not to attribute
    UNIX as a (whatever) of (whomever.) It could prove very useful
    to open an argument that any appearance of it coming into
    common use was in fact a conspiracy on the part of the technological
    community."

   I have no idea of the likelihood of the "conspiracy" defense working to
hold onto AT&T's trademark, however the part about holding onto the note
got me to thinking.  Does anyone out there know if any precedents have been
set for the admissability/inadmissability of computer files as evidence in
court?

    I, for one, find the thought that some court of law might, in ignorance,
accept computer files as evidence frightening.  Certainly on UNIX if you can
get access to a privileged account, whether legally or illegally, you can
change anything on the system, including editing i-node entries to alter
creation dates, etc., with no way I can think of of proving that alterations
were made unless the hacker does something extra-ordinarily stupid.  I suspect
that the same is true of most other systems.  No matter how good system
security is, given sufficient knowledge of how it works, it is breakable.

    Coupled with the unfortunate tendency of the layman to accept whatever
comes out of a computer as gospel, this provides some very strong reasons for
not trusting computer files as evidence, but considering the growing number of
transactions being performed by/on computers, there are, or soon will be, a
great number of areas where the computer's audit trail may be the only evidence
of a transaction.  Have any precedents been set already, and if not, what do
people think the solution is?

                    Kathryn Smith
                    (...decvax!gsg!kathy)
                    General Systems Group
                    Salem, NH

   [This is a very valid question.  The crypto community has all sorts of
    techniques for crypto sealing for integrity and crypto authentication.
    Reasonable techniques exist to give some better assurance, but there
    are always going to be some internal vulnerabilities.  However, since
    most legal and administrative people do not yet recognize the ease with
    which on-line evidence -- including audit trails -- can be altered, and
    for other reasons as well, these techniques are not yet in widespread
    use.  PGN]

"Rapid advance" of SDI software

<thode@nprdc.arpa>

9 April 1986 0807-PST (Wednesday)

In an article in the Sunday San Diego Union, Gregory Fossedal (Copley
News Service) discusses the "rapid advance of SDI."  He indicates that
progress is good enough that a "decision to deploy a Star Wars defense ...
could be made before Ronald Reagan leaves office."  He describes some
progress made in lasers and other hardware areas.  He then goes on to
discuss progress by software engineers, and says that "concepts in
computer software ... have leaped ahead."  He indicates that critical
arguments "...that 'a single error' could cripple the whole shield apply
only to outmoded types of unwieldy, highly centralized software.  Thanks
to new software ideas, Star Wars defenses need not be run by a grand
central brain."

--Walt Thode (thode@nprdc)

   [Announcements of great BREAKTHROUGHS often coincide with great BREAKDOWNS
    -- in communication and common sense.  This one is being hyped like a
    great BREAKFAST cereal -- distributed Wheaties are better than old
    Wheaties, the breakfast of chumpions.  Don't put all your eggs in one
    basket -- just use thousands of baskets instead, and train the hens to
    BREAKDANCE in space.  But don't forget to distribute the roosters as well.
    Walt, thanks for the enlightenment.

    I note that in principle there are indeed some software engineering
    advances, but nothing that GUARANTEES that distributed systems are sound
    -- especially in their operating environments.  The tradeoffs are very
    complex, and thus this is not a simple discussion.  Many problems of
    centralized systems reappear in other guises in distributed systems, and
    wonderful new problems arise.  Perhaps some day we will have a
    dispassionate, technically motivated analysis -- although many of the
    arguments are nontechnical.  PGN]

Blame-the-computer syndrome

<JANLEE%VTCS1.BITNET@WISCVM.WISC.EDU>

Wed, 9-APR-1986 09:37 EST

One of my colleagues, a visiting prof. from the UK, bought a new Ford Escort
in mid-February and at the same time purchased the "Extended Warranty"
package.  Following a trip to Florida for Spring break, the vehicle broke
down outside Daytona (that may suggest this is a put-up job!!)  on Saturday
afternoon March 29th (also Easter Weekend).  Calling the 800 number he was
referred to a specific repair shop.  On arriving there the owner called the
800 number to confirm the warranty and was told that there was no record of
a warranty "in the computer" and that any additional enquiries would have to
wait until Monday.  They stayed in a hotel over the weekend (at a high rate
since they had no reservations and limited means of transportation) and on
Monday were again informed that there was no record of their warranty.  It
took most of the rest of that day to have the dealer from whom they
purchased the car to confirm that ARTh a warrenty did exist and to have the
repair shop agree to START the repairs.  It turns out that the dealer
doesn't send in the warranties until the end of each month, and the backlog
doesn't allow the warrantor to get them in the computer for perhaps another
month.  This is probably based on the probability that a new car won't need
repairs in the first two months and in any case the owner would probably be
close to home still!  Here is a typical case of having a computer in the
system and thus being able to "hide" behind it.  By the way, check you own
extended warranty to see if it covers the cost of hotel accomodations!

Also, I am still researching the Melbourne Bridge Failure for you -- I have
got the sequence of events and a precis of the findings of the Royal
Commission which blamed the failure on a computer program, but I am waiting
for a copy of the actual report before I send you more.  The sequence of
events is well documented in the London Times but I am not sure I want ot
trust their reporting on this about the program use until I see the report.

JAN

PS. Did you see the Hackers Report in CACM this month?   [Yup.  Arrived today.]

Hackensack Phone Snafu

Dirk Grunwald <grunwald@b.CS.UIUC.EDU>

Thu, 10 Apr 86 16:04:50 CST

According to a NYT article reprinted in the Daily Illini, a local student
newspaper, the phone system in Hackensack N.J. experienced a problem with
billing long-distance phone calls from pay-phones. I quote:

    Technology in an electronic switching center here failed
    New Jersey Bell, and for nearly two months perhaps half
    the international calls placed from 400 pay phones around
    town went through without charge, according to Ted Spencer,
    a spokesman for the company.
      ``Apparently a problem developed in a computer program - in
    the software,'' Spencer said. ``We don't have a record of the
    calls that got through. They bypassed the billing system.''

Does anyone have anymore in-depth information concerning this? Several
people who used the loop-hole were arrested and charge with theft of
services.

Dirk Grunwald, Univ. of Illinois

Report problems with the web pages to the maintainer