Subject: RISKS DIGEST 15.32
REPLY-TO: [email protected]

RISKS-LIST: RISKS-FORUM Digest  Tuesday 7 December 1993  Volume 15 : Issue 32

        FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
  ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

 Contents:
FAX sends instead of receives (John McKay)
Risks of conference calls "lack of announcement"
Apple Computer Distributes a CD-ROM with a "Trojan Horse" (Saul Tannenbaum)
French Wiretaps (Mich Kabay)
Tokyo bank fraud (Mich Kabay)
German Radicals use Computers (Mich Kabay)
NJ credit thefts (Mich Kabay)
Counterfeits (Mich Kabay)
AIDS data stolen in Florida (Mich Kabay)
Unauthorized changes of address (George Zmijewski)
Massive credit card fraud (Mich Kabay)
Lufthansa Warsaw crash - A Clarification (Peter B Ladkin)
Reminder for DCCA-4: Fourth IFIP Working Conference (Flaviu Cristian)

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 [email protected], 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 [email protected] (not automated).  BITNET users may subscribe
via your favorite LISTSERV: "SUBSCRIBE RISKS".

Vol i issue j, type "FTP CRVAX.SRI.COM<CR>login anonymous<CR>YourName<CR>
CD RISKS:<CR>GET RISKS-i.j<CR>" (where i=1 to 15, j always TWO digits).
Vol i summaries in j=00; "dir risks-*.*<CR>" gives directory; "bye<CR>"
logs out. The COLON in "CD RISKS:" is vital. CRVAX.SRI.COM = [128.18.10.1].
************ AFTER 10 DEC 1993, CRVAX.SRI.COM = [128.18.30.65] ************
<CR>=CarriageReturn; FTPs may differ; UNIX prompts for username, password.
WAIS and [email protected] 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 [email protected] .

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, 7 Dec 1993 16:56:43 -0500
From: [email protected] (John McKay)
Subject: FAX sends instead of receives

