Subject: RISKS DIGEST 14.11 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Friday 27 November 1992 Volume 14 : Issue 11 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Re: Computer Security Act and Computerized Voting Systems (Roy G. Saltman, Rebecca Mercuri) How Is Technology Used for Crime in the Post-Hacker Era? (Sanford Sherizen) Re: Nuclear plant risks (Brad Dolan) Re: Installer Programs (John Bennett, Mathew) Re: How to tell people about risks? (Sanford Sherizen, Mark Day) Change in the Maximum Length of International Telephone Numbers (Nigel Allen) Humorous submissions for a book (Andrew Davison) 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 may be ignored! Contributions will not be ACKed. The load is too great. **PLEASE** INCLUDE YOUR NAME & INTERNET FROM: ADDRESS, especially .UUCP folks. REQUESTS please to RISKS-Request@CSL.SRI.COM. Vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousAnyNonNullPW CD RISKS:GET RISKS-i.j" (where i=1 to 14, 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. For information regarding delivery of RISKS by FAX, phone 310-455-9300 (or send FAX to RISKS at 310-455-2364, or EMail to risks-fax@cv.vortex.com). 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: Fri, 27 Nov 1992 15:39:01 -0500 (EST) From: SALTMAN@ECF.NCSL.NIST.GOV (Roy G. Saltman) Subject: Re: Computer Security Act and Computerized Voting Systems This is in response to Rebecca Mercuri [RISKS-14.09] and Bill Murray [RISKS-14.10] on the subject of the applicability of the Computer Security Act of 1987 (P.L. 100-235) to computerized voting systems. The purpose of the Computer Security Act was to create, according to Section 2 (a) of that act, "a means for establishing minimum acceptable security practices" for "improving the security and privacy of sensitive information in Federal computer systems." Systems containing national security, i.e., classified, information are excluded from the purview of the act. In Section 2 (b), the act assigned to the National Bureau of Standards (now the National Institute of Standards and Technology, NIST) "responsibility for developing standards and guidelines needed to assure the cost-effective security and privacy of sensitive information in Federal computer systems..." By assigning primary responsibility to NIST for providing the necessary guidance, the act limited the influence of DoD, as Mr. Murray states, although that was only one of the purposes, not "the" explicit purpose. The Computer Security Act of 1987 applies to "Federal computer systems," where such a system, in the language of the act "means a computer system operated by a Federal agency or by a contractor of a Federal agency or other organization that processes information (using a computer system) on behalf of the Federal Government to accomplish a Federal function." Now, Mr. Murray is incorrect when he states that "control over voting procedures is reserved to the states." That is specifically untrue in the case of Federal elections. Federal elections are elections for President, Vice-President, U.S. Senators, and U.S. Representatives. The U.S. Constitution provides, in Article I, section 4 that the Congress may "at any time by law alter such regulations" that the State Legislatures impose for determining the time, places, and manner of holding [Federal] elections. In addition, in Article I, section 5, the Constitution states that "each House [of Congress] shall be the judge of the elections, returns and qualifications of its own members." A number of Constitutional Amendments and Federal laws have changed (expanded) voting rights. In the most recent Congress, a bill was passed mandating very specific procedures for voter registration. The bill would have become law if not vetoed successfully by President Bush. While such laws affect only Federal elections, the states invariably apply them to their own state elections, because they cannot afford two sets of procedures. This was specifically true for the amendment granting voting rights to 18-year-olds, as well as for the Voting Rights Act of 1965. As the President, Vice-President, and members of Congress are Federal officials remunerated through appropriations of the Federal budget, the votes cast for them on a state or local government computer system is a "system operated by ... [an] other organization that processes information ... on behalf of the Federal Government to accomplish a Federal function." Clearly, votes in Federal elections are sensitive information, under the Computer Security Act. The reason that vote-tallying in Federal elections is not covered is that the act mandates actions by Federal agencies to implement the act. However, the definition given to "Federal agency" given in the act specifically omits the U.S. Senate and the U.S. House of Representatives. These are the agencies ultimately responsible for Federal election data, and they have excluded themselves from coverage of the act. Thus, the only sensitive Federal data omitted from coverage is the most important for continuation of our democratic government. ------------------------------ Date: Fri, 27 Nov 92 18:28:39 EST From: mercuri@gradient.cis.upenn.edu (Rebecca Mercuri) Subject: Re: Computer Security Act and Computerized Voting Systems In response to William Hugh Murray's posting in RISKS Forum 14.10: First of all, let me state that I agree with much of what was said. Some of which has even appeared in my earlier writings on this subject, most notably the observation that DREs are similar to ATMs (which I comment on extensively in my March 1992 paper published in the Proceedings for the Fifth International Computer Virus & Security Conference), the statement that "control over voting procedures is reserved to the states" (which also appears in that same paper), and I had also alluded to the insufficiency of security standards and theory applicable to this problem in my recent (November 92 CACM) Inside Risks column. So it appears that we are in agreement here (with sufficient citations in evidence of this fact). Readers should note that my use of the phrase "Orange Book" was intended more generically (as is common) than to the specific book itself. The primary intent of my posting was to make the public aware of the fact that the FEC and NASED have not made sufficient use of the ongoing work by NCSC in their establishment of guidelines and controls for voting equipment. I was not suggesting that the NCSC documents would BE SUFFICIENT for voting applications, only that they should be consulted as it is the largest body of standards work to date regarding computer security and MUCH (not all) of the rainbow series material IS applicable to the voting area (as well as in banking, where it is certainly considered), regardless of the original intention of the Act. Where Murray and I are not in agreement is in his assertion that the shared resource problem is not applicable to vote recording, reporting and tallying. He may have conceived of computerized voting as taking place on independent, stand-alone systems, but in actuality this is often not the case. Many computer systems used for voting purposes are networked and time-shared. The RISKS implications of this should be obvious, now that I have pointed this out. A recent voting machine security document that I was asked to review contained the following statement: "The proposed DEC computer operating system (VMS) is one of the most secure systems available today. Security features that comply with the National Computer Security System (NCSC) C2 classification have been built in as an integral part of the operating system." I include these sentences not for their merit (with which I have considerable difficulty), but to point out that the operating system problem is ALSO highly applicable to the voting problem. Both Peter Neumann and I are well aware of the ramifications of getting what is asked for. We have each publically called for greater care in developing voting systems with, as Murray said, "extraordinary, not standard, rigor and ... in the light of independent scrutiny." But I must bring to light the fact that this is not presently the case. I also agree that the laws which affect voting machines should be specific to their manufacture, and have personally lobbied to improve these laws, but as some states have failed to adopt even weak regulations, there must be some place to start, and an existing Computer Security Act might be a good place to at least look. Note that Congress IS responsible for overseeing FEDERAL (Presidential and Congressional) elections, and such SHOULD be considered a matter of national security. Congress did, though, exempt itself from the CSA and hence it does not apply to elections at present. Due to time constraints I am not at liberty to iterate at length on this subject, but numerous documents and publications are available that will confirm the fact that electronic voting systems are not being administered with the care that should be given, that current laws are inadequate, standards are lacking, and rigorous theories are needed in this area. CPSR is a good place to contact if one would like to become more fully aware of this problem, and then I hope that more individuals will join the effort to ensure that accurate, anonymous voting is guaranteed. Rebecca Mercuri. ------------------------------ Date: Fri, 27 Nov 92 14:38 GMT From: Sanford Sherizen <0003965782@mcimail.com> Subject: How Is Technology Used for Crime in the Post-Hacker Era? I am working on a research project and book involving the process by which some people have been able to "invent" computer and other high tech crimes. The issue that I am trying to understand is how people adopt new technologies for purposes other than those envisaged by the developers. Specifically, some people are very skilled in what I call thinking like a thief. They see technology from a particular perspective, based on how it can be used for anti-social, deviant, and/or criminal acts. A counterpart to this are those who come up with new applications for technology, which may also be viewed as negative by developers but can often lead to new applications (and even new industries). It could be quite important to establish how other technologies have been used for "inventing" crimes. How do technologies get expanded and changed, especially by "non-official" people, i.e., they do not work for the original technology developers or owners? These "non-official people" see new possibilities, whether for a positive or negative use. I know that the terms positive and negative raise many definitional and value difficulties. Yet, I am interested in how people view technology, how they are able to frame questions about other uses, how this information gets spread to others, and the positive as well as negative consequences of this process. Drawing on my background in criminology, sociology, and information security, I have collected examples on how other crimes have developed and been responded to by technologists and law enforcement. Some examples that come to mind include how the car was relatively quickly adopted by bank robbers to improve their chances of getting away from the crime scene. This led to police forces having to become motorized, which had many other consequences for command and control of police deployment and changes in how the police had involvements with citizens. The Xerox or photocopying machine certainly led to better protection of documents by allowing the making of file copies but was quickly understood by some that it could also be used to steal copies as well as to leak documents to unauthorized sources, e.g. the Pentagon Papers. The automatic dial system was invented to Strowger to prevent Kansas City telephone operators from depriving him of business by giving busy signals or wrong numbers to potential customers. Ithiel de Sola Pool, in his book on the telephone, discusses how the telephone was portrayed as both the promoter and the conquerer of crime. "Call girls" and obscene callers were at least two of the ways that telephones were viewed as contributing to moral decay while the first electric police-communication system of record was installed in 1867. Answering these questions could help establish some clues as to how computer crime is developing and areas that require particular security attention. We have not been very prepared for the "Post-Hacker Era" and we have not been raising questions about the crime potential of new technologies. Any ideas, reactions to these comments, and suggestions of any social historical studies about these issues are welcomed. I will post a summary of responses. Sanford Sherizen, Data Security Systems, Inc., Natick, MA MCI Mail: 3965782 ------------------------------ Date: 27 Nov 92 15:36:59 EST From: Brad Dolan <71431.2564@compuserve.com> Subject: Re: Nuclear plant risks (RISKS-14.09, 14.10) Mr. Wexelblat points out that recent legislation (mostly) eliminates post-construction hearings from the nuclear plant licensing process. I believe the second stage review was often used as a platform by intervenor groups to delay plant licensing; adding millions, even billions to plant costs. Utilities pass these costs along to ratepayers, who must either reduce their consumption of electrical energy or reduce spending on other things to pay increased electrical bills. In the southeastern U.S., many people have begun heating their homes with wood or (unvented!) kerosene heaters, which expose them to potentially substantial risks. I would like to see a comparison of safety benefits (in terms of expected lives saved, property saved, or whatever) resulting from intervenors' interventions with the safety detriments which have resulted from increased electrical bills. Brad Dolan 71431.2564@compuserve.com 10288-700-NUCLEAR N4VHH ------------------------------ Date: Thu, 26 Nov 1992 9:58:23 +1030 (CST) From: BENNETT@dstos3.dsto.gov.au (John Bennett, Defence Science & Technology) Subject: Re: Installer Programs (Thorson alias mmm, RISKS-14.08) Unfortunately, a de-installer is likely to introduce its own risks if it is written by the writer of a buggy installer, e.g., a. It might not deinstall everything which should be deinstalled b. It might deinstall something which should not be deinstalled c. Something else might go wrong. Sometimes I think Macs are too smart, there are times when I would like some manual intervention in automatic processes such as Mak describes. John Bennett, DEFENCE SCIENCE AND TECHNOLOGY ORGANISATION PO Box 1500 Salisbury, South Australia 5108 Phone : +61 8 259 5292 FAX : +61 8 259 5537 ------------------------------ Date: Thu, 26 Nov 92 12:33:59 GMT Subject: Risks of Believing Install Programs From: mathew I recently installed Microsoft Windows for Workgroups on a Toshiba T5200 "portable" computer. (I say "portable" because the machine is a few years old, and hence measures 37x10x40cm and weighs nearly 9kg.) The machine is connected to our Novell Netware network, and so the process included installation of Netware and Ethernet drivers. Windows for Workgroups detected the Ethernet card automatically, and presented a dialogue box suggesting that it was a Novell NE2000 Anthem card. This was absolutely correct, so I confirmed it. The installer then presented another dialogue, this time with the DMA address and IRQ interrupt number. The DMA address was correct, and I reasoned that since the machine had worked everything else out it probably had the IRQ number correct also. I hit the OK button. A warning box appeared stating that the IRQ number on my Ethernet card would clash with the machine's second serial port, and would have to be changed if I wanted to use that port. I'd never used it before, but I did want to now. I abandoned the installation. Twenty minutes, three technical reference manuals, twelve fixing screws and three removable covers later, I had the Ethernet card in my hands. I peered at the card. It was set to address 320, IRQ 2. Windows had reported this as address 320, IRQ 3. I left it exactly as it was, put the machine back together again, and went through the install once more. The risk, of course, is that because the install program seemed to know exactly what sort of Ethernet card I had and what DMA address it used, I automatically assumed it knew what it was talking about when it told me the IRQ number. In my defence, I must say that Windows had been spot-on at working out the IRQ number for the card in my Elonex machine. The message for authors of install programs is that perhaps they should avoid making their programs supply default values using guesswork if the software can't actually read the value. If the program makes a couple of lucky guesses, the user might be tempted to believe that the program knows something he doesn't. The message for users is: even if an install program tells you exactly what hardware you have attached to your machine, never trust it to pick correct settings based on that information. mathew ------------------------------ Date: Fri, 27 Nov 92 14:24 GMT From: Sanford Sherizen <0003965782@mcimail.com> Subject: Re: How to tell people about risks? Several years ago, public safety messages would appear prior to major holidays warning drivers in the U.S. about accidents. The messages said (paraphrase) "350 people will die this Thanksgiving holiday. Don't be one of these fatalities. Drive carefully." Researchers from the Safety Council found that these risk messages were not helpful at all. Drivers thought that an accident would not happen to them. The risks became someone else's problem. The Safety Council then decided to personalize risk. They ran ads directed at kids suggesting that the kids ask their parents to drive safely and to use seatbelts. This approach to risk was much more successful and may have been one of the many reasons why traffic fatalities have declined over the years. Sanford Sherizen, Data Security Systems, MCI MAIL: SSHERIZEN (396-5782) ------------------------------ Date: Fri, 27 Nov 92 11:40:25 -0500 From: mday@jukebox.lcs.mit.edu (Mark Day) Subject: Telling people about risks (ingredient labels) One contributor to the discussion about describing risks made two alarming comments. I read both comments as arguing (basically) "since ingredient labels pose certain problems, we should eliminate them and thereby eliminate the problems". The comments struck me as a good example of creating a major risk to correct a minor one, perhaps because I'm more interested in this issue as a consumer of food than as a producer of food. Here's the first comment: I do not believe that there is any point in attempting to convey numerical, let alone statistical, information to a 'general public' increasingly deskilled, de-educated, aggressive and litigious. In essence, since the 'general public' can't be trusted to interpret facts properly, better not to tell them. The writer would presumably not include himself in the 'general public' that he characterizes as so unpleasant; no doubt he could interpret the facts properly. But unless the information is on the carton of whatever he's buying, he won't have access to that information either. Realistically, the choice is between making the information available to everyone or making it available to no-one. The writer will not be able to go to a special store (reserved for those who pass a test of numerical skills) to buy goods with labels describing their contents. On to the second alarming comment: An example of the perceptions of the general public: European food manufacturers, who are subject to labelling requirements, find it expensive to produce a different label for each country, translating the complex chemical names of food additives for each language group. Solution: give each additive - they are more or less standardised - a European code number (e.g. "E123"). This can then be looked up in a language-specific list to provide the chemical name in the required language, if anyone is really that interested. [goes on to describe that consumers didn't like this] This is a dreadful solution, and I can understand why consumers would be less than thrilled about it. The purpose of ingredient labels on goods is to convey information to potential purchasers, and this code-word scheme definitely conveys less information in the real world. An analogous argument would eliminate ingredient labels altogether, and require only that the manufacturers provide a telephone number to call for the ingredients. After all, the information is still "available", just much less convenient to check when you actually need it. If I've learned that I must avoid products containing monosodium glutamate because of an allergy, I'm going to be unhappy when I need to learn a new code name for it. The convenience for the manufacturer is balanced by an inconvenience for me. And frankly, the whole business seems like a fraud to me. It's not just chemicals that have different names in different European languages, it's also simple things like water, sugar, salt. Either all of those get code numbers (at which point the ingredient labels become utterly useless) or else the manufacturers still have to produce multiple labels for an identical product. --Mark Day ------------------------------ Date: Wed, 25 Nov 1992 19:00:00 -0500 From: Nigel Allen Subject: Change in the Maximum Length of International Telephone Numbers Any application that does not allow for fifteen-digit international telephone numbers is a potential risk today, and will become a real risk on January 1, 1997. The following information from Stentor Canadian Network Management, the consortium of major Canadian telephone companies, was distributed through the Canadian Department of Communications' Terminal Attachment Program Advisory Committee as TAPAC bulletin 92-13. Advance Notice of Change in the Maximum Length of International Telephone Numbers Beginning midnight December 31, 1996, CCITT Recommendation E.164 will be implemented. This recommendation allows the expansion of international telephone numbers from 12 to 15 digits. Although the North American Numbering Plan will not change, some foreign administrations may assign numbers up to 15 digits long to subscribers. Therefore, terminal equipment originating calls to these subscribers must be able to handle the additional digits. For more information on this change, please contact: Marion Norman Stentor Canadian Network Management 410 Laurier Ave. West, 8th Floor P.O. Box 2410, Station D Ottawa, Ontario Canada K1P 6H5 telephone (613) 560-3420 fax (613) 560-3226 Note from NDA: I think the "international telephone number" in this context includes the country code but excludes the access prefix, such as 011 in Canada and the United States. Readers in the United States should presumably contact the North American Numbering Plan Administration at Bellcore rather than Stentor. Nigel Allen nigel.allen@canrem.com Canada Remote Systems - Toronto, Ontario World's Largest PCBOARD System - 416-629-7000/629-7044 [And so, dear RISKS readers, beginning 1 Jan 1997 we can expect various strange reports to appear... PGN ------------------------------ Date: Fri, 27 Nov 1992 11:53:46 +1100 From: ad@munta.cs.mu.OZ.AU (Andrew Davison) Subject: Humorous Submissions CALL FOR SUBMISSIONS FOR A NEW BOOK Tentatively titled: "Humour the Computer: Humorous Writings concerning Computing" We seek contributions of a humorous nature for a new book called `Humour the Computer', an anthology of the comic, amusing and laughable aspects of Computing. It is scheduled to be published by MIT Press early in 1994. Topics of interest include: * computing experiences: e.g. `a day in the life', computing jobs - industry, commerce, teaching, research, etc; getting funded in the 90's, getting a job in the 90's, home computing, how computer people relax, exam marking stories, getting published, office politics * the history of computing: e.g. the mistakes, the disasters, the egos gone mad (with names changed to prevent law suits), folklore (not necessarily true) * the future of computing * computing in the Real World: e.g. in the media, computer salesmen, misconceptions about computing, the misuse (abuse) of computing, faulty software/hardware, the `training' course * fake journal articles: e.g. AI, expert systems, machine architectures software engineering, new programming languages, semantics; surveys of `important' fields: Virtual Reality, neural nets, OO, what-ever, etcl * jokes and cartoons (these will only occupy a small portion of the book) * suggestions for a better name for the collection Contributions will be judged on clarity, insignificance, irrelevance, incorrectness, originality, but most of all for their ability to make the editor laugh. Authors should make their papers understandable to a broad audience - not too many `in-jokes' please. Authors should submit three (3) copies (preferably double-sided) of the prospective article to the editor; people without access to a photocopier may submit a single copy. Electronic submissions are *not* encouraged. Each manuscript should have a title page with the title of the essay, full name(s) and affiliation(s) of author(s), complete postal and electronic addresses, telephone number(s), and a 150 word summary. Contributions must *not* exceed 4000 words (approximately 8 A4 pages typeset 10-point on 16-point spacing, or 12 pages if typewritten double-spaced). Shorter articles will be viewed more favourably than longer ones. Previously unpublished material is preferred. Contributors of published material must have copyright to it. All contributors will be asked to sign a permission letter giving MIT Press the right to print the material but NOT transferring copyright. Submissions must be received by April 3rd, 1993. Authors will be notified of acceptance or rejection by July 1st, 1993. Full versions of the accepted articles must be formatted according to MIT Press conventions, and camera-ready copy must be received by the editor by August 24th, 1993. For further information, contact the editor: Dr. Andrew Davison, Department of Computer Science University of Melbourne, Parkville, Victoria 3052, Australia Email: ad@cs.mu.oz.au Fax: +61 3 348 1184 Tel: +61 3 344 7207 / 5230 Telex: AA 35185 Summary of Important Dates: April 3rd, 1993: Due date for 3 copies of submission July 1st, 1993: Notification of acceptance August 24th, 1993: Due date for final manuscript Early 1994: Publication [If you submit something that you saw in RISKS, which even I shall probably do, you might be very careful to indicate all of the indicated sources -- including RISKS... Good luck! PGN] ------------------------------ End of RISKS-FORUM Digest 14.11 ************************