From risks-request@pica.army.mil Sat May 30 16:40:57 1992 Return-Path: Received: from csmes.ncsl.nist.gov (macbeth.ncsl.nist.gov) by csrc.ncsl.nist.gov (4.1/NIST) id AA19214; Sat, 30 May 92 16:40:53 EDT Posted-Date: Sat, 30 May 92 13:09:23 PDT Received-Date: Sat, 30 May 92 16:40:53 EDT Received: from PICA.ARMY.MIL ([129.139.160.100]) by csmes.ncsl.nist.gov (4.1/NIST(rbj/dougm)) id AA08914; Sat, 30 May 92 16:39:01 EDT Received: from PICA.ARMY.MIL by fsac5.pica.army.mil id aa00211; 30 May 92 16:27 EDT Received: from aed.pica.army.mil by fsac5.pica.army.mil id aa00207; 30 May 92 16:22 EDT Received: from chiron.csl.sri.com by AED.PICA.ARMY.MIL id aa16731; 30 May 92 16:15 EDT Received: by chiron.csl.sri.com id AA03708 (5.65b/IDA-1.4.3.12 for risks-mil@pica.army.mil); Sat, 30 May 92 13:09:26 -0700 From: RISKS Forum Sender: RISKS Forum Date: Sat, 30 May 92 13:09:23 PDT Subject: RISKS DIGEST 13.53 Reply-To: risks@csl.sri.com To: ;@risks-list.ncsl.nist.gov Message-Id: Status: R RISKS-LIST: RISKS-FORUM Digest Saturday 30 May 1992 Volume 13 : Issue 53 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Software problem in shuttle software (Nancy Leveson) The Thin Edge of the Wedge? Next-of-kin database in Vienna VA (Barry Johnson) The Federal Government and Civilian Encryption (Larry Hunter) White House records (E. N. Kittlitz) Computer virus insurance (John Mello) The risks of telling the truth about viruses (Fred Cohen) C-17 problems attributed to software diversity (David G. Novick) C-17 story, Chmn. McDonnell's reply (via Michael Cook) SDI Costs (anonymous) Risks of SDI? (PGN) New CPSR List Server (Ronni Rosenberg) Call for Papers, IFIP/Sec '93 (Dr. Harold Joseph Highland) 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 13, 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. *** For information regarding the availability of this digest via FAX, *** *** please send an inquiry to digest-fax@cv.vortex.com. *** ---------------------------------------------------------------------- Date: Thu, 28 May 92 06:29:42 -0400 >From: leveson@cs.UMD.EDU (Nancy Leveson) Subject: Software problem in shuttle software (forwarded from Marty Kaszubowski) In this week's Aviation Week and Space magazine, there is an article entitled "Mission Control Saves Intelsat Rescue from Software, Checklist Problems." In the article it is stated that: Analysis of the problem showed that it occurred when IBM, with NASA approval, made pre-launch changes in rendezvous software. ``It didn't work exactly the way they thought it would work,'' [launch director] Hale said. The problem not only threatened the rendezvous, but also raised questions about the entire shuttle guidance and control software. ... ``We were concerned about the safety of all the other software on the orbiter -- if the computers don't work, nothing on the orbiter works.'' ------------------------------ Date: Thu, 28 May 92 18:18:00 EDT >From: BARRY JOHNSON Subject: The Thin Edge of the Wedge? The Town of Vienna is a small bedroom-community enclave of about 15,000 people in the northern Virginian suburban overflow of Washington DC. Although dependent on the surrounding Fairfax County for many services (most notably schools and, for the sake of the second story, the cable franchise), Vienna does have its own police force. Vienna is proposing to maintain a voluntary-entry next-of-kin database for all town residents, to be used only in the event of death or medical emergency. Contacting next-of-kin has been a serious problem in cases of recent fire victims. Opponents see this as a further incursion into privacy. [This paragraph starkly excerpted by PGN from "The Washington Post" FAIRFAX WEEKLY Section - May 21, 1992, `Next-of-Kin Plan Splits Vienna Residents', by By Whitney Redding - Washington Post Staff Writer. See also "The Connection", a local freebie weekly - May 6, 1992, `Police data base has some Vienna residents irked', by Darcy Nair, and a letter in the same issue. PGN] The impression I get from this and other stuff that appeared was that a lot of it arose because a larger budget (several thousand dollars?) was originally requested to implement a "database"(? - and is it any coincidence the way this term seems to be bandied around?). My impression was that a proposal without the `computer' dimension (say, storing 3"-by-5" index cards in street address order) might not have caused such debate. Barry Johnson WB15471@IBRDVax1 ------------------------------ Date: 28 May 92 11:24:06 >From: hunter@work.nlm.nih.gov (Larry Hunter) Subject: The Federal Government and Civilian Encryption The lead article in today's Government Computer News (5/25/92, v.11, n.11), entitled "NIST standing firm on digital signature," describes the efforts of the National Institute of Standards and Technology to defend its harshly criticized proposed standard, DSS. It contains some particularly important comments by the Chairman of the House Judiciary Committee, Jack Brooks, on executive branch actions regarding use of secure technology by the American public. During the hearings, vendors and industry experts kept hammering at what they described as critical flaws in the DSS proposal. The Director of NIST, John Lyons, testified before the House Judiciary Subcommittee on Economic and Commercial Law that DSS is being established strictly for federal agency applications and should not impede the development of technology within the private sector. Under questioning, Lyons admitted that "Any standard improperly formulated can slow down and stifle technology." At an earlier hearing, Assistant Comptroller General Milton Socolar (from the General Accounting Office) testified that DSS is weaker than a popular commercial signature verification product developed by RSA Data Security, Inc. of Redwood City, CA. He questioned whether requiring federal civilian agencies to use NIST's DSS, if it is less effective than commercial alternatives, would serve a useful purpose. He also said that the National Security Agency and the FBI pressured NIST into proposing a weak standard to ensure that NSA and FBI can crack it, and thereby forge digital signatures. The chair of the House Judiciary Committee, Jack Brooks (D-Texas) agreed, stating that FBI Director William Sessions had told the subcommittee that the FBI is "against having security encryption devices that they could not break. They did not want any system that they could not have a key to," Brooks said. "They said it would give drug dealers, terrorists and buggers an advantage. That's what they said publicly, and there's no use dissenting on it." [It certainly does give those buggers an advantage.... -lh] Brooks said Congress must be wary of White House efforts to grant intelligence agencies a greater role in civilian security matters. [The rest of us should be vigilant, too.] Larry Lawrence Hunter, PhD., National Library of Medicine, Bldg. 38A, MS-54 Bethesda. MD 20894 (301) 496-9300 (301) 496-0673 (fax) hunter@nlm.nih.gov ------------------------------ Date: Wed, 27 May 92 20:18:01 EDT >From: kittlitz@osf.org Subject: White House records In RISKS-13.52, "White House Fights to Erase E-Mail Backups", it is noted that `In 1978, Congress made clear that the law applied to presidential records, including "electronic or mechanical recordations".' Does the executive branch use voice-mail? Will they have to re-program it so that old messages cannot be deleted; they just fade away to the archives? Think of all the telephone pranks (a la Bart Simpson) which might result. Spoofing of computer backups may also become more likely as their volume grows; will we need digital signatures (!) on the documents? E. N. Kittlitz kittlitz@world.std.com kittlitz@osf.org (contracting at OSF, not representing their positions) ------------------------------ Date: Fri, 29 May 92 12:32:10 PDT >From: John Mello Subject: Computer virus insurance Followers of the Risks conference aren't the only ones worried about computer risks. So's your friendly neighborhood insurance agent. Several insurers have launched programs to protect businesses against computer mischief, namely computer viruses. And one, the Aetna Casualty and Surety Company of Hartford, Connecticut, has gone much further. The major reason carriers aren't shying away from virus insurance is they don't expect to get whacked with significant losses. That certainly has been the experience of two companies that offer virus protection, the St. Paul Companies of St. Paul, Minnesota, and the Allstate Insurance Companies of Northbrook, Illinois. In 1991, St. Paul's losses were less than $15,000. Allstate has had to pay off on its virus coverage but nothing in excess of $5000. A typical small business computer policy from Allstate, which would automatically include virus insurance, would cover an exposure of $25,000 to $50,000 and have an average premium of $250 to $750. An ambitious computer crime insurance program has been launched by Aetna. Called ACCENT (Aetna Coverage for Computer and Electronic Network Technology), the program, limited to financial institutions and service bureaus, includes protection against phone fraud, computer viruses, software piracy, and threats to set off "time-bomb" viruses, disclose security codes, and other forms of extortion. ------------------------------ Date: Sat, 30 May 92 09:39 EDT >From: fc Subject: The risks of telling the truth about viruses I probably shouldn't be writing this entry until I have time to cool down about it, so FLAME-ON=> ISPNews just published a tiny piece derived from an article I wrote them on benevolent viruses, and left my name attached. I think I will sue for liable and slander. If you get a chance to read this piece, please realize that they mangled it to promote the protection business. The main point of the article (which was written before the Michelangelo scare but only published this week) was that benevolent viruses are possible and that only the computer security industry wants to claim they are not - and the reason is so they can scare you into paying them. The article had a counterpoint to each point of an abusive article written in a previous issue, but of course the counterpoints were all removed and replaced by a single sentence saying you should support good viruses. The claims that you could write safe viruses were included, but the reasons why were removed. The article it criticized was given great placement, but the counterarticle was placed in a hard to find area and given half the space of the original article it criticized. If you get ISPNews, write to the editor and tell them that you know about the hatchet job they did on my article. Tell them that you no longer trust them to tell you about integrity protection in computers, since they obviously don't have any integrity and care more about money than truth (they will probably agree with that one). Cancel your subscription, and pull your advertising! (just kidding) The point of all this is not that they mangled my article - I am used to that - but rather that there is a tremendous risk in an uncontrolled protection racket that goes by the name of "computer security". If I told you your house would burn down unless you paid me $100/year, you would probably report me to the police (and wonder why I charged so little). If someone in the protection rackets tells you your computer will crash and you will lose all your data unless you pay them $100/year, how is that any different? There's a finite probability your house will burn down, and there's a similar probability you will suffer damage at the hands (bytes) of a computer virus. If you think the person will burn down your house by lighting a fire, you should be aware that some computer virus defenders have sent copies of viruses out to their customers on demo disks (along with an order form for the cure). I would like the FTC to look into truth in advertising in the computer security industry, but I can't convince them that there is any false advertising, since they seem to think that nobody could be fooled into thinking that Norton antivirus would actually protect them from all future viruses (old ad), or that central point caught ALL 150 viruses (that they knew about - I knew about a lot more). Oh well - so much for now. FLAME-OFF... ------------------------------ Date: Wed, 27 May 92 10:45 PDT >From: novick@cse.ogi.edu (David G. Novick) Subject: C-17 problems attributed to software diversity C-17 Program Faces Problems in Manufacturing, Software (Excerpted from Aviation Week & Space Technology, May 18, 1992, p. 31) The C-17 [military aircraft] program encountered manufacturing problems in flight control surfaces and criticism by the General Accounting Office of software development last week. [...] Reviewing the status of C-17 embedded computer systems, GAO said the program is "a good example of how not manage software development when procuring a major weapon system." The Air Force waived or ignored many Pentagon software standards and guidelines, gave Douglas Aircraft Co. control over software development, limited its own access to software information, and restricted its ability to require correction of problems, even after critical problems were evident, GAO said. "In essence, the Air Force assumed that software was a low-risk part of the C-17 program and did little to either manage its development of to oversee the contractor's performance," GAO said. "Douglas (with the Air Force's concurrence) to a number of shortcuts that have substantially increased the risk of not successfully completing software development and testing and may result in substantially higher software maintenance costs with the C-17 is eventually fielded. [The first C-17 in 9/91 had all safety software but only 34% of avionics software. The complete software is supposed to be provided with the second aircraft in 6/92. The GAO lays the blame on proliferation of languages in the project. The systems were supposed to have been written in Ada, but Douglas had been working in JOVIAL. Further,] ... Douglas had trouble finding subcontractors who would use JOVIAL, however, and the Air Force "allowed the subcontractors to develop software in whatever language they chose." As a result there are six languages, four of them using existing as well as newly developed code and one of them proprietary to General Electric Co. Many subsystems contain more than one language. There are three in the flight control computer, for example. [The Air Force now plans to convert all this code to Ada, which may be difficult because of inadequate documentation.] David G. Novick, Computer Science and Engineering, Oregon Graduate Institute of Science and Technology, 19600 N.W. Von Neumann Drive Beaverton, OR 97006-1999 ------------------------------ Date: 29 May 92 06:39:00 PST >From: "GVA::MLC" Subject: C-17 story, Chmn. McDonnell's reply Chairman McDonnell's reply to some of the C-17 criticisms follows. This was sent to me from my brother at McDonnell-Douglas. Neither one of us is/was involved in the C-17 work. Michael Cook [Don't reply to Michael!] ==================================================================== C-17 - The Real Story To All Teammates: May 13, 1992 The chorus of critics has been out in force lately. Their target: our C-17 program. These critics continue to focus on outdated, unsubstantiated allegations, and in some cases flat untruths about the C-17. They also echo the groundless charges that we were "bailed out" of financial difficulty by the government. I'm angry about this partial, slanted, misleading reporting, and you should be too. You deserve to hear the real story. Let's begin with the C-17 wings. The critics have focused on the Drivmatic machine, saying the rivets it installs do not fully expand all of the time. Here are the facts. First, the C-17 wing is designed to last 60,000 hours, or twice as long as the required 30,000-hour life of the airframe. Second, fully expanded rivets add to that 60,000 hours. Those that do not fully expand do not detract from wing life. Beyond that, we have improved the processes and the machines. Our own internal investigations and those of Department of Defense agencies and the FBI found no fraud or wrongdoing. The bottom line: There is no safety of flight issue. There was no cover-up. The wings exceed contract requirements. A network television reporter claimed the Drivmatic machines caused fuel leaks in the wing. Here are the facts. None of the leaks occurred around fasteners installed by the Drivmatic machines. We told the reporter that. We explained in detail to him where the leaks were found. In addition, we described the leak rate, which was less than one drop per minute; we told him we found that out of position work had caused the problem; we told him we had developed a new sealing process; and we told him we had taken the precaution of doing a reinspection of all wing sealing in every aircraft on the production line. He chose not to report the facts. Some critics say we fired the employees who reported and investigated the Drivmatic issue. Here are the facts. Both individuals were fully involved in our investigation of the issue. The individual who reported the issue was given a pay raise for his role, but then just stopped showing up for work. After a period of months, we fired him just as we would any other employee who failed to show up for work for extended periods. The second individual, an internal investigator, had been identified as a part of a reduction in force decision a month before the investigation started. He was ultimately let go as part of our overall reductions, and not for any reason related to the investigation. Other critics say problems are showing up in the C-17 flaps. Here are the facts. Early ground testing showed greater pressure on the flaps than had been anticipated in design. The flaps were redesigned and new flaps were made available for the first production aircraft. In actual flight, it turns out the pressures were much less than the ground testing had predicted. Result - the present flap exceeds contract specs. Flight testing also shows higher temperatures than anticipated in one area of the flap. We made a relatively simple change to more temperature-resistant materials. Those who attempt to judge a program solely by problems found and fixed during tests seem to ignore that one purpose of a test program is to do just that. The fact is that these incidents are a test program success, not a failure. Still others question our candor on the C-17. Here are the facts. We keep our customers fully informed. We are consistently on the record with the facts concerning our problem areas as well as successes. Most recently we joined with the United States Air Force and the Grumman Corporation in announcing an inspection program to detect possible flaws in composite materials provided by Grumman. Some alarmists claim the taxpayers will pay billions in contract ceiling overruns. Here are the facts. This is a fixed-price type contract for development and initial production of C-17. We believe the government is responsible for at least some of the cost growth, and we are submitting claims for those costs. Once our claims are resolved, we pay any difference - not the taxpayer. As for those who project costs greater than $8 and even $9 billion, with more than 90% of the work done, we believe our estimate of $7.39 billion is correct. Finally the bailout allegation. We didn't ask for a bailout, and we didn't get one. The facts are simple. We do the work, we submit bills, and then we get paid. And now to conclude the real story. We are continuing to improve. We are building each new C-17 with far fewer labor hours than the previous aircraft. We are reducing rework. We are flying a rigorous test program - more than 200 hours so far - and passing with top grades. And in the final analysis, we will silence the chorus of critics with our successes. John F. McDonnell, Chairman and Chief Executive Officer ------------------------------ Date: Thu, 28 May 92 9:06:36 PDT >From: [anonymous] Subject: SDI Costs Report Questions SDI Estimates WASHINGTON (AP) Deploying an antimissile defense system will cost $37 billion over five years, about $10 billion more than the Bush administration estimates, a congressional report said Wednesday. The Congressional Budget Office said costs for the Strategic Defense Initiative from fiscal 1994 to fiscal 1997 would be about $8 billion a year. President Bush has requested $5.4 billion for the system in the fiscal year beginning Oct. 1. SDI Director Henry Cooper has said building a system of defenses would cost $25 billion. The government has already spent about $29 billion on the program commonly known as Star Wars. The CBO based its report on administration figures for research, development and procurement of a single-site defense at Grand Forks, N.D., by late 1997. The program would include either ground-based or space-based sensors to detect incoming missiles, interceptors and a controlling command system. Last year, leading defense Democrats such as Sen. Sam Nunn, D-Ga., and Rep. Les Aspin, D-Wis., joined congressional Republicans in backing the Missile Defense Act, which set a new goal for the program. The law directs the administration to deploy an SDI system by 1996 or when the technology allows that would comply with the U.S.-Soviet Anti-Ballistic Missile treaty of 1972. The CBO calculated the cost of alternatives to the administration's SDI plan, including a system favored by Nunn, Aspin and several Republicans. That system would cost $31 billion with an average annual budget of $7 billion. The system would be deployed at a single site by 1997 and would include an additional system of sensors known as the ground-based surveillance and tracking system. It also would spend less money on space-based interceptors such as Brilliant Pebbles. The House Armed Services Committee, in its version of the fiscal 1993 military budget, approved $4.3 billion for SDI, cutting about $1 billion from Bush's request. The panel eliminated all funds for space-based interceptors. The CBO report acknowledges that its estimates "do not attempt to account for cost increases that might occur during development of a technically challenging project such as missile defense." In August 1988, the CBO examined the cost growth of more proven weapons such as missiles, helicopters, tanks and fighter planes. It found that concurrent work on each program resulted in a cost growth of 193 percent to 288 percent. Rep. Charles Bennett, D-Fla., one of four House members to request the report, said the CBO cost estimates combined with recent comments from Cooper that deploying an SDI system by 1997 is a major challenge, creates a "recipe for cost overruns and operational effectiveness problems. With real defense assets being scrapped for budgetary reasons, it is hard to justify big expenditures for a questionable concept like SDI," Bennett said. Aspin, Rep. Ron Dellums, D-Calif., and Rep. John Spratt, D-S.C., also asked for the SDI report. ------------------------------ Date: Fri, 29 May 92 15:09:22 PDT >From: Peter G. Neumann (neumann@csl.sri.com) Subject: Risks of SDI? An AP item in the San Francisco Chronicle on 26 May 1992, p.A3 noted that at least $7.7 billion (out of a total investment of $29B) in Star Wars projects "never got off the ground", being "cast aside as unneeded, unworkable, or unaffordable". These included the following: * A surveillance satellite to detect and track hostile missiles. $1B. Dead. * A ground-based laser to zap missiles in flight by bouncing laser beams off relay and "fighting" mirrors stationed in space. At least $1.2B. Mothballed. * A Nuclear bomb-powered X-ray laser and other "nuclear-directed energy" weapons in space. At least $1.8B. Dead. * A pop-up "probe" to help interceptors distinguish warheads from decoys. At least $.5B. To be mothballed in 1993, but until last year deemed `essential'. * A guided rocket to intercept hostile missiles inside or outside the atmosphere. $623M. Mothballed. ------------------------------ Date: Wed, 27 May 92 13:32:44 EDT >From: ronni@ksr.com (Ronni Rosenberg) Subject: New CPSR List Server Computer Professionals for Social Responsibility (CPSR) has set up a list server to (1) archive CPSR-related materials and make them available on request, and (2) disseminate relatively official, short, CPSR-related announcements (e.g., press releases, conference announcements, and project updates). It is accessible via Internet and Bitnet e-mail. Mail traffic will be light; the list is set up so that only the CPSR Board and staff can post to it. Because it is self-subscribing, it easily makes material available to a wide audience. We encourage you to subscribe to the list server and publicize it widely. To subscribe, send mail to: listserv@gwuvm.gwu.edu (Internet) OR listserv@gwuvm (Bitnet) Your message needs to contain only one line: subscribe cpsr You will get a message that confirms your subscription. The message also explains how to use the list server to request archived materials (including an index of everything in CPSR's archive), and how to request more information about the list server. Please send any CPSR queries to cpsr@csli.stanford.edu. If you have a problem with the list server, please contact the administrator, Paul Hyland (phyland@gwuvm.gwu.edu or phyland@gwuvm). We hope you enjoy this new service. Ronni Rosenberg, CPSR Board of Directors ------------------------------ Date: Thu, 21 May 92 09:50 EDT >From: "Dr. Harold Joseph Highland, FICS" Subject: Call for Papers, IFIP/Sec '93 ANNOUNCEMENT AND CALL FOR PAPERS IFIP/Sec '93 in Toronto -- May 12-14,1993 IFIP/Sec'93, the Ninth International Computer Security Symposium and Exhibition, is part of a series of international conferences devoted to advances in data, computer and communications security management, planning and control. It will be held May 12-14, 1993 in Toronto Canada. This international conference, with the theme "Discovering Tomorrow", will encompass developments in both theory and practice and is intended for computer security researchers, managers, advisors, EDP auditors from government and industry, as well as other information technology professionals interested in computer security. The purpose of the 1993 International Federation for Information Processing Security Conference [IFIP/Sec'93] is to provide a forum for the interchange of ideas, research results, and development activities and applications amongst academicians and practitioners in the information, computer and systems sciences. IFIP/Sec'93 will consists of advanced seminars, tutorials, open forums, distinguished keynote speakers and the presentation of high-quality accepted papers. It is hoped that there will be a high degree of interaction and discussion amongst conference participants, as a workshop-like setting is to be promoted. The upcoming conference, IFIP/Sec'93, is jointly organized by IFIP/TC 11, the Canadian Information Processing Society [CIPS] and the Toronto Chapter of the Information Systems Security Association [ISSA]. Call for Papers Papers are invited in the areas shown and may be theoretical, conceptual, tutorial or descriptive in nature. Submitted papers will be referred, and those presented at the Conference will be included in the Conference proceedings. Submissions must not have been previously published and must be the original work of the author(s). Possible topics of submissions include, but are not restricted to: Auditing the Small Systems Environment Auditing Workstations PC and Microcomputer Security Security and Control of LANs and WANs OSI Security and Management Electronic Data Interchange (EDI) Security Management and Control of Cryptographic Systems Security in High Performance Transaction Systems Data Security in Developing Countries Software Property Rights Trans-border Data Flow Database Security Risk Assessment and Management Legal Response to Computer Crime/Privacy Smart Cards for Information Systems Security Biometric Systems for Access Control Security and Privacy in Electronic Mail Refereeing Process All papers and panel proposals received by the submission deadline will be considered for presentation at the IFIP/Sec'93 in Toronto. To ensure acceptance of high-quality papers, each paper submitted will be blind refereed. The papers presented will be included in the Conference preprint of the Conference Proceedings, copies of which will be provided to the Conference attendees. All the papers presented will also be included in Proceedings which will be published by Elsevier Science Publishers B.V. (North-Holland). Author(s) will assign copyright of the paper to IFIP. Additionally, one or more of the authors must present the paper at the conference. Presenters of papers are eligible for a reduced conference fee. Instructions to Authors Three (3) copies of the full paper, consisting of 22-26 double-spaced, typewritten pages, including diagrams (approximately 5,000 words), must be received no later than October 1, 1992. Diskettes and electronically transmitted papers will NOT be accepted. Papers must be sent to the Program Committee Co-Chairman. Each paper must have a title page which includes the title of the paper, full name of all author(s) and their complete address(es), including affiliation(s), telephone number(s) and fax number(s). To facilitate the blind review process, the author's particulars should appear only on the separate title page. The language of the Conference is English. The first page of the manuscript should include the title and a 300 word abstract of the paper. Abstracts may be submitted to the Program Committee if guidance and indication of appropriate content is required. Full papers must be received by: October 1, 1992 Conference dates: May 12-14, 1993 Papers Submission Mr. Graham Dougall, IFIP/Sec '93 -- Program Committee Co-Chairman c/o Concord-Eracom Computer Ltd, 7370 Bramalea Road, Unit 18 Mississauga, Ontario Canada L5S 1N6 Registration and Other Enquiries Those interested in additional information about the upcoming conference on May 12-14, 1993 should communicate with the Organizing Committee's Chairman. Mr. Dave Batchelor, IFIP/Sec '93 -- Organizing Committee Chairman c/o Concord-Eracom Computer Ltd, 7370 Bramalea Road, Unit 18 Mississauga, Ontario Canada L5S 1N6 FAX: (416) 672-0017 FOR IMMEDIATE HELP: Highland@dockmaster.ncsc.mil ------------------------------ End of RISKS-FORUM Digest 13.53 ************************ Downloaded From P-80 International Information Systems 304-744-2253