Subject: RISKS DIGEST 12.18 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Tuesday 27 August 1991 Volume 12 : Issue 18 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: 13 Aug 91 NY Nine Mile Point 2 Nuclear Plant Incident Reassessed (PGN) Risks to Computers from Coup Attempt (Aldis Ozols) Oil Firm Surveys for Data and a Data Interchange Format (John F Stoffel) Ada beats C++ according to the DoD (John F Stoffel) Unwarranted equivalence assumptions (Andrew Koenig) Study Recommends Earthquake Warning Network (Fernando Pereira) Re: Firefighters won't give first aid to AIDS patients (Tim Oldham) Re: Cracker charged in Australia (Richard A. O'Keefe) FAA seems misled (Re: TCAS Sees Ghosts) (Richard Johnson) Risks of CDROM publishing (Donald M. Craig) The RISKS of a national computerized entertainment ticketing network (Steve McDowell) New List: C+HEALTH (Computers and Health) (Judy Smith) 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. Others ignored! REQUESTS to RISKS-Request@CSL.SRI.COM. For vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousAnyNonNullPW CD RISKS:GET RISKS-i.j" (where i=1 to 12, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*" gives directory; "bye" logs out. The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1". =CarriageReturn; FTPs may differ; UNIX prompts for username, password. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ---------------------------------------------------------------------- Date: Tue, 27 Aug 91 10:47:07 PDT From: neumann@csl.sri.com (Peter G. Neumann) Subject: 13 Aug 91 NY Nine Mile Point 2 Nuclear Plant Incident Reassessed An AP item today, datelined WASHINGTON, noted that Federal investigators are still trying to determine why backup systems failed at the Nine Mile Point 2 nuclear power plant in upstate New York during the 13 Aug 91 blackout, after a 25,000-volt transformer blacked out. Cutover to the "uninterruptible power" system's standby batteries failed. ``The team issued a preliminary "sequence of events" late last week, which indicated that many more systems had failed than originally reported.'' Furthermore, the plant actually went into "scram" (emergency shutdown), despite earlier reports to the contrary. The plant operators had apparently not known this at the time, because of the lack of backup power. The feedwater control, radio and public address system, computer systems, and some lighting failed. (The NRC team leader, Michael Jordan, was quoted as saying, "Most of it was monitoring systems. All the ones that failed were not safety related.") [Good thing Jordan was not in Chicago, or there might have been suspicions of his having something to do with the Bulls... PGN] ------------------------------ Date: Sat, 24 Aug 91 16:41:57 PDT From: peg!aldis@igc.org Subject: Risks to Computers from Coup Attempt >From Aldis Ozols, Sydney, Australia. During the abortive Soviet coup, several data communications links remained open. Not all computer users were fortunate, however, as the following report from Leningrad attests: >NorthWest northwest.news 6:49 pm Aug 19, 1991 >(at p2013.f20.n490.z2.Fidonet.Org)(From News system) > >LENINGRAD-MOSCOW, August 19 /"NORTH-WEST" Information Agency/ > [coup progress news deleted] > > All fax-machines and computers at publishing houses of democratic newspapers > "Smena" and "Nevskoye Vremya" were burnt by strong electric impulses. [Beware of opening (electric) charge account, and must not buy on impulse! A truly shocking story. But we now have the inevitability of life, death, and faxes--which transcend all sorts of would-be barriers, as long as they don't get fried. PGN] ------------------------------ Date: Tue, 27 Aug 91 02:02:49 EST From: john@wpi.WPI.EDU (John F Stoffel) Subject: Oil Firm Surveys for Data and a Data Interchange Format Conoco Inc. wants to redesign the way it keeps track of names and address by consolidating scores of files into one global name and address system. The problem is, it does not know how to do it. In a unique approach, the $2 billion, Houston Texas based oil and gass subsidiary of E.I. du Pont de Nemours & Co. Inc. sent out a survey to the top 108 companies on the Fortune 500 and a majority of its competitors to garner input on whether they have ever attempted a similar records consolidation and what suggestions they could make. In the survey, Conoco also asks if some of its systems personnel can visit the corporation's sites. The project is being administered by Conoco's accounting systems group and the Conoco Information Systems group in Ponca City Okla. So far, the response rate has been excellent, according to Walt Drawl training director of the accounting system group. After sending out the surveys on June 28, Conoco has received 35 responses - including some from competitors. "We've been getting some good information on EDI," says Drawl. Once of Conoco's biggest concerns in file consolidation and information exchange is maintaining data security. "Network security is one of the those monsters out there we have to be very careful of," says Drawl. Drawl and his associates plan to release their findings by the end of August and present them to Conoco management. {InformationWeek July 29, 1991} ------------------------------ Date: Tue, 27 Aug 91 01:59:58 EST From: john@wpi.WPI.EDU (John F Stoffel) Subject: Ada beats C++ according to the DoD I got this from VNS (The Vogon News Service) an internal news feed from Digital for British people working in the US. I thought this article tied in very nicely with the New Jersey bill trying to license programmers. Mostly in the way they compile and use statistics which are pretty meaningless, or do not give enough of a break down on what kind of errors they are. [In general I think VOGON has no objections to reuse. However, John, next time please leave their HEADERS intact... PGN] {ComputerWorld July 29, 1991} Ada Bests C++ The US Department of Defense has released the results of four recent studies showing that the DoD mandated programming language Ada is superior in a variety of ways to its newer rival C++. The studies showed that "there is no compelling reason to waive the Ada requirement [in favor of] C++", the Pentagon said. A fifth study went beyond a look at the third generation, object oriented languages and said the use of fourth generation languages with good development environments and methods can boost software productivity by a factor of 10. The studies generally found that Ada is more mature than C++, is more standardized, is supported by more vendors and is accompanied by a richer set of development tools. A TRW Inc. study said that Ada is about three years ahead of C++. TRW found that Ada now offered a 35% cost advantage in development and a 70% in maintenance over C++. After 1994, TRW said, those figures may erode to 10% and 30%. However, TRW said C++ rated better than Ada in compilation and runtime efficiency and support of object oriented design. Carnegie Mellon University's Software Engineering Institute used a language evaluation methodology developed by IBM in the mid-1980s and concluded that Ada was 23% better than C++ in six categories. CTA Inc. looked at the productivity of the two languages based on actual projects and found Ada programmers on average produced 210 source lines per month while C++ programmers turned out 187 lines. CTA also found an average 24 errors 1,000 lines of Ada code vs 31 errors for C++. CTA said that normalizing the data to account for different project sizes indicated a 35% productivity advantage for Ada. [That is 5 errors/month/pgmr for Ada and 5.8 errors/month/pgmr for C++, making C++ 16% more. Maybe "errors/month/pgmr" can become the "mips" measurement of software development? --mjt] A Naval Postgraduate School report said language selection, training, and computer aided software development can improve productivity modestly, but it said "a fundamental change in software development paradigm will be necessary to achieve an order of magnitude gain." The school said that boosts in productivity can be had from the use of a 4GL provided it is accompanied by "a productive development environment, an evolutionary implementation methodology, and well trained development teams." ------------------------------ Date: Tue, 27 Aug 91 10:34:25 EDT From: ark@research.att.com Subject: Unwarranted equivalence assumptions What do the following statements have in common? `We don't want any illegal drug users in our company, so we won't hire anyone who doesn't pass a drug test.' `We can't give you that loan; your credit report shows a poor payment history on one of your credit cards.' `We want to make sure airplanes that enter the country do so legally, so we will only allow airplanes to clear Customs if they have their original certificates of registration with them.' `I'm sorry, Sir; but even if you are indeed the Ambassador, we can't let you into the Embassy building without a proper pass.' The obvious similarity is that they would all be supremely frustrating, especially if made inappropriately. Behind that, though, is that each one is the result of a system that assumes that two things are equivalent even when they sometimes aren't. Not everyone who fails a drug test is a user of illegal drugs; the test might be in error or, as happened not too long ago, the lab might have deliberately fudged the results so that its statistics would look better. Not everyone who turns up with a bad credit report has a reason for it; sometimes the negative history actually belongs to, say, someone else with the same name. Not every airplane without an official registration certificate is illegal; perhaps its present owner bought it only recently and is waiting for the permanent registration certificate to arrive from the FAA (which can take many months). Perhaps the Ambassador was appointed only a week ago, has been outside the country since then, and therefore hasn't had the opportunity to pick up the pass that has been waiting for him. All four of these examples are based on real events; all four point up an error that is made all too often by people who should really know better. They reemphasize something that everyone knows who has been working with software for any length of time: it's practically impossible to keep two separate databases in step for any length of time. That's true even when one of the `databases' is reality itself. --Andrew Koenig ark@europa.att.com ------------------------------ Date: Tue, 27 Aug 91 18:08:08 EDT From: pereira@klee.research.att.com (Fernando Pereira) Subject: Study Recommends Earthquake Warning Network (AP) AP Science writer Paul Recer reports that a committee of the National Research Council recommended the creation of automatic earthquake warning networks for highly seismic areas. The network would take advantage of the fact that the primary (P) wave train from an earthquake moves faster but is less destructive than the secondary (S) wave train, and can therefore be used as the trigger for an automated alarm system. Even relatively close to the epicenter, P waves precede S waves by a few seconds. Such a system could be used to lower fire risks by shutting down natural gas and power distribution networks, to protect computer systems by retracting disk heads, to start a controlled shut down of factory processes, to divert aircraft, etc. Well trained people could also take advantage of the warning to seek shelter. Even with the risk of false alarms that could cause blackouts and damage, the committee recommended that such a system should be automatic to achieve the required fast response. The system would involve a network of sensors connected by microwave or satellite to a central computer system. I guess we need a new Emacs function save-all-buffers-on-quake... More seriously, this poses all sorts of interesting RISKs issues. Does anyone know how reliable such a system might be? I assume it would use some form of spaciotemporal cross-correlation to discriminate real quakes from sensor malfunction or local disturbances (big truck going by?) Are there results relating density of sensors, network topology and probability of sensor or link malfunction to probability of false alarm? What are the legal implications of "alarmist" versus "conservative" decision rules? Fernando Pereira, 2D-447, AT&T Bell Laboratories, 600 Mountain Ave, Murray Hill, NJ 07974 ------------------------------ Date: Tue, 13 Aug 91 14:31:23 BST From: Tim Oldham Subject: Re: Firefighters won't give first aid to AIDS patients (RISKS-12.12) This is also the case in Britain. A piece on the (National) Radio 4 news programme ``Today'' broadcast today 13th August described how the Police National Computer (PNC) stores information relating to *suspected* contagious diseases, including AIDS. This information is shown in the form of a warning when a look-up is done. According to ``Today'', the source of the information is never medical files but prison authorities and ``other sources'' (presumably hearsay sources). An example of a woman whose record showed that she had AIDS (presumably HIV, in actual fact) when she did not was quoted. In order for her record to be corrected she had to undergo an HIV test. The woman stated that she had been ostracised by her friends and community because the police had displayed a photograph of her with the word ``AIDS'' above it in the local police station. I'm not clear whether the computer record or the photograph came first, but there is certainly every possibility that police units will create incorrect records and others will use these records to discriminate against people. The police have ``apologised'' to the victim in this case. No other compensation seems to have been offered and it appears that she is not suing. A police spokesman stated that such records were used to ensure that the police take appropriate precautions when dealing with someone whose record showed that they had a contagious disease. By law, the records should be available, although there a number of police get-out clauses to allow them to refuse to reveal parts of their computer records. Tim Oldham, BT Group Computing Services ------------------------------ Date: 22 Aug 91 05:16:05 GMT From: ok@goanna.cs.rmit.OZ.AU (Richard A. O'Keefe) Subject: Re: Cracker charged in Australia (RISKS-12.13) Fernando Pereira cites an AP report on Nashon Evan-Chaim. Since I know Nashon (he was in one of my classes here last year), I thought I'd put in a word on his behalf. If there is such a thing as ``innocent cracking'', where someone goes around logging into computers all round the world without any malicious intent, for the sheer joy of exercising an admittedly reprehensible skill, then in my opinion this is an example of it. Based on my conversations with him, he has exactly the kind of knowledge about security holes that you would expect a bright CS undergraduate who isn't afraid of reading manuals to work out. The particular part of the quote which caught my attention was: > Execucom Systems Corp. of Austin, Texas, where it is alleged he destroyed > important files, including the only inventory of the company's assets. I don't know Nashon _very_ well, but I've spoken with him quite a few times, and it would be completely inconsistent with his character as I know it for him to have done anything like this deliberately. Nashon isn't an anti-social "loner", he is quite a helpful person. I would be very surprised and disappointed if this charge turned out to be true. (What company would not have a backup of their inventory, plus the paper audit trail to bring it up to date?) Although I do not believe Nashon guilty of any malicious intent, that is not to say that I approve of entering systems which don't display a ``Welcome'' message for visitors. ------------------------------ Date: Mon, 26 Aug 91 13:51:39 PDT From: richard@oresoft.com (Richard Johnson) Subject: FAA seems misled (Re: TCAS Sees Ghosts) A little correction to the comments made by the FAA in Jim Horning's excerpt from "IEEE Spectrum: TCAS Sees Ghosts".. (By the way, thanks, Jim.) ... : The FAA emphasized that the software fault did not pose a hazard. TCAS is : a backup system; primary responsibility for avoiding midair collisions still : remains with the ground-based air traffic control systems. Not quite. TCAS is a backup system. It's a redundant backup. Primary responsibility for "see and avoid" is with the pilot (FAR part 91). The air traffic control system, with all it's eyes, ears, and radar exists to help the pilot avoid situations that can develop into genuine emergencies. The concept of TCAS is to give back to the pilot some of the ability to "see and avoid" that goes with the responsibility, in an era where huge aircraft can be atop you before you see them. It puts an electronic eye in the cockpit with the pilot; something to help the pilot, rather than air traffic control. Of course, the FAA has maintained since around 1946 or so that the ONLY effective way to maintain safe skies is through control from the ground, rather than from the cockpit. Draw your own conclusions. Because of this, in some ways, TCAS and air traffic control are at crossed purposes. TCAS gives authority to the pilot, and ATC takes it away. It is important to remember, that as much as the FAA likes to calm people's fears by telling them that ATC is in "control", the rules put the pilot in the hot seat. The total and ultimate safety of every flight is the job of the pilot first. Everything else is advice. And there are some interesting failure modes that I hope "experts" have looked into already (faulty or missing messages, failure to notify ATC, etc.) Richard Johnson richard@oresoft.com richard@agora.rain.com ------------------------------ Date: Tue, 27 Aug 1991 15:00:50 -0700 From: "Donald M. Craig" Subject: Risks of CDROM publishing Last weekend, interested in trying out a SparcStation draw program, I inserted a recently arrived SUN Catalyst CDWare disk, Volume 1, in my CDROM drive and attempted to mount it. No luck. After some mucking about, the disk mounted when I specified High Sierra file format. But none of the advertised browsers or programs were to be seen - instead there were a number of very large MSDOS format files. Inside a text file, I found: "Dear OncoDisc Customer, Congratulations on your subscription to OncoDisc, the cancer information service on CD-ROM! You have chosen a unique information service that will provide you with immediate and unlimited access to the key sources in oncology. We at Lippincott are pleased to have you as a new subscriber and are sure you will find using OncoDisc very exciting and worthwhile." The disk had Sun Microsystems Catalyst printing on the front, and the silver lettered text on the back said: MADE BY 3M USA CR14614A 910213 My conclusion from this is that some low probability process at 3M's CDROM pressing(?) plant permutes disk labels and contents - and that somewhere there is an unhappy Lippincott customer. Sigh. Not only a computer risk, but another cancer risk as well. Don Craig dmc@tv.tv.tek.com Tektronix Television Division ------------------------------ Date: Mon, 26 Aug 91 14:06:38 CDT From: mcdowell@exlog.com (Steve McDowell) Subject: The RISKS of a national computerized entertainment ticketing network Re: KJPhelan@SUNRISE.ACS.SYR.EDU, RISKS-12.15 Back in 1985 I worked for the Ticketmaster Corporation on the then latest-and-greatest ticket selling software. At that time, everything was done on PDP-11's running in a fault-tolerent configuration under a Ticketmaster proprietary operating system (a risk in it's own right). Each data center was then linked via leased lines into a centralized database. I understand that they have ported their operating system now to the VAX architecture. Extreme consideration was given to eliminating the risks of minimum waged ticket sellers turning an unethical profit. They had a command set of about six commands, most of which delt with whether the customer was paying cash or credit. The system would generate audit reports and automatically check the arenea map against tickets sold and the cash reported for each location each night. If there was a discrepancy or if an unusually large number of tickets were sold for a particular location, then the system would generate an alarm on that location. The promoter for each event also recieved daily activity reports from the system. The weak link in this system, as in all systems, is the human element. Though it was very hard to make the computer do something that it was programmed to believe to be unethical, things could be done. The seller could "forget" to program returned tickets, for instance. For the most part, however, very little trouble came from the low paid, low techno-savey, ticketsellers. The big risk exists in trusted accounts on the system. It could be fooled, but only by someone with direct access. There was a general manager for Ticketmaster in a rather large urban area who had a cocaine habit. He would trade tickets for drugs. He would come in at three in the morning, after the night operaters had run their nightly audit procedure, bring the system up thinking it was some absurd date, sell himself fifty or one hundred tickets, then run the nightly audit reports again, ignoring the alarms generated. He could tell the computer that the seats he sold himself were available, but to not sell them to any outlet. This went on for about three years before he was caught by the night operators who were just trying to learn what made the PDP-11's tick! The bottom line is that there is a risk, but not a risk any greater than that of, say, the American Airlines ticket reservation system. Abuses of power happen; very little can deter a super-user from doing what he wants to do. Managers simply have to read the audit reports, not just file them. The computer should do self-audits, as the Ticketmaster system does. Care should be taken, and in the case of Ticketmaster it is. Steve McDowell ------------------------------ Date: Tue, 13 Aug 91 10:24:01 -0400 From: "Judy Smith" Subject: New List: C+HEALTH (Computers and Health) [Sorry for those of you on BITNET who get two copies. Judy double posted.] This list is intended to promote sharing of information, experiences, concerns, and advice about computers and health. Anecdotal evidence, media reports, and some formal studies suggest that computer users are at risk from misuse and overuse of computers. Eyestrain, headache, carpal tunnel syndrome, and other apparently computer-related maladies are increasing. And, it would appear that colleges, universities, and other institutions have been slow to respond with education, training, office and lab design, furniture purchasing, and other programs that could make computing more healthful -- and productive. We welcome questions and answers; article and book reviews; hardware, software, and furniture evaluations; approaches to influencing institutional policy; speculation; and humor. Medical, legal, technical, financial, aesthetic, and administrative viewpoints are encouraged. We hope that this forum will be of interest to end users, computing managers, epidemiologists, and policymakers. Subscribers to this list may also wish to participate in EDUCOM's Project EASI: Equal Access to Software for Instruction, "dedicated to assisting higher education in developing computer support services for people with disabilities." EASI provides information and guidance on campus applications of adaptive computer technology. For information on EASI, contact Carmela Castorina, CSMICLC@UCLAMVS.BITNET. In general, C+Health will focus on individual and institutional measures for "keeping healthy people healthy" as well as remedies for restoring temporarily disabled people to health. We suggest that computing issues related to those with permanent disabilities be referred to our dedicated colleagues at EASI. Although this distinction will not always be "easy," one goal of C+Health is to minimize the number of casualties in our increasingly computer-intensive campuses, offices, and homes. This list will not be moderated, at least initially, so we encourage contributors to be succinct, to include relevant parts of messages to which they are responding, and to append their names, titles, and institutions to contributions. New users are welcome to send to the list a brief statement of their experiences and interests in this topic. Unless stated otherwise, it will be assumed that contributions represent individual opinion rather than institutional policy. As list owners, we look forward to your contributions to C+Health, Judy Smith, Data Analyst, Office of Data Administration and Information Resource Planning, University of Pennsylvania; SmithJ@a1.relay.upenn.edu. Kimberly Updegrove, Lecturer, School of Nursing, University of Pennsylvania; kimu@dairp.upenn.edu. ********************************************************** On-line references on Computing and Health: The following articles from campus computing newsletters are recommended for those interested in issues of ergonomics, radiation, light and glare, work habits and exercise, and related issues and protective measures. Articles can be retrieved by sending a GET FILENAME FILETYPE command to LISTSERV@BITNIC (not IUBVM), where FILENAME FILETYPE are shown below in CAPITAL LETTERS. COMPHEAL DUBEY_J Computers & Health (Reed College; 3/91; 520 lines) COMPHEAL UPDEGR_D Computers & Health: Issues & Protective Measures (U of Pennsylvania; 1/91; 262 lines) CTS SHEEHAN_M Carpal Tunnel Syndrome (Indiana U; 11/90; 212 lines) ERGONOM UPDEGR_D Computers Don't Belong on Desktops (U of Pennsylvania; 11/90; 90 lines) ERGO BALKITS Workstation design (UC Davis; 8/88; 64 lines) PAIN BRADLE_J Computing Pains (U of Houston; 3/89; 135 lines) SFVDTLAW UPDEGR_D San Francisco VDT Safety Ordinance (1/91; 146 lines) VDT SHEEHA_M VDT Health Risks (Indiana U; 11/90; 137 lines) Thanks to Wendy Rickard-Bollentin of EDUCOM for maintaining the articles archive of CCNEWS, from which these articles were selected. ********************************************************** Hints for using LISTSERV: To send a message to all subscribers, address it to C+HEALTH@IUBVM (from BITNET sites) or to C+HEALTH@IUBVM.UCS.INDIANA.EDU (from Internet sites). For all "list management" commands below, send mail or messages to LISTSERV@IUBVM (from BITNET sites) or (from Internet sites) mail to LISTSERV@IUBVM.UCS.INDIANA.EDU. Do not send LISTSERV commands to C+HEALTH, since they will be distributed to all subscribers * To leave the list, send command, SIGNOFF C+HEALTH * The amount of acknowledgement you receive upon completion of a mailing operation can be changed by means of a SET C+HEALTH OPTION command, where "option" may be either ACK (mail acknowledgement), MSGACK (interactive messages only) or NOACK. * Contributions sent to this list are automatically archived. You can obtain a list of the available archive files by sending an INDEX C+HEALTH command. These files can then be retrieved by means of a GET C+HEALTH FILETYPE command (where "filetype" is the name following C+HEALTH in the file list) or by using the database search facilities of LISTSERV. Send an INFO DATABASE command for more information on the latter. * It is presently possible for other people to determine that you are signed up to the list through the use of the REVIEW command, which returns the network address and name of all the subscribers. If you do not wish your name to be available to others in this fashion, issue a SET C+HEALTH CONCEAL command. * More information on LISTSERV commands can be found in the "General Intro- duction guide," which you can retrieve by sending an INFO GENINTRO command. ------------------------------ End of RISKS-FORUM Digest 12.18 ************************