Forum on Risks to the Public in Computers and Related Systems
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
Volume 9: Issue 60
Monday 15 January 1990
Contents
The C3 legacy: top-down goes belly-up recursively- Les Earnest
- Dispatchinate Computerized Cab Service
- PGN
- Risks of manual page formatters and inserted text
- J. Eric Townsend
- Re: What hung the computer?
- Dave Platt
- Perils of not planning for errors
- Ted Shapin
- Wrong 800 numbers
- Steven W. Grabhorn
- Password Sharing
- Dave Bafumo
- Call for papers for computer security foundations workshop
- John McLean
- Info on RISKS (comp.risks)
The C3 legacy: top-down goes belly-up recursively
Les Earnest <LES@SAIL.Stanford.EDU>
10 Jan 90 1200 PST
After more than 30 years of accumulated evidence to the contrary, the U.S. Defense Department apparently still believes that so-called command-control- communications (C3) systems should be designed and built from the top down as fully integrated systems. While that approach may have some validity in the design of weapon systems, it simply doesn't work for systems intended to gather information, aid analysis, and disseminate decisions. The top-down approach has wasted billions of dollars so far, with more to come, apparently. I noticed the citation in RISKS 9.52 of the article, "The Pentagon's Botched Mission," in DATAMATION, Sept. 1 1989, which describes the latest development failures in the World Wide Military Command and Control System (WWMCCS). The cited article indicates that they are still following the same misguided "total system" approach that helped me to decide to leave that project in 1965. I confess that it took me awhile to figure out just how misguided that approach is -- I helped design military computer systems for 11 years before deciding to do something else with my life. In RISKS 9.56, Dave Davis and Tom Reid observe that current C3 development projects seem to be sinking deeper into the mire of nonperformance even as the plans for these systems become more grandiose and unrealistic. Please understand that I am not arguing against top-down analysis of organizational goals and functions. It is clearly essential to know which are the important responsibilities of an organization in order to properly prioritize efforts. Based on my experience, attempts at aiding analysis and decision-making tasks with computer applications should begin with the lowest levels and proceed upward IN THE CASES THAT WORK. Contrary to some widely held beliefs, many such tasks do not lend themselves to computer assistance and the sooner one weeds out the mistakes and intractable tasks the faster one can improve the areas that do lend themselves to automation and integration. A great deal of time, effort, and money can be save by approaching development in an evolutionary bottom-up way. It is essential to shake-down, test, and improve lower level functions before trying to integrate at a higher level. Trying to do it all at once leads to gross instability that takes so long to resolve that the requirements change long before the initial version of the system is "finished." Each time one moves up a level it is usually necessary to redesign and modify some or all of the system. It is much faster to do that a number of times than it is to try to build a "total system" the first time because that approach almost never works. Someone (Karl von Clausewitz?) once said that people who don't know history are condemned to repeat it. A modern corollary is that people who do know history will choose to repeat it as long as it is profitable. Unfortunately, the Defense Department's procurement policies often reward technical incompetence and charlatanism. I will support this claim with a few "peace stories" that would have been much more atrocious "war stories" if any of the systems that we designed had been involved in a real war. Fortunately, that didn't happen. The presumption that computer-communication system development should be done on a grand scale from the outset is just one of many bad ideas that have taken root within the military-industrial establishment. The reason that this misconception has persisted for decades is that there is no penalty associated with failure. On the contrary, failures are often very profitable to the contractors -- the bigger, the better. The bureaucrats who initiate these fiascos usually move on before the project fails, so if anyone tries to point fingers they can say that it was the fault of the subsequent management. While the "total system" approach is one of the more persistent causes of failure in C3 development, it is by no means the only misconception afloat. In subsequent segments I will review some other causes of historical fiascos. All of this will be ancient history, since I got out of this field about 25 years ago. Of course, many of the more recent fiascos are protected from public scrutiny anyway by the cloak of national security. (Next segment: a SAGE beginning.) -Les Earnest (Les@Sail.Stanford.edu)
Dispatchinate Computerized Cab Service
"Peter G. Neumann" <neumann@csl.sri.com>
Mon, 15 Jan 1990 12:33:13 PST
Yellow Cab in San Francisco is using a dash-mounted computer in each taxicab to facilitate dispatching and supposedly to prevent dispatchers from favoring particular drivers. However, the system ($800,000) ``remains plagued by breakdowns and by drivers grumbling that foul-ups mean a loss in income.'' "When the system is on line, it works well," said Leon Collett, first vice president of the cab firm. "But we have had transmitter problems, hardware problems, software problems." ... [Computer Snarling Yellow Cabs in S.F., Maitland Zane, San Francisco Chronicle, 15 Jan 90, p.A2.]
There's no horror story to go with this, we wised up in time... Recently, we aquired two Sun SparcStation-1s. We only bought 1 100Mb drive for each from Sun and we're (still) waiting on shipment of our CDC drive. To save space, I only installed the basics: /, /usr, development tools, and a couple of other goodies. I did *not* install the man pages, as they took up around 6Mb of badly needed space. Then I had an idea: Mount /usr/man from our DECstation 3100 as /usr/man on the sparc-1s. It worked, and I sent mail to all accounts saying that the man pages were from Ultrix/BSD, and probably shouldn't be trusted in critical apps; they were just there for ease of remembering things like which ls(1) flag does what. The next day there's mail telling me I've screwed up. There *are* man pages for the sun, and I've mounted DEC3100:/usr/man pages over them. I typed "man ar", and sure enough, there were man pages with Sun Release 4.0 Last change: RISC <pagenum> at the bottom of each page... I was astounded. Luckily, the ar commands my prof needed must have been the same, as no data was lost, and everything worked. I dismounted all nfs, and looked at /usr/man -- nothing was there. "man ar" returned an error about not finding the man pages. A little experimentation shows that the SunOS 4.0.3-4c man command inserts the above line in the formatted man pages. I think it's presuming a little too much to go ahead and cite the source/version of a manual page from within the formatting program... J. Eric Townsend, University of Houston Dept. of Mathematics
Re: What hung the computer?
<dplatt@coherent.com>
Wed, 10 Jan 90 16:10:54 PST
... It takes more than minute
for this particular CDROM to come online, during which time the
Macintosh is busied out, thus the inexplicable delay....
Part of the blame for this confusion can be laid squarely on
Apple. Their own Human Interface Guidelines specify that the
pointer should be replaced with a watch for a "lengthy
operation" (Inside Macintosh p.I-37). They often follow their
own guidelines, but not in this case.
This is probably one of those cases in which an implementation in one
part of a complex system (the CD-ROM drivers) invalidated a simplifying
assumption which had been made in another part of the system (the Finder).
During normal operations, it takes very little time for the Mac operating
system to process a "disk mount" event. The current application (the Finder,
in this case) calls MountVol(), which reads in the volume information
and adds the necessary entry to the drive queue. The delay is usually
less than a second, and so the Finder's author didn't consider it a
"lengthy" operation which required putting up the stopwatch-cursor.
There are a couple of circumstances in which this assumption turns out
to be invalid, though. One of them is when the volume being mounted
is a CD-ROM which adheres to the ISO 9660 standard.
The Mac operating system keeps track of the number of files available
on each volume, and the Finder can display the counter. However, ISO
9660 CD-ROMs don't store this value in their headers. So, when you
mount a new CD-ROM, the Mac's "Foreign File" code quite politely
calculates the file-count, by stepping through the disk's directory!
As you've noticed, this can take a loooooong time!
Unfortunately, there's no practical way for the Finder to tell that
it's about to mount an ISO 9660 CD-ROM until _after_ it has done so.
>From the Finder's point of view, the MountVol() call is an atomic
operation... one which takes a long time to return, it's true, but
one which is not divisible into a look-first/do-it-now couplet. Hence,
the Finder can't tell that it should [have] put up a stopwatch, until
it's too late!
Fortunately, this issue will probably be moot when the new version of
the ISO 9660 Foreign File code is released by Apple. I've heard that
Apple has eliminated the scan-the-directory-and-count-the-files process;
it's too much work to do, for a small bit of information which is rarely
used or useful.
Presumably, the new driver-code will be available through Apple dealers at no
cost. It would be adding insult to injury for Apple to tell users that they'd
have charge this Fur'in File code on their Apple Fee Line.
Dave Platt, Coherent Thought Inc. 3350 West Bayshore #205 Palo Alto CA 94303 (415) 493-8805
Perils of not planning for errors
Ted Shapin <tshapin@orion.oac.uci.edu>
Fri, 12 Jan 90 10:36:55 -0800
A large computer manufacturer (which my friend prefers remain anonymous) laid off 7% of its employees just before Labor Day. My friend, who works there, and who I will refer to as 'Pat', was told he/she was not in the group to be terminated. However, when Pat called Saturday to get phone mail, Pat found his/her phone mail box no longer existed. Pat also could not log on to the company computer system. Needless to say, Pat was worried over the weekend. When Pat went to the plant on Tuesday, the magnetic badge would not open the computer-controlled door. After some investigation, it turned out that a data entry operator had made some errors in entering employee numbers, and indeed Pat along with a few others in the same boat were still supposed to be employed. It took 36 hours before all of Pat's computer-controlled privileges could be restored, (apparently, there was no procedure for correcting errors of this sort). Finally, some weeks later, Pat found that all of Pat's accrued vacation days had been reset to zero!
wrong 800 numbers
Steven W. Grabhorn <grabhorn@marlin.nosc.mil>
13 Jan 90 07:09:29 GMT
Here's a short article on the risks of having an 800 number.
The 1/12/90 San Diego edition of the Los Angeles Times had the following
article (first, a little background, Joan Kroc is having trouble finding a
buyer for the San Diego Padres):
It started with a joking headline on Times sports editor Dave Distel's
column on Thursday: "Have a Credit Card Ready and Call Now! 1-800-BUY-PADRES."
Richard Cole, co-owner of Emslee Products of Cleveland, Ohio, is not laughing.
His company sells sanitary napkins. Its number is 1-800-BUY-PADS. "Our phone
has been ringing all day," Cole said. "My secretary can't get any work done,
I'm losing orders, I'm paying 12 cents per minute for every call, what in hell
are you people doing out there?" [...]
Steve Grabhorn, Code 645, Naval Ocean Systems Center, San Diego, CA, 92152
Password Sharing
<DXB4769@RITVAX.BITNET>
Wed, 10 Jan 90 21:36 EST
It's the careless attitude that a computer password is no different than a
house key that literally opens businesses and government to fraud and espionage.
The difference between loaning someone your house key and you passwordd is
simple. You own your house (or the bank does :) ), but your password and the
resources that it protects are not yours, or yours to lend.
In addition, one loaned password can affect many people, even an
organization, if abused - or misused, for that matter.
Lending and trust are key concepts in a democratic society, and
important in social interaction. Yet in the electronic society that we
live in, where a single password can affect people's lives, prudence
and adherence to good security policies are just as important.
Dave Bafumo
Rochester Institute of Technology Criminal Justice/Computer Science (Student)
call for papers for computer security foundations workshop
<mclean@itd.nrl.navy.mil>
Wed, 10 Jan 90 17:28:31 EST
CALL FOR PAPERS
COMPUTER SECURITY FOUNDATIONS WORKSHOP III
June 12-14, 1990
Franconia, New Hampshire
The purpose of this workshop is to bring together researchers and
practitioners in computer security to examine current theories of
security in computing systems, with attention to the system models that
provide context for such theories and techniques for verifying security
as defined by these theories.
The workshop will include paper presentations, panel sessions, and
participation in working groups. Papers and proposals for both panel
sessions and working group problems are solicited in any application of
formal methods from computer science, mathematics, and logic to
computer security. Possible topics include security models, covert
channel definition and analysis, information flow, access control,
secure protocols, and verification techniques.
Instructions for Participants: Workshop attendance will be limited to
thirty-five participants. Prospective participants should send four
copies of a paper, panel proposal, or working group proposal to John
McLean, Program Chair, at the address below. Submissions must be
received by February 15, 1990. Participants will be notified of
acceptance by March 15, 1990. Papers will be published in a
proceedings that will be available at the workshop.
Program Committee:
Janice Glasgow Daryl McCullough Jon Millen
Bob Morris Ravi Sandhu Marv Schaefer
For further information contact:
General Chair: Program Chair:
Tom Haigh John McLean
Secure Computing Technology Corp. Code 5540
2855 Anthony Lane, Suite 130 Naval Research Laboratory
St. Anthony, MN 55418 Washington, DC 20375
(612) 782-7145 (202) 767-3852
haigh@dockmaster.arpa mclean@itd.nrl.navy.mil
Publications Chair:
Bill Young
Computational Logic, Inc.
1717 W. 6thSt, Suite 290
Austin, TX 78703
(512) 322-9951
young@cli.com
Report problems with the web pages to the maintainer