precedence: bulk Subject: Risks Digest 21.31 RISKS-LIST: Risks-Forum Digest Sunday 1 April 2001 Volume 21 : Issue 31 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, caveats, etc. ***** This issue is archived at and by anonymous ftp at ftp.sri.com, cd risks . Contents: [Beware the Calends of April] Windows 2000 source code (Mark Thorson) Foot-and-mouth virus propagation (PGN) Upcoming time-change risks (Alan Wexelblat) More self-inflicted defense difficulties (PGN) Classification of the Three Mile Island accident (Andrew Raybould) Re: German armed forces ban MS software (Ralf Bendrath) What they can do with your SSN (Ian Macky) Re: Serious new California drivers license ID risk (Tom Goltz, John Noble) Book: Security Engineering, Ross Anderson (PGN) Invitation to the First "PFIR Future of the Internet Workshop" (Lauren Weinstein) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Tue, 20 Mar 2001 17:20:38 -0800 From: Mark Thorson Subject: Windows 2000 source code Microsoft Corp.'s decision last week to give its 1,000 top U.S. enterprise customers access to the Windows 2000 source code has been sharply criticized by smaller customers. [Source: eWeek (formerly PCWeek), "Windows Source Code Deal: Not For All", March 12, 2001, page 20] ... even more concern was raised by its implementation language, Microsoft Basic. ``Most of our programmers haven't used Basic since college,'' said an IT manager at a Fortune 500 insurance company, ``most OS guys don't consider it [Basic] to be a serious implementation language.'' Mike Conelrad, a senior programmer at an enterprise solution provider based in Kentucky, said he is disappointed that Microsoft has only chosen to release 'desimonyzed' source code. ``The original variable names have been replaced with code names like A002134,'' according to Conelrad. ``That tells me absolutely nothing about the variable. But with a name like wParam, at least I know that the variable is word length.'' ``Some of the variable names were unacceptable,'' said Microsoft spokesperson Lirpa Loof. ``They used trademarks improperly and had other defects which were simply not acceptable in any Microsoft product.'' Sources close to the Windows 2000 development team indicate that the defects include references to Microsoft founder Bill Gates and other officers of the Redmond-based company. ------------------------------ Date: Sun, 1 Apr 2001 01:02:03 PST From: "Peter G. Neumann" Subject: Foot-and-mouth virus propagation This bit of satire is very cute. Unfortunately, its copyright keeps us from reproducing it here. Hopefully the given URL will persist. [This item is noted courtesy of Mark Brader.] Foot-and-mouth believed to be the first virus unable to spread through Microsoft Outlook http://www.satirewire.com/news/0103/outlook.shtml ------------------------------ Date: Wed, 21 Mar 2001 10:45:28 -0500 From: Graystreak Subject: Upcoming time-change risks [Sorry I could not get this out BEFORE the First of April, as an early warning. But it is still timely. PGN] I foresee a rash of social engineering set to happen in a few days. In the USA we change to Daylight Savings Time (spring ahead) shortly after the equinox. By 1966 law, we begin observance on the first Sunday in April, though Congress has a history of mucking about with that date. This year, that also happens to be the first day in April. In the US (and other countries?) there is a long tradition of practical joking, social engineering, and otherwise just plain messing with people on or around April first. I can see that this confluence is going to cause some amount of confusion, as some people automatically disbelieve any official-seeming announcement or notice that comes out on or in reference to April 1. Exchanges of the form "Don't forget to set your clocks forward" followed by "yeah, right, funny guy" will likely occur. Most probably the incidents and losses will be minor and more likely embarrassing than damaging; however, if I was going to try some kind of social engineering feat I'd try to structure it so that it seemed an April Fool's prank if I was caught. --Alan Wexelblat P.S. http://www.standardtime.com/ provides a good explanation of why DST exists and why it's no longer useful. ------------------------------ Date: Thu, 29 Mar 2001 14:57:22 PST From: "Peter G. Neumann" Subject: More self-inflicted defense difficulties On 26 Mar 2001, two U.S. F-15 jets disappeared over Scotland, 45 minutes after takeoff, each with just the pilot on board. One plane was later discovered near the 4,296-foot summit of Scotland's Ben Macdhui, in highest range in Britain. Also on 26 Mar 2001, a U.S. Army RC-12 reconnaissance plane crashed near Nuremberg, Germany, killing its two pilots. In all, 58 military people were killed in the 12 months ending on 30 Sep 2000 (including 19 aboard the V-22 Osprey in April 2000, but not the four marines killed on 11 Dec 2000, noted in RISKS-21.14). Nevertheless, this was reportedly the lowest military accident rate (1.23 per 100,000 flight hours) ever recorded. [Source: AP item, 28 March 2001] Also, a German military helicopter crashed in Peppen, Germany, on 27 Mar 2001, killing four. Incidentally, RISKS has not previously noted the most unfortunate recent U.S. submarine exercise that resulted in the sinking of a Japanese fishing vessel. Although the circumstances of that incident are still under investigation, human mistakes seem to have been much more critical than any direct implications of the computer-communication technology. However, that is of course a common thread among many of the life-critical incidents reported in RISKS. ------------------------------ Date: Mon, 26 Mar 2001 10:52:01 -0500 From: "Andrew Raybould" Subject: Classification of the Three Mile Island accident This week marks the 22nd anniversary of the Three Mile Island accident, and while reflecting on that event, it occurred to me that describing it as a Loss of Coolant Accident (LOCA) doesn't really capture its true nature. Fundamentally, it was what might be called a Loss of Comprehension Accident: a minor and correctable problem became the accident it was because neither the plant's operators, nor the increasingly-senior engineers and managers brought in as the situation deteriorated beyond recovery, understood what was happening. This sort of problem has probably been with us since the development of organized warfare, but it has increasingly become an issue for ordinary life as complex control systems have proliferated, starting with railroad switching and signaling. There is, I understand from this forum and elsewhere, some concern over whether today's pilots can fully understand their increasingly-complex airliners (I recall a news item in which the interviewee quoted pilots as saying things like "why did it do that?" "what will it do next?" "how can we make it do..."). As the hardware becomes more reliable, this type of accident becomes relatively more prevalent. Also, I also strongly suspect that this is a major cause of software development failures: my experience suggests that projects fall apart at that point where the level of detail exceeds the developers' cognitive skills. If so, then the solution will not be found in ever more detailed procedures and standards; we must pay attention to the abstract reasoning and language skills that are necessary for a group of developers to understand, individually and collectively, what it is that they are doing. Andrew Raybould andy.raybould@att.net ------------------------------ Date: Sat, 24 Mar 2001 03:16:12 -0600 From: Ralf Bendrath Subject: Re: German armed forces ban MS software (McVay, RISKS-21.30) This news is old and wrong - the German armed forces immediately told the press that they still use Microsoft products. Actually they just bought a general licence for MS standard office applications half a year ago. They even use Lotus Notes, which is known for the "work factor reduction field" in its encryption keys - and these are known to the NSA. But the Bundeswehr is not that stupid - they just put everything through hardware encryption (as far as I remember from Siemens) additionally. I only have a German article on this update, sorry. Ralf Bendrath Listowner Infowar.de http://userpage.fu-berlin.de/~bendrath Update: Bundeswehr setzt weiter auf MS-Software (tecChannel.de, 19 Mar 2001) Das Verteidigungsministerium hat gegenueber tecChannel.de einen Bericht des Nachrichtenmagazins Der Spiegel dementiert, wonach die Bundeswehr kuenftig in Computern keine Software von Microsoft mehr einsetzen werde. Wie berichtet, heisst es in dem Artikel "Die Angst der Deutschen vor amerikanischer Spionage", der amerikanische Geheimdienst NSA habe nach Erkenntnissen deutscher Sicherheitsbehoerden Zugriff auf alle wichtigenQuellcodes von Microsoft Dadurch koenne er auch verschluesselte Daten lesen. Das Verteidigungsministerium wolle daher in sensiblen Bereichen kuenftig nur noch Verschluesselungstechniken der deutschen Firmen Siemens und der Telekom einsetzen, um seine Geheimnisse zu schuetzen, so der Spiegel. Ein Sprecher des Bundesministeriums fuer Verteidigung hat den Spiegel-Bericht jetzt gegenueber tecChannel.de dementiert. In einem Fax, das die Redaktion vor wenigen Minuten erreichte, heisst es: "Die Behauptung, die Bundeswehr werde in sensiblen Bereichen kunftig keine Software der Firma Microsoft mehr verwenden, ist falsch." Die Bundeswehr habe demnach erst vor einem halben Jahr einen Generallizenzvertrag ueber die handelsueblichen Softwareprodukte mit Microsoft abgeschlossen. "Die Bundeswehr beabsichtigt, diese Produkte auch weiterhin einzusetzen", so der Sprecher weiter. Er betonte, dass sensible Daten im IT-Bereich der Bundeswehr zum einen durch Firewalls gesichert seien. Zum anderen setze die Bundeswehr auf Verschluesselungstechniken, "die durch das Bundesamt fuer Sicherheit in der Informationstechnologie (BSI) zugelassen sind. Deren Schutzfunktionen arbeiten unabhängig von der benutzten Software", heisst es in der Mitteilung. (jma) ------------------------------ Date: Sat, 24 Mar 2001 14:07:52 -0800 (PST) From: Ian Macky Subject: What they can do with your SSN In March of this year, 2001, in which it is proven that we are all very smart monkeys indeed, I received my monthly mortgage statement and noticed in the bottom IMPORTANT MESSAGES section: YOUR MORTGAGE INFORMATION IS NOW AVAILABLE ONLINE! [Note, feel dreadful sort of arousal here, like anticipation of being screwed] JUST FOLLOW THESE STEPS: 1. GO TO WWW.xyz.COM [Censored] 2. CLICK ON "MY HOME LOAN ACCOUNT" 3. ENTER YOUR ACCOUNT NUMBER 4. ENTER YOUR PASSWORD (YOUR STATE ABBREVIATION & THE LAST 4 DIGITS OF THE PRIMARY BORROWER'S SOCIAL SECURITY NUMBER, EXAMPLE NY1234). On this same piece of paper are my account number and state abbreviation. Yet ``it's unlikely and unusual for someone who has your Social Security number to be able to do anything with it. Normally, financial institutions require additional information.'' "Unlikely", "unusual". Pretty squirmy. And that additional information sure was hard to come by. BTW, my mortgage holder is a colossus whom everyone has heard of. Large body does not equal large brain when it comes to corporations-- the area of the pyramid's tip remains constant (and small!). ------------------------------ Date: Sun, 25 Mar 2001 20:48:30 -0500 From: Tom Goltz Subject: Re: Serious new California drivers license ID risk (Cornell, R-21.29) [From Dave Farber's IP distribution] Ironically, the fake doesn't even have to be very good. A couple of facts that you may find interesting: I am white. I have held a California driver's license in the past, but that license has been inactive for over two years since I established residency in another state. In October of last year, a black male obtained a fake California driver's license with my name on it and his picture. The driver's license ID # he used belongs to a white female. The address is a Commercial Mail Receiving Agency in Costa Mesa CA, which the state doesn't normally allow. The fake also contained two spelling errors. This person used this ID and my social security number to open a dozen different credit accounts in my name at various locations around the Los Angeles area. He was using a cell phone with a phone number based in the 603 area code as his residence phone. If anyone had bothered to look, just about everything about this guy screamed fraud, yet he managed to steal $15,000 worth of merchandise (mostly jewelry). Out of all these people who were supposed to be checking this information, only TWO found problems. One was a used car dealer who became suspicious when the check this guy gave for the down payment proved to be bogus. They refused to give the guy the car, but didn't bother to pursue the matter with the police. The other was store security at a Costco in Las Vegas, who tracked me down in New Hampshire and informed me that I had a problem. They detained the man, and turned him over to the police. Sadly, the most he's going do is a couple of years probation - he didn't actually steal anything in Las Vegas, and the identity theft, although a crime in NV is not sufficient to assure jail time by itself. I discussed the matter of extraditing the varmint to California with Las Vegas police, but they told me that it was unlikely that California would bother for something that would only net the offender probation there as well. According to the LV police detective, in California, you have to be charged with stealing over $50,000 before you'll do any jail time. It's no wonder this crime is exploding...it's low risk, extremely profitable, and trivial to implement. Oh yes...how did he get my name and social security number? He told the Las Vegas police that he purchased the information on the street for $500. Tom Goltz, Software Engineering Services (603) 594-9922 ------------------------------ Date: Mon, 26 Mar 2001 06:17:46 -0500 From: John Noble Subject: Re: Serious new California drivers license ID risk (Cornell, R-21.29) [From Dave Farber's IP distribution] I'm a recovering bank lawyer who hasn't had a serious lapse in nearly ten years, but I find I can't help myself. The account of the fraud perpetrated with a forged drivers license and the supposed complicity of Wells Fargo and California law is misinformed and misinforms your subscribers. It has nothing to do with the real risks identified in the Risk Digest item he points to. Although drivers licenses are increasingly designed to be more difficult to duplicate than they used to be, you can forge anything with the right equipment. There is nothing new about that. People have been forging identification and cashing bad checks since they invented banks. Whatever the problem with the CA license, it is not obvious how it contributes to the fraud Mr. Cornell describes. The fact that the lic. no. and DOB is recorded on a magnetic strip instead of printed on the license only makes it that much harder to discover, and that much harder to duplicate. Mr. Cornell indicates that he wants one without a photo. How does that help? Cornell's photo-free driver's license is only going to prevent him from cashing checks. It isn't going to stop someone else with a forged license that does have a picture unless he can find a bank that requires DNA testing to cash a check. Mr. Cornell's description of the CA Commercial Code leaves out the good parts. An account may be debited if the item was "properly paid," i.e. "authorized" in fact. If the item was not authorized, the customer need only notify the bank within a reasonable time after receiving his statement to have the account re-credited -- the burden is on the bank to prove that the endorsement was genuine, which is impossible. Banks typically ask the customer to sign an affidavit; and they pull the video sequence of the transaction at the teller window to confirm that the customer did not cash the check himself (the unlikely exception to the impossibility of proving the endorsement was genuine). Mr. Cornell points to Code provisions that require the victim to "prove" that the bank failed to exercise "ordinary care." But the provision only applies to losses caused by the customer's failure to review his bank statement and report an unauthorized debit within a reasonable time. In effect the bank is strictly liable for unauthorized debits during the first 6-8 weeks on little more than the customer's insistence that they were unauthorized. But if the customer doesn't look at his statement and report the unauthorized transactions disclosed on the statement, the bank's liability is cut off and the customer is stuck with the additional losses. The reasons for this are obvious. Only the customer is in a position to know that the debit was unauthorized. If he doesn't look at his statements, and the same guy is cleaning him out month after month, whose fault is that? In addition, the law has to take into account the possibility that the customer is having his own checks cashed by a third party. If Cornell has scoured the internet without finding it mentioned, it is because it is relatively rare. This is a risky, complicated, inefficient and finally stupid way to steal money. Someone has to make the ID (holograms, magnetic strips encoded with the drivers lic. no. and DOB); then stand at the teller's window in front of a camera posing for the wanted poster. Moreover, when you cash a check that bounces, the bank doesn't wait until the end of the statement cycle to let you know about it. They send you a letter. You would need to ignore those letters, as well as your bank statement, to lose the tens of thousands of dollars Cornell reports. When the forger cashes a check for which the the bank isn't liable, 6-8 weeks after he cashed the first check, the forger needs to assume that the victim has ignored the letters and statement -- because otherwise he's busted. Anybody who has your bank account no. can far more easily create checks that carry your name and account number. He doesn't need your drivers lic. no., DOB, or soc. sec. no. for that. He just draws against your account on checks coded with your account no.; deposits them in a straw account; withdraws the funds and closes the account before your statement goes out; and moves on to another bank and another victim because he has to assume you reported the fraud. He can do all that without ever having his picture taken for either a fake drivers license or a wanted poster. He doesn't have to stand at the teller window in your bank wondering whether he's about to get busted because you reviewed your statement and reported the fraud, and his picture from the videotape has been circulated to the tellers and security personnel. He can move the money and close the account from the safety of his apartment using his computer. The moral of the story: review your bank statements -- it's part of the deal. John Noble ------------------------------ Date: Thu, 29 Mar 2001 16:12:17 PST From: "Peter G. Neumann" Subject: Book: Security Engineering, Ross Anderson Ross Anderson Security Engineering: A Guide to Building Dependable Distributed Systems John Wiley & Sons March 2001 xxviii+612 pp. ISBN 0-471-38922-6 This book is an enormous undertaking. The chapter titles suggest the breadth of coverage. Part 1 (basic concepts) 1. What is security engineering 2. Protocols 3. Passwords 4. Access controls 5. Cryptography 6. Distributed systems Part 2 (important applications) 7, Multilevel security 8. Multilateral security 9. Banking and bookkeeping 10. Monitoring systems 11. Nuclear command and control 12. Security printing and seals 13. Biometrics 14. Physical tamper resistance 15. Emission security 16. Electronic and information warfare 17. Telcom system security 18. Network attack and defense 19. Protecting e-commerce systems 20. Copyright and privacy protection Part 3 (organizational and policy issues) 21. E-policy 22. Management issues 23. System evaluation and assurance 24. Conclusions Although there are other books that delve into greater detail on specific topics, this book should be extremely useful to many people who need the overall system perspective that Ross provides. Ross's preface concludes with this sentence: "I believe that building systems that continue to perform robustly in the face of malice is one of the most important, interesting, and difficult tasks facing engineers in the twenty-first century." I could not agree more, although I would add that building systems to perform robustly in the face of arbitrary adversities (accommodating power and communication losses, rodents, bad software engineering, user errors, etc. -- that is, not merely accounting for malice) is even more challenging. Many systems in common use tend to fall apart all by themselves -- without any malice! ------------------------------ Date: Sat, 31 Mar 2001 16:13:40 -0800 (PST) From: Lauren Weinstein Subject: Invitation to the First "PFIR Future of the Internet Workshop" "PFIR Future of the Internet Workshop" From: Lauren Weinstein Peter G. Neumann lauren@pfir.org and neumann@pfir.org lauren@vortex.com neumann@csl.sri.com Co-Founders, PFIR - People For Internet Responsibility http://www.pfir.org Greetings. People For Internet Responsibility (PFIR), in conjunction with the ACM Committee on Computers and Public Policy, is pleased to announce the first "PFIR Future of the Internet Workshop," to be held on the weekend of May 5 and 6, 2001, at the Culver City Veterans Memorial Complex, just minutes from Los Angeles International (LAX) airport. Vortex Technology of Woodland Hills, California is handling the event logistics. Information about PFIR, and the current PFIR position papers, are available at: http://www.pfir.org. This very small event will bring together for open discussions some of the Internet's most important "doers" (including Dave Farber, former Chief Scientist for the FCC and a founding member of the PFIR Board of Directors). The workshop is aimed at encouraging discourse with and among the persons who have not only been responsible for helping to get the Internet (and its ancestor ARPANET) to the level we know today, but are also leading in doing the actual work of helping to guide the Net's future. The workshop (which we want to limit to around 40 attendees) will be interdisciplinary in focus. It will also be informal, low-key, basically utilitarian, and largely off-the-record. There will be no formal paper presentations, no exhibits, and while we expect attendance by one or two major technology reporters, they will be coming mainly as individual participants and will have agreed not to report on the content of off-the-record discussions. Because space will be limited, and we wish to encourage a diversity of attendees (in terms of interests, specialties, and geography), we cannot guarantee that everyone who wishes to attend will be able to do so. In such a circumstance, we'll choose among prospective attendees in a manner that will hopefully enhance the usefulness of the workshop for everyone concerned. Unless otherwise prearranged in particular cases, all attendees must be registered in advance of the event. A framework agenda of the conference will be discussed via e-mail among participants during the weeks before the event, but it is expected that a variety of the topics listed in the PFIR Issues document (http://www.pfir.org/issues) will be of interest. The agenda will be subject to change at the workshop as participants see fit. The Internet is of course an international medium, and international issues should be of significant importance in the discussions. Any topics of relevance to the Internet, from domain names to governmental controls, from censorship to intellectual property protections, from infrastructure to law enforcement, and any others of interest, will be fair game during our discussions. As Internet-related issues have come to pervade ever more aspects of our society, reasoned discourse regarding many of these issues has increasingly been drowned out by a sea of emotional e-mail interactions and hardening uncooperative positions. This workshop will present an opportunity to meet face-to-face for two days of intelligent conversations as human beings, as we try to chart some possible solutions and courses for the range of difficult challenges the Internet (and society's reactions to the Net) have presented to us. We're trying to keep the workshop as simple as possible. We'll be charging a small registration fee (about $85) to help defray costs. This amount will include continental breakfast and a lunch both days. There are a number of reasonably-priced hotels in the area. L.A. being what it is, you'd probably want to rent a car, though some car-pooling arrangements can possibly be worked out if there is interest. The workshop will run from 9 AM to 4:30 PM on Saturday May 5, and from 9 AM to 3:00 PM on Sunday May 6. We'd like to handle most or all of the registrations before the actual event if possible. Details on this and other related information (hotel lists, etc.) will be provided later. If you're interested in attending, or if you have other questions about the workshop purpose, agenda, or other associated matters, please send an e-mail note to: workshop@pfir.org Please be sure to mention your areas of interest and specialties relating to Internet issues. We'd also be happy to chat by phone at the numbers listed below. Questions regarding ongoing workshop operational issues (registrations, information about the area or other assistance and questions, etc.) should be directed to Susie Hirsch (susie@pfir.org). You can contact Susie by phone at: (310) 737-1739. We hope that you'll consider attending! Please let us know if you're interested, at your earliest opportunity, and we'll keep you on the information list. Because this is a small event, every attendee is especially important, and we're doing our utmost to bring together a fascinating and somewhat eclectic group of "movers and shakers" who, working together, can help the Internet better serve everyone, everywhere. We look forward to hearing from you. Thank you very much. Lauren Weinstein lauren@pfir.org or lauren@vortex.com (818) 225-2800 Co-Founder, PFIR - People For Internet Responsibility - http://www.pfir.org Moderator, PRIVACY Forum - http://www.vortex.com Member, ACM Committee on Computers and Public Policy Peter G. Neumann neumann@pfir.org or neumann@csl.sri.com (650) 859-2375 Co-Founder, PFIR - People For Internet Responsibility - http://www.pfir.org Moderator, RISKS Forum - http://catless.ncl.ac.uk/Risks Chairman, ACM Committee on Computers and Public Policy ------------------------------ Date: 12 Feb 2001 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Abridged info on RISKS (comp.risks) The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. Alternatively, via majordomo, SEND DIRECT E-MAIL REQUESTS to with one-line, SUBSCRIBE (or UNSUBSCRIBE) which now requires confirmation to majordomo@CSL.sri.com (not to risks-owner) [with option of E-mail address if not the same as FROM: on the same line, which requires PGN's intervention -- to block spamming subscriptions, etc.] or INFO [for unabridged version of RISKS information] .MIL users should contact (Dennis Rears). .UK users should contact . => The INFO file (submissions, default disclaimers, archive sites, copyright policy, PRIVACY digests, etc.) is also obtainable from http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info The full info file will appear now and then in future issues. *** All contributors are assumed to have read the full info file for guidelines. *** => SUBMISSIONS: to risks@CSL.sri.com with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.comlogin anonymous[YourNetAddress]cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 20" for volume 20] http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. Lindsay Marshall has also added to the Newcastle catless site a palmtop version of the most recent RISKS issue and a WAP version that works for many but not all telephones: http://catless.ncl.ac.uk/w/r http://the.wiretapped.net/security/info/textfiles/risks-digest/ . http://www.planetmirror.com/pub/risks/ ftp://ftp.planetmirror.com/pub/risks/ ==> PGN's comprehensive historical Illustrative Risks summary of one liners: http://www.csl.sri.com/illustrative.html for browsing, http://www.csl.sri.com/illustrative.pdf or .ps for printing ------------------------------ End of RISKS-FORUM Digest 21.31 ************************