12-Aug-87 21:43:19-PDT,29219;000000000000 Return-Path: Received: from csl.csl.sri.com (CSL.SRI.COM) by F4.CSL.SRI.COM with TCP; Wed 12 Aug 87 21:37:52-PDT Received: from F4.CSL.SRI.COM by csl.csl.sri.com (3.2/4.16) id AA03270 for RISKS-LIST@f4.csl.sri.com; Wed, 12 Aug 87 21:40:06 PDT Message-Id: <8708130440.AA03270@csl.csl.sri.com> Date: Wed 12 Aug 87 21:37:07-PDT From: RISKS FORUM (Peter G. Neumann -- Coordinator) Subject: RISKS DIGEST 5.28 Sender: NEUMANN@csl.sri.com To: RISKS-LIST@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Wednesday, 12 August 1987 Volume 5 : Issue 28 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Certification of software engineers (Nancy Leveson) Re: Secrecy About Risks of Secrecy (Maj. Doug Hardie, Russell Williams, Jeff Putnam) Eliminating the Need for Passwords (Lee Hasiuk) Re: Risks of automating production (Richard A. Cowan, James H. Coombs) 'Mustn't tire the computer!' (Scott E. Preece, Rick Kuhn) Re: NASA wet computers (Eugene Miya) Halon (Dave Platt, Steve Conklin, Jack Ostroff, LT Scott Norton, Scott Preece) Railway automation (Stephen Colwill) Employment opportunities at MITRE (Marshall D. Abrams) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, nonrepetitious. Diversity is welcome. Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM. FTP back issues Vol i Issue j from F4.CSL.SRI.COM:RISKS-i.j. Volume summaries for each i in max j: (i,j) = (1,46),(2,57),(3,92),(4,97). ---------------------------------------------------------------------- Date: Wed, 12 Aug 87 21:16:16 -0700 From: Nancy Leveson Subject: Certification of software engineers To: RISKS@CSL.SRI.COM I would like to raise the issue in this forum of certification of software engineers. Certainly, someone who has built a model aircraft would not be considered (or consider themself) competent to design a commercial jet. Yet those who have written a few BASIC programs as a hobby often seem to have no such qualms about their education and abilities. High school students tell me about their jobs building important software systems. As a contrast, engineers must usually satisfy minimal educational requirements, and engineering projects for critical systems often have a requirement for a professional engineer to be involved. Although the ACARD report suggestions were regarded as extreme by many in the computer science field, they are not necessarily much more than is routinely expected in other related professions. For example, System Safety Engineering is a field that is about the same age as computer science or perhaps even somewhat younger. There are, however, already certification programs. And as an example of what can be done for critical systems, there is a MIL-STD-1574A (USAF): System Safety Program for Space and Missile Systems that mandates that Air Force space and missile projects have a "Qualified System Safety Engineer" to manage the system safety program and be "responsible for the effective implementation of the following tasks ... [too many to cite, but essentially the tasks necessary to implement a system safety program]" and who is "directly accountable to the program manager [i.e., the US Air Force program manager] for the conduct and effectiveness of all contracted safety effort for the entire program." A Qualified System Safety Engineer is defined as someone who must meet the following requirements: "A technically competent individual who is educated at least to the bachelor of science level in engineering or related applied science and is registered as a professional engineer in one of the states or territories of the United States or has equivalent experience approved by the Purchasing Office. This individual shall have been assigned as a system safety engineer on a full-time basis for a minimum of four years in at least three of the six functional areas listed below: System Safety Management System Safety Analysis System Safety Design System Safety Research System Safety Operations Accident Investigation I don't know of any similar requirements in government standards for managers of software engineering programs on critical projects nor any similar assignment and acceptance of direct responsibility and accountability to the customer for the *effectiveness* of the software engineering effort. Does anybody else? Am I wrong in my observation that under-qualified people are sometimes doing critical jobs and making important decisions? Do you agree that some type of certification is necessary? If so, there are still many open issues e.g., should there be minimum educational requirements and what kind, should there be minimum experience requirements, should there be examinations, should certification be in particular application areas (dp, scientific, safety-critical real-time, etc.) or perhaps in particular subareas (systems analysis, design and coding, QA, etc.), should there be continuing education requirements, should there be minimum requirements for those teaching software engineering and certification of educational programs, ... Nancy Leveson ------------------------------ Date: Wed, 12 Aug 87 12:46 EDT From: "Maj. Doug Hardie" To: risks@csl.sri.com Subject: Re: Secrecy About Risks of Secrecy (RISKS-5.26) > From: Jerome H. Saltzer > So the decision must be accompanied by a plan to shore things up, either > by fixing the flaw, getting the information moved to a safer place, or-- > a common solution--putting other barriers around the flawed system... This is practical when you are dealing with a single system. However, the number of DEC VAXs (as an example) that handle sensitive information is too large to identify. There currently exists no way to even tell all the administrators using any particular system that they have a problem. While additional barriers are probably not prohibitive for one system, when multiplied by the number of systems in use throughout the government, I expect that cost would be unbearable. -- Doug [... and the cost of each administrator and user on each system keeping his head in sand may be even greater... PGN] ------------------------------ Date: Tue, 11 Aug 87 08:18:31 pdt From: ucbcad!ames.UUCP!lll-tis!elxsi!beatnix!rw@ucbvax.Berkeley.EDU (Russell Williams) To: ames!CSL.SRI!RISKS@csl.sri.com Subject: Secrecy of Secrecy: A vote for disclosure I just want to vote, very strongly, for disclosure of operating system security flaws. Non-publication of these flaws assumes that there is some other system for distributing such information only to those of us in industry responsible for design and implementation of reasonably secure operating systems. If there is such a system please let me in on it (after a suitable security check, of course); if not, I'm confident our customers would prefer the situation where 10 potential penetrators *and* I know the information, to the situation where only 5 potential penetrators know it. Russell Williams, ELXSI Super Computers, San Jose ...{ucbvax!sun,lll-lcc!lll-tis,altos86}!elxsi!rw ------------------------------ Date: 12 Aug 87 11:42 EST From: putnam%thuban.tcpip@ge-crd.arpa Subject: security discussions To: risks@csl.sri.com The question about open discussion of computer security flaws brings up an interesting point that I have not seen mentioned, that is, that the people who understand such flaws (often the people who try to find them) are not as often as we might like the people who administer the systems. In many cases I have seen the systems managers are not prepared, either by interest, temperament, or background, to understand the security problems and react properly to them. (Not that this is the case everywhere, but it is certainly the case in many situations.) Such system managers are the types who tend to react to security holes by trying to suppress any information about them - not by trying to fix them. They are also quite likely to respond inappropriately by imposing severe security measures in the wrong places - usually impeding the real purpose of the machines, and rarely actually fixing the problems (indeed, sometimes this "added security" makes the problem worse). The question of publicizing security holes is thus further complicated. If the problem is publicized, will it spur some people to take (often inappropriate) measures that will inconvenience (or worse) the users of the machine in a misguided attempt to patch the problem? jeff putnam [We have also had various cases of people who tried vainly to convince their administrators that there were problems, and then got fired when they demonstrated the problems... PGN] ------------------------------ Date: Wed, 12 Aug 87 10:07:33 EDT From: ucbcad!ames.UUCP!rochester!srs!lee@ucbvax.Berkeley.EDU (Lee Hasiuk) To: rochester!CSL.SRI!RISKS@csl.sri.com Subject: Eliminating the Need for Passwords Without trying to continue the discussion on passwords, access codes, credit card numbers, etc, I would like to relate a very interesting article about eliminating the need for people to ever put their actual code in the open. The article was about 'Zero Knowledge Proofs' and appeared in the Science Times section of the New York Times earlier this year. It appears that an Israeli scientist has developed an authorization system based on such proofs that allows a person to verify that they are the owner of an account, without having to give away the 'account number' or any other information which allows them to be impersonated. The basic idea is to give the account owner a complex graph which is successfully colored so that no two connected nodes use the same color. It is easy to generate such a graph, but given a complex graph, coloring it is not, in general, possible to color it successfully. A device checking authorization gets to see the graph, but the color of the nodes is hidden. The device picks two connected nodes at a time and is shown that they are, indeed, colored differently. After each pair has been shown, the colors used in the graph are interchanged so that after many tries the device can be quite sure that the graph is colored, but have no clue as to a coloring scheme that works (which when combined with the graph, represents the actual account number). The article stated that such a scheme could be applied to passwords, and hypothesized a computer that, rather than ask for a login password, asked a series of questions that would change each session. The user would know a scheme, based on the questions and his 'password' to produce answers that would let the computer know with very high certainty that they were the authorized user. Lee Hasiuk [Also note crypto authenticators such as the Sytek Challenge mechanism. But also note that access has been gained, some underlying operating systems may force you to assume that everyone is equally trusted (or untrusted)... PGN] ------------------------------ Date: Mon 10 Aug 87 03:47:58-EDT From: Richard A. Cowan Subject: Re: Risks of automating production To: risks@csl.sri.com, jazbo%brownvm.bitnet@WISCVM.WISC.EDU From: "James H. Coombs" The folklore has always been that computers, especially in the form of robots, would one day render blue collar workers obsolete... It is true that automation has not rendered workers obsolete, or resulted in huge cost savings. As you note, the main impact of automation so far is that it results in greater central *control* over the production process. In fact, this was one of the principal motives for automation from the start: management wanted greater control over labor. (By "management" here I mean high-level managers who are removed from day-to-day production.) Even though the worst fears have not been realized yet, that is no reason to be optimistic. Although automation thus far has been rather awkwardly implemented (requiring nearly as many workers as before), it has set the stage (by routinizing work and thus deskilling workers) for a new phase in automation that actually gets rid of the work force. As David Noble said in his (highly recommended) book Forces of Production, "Men behaving like machines paved the way for machines without men." ... The speculation now is that managers are more likely to be displaced than workers, since it is the managers who tend to be responsible for inventory management and accounting. The "managers" to be replaced here are probably quite low-level supervisors. But the idea that automation hurts management *in general* (while the workers make out fine) would be a bit silly. In the end, I believe that automation will cause incredibly disruption and suffering unless there is also a dramatic shortening of the work week. Check out the Noble book -- Oxford University Press, 1984! -rich ------------------------------ Date: Mon, 10 Aug 87 13:09:17 EDT From: "James H. Coombs" Subject: Re: Risks of automating production To: "Richard A. Cowan" , RISKS@csl.sri.com From: Richard A. Cowan Although automation thus far has been rather awkwardly implemented (requiring nearly as many workers as before), it has set the stage (by routinizing work and thus deskilling workers) for a new phase in automation that actually gets rid of the work force. I have been confused from the beginning about what it is that the workers do now. I suppose that it could be little more than filling parts buckets for machines or something like that, in which case their work would be even more routine than before. I had this hope, however, that they were servicing the machines, in which case their work might be significantly more skilled and interesting. Can anyone give more details on this? Also, I wonder what happens to the managers at various levels. Does their work become more interesting and rewarding, or less? I'm sure that for some, the "planners," work becomes less stressful. What about the others? --Jim ------------------------------ Date: Wed, 12 Aug 87 09:34:52 CDT From: preece%mycroft@gswd-vms.Gould.COM (Scott E. Preece) To: RISKS@csl.sri.com Subject: 'Mustn't tire the computer!' "A. N. Walker" > "It is true that we tell counter staff at branches to make enquiries if > cheques are cashed on three consecutive days. But to instruct the > computer to do this on ATMs would be far too time-consuming," he said. Well, while it's true that it shows great lack of insight not to do anything about a known potential problem (especially when the withdrawals were at the daily max, which should always be a flag for caution), it's less than clear what they should do. A human teller can ask for ID; most existing ATMs can't. If you just fail the transaction, you're going to make customers unhappy (how often we object to restrictions intended to protect us). It would be a good idea for all ATMs to have cameras and for human intervention to be triggered by any of a number of suspicious circumstances (I'd say max withdrawals on two successive days was suspicious), but that's also going to raise the cost of service... scott preece, gould/csd - urbana, uucp: ihnp4!uiucdcs!ccvaxa!preece ["The real risk here is having people who do not know anything make pronouncements about what computers can and cannot do, including the bank manager... Why would anybody store the information unsorted and unorganized and then search brute force through every record?!" ... anonymous commenter on Andy Walker's message] ------------------------------ Date: Wed, 12 Aug 87 10:45:24 edt From: kuhn@ICST-SE.ARPA (Kuhn) To: risks@csl.sri.com Subject: Re: "Mustn't Tire the Computer" [...] When I worked on ATM and systems software for banks and savings & loans, [for UK readers: US savings & loans are descendents of your Building Societies] I learned that some of them run what they call a "Kiting Suspect Report" that attempts to spot check kiting schemes. One of my customers detected a check kiter three or four days after he had started cashing 8-10 checks a day at area supermarkets against his accounts at my customer and another S&L. I don't know if charges were ever filed, but the other S&L and all the supermarkets were notified and the scheme stopped. --Rick Kuhn, National Bureau of Standards ------------------------------ Date: Tue, 11 Aug 87 23:43:31 PDT From: Eugene Miya To: risks@csl.sri.com Subject: Re: NASA wet computers [...] Practically, all of major computing computing facilities in NASA (not the really small distributed machines) have wet covers. This is because most Centers were constructed before halon was put to wide use and so fire protection is provided via "wet" protection. The problem comes in upgrade. Mission Control Centers are used practically all the time, making upgrades tough. I asked this question at a meeting today for RISKS. It comes from "very reliable sources." Also note that lots of Centers are in hurricane areas as well. --eugene ------------------------------ Date: Wed, 12 Aug 87 10:43:35 PDT From: dplatt@teknowledge-vaxc.arpa (Dave Platt) To: risks@csl.sri.com Subject: Halon risks in computer rooms, etc. Originally-Sent-To: davy@intrepid.ecn.purdue.edu [Many messages on this subject... I have excerpted to reduce overlap. PGN] As I understand it, Halon's fire-killing ability comes from two characteristics of the gas: 1) It excludes oxygen, when used in sufficiently large amounts. This is one of the ways in which carbon dioxide kills flames (its cooling effect being the other), and thus any oxygen-exclusion risks from a Halon system would also probably exist in a CO2 system of similar gas-magnitude. 2) Halon interferes, chemically, with the combustion process. I believe that it ties up the free (ionized) radicals in the flame, and blocks one or more of the partial-oxidation steps. Because this is a chemical effect, and not a physical one such as oxygen exclusion, it can occur at relatively low concentrations of Halon in the atmosphere. I saw a demo at NCC a couple of years ago, in which a Halon-system manufacturer's sales-rep stood in a closed booth smoking a cigarette. He then let loose a 1-second burst of Halon, and the cigarette went out. For the next several minutes, he stood in the booth, breathing normally, and demonstrated that he was unable to relight his cigarette (he stuck a Bic lighter outside the booth through an arm-sized hold, flicked it alight, moved it gently back within the booth, and it went out the moment it entered the Halon-charged atmosphere). I've been told that the major risk to humans from being in an area that has been Halonized isn't the Halon itself... instead, it's the risk of inhaling the rather nasty partial-combustion products of the plastics, other petrochemicals, and miscellaneous combustibles that were burning when the Halon was released. Because the combustion was interrupted, these chemicals won't have been burned to completion (to water, carbon dioxide, etc.); they may include lots of carbon monoxide, hydrochloric or other acids, and similar things that aren't conducive to long life and respiratory health. Please don't take this as gospel... and kids, don't try this at home. X-Uucp: /decwrl|hplabs \ { seismo|uw-beaver}!teknowledge-vaxc.arpa!dplatt \ucbvax|sun / X-Usnail: Teknowledge Inc., 1850 Embarcadero Road, Palo Alto CA 94303 X-Voice: (415) 424-0500 ------------------------------ From: uwvax!seismo!ingr!tesla!steve@ucbvax.Berkeley.EDU Date: Wed, 12 Aug 87 11:57:41 EDT To: ucbvax!csl.sri!risks@csl.sri.com Subject: HALON Several years ago, at a previous employer, I designed fire control systems, including many HALON systems. HALON does -not- extinguish the fire by displacing the oxygen in the air. It interferes with the actual combustion process. The amount of HALON required to disable combustion is only around 3%-7%, which leaves plenty of oxygen for humans. (The following is all from memory and may not be entirely accurate) There are some effects to humans from prolonged ( >1 hour ) exposure to HALON at this concentration. I think that they are on the order of headaches, etc. and dissappear when exposure ceases. There were no long term effects known at that time. The greatest danger in using HALON that I know of results from exposure to the gas as it is discharged from the nozzles into the room. HALON systems are designed to get the gas dispersed in the required concentration as rapidly as possible. The high flow rate of the gas and the expansion at the nozzle results in very low temperatures in the discharged gas. I heard a story that a government agency required a full discharge test of a HALON system in a computer room, and to shield some installed equipment, someone held a sheet of plywood between one of the nozzles and the equipment. He suffered severe frostbite on all eight fingers. Steve Conklin, Intergraph Corp., Huntsville, AL 35807, (205) 772-6618 {uunet,ihnp4}!ingr!tesla!steve ------------------------------ Date: 12 Aug 87 11:48:01 EDT From: Jack Ostroff Subject: halon, sprinklers, etc. To: risks@csl.sri.com Cc: ostroff@RED.RUTGERS.EDU I used to be a volunteer fireman when Halon became popular, [...] At one computer center I know, the fire extinguisher system consists of CO2 jets below the artificial floor. It has never gone off, but rumor has it that the jets will throw the floor tiles a small way, before flooding the entire basement with CO2 in several minutes. This DOES replace the oxygen, and everyone who works there is told to RUN LIKE HELL if they hear the fire alarms go off. Jack (OSTROFF@RED.RUTGERS.EDU or ...!rutgers!red.rutgers.edu!ostroff) ------------------------------ Date: Wed, 12 Aug 1987 15:10:03 PDT From: "LT Scott A. Norton, USN" <4526P%NAVPGS.BITNET@wiscvm.wisc.edu> Subject: Halon to protect computer installations To: Risks Forum [...] Of course, Halon does have some risks. Nothing's perfect. The immediate risk to people is that at very high temperatures, Halon is chemically changed to phosgene, a strong poison that burns the lungs. The temperature in a small class-A fire in a computer room would not produce hazardous amounts of phosgene, but a large conflagration might. The reason why the fire department is not satisfied with just Halon is that it is a one-shot system. That's O.K. if a fire breaks out in the protected area, the Halon system activates promptly, and the fire goes out. But there are some failure modes: 1. If the room is not sealed, the Halon will be blown away. If the initial source of combustion is still present, the fire will reflash. Normally, Halon systems shut off ventilation and air conditioning before discharging the Halon, but do you trust those relays to work? 2. If the fire spreads to the area from outside, the Halon system will only push it back once. Once the Halon dissipates, the fire can move in again. 3. Halon systems are complicated. Contrast that with a sprinkler system: Water in a pipe, Wood's metal keeping it there. In a fire, the metal melts and water sprays out. So, the tradeoff in computer room fire protection is that Halon is very safe to the equipment and to people in the event of an accidental discharge, sprinklers are safe for the people but not the equipment in an accidental discharge. In a small fire under normal conditions, Halon is effective at extinguishing the fire but doesn't hurt the equipment and has a low risk to the people (probably lower than that of the carbon monoxide from the fire). But in the case of a big fire, Halon by itself can not be counted on to fully extinguish the fire. When I was Tactical Data Systems Officer on a cruiser, I worried about firefighting water, since the Navy uses sea water to fight fires. So don't complain about fresh water spraying into your equipment, it will just wash troublesome dust off the circuits. :-) LT Scott A. Norton, USN Naval Postgraduate School Monterey, CA 93943-5018 4526P@NavPGS.BITNET ------------------------------ Date: Wed, 12 Aug 87 09:45:10 CDT From: preece%mycroft@gswd-vms.Gould.COM (Scott E. Preece) Received: by mycroft.gould.com (5.54/) Message-Id: <8708121445.AA04283@mycroft.gould.com> To: RISKS@csl.sri.com Subject: Fire protection in the computer room [...] We had a false alarm set off the halon in our machine room. The amount of warning the system gives before discharging the gas is impressive. So is the effect on the computer room (lots of gas, lots of air motion, lots of dust and displaced ceiling tiles). Much preferable to water. (But also much more expensive -- that false alarm was not cheap by any stretch of the language.) scott preece, gould/csd - urbana, uucp: ihnp4!uiucdcs!ccvaxa!preece ------------------------------ From: Stephen Colwill To: RISKS@csl.sri.com Date: Wed, 12 Aug 87 11:09:00 WET Subject: railway automation > Scott E. Preece > A train is a large object whose position is only approximately known > at best, whose speed is hard to change and is changed using systems > whose performance is subject to wild fluctuations with age, maintenance > and track conditions, and whose surroundings are totally invisible to > the controlling system. In the context of the automation of an existing network using old rolling stock, I take your point. My original posting focussed, however, on the London Docklands Light Railway. The LDLR was purpose-built from scratch, the rolling stock is new and also purpose-built. It seems to me that the designers had ample opportunity to install precisely the kind of sensors you describe. I cannot believe that these sensors are beyond modern technology. Stories of trains jumping buffers give the lie to any hope that the opportunity afforded by the design of a virgin system has been properly taken. It is this that I find so disappointing. Steve Colwill, Praxis, Bath. ------------------------------ To: risks@csl.sri.com Subject: Employment opportunities at MITRE Date: Wed, 12 Aug 87 15:40:37 -0400 From: Marshall D. Abrams We are looking for for people to join the Information Security Group at The MITRE Washington Center. As you probably know, MITRE is a not-for-profit Federal Funded Research and Development Center, founded at the request of the Air Force. We work almost exclusively for the government, both for civil and military agencies and departments. MITRE support to sponsors includes: security requirements analysis and definition; security assessment of existing systems; information security design; procurement support including document development, evaluation, and contractors supervision; policy development support; prototype implementation; verification; and certification and accreditation planning. We have a good mix of theory, policy, and real applications which has proven to be very synergistic. We are currently involved with network and database security both for development of evaluation criteria, and for applications to operational systems. I would welcome the opportunity to discuss our work program, and staffing requirements with people at all levels of qualifications. U.S. citizenship is required. Marshall D. Abrams, phone: (703) 883-6938, The MITRE Corporation, 7525 Colshire Drive, Mail Stop Z670, Mc Lean, VA 22102 ------------------------------ End of RISKS-FORUM Digest ************************ -------