Today I tried to send a FAX to a local lawyer.  It dialed but instead of
reading the paper it generated a copy of a document from the lawyer to a
Canadian Embassy many thousands of miles away.  Moral: Don't use FAX if you
want it to get there!

 [A fine example of a nonatomic transaction at the lawyer's end.  PGN]

------------------------------

Date: Tue, 7 Dec 93 10:55:38 -0600
From: [email protected]
Subject: Risks of conference calls "lack of announcement"

Comments: This message DID NOT originate from the address listed in
       the From line.  It was remailed by an automated remailing service
       operating at that address.  Please report problems by mailing to
       <[email protected]> with the subject header of PROBLEM.

Recently I had a coworker at our HQ arrange to "pull me in" to a conference
call a vendor had arranged.  We had a conversation about their product, after
which I hung up.  After I left, apparently the vendor techs all discussed the
number of bugs in their product, and how glad they were that I would not be
able to evaluate it for several weeks, since that gave them time to fix them.

How did I know this?  My coworker noticed them still on the line, and
after turning "mute" on with his phone, rejoined the conversation.

The risks are obvious.  This was a computer security vendor no less!

------------------------------

Date: Sun, 05 Dec 1993 20:54:58 -0500 (EST)
From: Saul Tannenbaum <[email protected]>
Subject: Apple Computer Distributes a CD-ROM with a "Trojan Horse"

Apple Software Dispatch is Apple Computer's new way to buy application
software. They send you a CD (mine came unsolicited in the mail, but there
are ads for it in MacWeek, etc.). You run an application on the CD,
register your CD by a code that comes with the package, and then you can
call an 800 number to purchase applications on the CD. You give them a
credit card number - they give you some code number that unlocks/decrypts
the application.

While the documentation nowhere says so, the registration process
installs a System Extension onto your startup disk.

[Technical digression - System Extensions (sometimes called INITs), are
pieces of code that execute at system initialization time that add to or
modify the function of Apple System Software. They do this by intercepting
calls to system routines and executing before, in place of, or after the
builtin routine. This is considered a normal practice, and is used by Apple
and 3rd parties extensively. A serious Macintosh configuration issue is the
possibility that some set of extension conflict in some way. For example,
if they intercept the same system routine , they may make the assumption
that they are the only piece of code to do so. Debugging this can be time
consuming - the last extension you add may uncover problems with an
extension that to that time has been trusted and stable. Thus, careful Mac
users are _very_ conservative about adding extensions and do things like
configure anti-viral software to warn of new extensions being added.]

The documentation left me with the impression that some sort of data file
with decryption keys or, perhaps, licensing information, would be left on
my system, though, again, there is nothing that says that. The only warning
I had was from anti-viral software, telling me that a new extension was
being put in place when I ran the registration program.

Unfortunately, on my system, this extension clearly conflicted with
something, rendering my disks (hard, floppy _and_ CD-ROM) unmountable.
Removing the extension fixed the problem. Booting with Software Dispatch as
the only extension also worked, so Software Dispatch is not inherently
buggy - it just suffers from classic Mac extension conflict problems.
However, since this extension is not mentioned in the documentation, there
are people who are in for a rude shock. And, since the symptoms for this
problem are just a dialog saying "This disk is unreadable on this
Macintosh. Would you like to initialize it?", there are people who are
going to waste endless amounts of time, restoring and rebuilding their
disks needlessly. After they do that, if they still don't notice the
Software Dispatch extension, they still won't have fixed the problem. And,
if they reinstall Software Dispatch, they'll see the problem again.

I can't believe that I'm the only person to whom this has happened. While I
run a fairly complex Mac, I am relatively conservative about system
extensions - with one or two exceptions, the extensions I have aren't
particularly funky, they're from Apple or 3rd party vendors. I expect that
Apple will be suffering from real grief about this, and, regrettably, they
deserve every little bit of it.

I should note that I did report this to Software Dispatch tech support. They
took all the information and promised to get back to me.  I'm still waiting.

Saul Tannenbaum, Manager, Scientific Computing, USDA Human Nutrition Research
Center on Aging at Tufts University           Internet: [email protected]

------------------------------

Date: 05 Dec 93 11:17:57 EST
From: "Mich Kabay / JINBU Corp." <[email protected]>
Subject: French Wiretaps

>From Reuter newswire via Executive News Service (GO ENS) on CompuServe,
2 Dec 1993:

 Mitterrand Guard Says Elysee Ordered Phone Bugging

 PARIS, Dec 2 (Reuter) - A former senior security guard of French President
 Francois Mitterrand told a magistrate on Thursday the president's office had
 ordered illegal buggings of journalists and politicians a decade ago, his
 lawyer said.

The article continues with details of the taps.  Main points:

o    organized by the deputy director of the cabinet;

o    "computerised file" set up to process buggings in many parts of the
    government and also in the offices of lawyers, journalists, actors,
    politicians, and writers.

o    A probe is now under way.

 [Just what did the "computerised file" involve?  Anyone with details, please
 contribute.]

Michel E. Kabay, Ph.D. / Director of Education / Natl Computer Security Assoc

------------------------------

Date: 05 Dec 93 11:18:22 EST
From: "Mich Kabay / JINBU Corp." <[email protected]>
Subject: Tokyo bank fraud

>From United Press International newswire via Executive News Service (GO ENS)
on Compuserve, 3 Dec 1993:

 TOKYO (UPI) -- Police arrested a former bank official and two advertising
 agency executives Friday on suspicion of fraud for allegedly stealing nearly
 $550,000 using a computer.

The article goes on to explain that the accused, Masuji Yamashita (a bank
official), and Yasuo Ueno and Yoichiro Suzuki (clients) are alleged to have
made 15 fraudulent computer entries transferring the equivalent of U$497,000
from Sakura Bank to the account of an advertising agency, Ken Enterprises.
The fraud occurred over about a month (1 Feb to 4 Mar 93).  "Yamashita
reportedly moved the money from Ken's checking account to its savings account
as cash deposits.  Ken Enterprises used the funds to service its payable
drafts."

 [Seems like over-commitment to client service.]

Michel E. Kabay, Ph.D. / Director of Education / Natl Computer Security Assoc.

------------------------------

Date: 07 Dec 93 10:49:36 EST
From: "Mich Kabay / JINBU Corp." <[email protected]>
Subject: German Radicals use Computers

>From United Press International newswire via Executive News Service (GO ENS)
on Compuserve, 6 Dec 1993:

 German radicals spy on ideological rivals
 BONN (UPI) -- German rightist and leftist radicals are spying on each other
 and drawing up hit lists of their respective enemies, the Spiegel newsweekly
 said in its latest issue.
   The issue that went on sale Monday sketched a frightening picture of
 increasingly well organized violent radicals using computer networks and
 undercover operations to gather and distribute information on those they
 consider their enemies."

The article also mentions computer-based training in how to make bombs.

 [This development is important because it will bring criminal use of
 computers and networks to public and political attention.  Unless
 knowledgeable people increase the pace of public education and awareness
 about computers and security, there will be hasty and ill-advised measures
 to restrict computer/network usage.  Watch Germany closely in the next year
 or two to see the future elsewhere.

 Comments from the ground in Germany, anyone?  MK]

Michel E. Kabay, Ph.D. / Director of Education / Natl Computer Security Assoc.

------------------------------

Date: 07 Dec 93 10:50:07 EST
From: "Mich Kabay / JINBU Corp." <[email protected]>
Subject: NJ credit thefts

>From Associated Press newswire via Executive News Service (GO ENS) on
Compuserve, 7 Dec 1993:

   NEWARK, N.J. (AP) -- Fifteen salespeople at a car dealership were charged
 with using the credit records of more than 450 people to steal millions of
 dollars.
   The salespeople tapped into credit reports through their computers, used
 the information to change the victims' addresses, and then ordered credit
 cards and ran up charges, Secret Service agent Peter A. Cavicchia said.
   They also allegedly used the credit information to obtain bank loans and
 cash advances."

The article goes on to say that the average theft was $7,500.  Although the
victims don't have to pay that amount, they do have to waste their time trying
to correct their credit records.  Apparently Autoland managers noticed the
excessive and unauthorized use of their computers and reported their
suspicions to the police.

Michel E. Kabay, Ph.D. / Director of Education / Natl Computer Security Assoc.

------------------------------

Date: 05 Dec 93 15:50:23 EST
From: "Mich Kabay / JINBU Corp." <[email protected]>
Subject: Counterfeits

>From Reuter newswire via Executive News Service (GO ENS) on Compuserve,
4 Dec 1993:

 Customs Declare Counterfeiting Is Here to Stay (By Steven Heilbronner)
   FLORENCE, Italy, Dec 5 (Reuter) - British customs officials were puzzled
 to discover that the source of counterfeit Estee Lauder perfume was
 war-ravaged Bosnia.  Puzzled, but not surprised, because in spite of recent
 seizures of counterfeit goods in Italy, Britain, Germany and France,
 European customs agents acknowledge they are fighting a war on so many
 fronts that they cannot win it."

The article discusses many non-computer counterfeits, but my eye was caught by
the following points:

o       "At Nintendo, the Japanese manufacturer of video games, executives
       estimate losses caused by piracy at $10 million a year."

o       Companies are hiring security specialists to tackle the problem.

Michel E. Kabay, Ph.D. / Director of Education / Natl Computer Security Assoc.

------------------------------

Date: 05 Dec 93 15:50:41 EST
From: "Mich Kabay / JINBU Corp." <[email protected]>
Subject: AIDS data stolen in Florida

 [The Associated Press reported on 4 Dec 1993 that the computerized
 records of at least 6000 people with AIDS or HIV were stolen from
 the Jackson Memorial Hospital in Miami.  Three PCs and several
 diskettes were stolen.  PGN abstracting]

The article goes on with details:

o Crime discovered 15 Nov but not made public "for fear of alarming patients."

o Florida Department of Health and Rehabilitative Services currently
 reviewing security at county facilities and AIDS clinics.

The risk to the patients is extortion.  In today's highly-charged atmosphere,
being identified as HIV-positive has about the same social effect as a bubo
during the Black Plague (even though in fact AIDS is not very communicable in
non-intimate social contacts).  I hope anyone victimized goes to the police
immediately if they are threatened with disclosure of their status.

Michel E. Kabay, Ph.D. / Director of Education / Natl Computer Security Assoc.

------------------------------

Date: Sun, 5 Dec 93 0:11:21 GMT
From: [email protected] (George Zmijewski)
Subject: Unauthorized changes of address (Re: Kuenning, RISKS-15.11 )

In UK when you move the house you ask Royal Mail to forward all letters
addressed to you to your new address. You can apply for this service by post
or in person.  A day or two after receiving your application for redirection
Royal Mail sends letter informing you that such service has been requested;
this letter is clearly marked DO NOT REDIRECT, DELIVER TO ORYGINAL ADDRESS.
This system was in practice 5 years ago when I used it for the first time. It
is the only company which seems to understand that change of address can be
requested by fraudsters.  -- George Zmijewski [email protected]

------------------------------

Date: 05 Dec 93 11:15:04 EST
From: "Mich Kabay / JINBU Corp." <[email protected]>
Subject: Massive credit card fraud

>From the Washington Post newswire via Executive News Service (GO ENS) on
CompuServe, 2 Dec 1993:

 Credit Scam Targets Mailboxes; 9 Postal Workers Among 40 Arrested in
 Washington Area Thefts (Serge F. Kovaleski / Washington Post Staff Writer)

 Thousands of Washington area residents have been targeted by sophisticated
 scam artists who have pilfered mail from homes and post offices to get
 credit cards, checkbooks and information that they have used to steal
 millions of dollars, authorities said.

The article continues with details of the fraud, none of which will surprise
readers of RISKS.  Salient features:

o    Thieves monitor external mailboxes on homes for weeks in wealthy
    neighbourhoods to steal credit cards and new cheques arriving in the
    mail.

o    Pre-approved applications for credit cards are particularly
    vulnerable, since the thieves fill them out, send them in, and then
    intercept them shortly after postal delivery.

o    The thieves impersonate bank officials to obtain personal information
    from victims, then impersonate the victims when they call banks for
    new personal identification numbers.

o    Some victims have seen as much as $300,000 stolen through their
    accounts; the credit card companies (which is to say, all users of the
    cards) have swallowed the charges.

o    A task force has been formed including members of "the Postal Service,
    the Immigration an Naturalization Service, the Drug Enforcement
    Administration, D.C. police and other local law enforcement agencies."

o    Theft has struck hundreds of people in some neighbourhoods, and
    residents are organizing to repair insecure mailboxes and watch over
    them.

o    Some residents are renting Post Office boxes.

o    Current credit-card and bank fraud cost about $4 billion a year in the
    U.S.

Banks and credit-card providers have been reluctant to discuss security
measures [trusting to the discredited principle of security by obscurity--MK].
Nonetheless, the authors note, certain changes are already being implemented:

o    Some new credit cards don't work until the card owner confirms receipt
    [This alone will not stop the thieves, but see next point.--MK]

o    To authenticate the card holder before activating the card, officials
    will use a personal profile, asking for previously-registered details
    of personal life.  [This won't stop the criminals who fill out new
    card applications and give false information.--MK]

o    The credit thieves use classical scavenging techniques: stealing all
    mail to learn about a victim, or dumpster diving to retrieve discarded
    documents with tidbits of personal information.

o    Some thieves have re-recorded fraudulent information on discarded,
    expired cards and used them successfully.

Additional comments by MK:

At first glance, one might ask how such crimes are relevant for RISKS readers.
I think we should be watching these developments because credit cards have
become the most widely-used access-control tokens on the planet.  Because their
use is usually mediated by other people, it may not seem obvious to naive users
that they are in fact using computer networks for electronic data interchange.
It is when credit and debit cards are personally inserted into an automatic
teller machine that the close link to computer networks should be evident to
everyone.

As access-control tokens, most credit cards are weaker than debit cards.  At
least debit cards require manual input of a personal identification number
(PIN) at all times.  Why don't credit card companies require a PIN too?

In Canada, some banks send credit cards only by registered mail.  This sounds
good in theory, but in fact I have never been asked for identification.  I
have often sent a clerk to collect registered mail and parcels without any
trouble at all.  Holding the notification card seems to be all that is
demanded by clerks at Canada Post.  We must sign a register, but such
signatures cannot be verified and are thus useless.  Perhaps banks will be
interested in requesting improved authentication measures by postal employees.

In the U.S., some credit cards include a digitized photograph laminated into
the card.  This technique presumably reduces fraudulent use in person, but
does not yet affect use in banking machines or by phone.  Photos would not
stop fraud by thieves who steal application forms and create new cards, but it
would help when legitimate cards are stolen.

Use of cards over the phone must be the easiest channel for abuse. Because
there is no PIN, there is no authentication at all.  Simply reciting a number
suffices to debit the credit-card account as long as the card is currently
valid.  If a PIN _were_ required, how could it be recorded by the sales person
without compromising the card's security?  I think there should be a method
for entering card numbers and PINs via touch-tone phone panel; such a system
should preclude the order-taker from seeing the account number or at least the
PIN.  If a direct link between the customer's phone and the validation system
were not feasible or affordable, an encryption routine on the receiving end
could convert the transmitted PIN into a temporary, time/date-dependent
version which would be unusable at any other time.  This cryptogram would then
be manually entered into the validation system by the order-taker.

Decisions on improving security boil down to cost and benefit, as always.  As
long as interest rates and card services charges are still acceptable to the
victims, er, users of these services, there will be little incentive to
change.  I look forward to seeing a credit card company with the vision to
protect its users and succeed in lowering costs as a result of lowered fraud.
Then the industry will change its ways.

Michel E. Kabay, Ph.D. / Dir. of Education / Natl Computer Security Assoc.

------------------------------

Date: 4 Dec 93 01:26:43 GMT (Sat)
From: Dr Peter B Ladkin <[email protected]>
Subject: Lufthansa Warsaw crash - A Clarification [Voges, RISKS-15.31]

>   [This echoes what Peter Ladkin contributed to RISKS-15.30, and is
>   included for those of you who did not go through Peter's account.  PGN]

I'm afraid I disagree that this echoes my account. Although Udo may have
correctly reported what the TV said, I find the account misleading. I'd like
to clarify some differences.

First, `causes': the final report from the Polish authorities will be *the*
legally valid document enumerating the factors. The major players are all
discussing their favored candidates, but there is not unanimity. At least one
candidate factor mentioned in my article has not been reported yet by the
media [RISKS is sometimes first!]. It was not on Udo's list, which is a strict
subset of the candidates so far. There may be more that we're not aware of
yet.  Factor 3 reported by Udo is a misleading statement of the braking logic.

Udo reports that Airbus `agreed to modify its control system'.  I wonder. The
so-called `modification' has been available as an option to operators for some
time, and has been installed on delivered A320s.  Airbus has already noted
that this option is available to operators. This can't count as modification.

Peter Ladkin

------------------------------

Date: Fri, 03 Dec 1993 17:37:39 -0800
From: Flaviu Cristian <[email protected]>
Subject: Reminder for DCCA-4: Fourth IFIP Working Conference

 [For a full copy of the program and registration information, send
 E-mail to Flaviu Cristian <[email protected]> or [email protected]
 or fax to +1-619-534-7029, or a telephone call to Keith Marzullo,
 +1-619-534-3729.  An earlier version, with that information, is in
 RISKS-15.05.  PGN]

                DCCA-4: Fourth IFIP Working Conference
          on Dependable Computing for Critical Applications
                           January 4-6, 1994
          Catamaran Resort Hotel, San Diego, California, USA

Organized by the IFIP Working Group 10.4 on Dependable Computing and
Fault-tolerance, in cooperation with:
 IFIP Technical Comittee 11 on Security and Protection in Information
      Processing Systems
 IEEE Computer Society Technical Committee on Fault-tolerant Computing
 EWICS Technical Committee 11 on Systems Reliability, Safety and Security
 University of California at San Diego

ADVANCE PROGRAM

Monday, January 3, 7-10pm  Welcome Reception

Tuesday, January 4
 9:00-9:15am Opening Remarks
 F. Cristian, General Chair
 G. Le Lann, T. Lunt, Program Co-chairs

 9:15-10:45am Session 1: Formal Methods for Critical Systems
 Chair: M. Melliar-Smith (U of California, Santa Barbara, US)
   W. Turski, Warsaw University, Poland: On Doubly Guarded
     MultiprocessorControl System Design
   G. Bruns, S. Anderson, U of Edinburgh, UK: Using Data Consistency
     Assumptions to Show System Safety

 11:00-12:30am Panel Session 1: Formal Methods for Safety in Critical Systems
 Moderator: Ricky Butler (NASA Langley, US)
 Panelists: S. Miller (Rockwell Collins, US), M. J. Morley (British
   Rail/Cambridge, UK),  S. Natarajan (SRI International, Menlo Park,
   US), F. Schneider (Cornell U, US).

 1:30-3:00pm Session 2: Combining The Fault-tolerance, Security and
   Real-time Aspects of Computing
 Chair: C. Landwehr (NRL, Washington DC, US)
   P. Boucher et al, SRI Intl, US: Tradeoffs Between Timeliness and Covert
     Channel Bandwith in Multilevel-Secure, Distributed Real-Time Systems
   K. Echtle, M. Leu, Dortmund U, Germany: Fault-Detecting Network
     Membership Protocols for Unknown Topologies

 4:00-6:00pm Session 3: Secure Systems
 Chair: P. G. Neumann (SRI International, Menlo Park, US)
   J. Millen, MITRE: Denial of Service: A Perspective
   R. Kailar, V. Gligor, S. Stubblebine: U of Maryland, US: Reasoning
     About Message Integrity
   R. Kailar, V. Gligor, U of Marland, L. Gong, SRI: On the Security
     Effectiveness of Cryptographic Protocols

Wednesday, January 5
 9:00-10:30am Session 4: Assessment of Dependability
 Chair: W. Howden (U of California, San Diego)
   C. Garrett, M.Yau, S. Guarro, G. Apostolakis, UCLA, US: Assessing the
     Dependability of Embedded Software Systems Using the Dynamic Flowgraph
     Methodology
   A. Aboulenga, TRW and D. Ball, MITRE, US: On Managing Fault-tolerance
     Design Risks

 11:00-12:30 Panel Session 2: Qualitative versus Quantitative
   Assessment of Security
 Moderator: T. Lunt (SRI International, Menlo Park, US)
 Panelists: M. Dacier (LAAS, Toulouse, France), B. Littlewood (City U, London,
   UK), J. McLean (NRL, US), C. Meadows (NRL, US), J. Millen (MITRE, US)

 1:30-3:00pm Session 5: Basic Problems in Distributed Fault-tolerant Systems
 Chair: F. B. Schneider (Cornell U, Ithaca, US)
   C. Walker, M. Hugue, N. Suri, Allied Signal Aerospace, US: Continual
     On-Line Diagnosis of Hybrid Faults
   A. Azadmanesh, R. Kieckhafer, U of Nebraska, US: The General Convergence
     Problem: A Unification of Synchronous and Asynchronous Systems

 4:00-6:00pm Session 6: Specification and Verification of Distributed Protocols
 Chair: R. Schlichting (U Arizona, Tucson, US)
   O. Babaoglu, U of Bologna, Italy, M. Raynal, IRISA, France: Specification
     and Verification of Behavioral Patterns in Distributed Computations
   P. Zhou, J. Hooman, Eindhoven Univ, The Netherlands: Formal Specification
     and Compositional Verification of an Atomic Broadcast Protocol
   H. Schepers, J. Coenen, Eindhoven Univ, The Netherlands: Trace-Based
     Compositional Refinement of Fault-Tolerant Distributed Systems

 6:30-10pm: Banquet; after dinner speaker: P. G. Neumann, SRI Int, US

Thursday, January 6
 9:00-10:30am Session 7: Design Techniques for Robustness
 Chair: J. Meyer (U. Michigan, Ann Arbor, US)
   N. Kanawati, G. Kanawati, J. Abraham, U of Texas, US: A Modular Robust
     Binary Tree
   R. Rowell, BNR, V. Nair, SMU, Texas, US: Secondary Storage Error
     Correction Utilizing the Inherent Redundancy of Stored Data

 11:00-12:30 Panel Session 3: Common Techniques in Fault-Tolerance and
   Security
 Moderator: C. Levitt (U of California, Davis, US)
 Panelists: Y. Deswartes (LAAS, Toulouse, France), C. Meadows (NRL, US)
   P. G. Neumann (SRI International), B. Randell (U of Newcastle upon
   Tyne, UK), K. Wilen (U of California, Davis, US)

 1:30-3:00pm Session 8: Real-Time Systems
 Chair: L. Sha (SEI, Pittsburgh, US)
   M. Goemans, I. Saias, N. Lynch, MIT, US: A Lower Bound for Faulty
     Systems without Repair
   S. Ramos-Thuel, J. Strosnider, CMU, US: Scheduling Fault Recovery
     Operations for Time-Critical Applications

 4:00-6:00pm Session 9: Evaluation of Dependability Aspects
 Chair:  K. Trivedi (Duke U, Durham, US)
   G. Miremedi, J. Torin, Chalmers Univ, Sweden: Effects of Physical
     some Software Implemented Error Detection Techniques
   J. Dugan, Univ of Virginia, M Lyu, Bellcore, US: System-Level
     Reliability and Sensitivity Analysis for Three Fault-Tolerant
     System Architectures
   J. Carrasco, U Polit de Catalunya, Barcelona, Spain: Improving
     Availability Bounds Using the Failure Distance Concept

CONFERENCE ORGANIZATION
General Chair: F. Cristian, U of California, San Diego, USA
Program Co-chairs: G. Le Lann, INRIA, France, T. Lunt, SRI International, USA
Local Arrangements/Publicity Chair:K. Marzullo, U of California, San Diego, USA

------------------------------

End of RISKS-FORUM Digest 15.32
************************