Subject: RISKS DIGEST 15.34 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Monday 13 December 1993 Volume 15 : Issue 34 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Computer glitch postpones 'Tommy' (David Tarabar) Electronic Money (Brian Randell) Financial Newswire Fraud (Thomas J Scoville) Canadian study on computer fraud (Mich Kabay) Risks of being a programmer (Jon Jacky) The risk of distributed servers with only partial uninterruptible power (Bob Cunningham) Risks of inband communication triggering call forwarding (Simson L. Garfinkel) Mail forwarding as easy as Call forwarding (Kiser) Re: Massive credit card fraud (Pete Mellor) Apple has poked around on your hard disk before (Grady Ward) Re: Corrupted Polling (Brian Randell) Re: Digital Woes (Harry Erwin) COMPASS '94 Call for Papers and Call for Tutorials (John Marciniak) The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. Contributions should be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. CONTRIBUTIONS to risks@csl.sri.com, with appropriate, substantive "Subject:" line; others may be ignored! Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially .UUCP folks. If you cannot read RISKS locally as a newsgroup (e.g., comp.risks), or you need help, send requests to risks-request@csl.sri.com (not automated). BITNET users may subscribe via your favorite LISTSERV: "SUBSCRIBE RISKS". Vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousYourName CD RISKS:GET RISKS-i.j" (where i=1 to 15, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*" gives directory; "bye" logs out. The COLON in "CD RISKS:" is vital. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password. WAIS and bitftp@pucc.Princeton.EDU are alternative repositories. IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ---------------------------------------------------------------------- Date: Fri, 3 Dec 93 18:51:16 -0500 From: dtarabar@hstbme.mit.edu (David Tarabar) Subject: Computer glitch postpones 'Tommy' From the Boston Globe of Friday, 3 Dec 1993: What "The Who's Tommy" needed yesterday was a computer wizard, not a pinball wizard. Last night's opening Boston performance of the high-tech musical was canceled because several computers required to stage the show suffered technical difficulties as a result of being shipped to the Colonial Theatre from Louisville, where the production completed a one-week run on Sunday. ... "Touring is apparently being more funky on the computers than anyone anticipated," David Balsom, the show's local press representative, lamented last night. ... ------------------------------ Date: Fri, 10 Dec 1993 12:35:44 GMT From: Brian.Randell@newcastle.ac.uk Subject: Electronic Money The attached article is from The Independent, 9 Dec 1993. This is the first I have heard of such a scheme here in the UK, but would not be at all surprised if similar schemes already exist elsewhere (you would not expect to find such information from a press conference!). I was particularly "interested" in the paragraph: The key to the card's security lies in the Japanese-developed technology and microchip. NatWest and Midland said that a technical breakthrough had made it impossible to counterfeit cards. and look forward to the reactions of RISKS' readers. Brian Randell, Dept. of Computing Science, University of Newcastle, Newcastle upon Tyne, NE1 7RU, UK Brian.Randell@newcastle.ac.uk PHONE = +44 91 222 7923 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - TIME FOR A TOP-UP: MONDEX FACES A YEAR-LONG TRIAL, BEGINNING IN SWINDON IN 1995. NATWEST IS RUNNING THE PROJECT IN CONJUNCTION WITH MIDLAND AND BRITISH TELECOM. BANKS STEP UP WAR ON CASH WITH PLASTIC CARD THAT CAN BE TOPPED UP BY PHONE EVEN STREET VENDORS WILL BE ABLE TO TAKE THE NEW ELECTRONIC MONEY, SAY ITS MAKERS. Nicholas Bannister reports on Mondex NATIONAL Westminster Bank has developed an alternative to cash - a plastic card with a microchip which stores "electronic money" and can be topped up over the phone. Yesterday it revealed plans for a year-long trial of Mondex, its electronic money system, starting in Swindon in 1995. The pilot project, in conjunction with Midland Bank and British Telecom is likely to involve about 10,000 people, mainly bank customers and retailers. The system lets customers add money to their card by using adapted cash dispensers or phones to access their accounts. Once charged with money, the card becomes the equivalent of cash. Payments are made by slipping the card into a retailer's terminal. The sum is transferred from the card to the retailer without need for time-consuming authorisations or signatures. Provided there is enough money on the card, the transaction will take place. Payments between individuals are carried out by inserting the card into a pocket-sized electronic wallet and making six keystrokes. Both customers and retailers can deposit electronic money into their bank accounts over the phone. Bert Morris, NatWest's deputy group chief executive, said that cash was still used for 90 per cent of all transactions in the United Kingdom, and that handling cash cost the banks more than #4.5 billion a year. He claimed that widespread use of Mondex would not lead to staff cuts and branch closures. Mr Morris, who is also on the Department of Social Security board, said that social security fraud could be reduced if the Mondex system was used for payments. Tim Jones, one of the two NatWest executives who came up with the Mondex concept, said the card was not intended to replace traditional debit and credit cards. The system was designed for small and large payments. Small traders, for example a newspaper vendor, could have a battery-powered terminal. He claimed that it was safer, quicker and more convenient to handle electronic rather than physical money. But if a Mondex card was lost or stolen, the money on it would be lost in the same way as money in a missing wallet. However, cards could be locked to prevent unauthorised use by tapping in a four-digit personal code. Once locked, the money could not be spent without re-entering the code. He said initially cash dispensers would be adapted to give customers the choice between drawing physical or electronic money. But the telephone would be the most important access point. BT was planning to adapt its pay phones, and special phones for home use were being designed. Customers would insert the card into the phone triggering an automatic call to the bank's computer system. After a prompt, the customer would tap in his personal identification number and transfer money from his account to the card or vice-versa. "Our strategy is that in 10 to 15 years time, we will see the phone as the dominant way in which electronic money is drawn and deposited," Mr Jones said. Derek Wanless, NatWest's chief executive, said: "Although Mondex will be launched in the UK, it is a major commercial, opportunity for banks everywhere. Mondex is a multi-currency product, capable of holding five separate currencies on a card simultaneously." He said that other British and foreign banks would be invited to join Mondex in due course to create a "truly global payment scheme". The British Retail Consortium said that the convenience, security, flexibility and potential for development should ensure customer acceptance of Mondex. Its director general, James May, said: "If successful, the Mondex trial should give UK shoppers a better way of paying, and provide retailers with benefits in this first step towards a cashless society." The key to the card's security lies in the Japanese-developed technology and microchip. NatWest and Midland said that a technical breakthrough had made it impossible to counterfeit cards. But Mr Jones said that Mondex would have a research budget "for ever" to keep ahead of the counterfeiters. ------------------------------ Date: Sun, 12 Dec 1993 14:55:56 -0500 From: tscovill@world.std.com (Thomas J Scoville) Subject: Financial Newswire Fraud Notes From the Financial Sector of Cyberspace: How To Profit by Faking Out the Market. A good deal has been written lately on the ease, dangers, and risks of spoofing (or counterfeiting) mail on the net. Stories of practical jokes and character assassination abound. A similar but much more serious risk exists in financial information networks. My consulting work brings me in touch with some very large mutual fund companies. Many of them have extensive network infrastructure to support systems to quickly distribute news items from a variety of sources: Comtex, Dow-Jones, Standard&Poors, and others. The delivery end of these systems work like a cross between rn and a mail-reader: Story headlines are displayed (like mail "Subject:" lines), most recent to least, with the body of the news story available on demand. The headlines are constantly updated with fresh stories. The news service is used by a variety of people: traders, portfolio managers, commercial brokers, to name a few. Trading (sometimes very high-volume trading) is quickly initiated based on the incoming news. Often the body of the stories is never read; hot stories contain only a headline - if you take the time to read the story, you've lost some or all of your opportunity. The time-dependence of the incoming news is striking. The traders act immediately on the incoming information; their 'edge' is the timeliness of the news. It enables them to exploit short-lived opportunities. In that business, information goes stale and becomes useless very quickly, sometimes in a matter of minutes. The news source is trusted. Verifying stories is not a top priority. With the proper access to the hub machines and a little understanding, news stories can be faked. Just as email can be spoofed with the popular port 25 Unix hack, a story which didn't originate at a legitimate news source can be injected into the flow. Given that the news wire is the trader's primary window into the marketplace, one could create a phantom in that window, one with predictable effects: "Bill Gates Dies of Heart Attack"... (perhaps just prior to selling short on Microsoft). Now the risky part: my experience to date is that many of the hub machines, servers, and subnets involved are no more secure than any on the Internet, and in some cases much less so. Any Unix site administrator connected to the Internet should be shivering in his/her boots at this point... Tom Scoville - tscovill@xs.com ------------------------------ Date: 05 Dec 93 11:18:53 EST From: "Mich Kabay / JINBU Corp." <75300.3232@compuserve.com> Subject: Canadian study on computer fraud >From United Press International newswire via Executive News Service (GO ENS) on Compuserve: Study says database breaches costly and increasing, by Robb Stewart TORONTO (UPI, 2 Dec 1993) - A Canadian study released Thursday says one quarter of North American companies have suffered data base breaches, at a cost of up to $1,000,000 per incident. The study by the Ernst and Young financial consulting firm and Information Week magazine said the problem is growing and that companies need to put greater emphasis on protecting their computer systems." Key points: o 30% of losses caused by employees. o Half of these criminals are greedy, the rest disgruntled. o Organizations "must integrate system and date security into their basic information technology strategies" to reduce fraud. o 80% of all employees surveyed have access to computers. o Additional problems are caused by hackers and by natural disasters. o "...senior managers need to send a message to employees that this is a serious issue," according to the author, John Kearns. o The author emphasized the importance of employee awareness training, security policies, and especially the example set by senior managers. According to Kearns, "employees react to the attitude of senior managers, leaving PCs on, or leaving documents on their desk or sharing their password." <> Hohum, another confirmation of what we already knew--but very important to provide management with a continuing stream of such confirmations. I was surprised that the employee involvement was as low as 30%; the consensus in the field seems to me to have been more like 75-85%. Michel E. Kabay, Ph.D. / Director of Education / Natl Computer Security Assoc. ------------------------------ Date: Mon, 13 Dec 1993 10:36:51 -0800 From: Jon Jacky Subject: Risks of being a programmer In this Sunday's NEW YORK TIMES (Dec. 12, 1993) the cover story on the business section is about Apple's Newton handheld computer project: MARKETER'S DREAM, ENGINEER'S NIGHTMARE Apple's chief promised too much on the Newton, and the design team paid a heavy price. by John Markoff ... The pressure to finish, exhilarating at first, eventually overwhelmed some of the young designers. After 18-hour days, some engineers went home and cried. Some quit. One had a breakdown and ended up in jail. One took a pistol and killed himself. (The story provides more detail on each of these.) - Jon Jacky, University of Washington, jon@radonc.washington.edu ------------------------------ Date: Fri, 10 Dec 93 07:08:48 HST From: "Bob Cunningham" Subject: The risk of distributed servers with only partial uninterruptible power Earlier this year in the School of Ocean & Earth Science & Technology at the University of Hawaii we replaced our large centralized NFS servers (all in one building with a large-capacity uninterruptible power system) with small, distributed mini-servers on each subnet in each building. This noticeably improved NFS performance, did away with a substantial amount inter-subnet network traffic, and reduced traffic significantly on the subnet the centralized servers were previously on. Economical, too, since the small servers were cheap. We didn't even bother to install UPS systems for the new mini-servers, though we did put the small server that replaced the large one in the original building on the old UPS. Which seemed like a good idea at the time... Of course most of the services were duplicated on all servers and we crafted the NFS maps such that systems within a particular building mounted from their in-building NFS server if possible, but could use a server in another building if their local server was down. Everything worked well until we had a series of power outages last week. After each outage, more and more individual computers would lock onto the small server in the original building (alway ups, thanks to its UPS) in preference to their local mini-server (with no UPS, those went down--and typically were slower to reboot than their former clients). NFS mounts are remarkably tenacious. We finally had to shut down the UPS-protected mini-server for several hours and reboot a variety of systems in several buildings to relieve the single overloaded server. ------------------------------ Date: Sat, 11 Dec 93 11:32:42 -0500 From: simsong@next.cambridge.ma.us (Simson L. Garfinkel) Subject: Risks of inband communication triggering call forwarding Fascinating article in the November 1993 issue of MIT Information Systems journal. "When Call Forwarding Goes Awry." "Have you ever heard from people who tried to dial you directly at your MIT number, but got the MIT operator instead? Or the operator at the Whitehead Institute? Or someone with no connection with your department?" Turns out that, at MIT, you can initiate a call-forwarding command by dialing 78-. To dial an outside number, you must dial 9-. Well, you guessed it, people are dialing outside numbers like 788-5000 (BayBanks main number) and forgetting to dial the "9", and the lovely phone system is taking this as a command to call forward your extension to 8-5000 (main number at Whitehead Institute). Lovely. You know, we've got these zillion-button digital phone sets at MIT. Wouldn't it be nice if there was a special button to turn call forwarding on or off, or if they used the # or * keys, or at least SOMETHING that doesn't look a phone number? Nah. ------------------------------ Date: Tue, 7 Dec 93 23:56:53 EST From: kiser@tecnet1.jcte.jcs.mil Subject: Mail forwarding as easy as Call forwarding After a recent move, I decided to fill out a change-of-address form at the US Post Office to have my mail forwarded for me as my personal name, me as my sole proprietorship, both of the names of the little informal "businesses" I and each of two friends have formed (to be on better terms with larger companies), and, since each of my friends occasionally sends mail from our hobby/ventures to my place, for them as well (for a grand total of five forwarding orders). I expected the large number of forwarding orders to be questioned; it wasn't. And I was not pleased to learn that just anyone can walk in and fill out one of these things for me. How did I come do that conclusion? I was not asked for any ID at all. Finally, when I asked if it "was ok" for me to fill out a change of address for someone else (i.e., the ones with my friends' names on them and my signature ;-<), the mail clerk responded "as long as they don't mind." Has anyone ever tried to have 1600 PENNSYLVANIA AVENUE forwarded? ------------------------------ Date: Mon, 13 Dec 93 19:22:37 GMT From: Pete Mellor Subject: Re: Massive credit card fraud (RISKS-15.32) "Mich Kabay / JINBU Corp." <75300.3232@compuserve.com> writes: > o Thieves monitor external mailboxes on homes for weeks in wealthy > neighbourhoods to steal credit cards and new cheques arriving in the > mail. A minor point here is that the theft requires the existence of *external* mailboxes, which are virtually unknown in the UK. (The only reason that UK e-mailers understand the "Mailbox" icon on the Sun windows interface is because they've read Li'l Abner! :-) All "letterboxes" in the UK are slots in the front door with metal hinged flaps over them. The mail drops down inside and lands on the doormat. (One exception to this is that blocks of flats *sometimes* have downstairs mailboxes for all occupants, but these are usually opened only by the owner's key, and are usually in an internal foyer, with at least some protection from casual theft. I live in a high-rise block of flats, and the postman delivers mail to each individual flat.) Risks here? Well, some terrorist or vandal could drop something nasty through it. (I will leave it to readers' imaginations what sort of "nasty" this could be!) Alternatively, the family dog could rip the mail to shreds. (This is a surprisingly common habit of dogs in the UK. I remember that the letterbox in my childhood home was backed by an internal mailbox to stop our otherwise sweet-tempered black labrador from doing just that.) Otherwise, the only problem is that delivery boys and postmen do not push the stuff right through the slot, so that a wedge of protruding paper advertises to the passing burglar that there is no-one at home, as well as leaving the mail itself once more vulnerable. Given that the two problems above can be solved by simple devices or by training (of dogs and delivery boys!) there is a possible low-tech solution to high-tech crime (or aren't US postmen allowed to walk up garden paths? :-) Peter Mellor, Centre for Software Reliability, City University, Northampton Sq., London EC1V 0HB Tel: +44 (71) 477-8422, p.mellor@csr.city.ac.uk ------------------------------ Date: Wed, 8 Dec 1993 09:32:47 -0800 From: grady@netcom.com (Grady Ward) Subject: Apple has poked around on your hard disk before Saul Tannenbaum in RISKS-15.32 explains how an uninvited software applet can unintentionally cause RISK to a user of certain Apple distribution software. This is not the first time that Apple software has violated the usual distinction between user hard disk data and its corporate interest. In 1991 as part of their developer's CDROM, an Apple application automatically gathered information about your Macintosh system configuration, names of Inits, Cdevs, and Extensions (applets associated with the operating system and generally available to all applications). Without assuring proper authorization, it then automagically e-mailed the information in real-time to Apple developer support. The RISK here is obvious: particular system configurations, code names of applications and system applets, and other gathered information could be used for significant competitive intelligence: knowing that the name of an application under development is, for example, NewApp version 1.0b32 gives a significant clue that the NewApp software is almost ready to go to market; knowing that a developer has installed a driver for a unique piece of hardware might very well tip off Apple that a new software product using that hardware is imminent. Subsequent issues of the Developer's CDROM with he offending Hypercard stack were changed to make more explicit the default behavior of the intelligence-gathering trojan. The RISK moral? A company has to give thought on how to obtain proper, informed authorization before a customer's privacy is invaded. :w ------------------------------ Date: Fri, 10 Dec 1993 09:58:31 GMT From: Brian.Randell@newcastle.ac.uk Subject: Re: Corrupted Polling, Inside Risks, Comm. ACM Quoting Rebecca Mercuri, Corrupted Polling, Inside Risks, Comm. ACM, vol 36, no 11, November 1993, p. 122. >Technology alone does not eliminate the possibility of corruption and >incompetence in elections; it merely changes the platform on which they may >occur. The voters and the Election Boards who serve them must be made aware >of the risks of adopting electronic vote-tallying systems, insisting that >the checks and balances inherent to our democracy be maintained. This comment reminds me of a fascinating book I read some years ago: R.S. Brumbaugh. Ancient Greek gadgets and machines, New York, Crowell, 1966. (Reprinted 1975 by Greenwood Press, Westport, Conn.) From memory, the author is a Professor of Classics, and puts forward the thesis that the Ancient Greeks tended to trust gadgets, i.e., physical devices, more than each other. He explains that this is why they devised and used, for example, means of trying to ensure that voting was carried out fairly, and that speeches were of equal length. (Unfortunately the book is not readily available to me, otherwise I'd quote chapter and verse.) [I think we are ready for Linux Polling. PGN] ------------------------------ Date: Wed, 8 Dec 93 15:11:58 EST From: erwin@trwacs.fp.trw.com (Harry Erwin) Subject: Re: Digital Woes I just started this book, and it caused me to open my desk drawer where I had an old memo. This is a certificate of commendation for my participation and support on the BMDSTP Software Project during 1972-1979. If I may quote Jack Distaso: Because of the expertise and dedication provided by the individuals who contributed to this project, STP established a record of outstanding performances which culminated with the complete success of the key demonstration mission for the Army. All milestones were completed on time, the software met 100 percent of its performance objectives, and the project generated a substantial cost underrun on our incentive contract.' My question is: why does this record remain nearly unique? My experience on the project seemed to show that software management was proactive and thorough. Since that time, I've never seen its like. The people on the project, while typically good-quality, were no better (for the most part) than many I've met since. What made the difference? Harry Erwin herwin@cs.gmu.edu or erwin@trwacs.fp.trw.com ------------------------------ Date: Fri, 03 Dec 93 16:20:24 EDT From: JOHN MARCINIAK Subject: COMPASS '94 Call for Papers and Call for Tutorials CALL FOR PAPERS, COMPASS '94 9th Annual IEEE Conference June 27-30, 1994 on COMPuter ASSurance Gaithersburg, MD The purpose of this conference is to bring together researchers, developers, and evaluators who work on problems related to specifying, building, and certifying high-assurance computer systems. What distinguishes COMPASS from similar conferences is its emphasis on bridging the gap between research and practice. Researchers are provided an opportunity to present results, new theories, and new technologies to both other researchers and practitioners who can put them to practice. They can also learn from practitioners of new research problem domains and of problems encountered in building real systems. Practitioners have an opportunity to share lessons learned, to learn of new research, and to influence future research. Papers should present advances in the theory, design, implementation, evaluation, or application of high-assurance systems, or report on experiments, evaluations, and open problems in the use of new technologies for computer assurance. Special consideration will be given to presentations (either single papers or paper pairs) by practitioners and researchers who have worked on the same problem. There will also be a tools fair. Papers, panel session proposals, tutorial proposals, and tools fair proposals are solicited in the following areas: Software Reliability Software Safety Computer Security Formal Methods Tools Process Models Real-Time Systems Networks Embedded Systems V&V Practices Certification Standards INSTRUCTIONS TO AUTHORS: Send five copies of your paper, panel session proposal, tutorial proposal, or tools fair proposal to John McLean, Program Chair, at the address given below. Abstracts, electronic submissions, late submissions, and papers that cannot be published in the proceedings will not be accepted. Papers submitted from outside North America should be sent via overnight courier service. Papers must be received by January 15, 1994 and must not exceed 7500 words. Authors are responsible for obtaining prior to acceptance any and all necessary clearances for publication. Authors will be notified of acceptance by March 11, 1994. Camera-ready copies are due not later than April 22, 1994. Papers that use technology presented at a previous COMPASS conference are eligible for a special award. Papers of exceptional quality and appropriate subject matter are eligible for inclusion in a special issue of the Journal of High Integrity Systems or the Journal of Computer Security. Limited financial assistance will be available for student authors. PROGRAM COMMITTEE Paul Ammann, George Mason Univ; John Marciniak, CTA; George Dinolt, Loral; John McDermid, York Univ; Jan Filsinger, Booz-Allen Hamilton Jon Millen, Mitre; Virgil Gligor, Univ. of Maryland; John McHugh, Portland State U; Li Gong, SRI; David Parnas, McMaster Univ. Connie Heitmeyer, Naval Res. Lab; John Rushby, SRI; Jeremy Jacob, York Univ; Ravi Sandhu, George Mason Univ.; Carl Landwehr, Naval Res. Lab; Jeannette Wing, CMU; Teresa Lunt, SRI FOR FURTHER INFORMATION CONCERNING THE SYMPOSIUM, CONTACT: Jan Filsinger, General Co-Chair John McLean, Program Chair Booz-Allen Hamilton, Inc Naval Research Laboratory 8283 Greensboro Dr. Code 5543 McLean, VA 22102 Washington, DC 20375 Tel: (703) 902-5302 Tel: (202)767-3852 Fax: (703) 902-3131 Fax: (202) 404-7942 filsing@itd.nrl.navy.mil mclean@itd.nrl.navy.mil - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The COMPASS '94 Program Committee solicits your interest in presenting a tutorial at COMPASS '94. The committee solicits tutorials that are pertinent to the goals of the conference and of interest to the attendees. We anticipate a full day of tutorials, the 27th of June 1994. This year we will offer an honorarium for the tutorial presentations. Please submit your request to include the following information: 1. Topic and specific focus of the material 2. Length (1/2 and full day tutorials will be considered) 3. Name and background and experience in the area 4. Detailed topical outline Selection will be made based on the appropriateness of the topic, the credentials of the presenter and the quality of the outline. Schedule considerations: Tutorials submissions: by 15 January, 1994 Response: by 1 February, 1994 Tutorial materials required: by 1 May 1994 * Send requests to: John Marciniak, CTA, Inc., 6116 Executive Blvd Rockville, MD 20852 301-816-1439 Fax: 816-1416 marcinik@smtplink.cta.com * Tutorial materials will be required prior to the conference and will be subject to quality control procedures. ------------------------------ End of RISKS-FORUM Digest 15.34 ************************