RISKS-LIST: RISKS-FORUM Digest Monday 15 January 1990 Volume 9 : Issue 60 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator 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) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line (otherwise they may be ignored). REQUESTS to RISKS-Request@CSL.SRI.COM. TO FTP VOL i ISSUE j: ftp CRVAX.sri.comlogin anonymousAnyNonNullPW cd sys$user2:[risks]get risks-i.j . Vol summaries now in risks-i.0 (j=0) ---------------------------------------------------------------------- Date: 10 Jan 90 1200 PST From: Les Earnest Subject: The C3 legacy: top-down goes belly-up recursively 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) ------------------------------ Date: Mon, 15 Jan 1990 12:33:13 PST From: "Peter G. Neumann" Subject: Dispatchinate Computerized Cab Service 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.] ------------------------------ Date: Sun, 14 Jan 90 22:27:49 CDT From: jet@karazm.math.uh.edu (J. Eric Townsend) SUbject: Risks of manual page formatters and inserted text 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 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 ------------------------------ Date: Wed, 10 Jan 90 16:10:54 PST From: dplatt@coherent.com Subject: Re: What hung the computer? ... 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 ------------------------------ Date: Fri, 12 Jan 90 10:36:55 -0800 From: Ted Shapin Subject: Perils of not planning for errors 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! ------------------------------ Date: 13 Jan 90 07:09:29 GMT From: grabhorn@marlin.nosc.mil (Steven W. Grabhorn) Subject: wrong 800 numbers 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 ------------------------------ Date: Wed, 10 Jan 90 21:36 EST From: DXB4769@RITVAX.BITNET Subject: Password Sharing 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) ------------------------------ Date: Wed, 10 Jan 90 17:28:31 EST From: mclean@itd.nrl.navy.mil Subject: call for papers for computer security foundations workshop 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 ------------------------------ End of RISKS-FORUM Digest 9.60 ************************