Subject: RISKS DIGEST 11.94 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Tuesday 18 June 1991 Volume 11 : Issue 94 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: V-22 Osprey crashes on first flight (Martyn Thomas) Re: The Patriot system and the Dharan Scud: Time Warp (Rob Horn) AT&T & voice recognition (Ralph Moonen) More RISKS of stolen credit cards (Tsutomu Shimomura) Ethics, Drug Testing, and Hacking (Sanford Sherizen) Legion-of-Doom Goes Corporate (Craig Neidorf) Communications Privacy Statement (Marc Rotenberg) Dependable Computing: DCCA-3 call for papers (Carl Landwehr) 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 11, 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, 18 Jun 91 12:43:18 BST From: Martyn Thomas Subject: V-22 Osprey crashes on first flight The fifth prototype Bell-Boeing V-22 Osprey tilt-rotor aircraft crashed one minute into its maiden flight on June 1st, according to Flight International (19-25 June, p 16). The pilots reported control problems, with the aircraft feeling tail heavy and rolling from side to side. The other four V-22s have 567 flight hours in 463 flights. The maiden flight of number 5 was postponed last week after tools were found to be missing, but only a drill-bit was found under the fuselage floor. Flight-control software problems in another V-22 were traced to a faulty switch. Martyn Thomas, Praxis plc, 20 Manvers Street, Bath BA1 1PX UK. Tel: +44-225-444700. Email: mct@praxis.co.uk ------------------------------ Date: Tue, 18 Jun 91 13:48 EST From: HORN%HYDRA@sdi.polaroid.com Subject: Re: The Patriot system and the Dharan Scud: Time Warp (RISKS-11.92) A slight correction, the specification for Patriot was 14 hours of operation. The 22 hour figure was the actual operational time for systems that did detect the Scud but were out of range. The origin of the 14 hour spec was the original intended use of Patriot in defense of mobile forces where it was expected that the systems would relocate several times per day, so the assumption was not tacit. It was a deliberate considered decision, balancing procurement and operational costs against the operational needs. For those who don't understand how a 0.36 second (or 1 ppm) error can cause this problem, you have to examine how a machine tracks a target. At initial acquisition time you have a single location, but no speed or direction. So you put a ``box'' around the location and look again a very short time later. Based upon the article, the timing error resulted in a mislocated box. A slower target (like an airplane) would still have been within the box. A Mach 6 missile was outside the box. So the computer did not associate the second echo with the first echo. This incident is a good illustration of the problem with the overemphasis of formal proofs. They are only as good as the specification being proved. I cannot find the reference, but I recall that more than half of the problems found in current delivered systems can be traced to incorrect specification. The issue of proper specification is important to all industries, not just software. It is time to start listening to the ideas that are being spread in other industries. A good starting point for a literature search is to read the works of Deming, Juran, Taguchi, and Ishahawa. Then look under keywords like ``Total Quality'' and ``Quality Function Deployment'' and expand from what you find there. Total Quality distinguishes three kinds of requirements: - Expressed, those that the user actually states e.g. ``I want a hotel room tomorrow night''. These are the traditional totality of software requirements. - Expected, those that are expected but not expressed e.g. that the hotel room has a bed. With Patriot, the expected but not expressed requirement was that so long as the other hardware remained functional past its specified endurance the software would also remain functional. - Unexpected delights, those that are neither consciously wanted nor missed when absent, like a spectacular view from the room window. The goal of requirements setting is to understand and learn all three. Many of the techniques used exploit different formalisms to learn what people need. They are based on the assumption that formalism is a tool to be used to clarify communications. Different or contradictory formalisms should be used so that diverse personalities can all understand proposed requirements and make their own comments and corrections. Some of the diversities that need to be supported are: left-brain vs right-brain personalities actor vs object vs observer perspectives verbal (written word/ formula) vs aural (spoken/ lecture) vs visual (pictures) vs tactile (touch) oriented personalities. You need to provide clear presentations that are oriented towards all of the above. One of the most difficult for computer systems requirements is the tactile personalities. Many people, especially those in the machinery field, need something that they can touch and feel. They may have been trained to understand pictures that represent objects, but you can see their eyes light up and their brain engage when you hand them a physical thing to understand. The traditional software documents are very poor communication tools with tactile people. This is a very real risk when more and more machinery involves software components. The people with the best understanding of machinery are the ones for whom we provide the worst communications and understanding. I suppose that this is vaguely related to the ongoing Formalism debate. I do know from both experience and the literature that men and women fall into all of the above categories. Rob Horn horn%hydra@polaroid.com [Rob, Thanks for the correction on the 14 vs 22 hours; what you describe is exactly as it was stated in the AW&ST article. I goofed. A comment to stave off objections from the formalists: bad specs are not an "illustration of the problem with the overemphasis of formal proofs." They are an illustration of the problem with bad specs, which can effect system behavior -- irrespective of whether formal methods are used! PGN] ------------------------------ Date: Tue, 18 Jun 91 13:22 MDT From: rmoonen@hvlpa.att.com Subject: AT&T & voice recognition USA today had an article about a new AT&T product involving voice recognition. This product would enable a shop-holder to call a number, read aloud his merchant number, the credit card number, and the purchase price, and the customer would be billed. I mean, how much more RISK'ier can you get? --Ralph Moonen ------------------------------ Date: Mon, 17 Jun 91 19:46:23 -0600 From: tsutomu@NO-SENSE.LANL.GOV (Tsutomu Shimomura) Subject: More RISKS of stolen credit cards About 18 months ago, I had my wallet stolen. Upon cancelling my credit cards and receiving replacements, I was somewhat surprised to discover that one them looked very familiar. It had an account number which was one greater than the one I'd just reported stolen (38XX-XXXXXX-XX11 instead of 38XX-XXXXXX-XX03; the final digit is a checksum, uniquely determined by the preceding digits). As it would be bad for a credit card thief to be able to trivially predict the account numbers of replacement cards, I had written this off to coincidence. This card was lost last week, and I just received the replacement. The account number follows in the obvious pattern: 38XX-XXXXXX-XX29. It is still possible that this sequence is coincidental, but it would seem most unlikely given the number of possible account numbers. I hope the RISKS are recognized by the issuing bank (a large U.S. bank) before they are recognized by the credit card thieves. ---TS ------------------------------ Date: Tue, 18 Jun 91 14:46 GMT From: Sanford Sherizen <0003965782@mcimail.com> Subject: Ethics, Drug Testing, and Hacking I sometimes read the comics. Only during off hours, hidden behind a computer book, and in places where no adults can see me. The Boston Globe on Thursday, June 13, had a Dilbert comic strip that showed us how to balance some competing risks. MAN TALKING TO HIS DOG. "It's an ethical dilemma...I support my company's goal of discouraging drug use, but the random drug testing policy is a violation of my constitutional rights. I'll get fired if I refuse the test. What is the ethical thing to do?" DOG TO MAN. "Hack into their computer and change your boss's test results." MAN USING THE COMPUTER AND TALKING TO DOG (AND HIMSELF). "Sometimes the straightest path is through the mud." DOG RESPONDING TO MAN. "Good, rationalize it with an obtuse metaphor." Out of the mouths of comic strips ... Sandy ------------------------------ Date: Tue, 18 Jun 91 11:32:59 CDT From: "Craig Neidorf" Subject: Legion-of-Doom Goes Corporate AFTER YOU'VE BEAT 'EM -- JOIN 'EM (Time Magazine, 24 June 1991, p.13) After infiltrating some of America's most sensitive computer banks, is there any challenge left for a digital desperado? Only to go legit, say three former members of the notorious hacker group, the LEGION OF DOOM, who have quit the outlaw game to start Comsec Data Security. The Legionnaires claimed an 80% success rate in penetrating computer networks, and now they want to teach private industry to protect itself from the next generation of intruders. "You can't put a price tag on the information we know," says Scott Chasin, a Comsec partner. But they'll try. (This article features a color photo of the three founding members: Erik Bloodaxe, Doc Holiday, and Malefactor.) ------------------------------ Date: Fri, 14 Jun 91 10:25:08 PDT From: cdp!mrotenberg@labrea.Stanford.EDU Subject: *Communications Privacy Statement* STATEMENT IN SUPPORT OF COMMUNICATIONS PRIVACY Washington, DC June 10, 1991 As representatives of leading computer and telecommunications companies, as members of national privacy and civil liberties organizations, as academics and researchers across the country, as computer users, as corporate users of computer networks, and as individuals interested in the protection of privacy and the promotion of liberty, we have joined together for the purpose of recommending that the United States government undertake a new approach to support communications privacy and to promote the availability of privacy-enhancing technologies. We believe that our effort will strengthen economic competitiveness, encourage technological innovation, and ensure that communications privacy will be carried forward into the next decade. In the past several months we have become aware that the federal government has failed to take advantage of opportunities to promote communications privacy. In some areas, it has considered proposals that would actually be a step backward. The area of cryptography is a prime example. Cryptography is the process of translating a communication into a code so that it can be understood only by the person who prepares the message and the person who is intended to receive the message. In the communications world, it is the technological equivalent of the seal on an envelope. In the security world, it is like a lock on a door. Cryptography also helps to ensure the authenticity of messages and promotes new forms of business in electronic environments. Cryptography makes possible the secure exchange of information through complex computer networks, and helps to prevent fraud and industrial espionage. For many years, the United States has sought to restrict the use of encryption technology, expressing concern that such restrictions were necessary for national security purposes. For the most part, computer systems were used by large organizations and military contractors. Computer policy was largely determined by the Department of Defense. Companies that tried to develop new encryption products confronted export control licensing, funding restrictions, and classification review. Little attention was paid to the importance of communications privacy for the general public. It is clear that our national needs are changing. Computers are ubiquitous. We also rely on communication networks to exchange messages daily. The national telephone system is in fact a large computer network. We have opportunities to reconsider and redirect our current policy on cryptography. Regrettably, our government has failed to move thus far in a direction that would make the benefits of cryptography available to a wider public. In late May, representatives of the State Department met in Europe with the leaders of the Committee for Multilateral Export Controls ("COCOM"). At the urging of the National Security Agency, our delegates blocked efforts to relax restrictions on cryptography and telecommunications technology, despite dramatic changes in Eastern Europe. Instead of focusing on specific national security needs, our delegates continued a blanket opposition to secure network communication technologies. While the State Department opposed efforts to promote technology overseas, the Department of Justice sought to restrict its use in the United States. A proposal was put forward by the Justice Department that would require telecommunications providers and manufacturers to redesign their services and products with weakened security. In effect, the proposal would have made communications networks less well protected so that the government could obtain access to all telephone communications. A Senate Committee Task Force Report on Privacy and Technology established by Senator Patrick Leahy noted that this proposal could undermine communications privacy. The public opposition to S. 266 was far-reaching. Many individuals wrote to Senator Biden and expressed their concern that cryptographic equipment and standards should not be designed to include a "trapdoor" to facilitate government eavesdropping. Designing in such trapdoors, they noted, is no more appropriate than giving the government the combination to every safe and a master key to every lock. We are pleased that the provision in S. 266 regarding government surveillance was withdrawn. We look forward to Senator Leahy's hearing on cryptography and communications privacy later this year. At the same time, we are aware that proposals like S. 266 may reemerge and that we will need to continue to oppose such efforts. We also hope that the export control issue will be revisited and the State Department will take advantage of the recent changes in East-West relations and relax the restrictions on cryptography and network communications technology. We believe that the government should promote communications privacy. We therefore recommend that the following steps be taken. First, proposals regarding cryptography should be moved beyond the domain of the intelligence and national security community. Today, we are growing increasingly dependent on computer communications. Policies regarding the appropriate use of cryptography should be subject to public review and public debate. Second, any proposal to facilitate government eavesdropping should be critically reviewed. Asking manufacturers and service providers to make their services less secure will ultimately undermine efforts to strengthen communications privacy across the country. While these proposals may be based on sound concerns, there are less invasive ways to pursue legitimate government goals. Third, government agencies with appropriate expertise should work free of NSA influence to promote the availability of cryptography so as to ensure communications privacy for the general public. The National Academy of Science has recently completed two important studies on export controls and computer security. The Academy should now undertake a study specifically on the use of cryptography and communications privacy, and should also evaluate current obstacles to the widespread adoption of cryptographic protection. Fourth, the export control restrictions for computer network technology and cryptography should be substantially relaxed. The cost of export control restrictions are enormous. Moreover, foreign companies are often able to obtain these products from other sources. And one result of export restrictions is that US manufacturers are less likely to develop privacy-protecting products for the domestic market. As our country becomes increasingly dependent on computer communications for all forms of business and personal communication, the need to ensure the privacy and security of these messages that travel along the networks grows. Cryptography is the most important technological safeguard for ensuring privacy and security. We believe that the general public should be able to make use of this technology free of government restrictions. There is a great opportunity today for the United States to play a leadership role in promoting communications privacy. We hope to begin this process by this call for a reevaluation of our national interest in cryptography and privacy. Mitchell Kapor, Electronic Frontier Foundation Marc Rotenberg, CPSR John Gilmore, EFF D. James Bidzos, RSA Phil Karn, BellCore Ron Rivest, MIT Jerry Berman, ACLU Whitfield Diffie, Northern Telecom David Peyton, ADAPSO Ronald Plesser, Information Industry Association Dorothy Denning, Georgetown University David Kahn, author *The Codebreakers* Ray Ozzie, IRIS Associates Evan D. Hendricks, US Privacy Council Priscella M. Regan, George Mason University Lance J. Hoffman, George Washington University David Bellin, Pratt University (affiliations are for identification purposes only) ------------------------------ Date: Tue, 18 Jun 91 13:20:11 -0400 From: landwehr@itd.nrl.navy.mil (Carl Landwehr) Subject: Dependable Computing: DCCA-3 call for papers DCCA-3 Call for Papers 3rd IFIP Working Conference on Dependable Computing for Critical Applications Can we rely on computers? Splendid Hotel La Torre, Mondello (Palermo), Sicily, Italy 14-16 September 1992 Organized by IFIP Working Group 10.4 on Dependable Computing and Fault Tolerance In cooperation with IFIP Technical Committee 11 on Security and Protection in Information Processing Systems IEEE Computer Society Technical Committee on Fault-Tolerant Computing EWICS Technical Committee 7 on Systems Reliability, Safety and Security University of Pisa Istituto di Elaborazione dell'Informazione del CNR, Pisa Associazione Italiana per l'Informatica ed il Calcolo Automatico General Chair L. Simoncini University of Pisa, Italy Program co-Chairs C.E. Landwehr Naval Research Laboratory, USA B. Randell University of Newcastle upon Tyne, UK Local Arrangements Chair E. Ricciardi, IEI-CNR, Italy Program Committee J.A. Abraham, U of Texas, USA B. Littlewood, City U, UK P. Bishop, National Power, UK T. Lunt, SRI Int'l, USA A. Costes, LAAS-CNRS, France J. Meyer, U of Michigan, USA D. Craigen, ORA Corp., Canada M. Morganti, Italtel, Italy K. Dittrich, U of Zurich, Switzerland S. Natkin, CNAM, France H. Ihara, Hitachi, Japan J-J. Quisquater, Philips, Belgium R.K. Iyer, U of Illinois, USA R.D. Schlichting, U of Arizona, USA J.P. Kelly, U of California, USA F.B. Schneider, Cornell U, USA R. Kemmerer, U of California, USA D. Siewiorek, Carnegie-Mellon U, USA H. Kopetz, Technische U Wien, Austria L. Strigini, IEI-CNR, Italy J.H. Lala, CS Draper Lab, USA I. Sutherland, ORA Corp, USA K. Levitt, U of California, USA W.M. Turski, Warsaw U, Poland Ex Officio J-C. Laprie, LAAS-CNRS, France IFIP WG 10.4 Chair DCCA-3 is held in conjunction with the 12th IFIP World Congress (Madrid, Spain, 7-11 September 1992) Increasingly, individuals and organizations are becoming critically dependent on sophisticated computing systems. In differing circumstances, this dependency might for example center on the continuity of service received from the computing system, the overall performance level achieved, the real-time response rate provided, the extent to which catastrophic failures are avoided, or confidentiality violations prevented. The notion of dependability, defined as the trustworthiness of computer service such that reliance can justifiably be placed on this service, enables these various concerns to be subsumed within a single conceptual framework with reliability, availability, safety and security, for example, being treated as particular attributes of dependability. This, the third IFIP Working Conference on the topic of Dependable Computing for Critical Applications, aims to continue the very successful tradition created by its predecessors (1989: Santa Barbara, California and 1991: Tucson, Arizona). It will thus provide a venue for the presentation and detailed discussion of research and advanced development relating to theory, techniques and tools for specifying, designing, implementing, assessing, validating, operating and maintaining critical computing systems. Of particular, but not exclusive, interest will again be presentations which address combinations of dependability attributes, e.g. safety and security, through studies of either a theoretical or an applied nature. Submitting a Paper: Six copies (in English) of original work should be submitted by 31 January 1992, to the Program co-Chair: Dr. Carl E. Landwehr Code 5540 Naval Research Laboratory Tel: +(1) 202 767 3381 Washington, DC 20375-5000 Fax: +(1) 202 404 7942 USA E-mail: landwehr@itd.nr.navy.mil Papers should be limited to 6000 words, full page figures being counted as 300 words. Each paper should include a short abstract and a list of keywords indicating subject classification. Papers will be refereed and the final choice will be made by the Program Committee. Notification of acceptance will be sent by 25 May 1992, and camera-ready copy will be due on 15 July 1992. A digest of papers will be available at the Conference, and hardbound proceedings will be published after the Conference as a volume of the Springer-Verlag series on Dependable Computing and Fault-Tolerant Systems. Important Dates: Submission deadline: 31 January 1992 Acceptance notification: 25 May 1992 Camera-ready copy due: 15 July 1992 ------------------------------ End of RISKS-FORUM Digest 11.94 ************************