15-Mar-86 12:29:33-PST,14071;000000000000 Mail-From: NEUMANN created at 15-Mar-86 12:27:57 Date: Sat 15 Mar 86 12:27:57-PST From: RISKS FORUM (Peter G. Neumann, Coordinator) Subject: RISKS-2.27 Sender: NEUMANN@SRI-CSL.ARPA To: RISKS-LIST@SRI-CSL.ARPA RISKS-LIST: RISKS-FORUM Digest, Saturday, 15 Mar 1986 Volume 2 : Issue 27 FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Overload of a different sort [Air traffic stoppage] (Ted Lee) Cordless Phones Cry Wolf! (Peter G. Neumann) The Mob Breaks into the Information Age (Mike McLaughlin) [Non]computerized train wreck (Mark Brader) Ballot Integrity; Specialization in Decision-Making (Tom Benson) Network Security, Integrity, and "Importance" (Kurt F. Sauer) Modems (James R. McGowan) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, nonrepetitious. Diversity is welcome. (Contributions to RISKS@SRI-CSL.ARPA, Requests to RISKS-Request@SRI-CSL.ARPA.) (Back issues Vol i Issue j stored in SRI-CSL:RISKS-i.j. Vol 1: MAXj=45) ---------------------------------------------------------------------- Date: Fri, 14 Mar 86 12:26 EST From: TMPLee@DOCKMASTER.ARPA Subject: Overload of a different sort [Air traffic stoppage] To: Risks@SRI-CSL.ARPA This may or may not involve a computer, but I think it did. Those of you travelling in the Southeast yesterday were made well aware that the Atlanta airport was thrown into a complete chaos by the thunderstorms in the area, and this rippled throughout the air transport system. To make a long story short, I managed to get out of Augusta on a plane that was five hours late, which was okay since that had me leaving Augusta only two hours after I was supposed two, and my connecting flight was also two hours late. The computer part is this. After we boarded in Atlanta the pilot announced he had called for his air traffic control clearance and was told that flow control into Minneapolis was in effect and there would be an indefinite delay. Those of you who have had nothing to do with air traffic control may not realize that in the late 60's or early 70's a change was made in the way the over-all air traffic was controlled: instead of stacking planes up over destinations when traffic got crowded, a national system was instituted to monitor and control the general flow, not allowing a plane to depart until there was a clear slot for it to land in. This is all coordinated between the terminal air traffic control computers and a central computer in Washington. Anyway, we sat for about another half hour and the pilot called again. Same answer. He and/or the Delta operations people used a little common sense: the weather in Minneapolis was just fine and they could understand no reason why the airport should be congested -- they called Washington and after someone checked around received the answer "there shouldn't be any flow control into Minnapolis; someone got their wires crossed." We left in five minutes, having been on the ground for nearly an hour by either a computer error or human error only possible because the computers were installed to manage a humanly unmanageable task -- almost certainly the error was caused by the overload generated to handle the disrupted schedules throughout the system. Ted ------------------------------ Date: Sat 15 Mar 86 12:00:04-PST From: Peter G. Neumann Subject: Cordless Phones Cry Wolf! To: RISKS@SRI-CSL.ARPA The SF Chronicle 15 March 1986 has a news story about cordless phones making ``ghost'' phone calls to the emergency number 911 (and presumably to other numbers as well). The cordless phones, which send out and respond to radio frequencies, behave strangely when their batteries start to run down. In addition, other household appliances can spur cordless phones to start diaing spontaneously. Michael Moos (president of the National Emergency Number Association) was quoted: ``Frequencies given off by other appliances -- micorwave ovens, blenders and even fluorescent lights -- interfere with the cordless phones and make them start dialing.'' On an average day, at least 12 of the 2000 calls received by Santa Clara County's 911 system are such ghost calls. [Cf. heart pacemaker interference, Sputnik triggering garage door openers, automotive CB interference, etc., in past RISKS.] PGN ------------------------------ Date: Fri, 14 Mar 86 15:17:48 est From: mikemcl@nrl-csr (Mike McLaughlin) To: risks@sri-csl Subject: The Mob Breaks into the Information Age INFOSYSTEMS, Vol 33, No. 3, March 86 carries subject article, beginning on page 40. Also several other computer security items. Ought to help sell a few password systems, at least. - Mike McLaughlin ------------------------------ Date: Fri, 14 Mar 86 08:45:38 EST From: ihnp4!utzoo!dciem!msb@seismo.CSS.GOV To: ihnp4!seismo!SRI-CSL.ARPA!RISKS@seismo.CSS.GOV Subject: [Non]computerized train wreck The wreck of a VIA Rail Canada train and Canadian National freight train on February 8 was mentioned in this forum. [See Martin Minow, RISKS-2.9; Chuck Weinstock, RISKS-2.12] I think it's worth pointing out that the accident has been attributed to human error, specifically by the CN engine crew, both of whom were among the 23 killed. (Not 30+ as feared originally.) They drove past a stop signal which both men should have seen. Not only was this NOT a case of computer malfunction, but indeed, a more fully computerized system (with cab signalling and automatic train stopping) would probably have prevented the accident. Mark Brader [A fine example of the risks having to include people, not just computers, and of a more pervasive role of the computer than meets the eye -- indeed a more human-oriented computer system might have helped! Thus, even though it appears NOT to be a computer problem, we discover that the computer could have done better! But, of course, don't blame the computer system. Blame the people who specified, designed, and implemented it -- not JUST the train operator(s). PGN] ------------------------------ Date: Fri, 14 Mar 86 10:54 EST From: (Tom Benson 238-5277) Subject: Ballot Integrity; Specialization in Decision-Making To: RISKS@SRI-CSL.ARPA I don't want to extend this discussion of ballot integrity, but my understanding is that in Pennsylvania there is a registration number on the ballot when it is given to the voter, but the voter tears it off and retains it, so the ballot when in the ballot box is not traceable to the voter. I'm curious about the tone of some of the discussion on this issue. Granted we shouldn't assume the absolute integrity of non-computerized voting without careful scrutiny. But some of the contributions seem, if I am not mistaken, to justify computerized balloting on the grounds of a broad (and unarguable) assumption that "any balloting process can be subverted." Sure. But the object is to insure insofar as possible that it won't be, and that means, primarily, protecting (1) secrecy, and (2) accuracy. Does anyone have an opinion on the question of how the local situation, in this case RISKS, may influence the general consideration of the issue? That is, RISKS is devoted to an interest in computers, not voting. Does that, explicitly or implicitly, influence the question of what ought to be relevant to the decision process? I'm not complaining, nor am I criticizing previous comments by correspondents or the editor. What I am trying to do is draw attention, as a communication scholar, to another potential RISK: the use of electronic mail and digests with clear agendas may inhibit the generalism needed to address substantive problems. Does anyone have instances of this in their experience? (Note: I understand that the problem is not limited to computers; committee work in general suffers from this problem). Tom Benson T3B AT PSUVM (BITNET) [Hmm. For some reason I am rarely accused of undergeneralizing. I keep mumbling that to deal with RISKS, we must do so holistically, and that the computer is only a small part of what must concern us -- even though it is the primary justification for the existence of this forum. Any weak link can be devastating. RISKS indeed tends more toward breadth than depth, toward ALL RISKS than just computer risks. Indeed a few other people have commented that we have strayed off into the subjects of THEIR on-line forums! I don't really think there is too much danger that we are too narrow. But discussion is welcome if relevant to RISKS. PGN] ------------------------------ Date: Fri, 14 Mar 86 18:46:51 CST From: "Kurt F. Sauer" To: Risks Forum Subject: Network Security, Integrity, and "Importance" Tom's Perrine's question about the Interface Message Processors' (IMP) security [RISKS-2.23] is a really well-founded one. As I see it (and I haven't spent much time thinking about it, really), we can design a network's security procedures based on some information and management judgements. Try answering some of these questions about the network you manage or administer: o How critical is the general network operation? This can be based on many things, not the least of which include the value of the tokens passed on the network and the desirability or necessity of proper message reception. o How confidential are the messages? Are patterns, themselves, classified? Traditional cryptology can be applied to "entire messages" (or whatever the DIRNSA will let you get away with), but would releasable routings disclose critical paths? Would they "give away" operational information which should be protected? o Can message speed be increased for vital information whose delivery is paramount? I'm not sure that this is as much a security problem as it is a basic applied-computer- science question. Some feel that packet precedence systems are unnecessary; some feel otherwise. The Defense Data Network (DDN), which is comprised of the ARPAnet and the MILNET, serves a mighty diverse consumer market. Universities, research facilities, commercial institutions, and government operations all share the facilities of the network. Currently, some classified (i.e. sensitive) operations make use of the DDN. Systems like the COINS-CINCPAC project now use the DDN as a transport medium; loss of the medium would have at least some impact on CINCPAC's intelligence operations. For such setups, the basic network security is ensured through fail-secure cryptographic setups which are only able to prepend one specific message header to an already encrypted packet. (One thus gets around the red-black interface problem with packet addressing.) And physical security is ensured by using guards, locked doors, and the like at the point of security interface, and at all secured locations. But this doesn't address the Internet physical or electronic security in general. I believe that the Defense Data Network Program Plan has a scheduled dis-integration of the DDN parts very soon. Obviously we have already traversed the ARPA/MIL separation, but more is soon to come. With the introduction of Internet Private Line Interfaces (IPLIs) (and, based on various community needs, estimates for numbers of IPLIs are nearly 1000--and probably higher), the network can divide itself such that hosts will not talk to non-community-of-interest hosts. The "big plan" includes folding MINET, MILNET, SACDIN (!), and IDHS (!!) into one network: the DDN. The current ARPAnet will remain an R&D network, essentially isolated completely from the DDN. I haven't been watching the network events (due to my absence) for about a year now, so I don't know how far along we are in this plan. But if it's implemented (we're all waiting for BLACKER, so budgetary holdbacks may well intervene), then "vital network nodes" would be physically secured, with the ability to fold ARPAnet into DDN in the event of a crisis where additional redundancy is required to limit network failures due to attacks on the system. Perhaps someone who really knows a lot about these things could comment on the physical security side of the DDN house. For those of you who are interested, I have some citations to references which I would be happy to share with persons on the ARPANET or MILNET; I will respond only to e-mail requests. Kurt F. Sauer Tulsa, Oklahoma Internet: ks@a.cs.okstate.EDU UUCP: ks@svo.UUCP ------------------------------ Date: Fri, 14 Mar 86 16:48:27 PST From: jrm@Ford-wdl1.ARPA (James R. McGowan) Subject: Modems [still... enough already?] To: RISKS@sri-csl.arpa In re the modem controversy: the originating modem contains circuitry to detect answering tones (in the range of 2000-2400 Hz.) It should remain silent until it does detect the answering carrier (at least if the modem claims to be Hayes standard.) However, other sounds on the telephone line (noise, human voice, even just picking up the phone) can sometimes excite th detection circuitry and software, resulting in the originating modem turning on its tone generator. Sorry, but Phil does know what he's talking about. Jim McGowan (jrm@ford-wdl1) [Let's BLOW the WHISTLE on this one. There's no modem operandi. PGN] ------------------------------ End of RISKS-FORUM Digest ************************ -------