Text File

Subject: RISKS DIGEST 13.05 REPLY-TO: risks@csl.sri.com

RISKS-LIST: RISKS-FORUM Digest Wednesday 22 January 1992 Volume 13 : Issue 05

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

Contents: Another A-320 crash in France (Paul) California Judge recommends NO on CALLER ID (PGN) Re: Gulf war virus? (Andrew Klossner) Chicken Little and the Computer (A. Padgett Peterson) CPAs leary of electronic filing (Paul Schmidt) Re: AT&T machines and dates (Chris Traynor, Daniel J Yurman) A Tale of Risk Avoidance (Kai-Mikael J\d\d-Aro) A little knowledge can lead to understanding the universe (Armando P. Stettner) Risk of computer-generated overhead foils (Jonathan Bowen) MacNeil/Lehrer Report on Phone System Risks (Randall C Gellens) Re: Automated bill collectors, privacy, ... (Marc Shannon) Re: Ohio justices fight over computer snooping (Bob Frankston) IEEE Software Safety (Tony Zawilski) IEEE Oakland Security and Privacy Symposium Preliminary Program (John McLean)

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 domain folks. REQUESTS please to RISKS-Request@CSL.SRI.COM. Vol i issue j, type "FTP CRVAX.SRI.COM<CR>login anonymous<CR>AnyNonNullPW<CR> CD RISKS:<CR>GET RISKS-i.j<CR>" (where i=1 to 13, 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 essential. "CRVAX.SRI.COM" = "128.18.10.1". <CR>=CarriageReturn; FTPs may differ; UNIX prompts for username, password. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.

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

Date: Tue, 21 Jan 1992 10:00:56 -0500 (EST) From: "NOVA::PAUL"@yttrium.house.gov Subject: Another A-320 crash in France

LATEST CRASH HEIGHTENS CONTROVERSY OVER AIRBUS A320 By Michela Wrong (REUTERS 21 Jan 1992)

PARIS, Jan 21, Reuters - The Airbus A320, a model of which crashed in France on Monday night killing 87 people, has been dogged by controversy since before its 1987 launch, with critics arguing that its computerised controls are too sophisticated. A French Air Inter A320 on a domestic flight ploughed into a mountainside in snow and fog shortly before it had been due to land at Strasbourg, giving no distress signal. Only nine of the 96 people on board survived. The narrow-bodied 150-seater became the world's fastest selling plane even before its 1987 maiden flight, notching up over 200 orders. It is central to Europe's challenge to U.S. planemakers for dominance of the world civil aviation market. But Airbus Industrie, a consortium of French, German, British and Spanish firms, has fought to win acceptance for the advanced avionics first put to civilian use in the A320. "Each time (one crashes) the crew is blamed whereas the responsibility is really shared in the hiatus between man and machine," said Romain Kroes, secretary-general of the SPAC civil aviation pilots' union. In a technique previously used only in combat aircraft, commands are sent electronically rather than hydraulically. Pilots say the system restricts what they can do in a crisis by setting built-in limits on the plane's movements. They objected to a cut in the number of cabin crew on the A320 from three to two. Airbus insists that "fly-by-wire" is safer in an emergency, allowing pilots to know how far they can push the plane without causing a disaster. Kroes said the latest crash, which followed accidents in France and India, proved that pilots' fears were well-founded. "There are numerous faults in the way man-machine communication and the cockpit have been designed on the A320... since the Habsheim and Bangalore crashes it has been clear to us that the crews were caught out by cockpit layout," he said in a radio interview. In June 1988, one of the first models sold to Air France crashed during a demonstration flight in eastern France. The plane cruised into a thicket of trees, killing three aboard. A commission of inquiry accused pilot Michel Asseline of "cowboy-like behaviour" for flying too low and concluded that there was nothing wrong with the aircraft. But Asseline, who survived, insisted that the plane's equipment had failed to alert him to the loss of altitude. A report commissioned by the victims' families found that standard procedures with flight recorders following a crash had been flouted. The main French pilots' union, SNPL, was convicted of libel for accusing the authorities of tampering with the recorders to absolve the plane and protect Airbus sales. The controversy resurfaced in February 1990 when an Indian Airlines plane crashed at Bangalore Airport, killing 90. Indian authorities grounded all Airbuses after the Indian Commercial Pilots Association blamed a systems problem. But a judicial inquiry concluded that the pilots were to blame for putting the engines on the wrong setting, which made the plane fly too slowly. Airbus, which sent four experts to the scene of Monday's crash, declined to speculate on the cause, saying it would await the results of an official inquiry. But company sources said there was no reason to think that fly-by-wire had played a role. Bad weather and the mountainous terrain were more likely factors, they said. Created in 1970 as a European challenge to U.S. giants Boeing Co. and McDonnell Douglas Corp., Airbus has received a total of 661 orders for the A320, with 251 already delivered. The consortium of British Aerospace PLC, France's Aerospatiale, the Deutsche Airbus subsidiary of Germany's Daimler-Benz AG and Spain's CASA has 26 per cent of the world market. The fly-by-wire technology used in the A320 is due to be adopted in a new four-engine A340 wide-body Airbus, which is being flight tested, and may also be used in a 600-seater that is in the planning stage.

[The 22 Jan 1992 San Fran Chron, p.A7, notes Agence France-Presse, citing informed sources, said that the aircraft made an abrupt 2,000-foot drop on its approach to the Strasbourg-Entzheim airport. PGN]

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

Date: Wed, 22 Jan 92 10:59:29 PST From: "Peter G. Neumann" <neumann@csl.sri.com> Subject: California Judge recommends NO on CALLER ID

California administrative law judge John Lemke has declared that Caller ID would be an unwarranted privacy invasion in an opinion that now goes to the state Public Utility Commission, which is expected to issue a final decision in the next two months. He recommended approval of other proposed services, Call Trace, Call Block, Call Return, Repeat Dialing, Priority Ringing, Select Call Forwarding, Special Call Waiting, and Special Call Acceptance, which he said could provide the benefits of Caller ID without the detriments. (Caller ID has been approved in 20 U.S. states, Washington D.C., and Canada.) [San Fran Chronicle, front page 22 Jan 1992]

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

Date: Tue, 21 Jan 92 14:21:33 PST From: andrew@frip.wv.tek.com (Andrew Klossner) Subject: Re: Gulf war virus?

"How could a "printer" infect a computer with a "virus"?"

One technically straightforward approach would be to plant the agent in a printer that will be connected directly to a network. For example, Macintosh printers are typically connected to an Appletalk network, where they enjoy full peer privileges. There is nothing to prevent such a printer from snooping around the network attempting to find and compromise other servers.

[My employer, a printer manufacturer, doesn't do this sort of thing.]

Andrew Klossner (andrew@frip.wv.tek.com, uunet!tektronix!frip.WV.TEK!andrew)

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

Date: Tue, 21 Jan 92 10:03:40 -0500 From: padgett%tccslr.dnet@uvs1.orl.mmc.com (A. Padgett Peterson) Subject: Chicken Little and the Computer

"and so the brave little printers destroyed all of the Evil Empire's computers and they lived happily ever after." - Some of the items seen in the last year bear a remarkable resemblance to the works of Hans Christian Anderson but then it just goes to prove P. T. Barnum's axiom.

The simple fact is that the public will believe anything the public wants to believe, particularly when it deals with "magic". As a result we have printer viruses, modem viruses, CMOS viruses, and on, and on, ad nauseum. (Actually I like Aryeh Groetsky's story of a virus that infects floppy disk drives and toasters that causes both to eject their contents at lethal velocities).

This is not to say that there hasn't been a printer virus (actually a trojan - it scrambled the password in Postscript printers rendering them inaccessible), rather that information does not flow both ways (not that it can't, both zero slot LANs such as Lantastic-Z (R I'm sure) and a nifty program by Diacom (plug) that comes with a cable to connect my car's computer to a laptop and lets me find out what is going on inside utilize bidirectional communications through the parallel port) without help from a program inside the computer (I am told that Dan Jenkins, one of my favorite authors, dislikes parenthetical statements immensely).

This was the underlying problem with that Army RFP about radio transmitted viruses (understand that there were two grants made for phase one @ $50k each): Building a virus is easy (too easy), transmitting the virus via radio is easy, the hard part is getting the other guy's computer to retrieve & execute it. Of course, if you can design the listener into the other guy's computer, you've got it made - see the French Novel "SoftWars" (not the current paperback of the same name, this one was earlier) for a description of one method. As I recall, the basis was a weather computer tied to Soviet defense systems and the program was designed so that if St. Kitts reported some impossible temperature...

Of course, the problem is that to understand what can and what cannot be done you must understand the architecture and that actually takes some research on the subject (shudder) - something abhorrent to the public and, while not unusual for a journalist, is really not what most get paid for (no-one is more ignorant than an expert speaking out of their field). Besides phone calls are more fun.

So what happens ? - a rumor starts, often innocently - like the April Fool's "InfoWorld" parody (incidentally one of the three best weekly PC magazines). However, for a parody to work it has to be just a bit off center, something obvious to experts but close enough to reality to be possible, especially when quoted out of context. In fact, as I recall, there were two similar stories at that time with the other in PC-Week).

So the rumor starts and the first thing that happens is journalists start calling up "experts" and asking "could this happen ?" with the predictable responses: "Uhhh", "If the SendMail buffer overflowed into the command queue...", "If the muffler bearings spun the transmission backwards..." and other techno-babble. Point is, it takes a lot of confidence to stand up and say "It can't happen." - besides, the journalist will then call up someone else who will say "It could" & guess which gets printed tomorrow ?

And so the headline comes out: "Army infects Iraqi computers with virus shipped in printers from Jordan". One comment made by a neighbor (remember, my house is only a half mile from Universal Studios) during televised coverage of the Gulf War sticks in my mind: "Universal could have done it better" & the "printer virus" is a natural. - You will, Oscar, you will.

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

Date: Tue, 21 Jan 92 09:28:59 EST From: tijc02!pjs269@uunet.UU.NET (Paul Schmidt) Subject: CPAs leary of electronic filing

Several CPAs in town are not using the electronic filing offered by the I.R.S. Why? Because the I.R.S. initiates the phone call to the CPA's office to retrieve the form. This means that the I.R.S. would be accessing computers remotely. Tax preparers are worried that the I.R.S. could get more than a person's tax information by accessing all of the data on the computer.

The solution that some tax preparer's are using is to have a separate, dedicated computer for filing electronically. They put only the tax forms onto this computer. This is an easy solution since they could probably get by with just a floppy drive.

Another threat is that someone else could call the tax preparers computer and get the information. Paul Schmidt

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

Date: Tue, 21 Jan 1992 11:44:36 -0500 From: ctraynor@ATTCCS1.ATTMAIL.COM Subject: Re: AT&T machines and dates (Thomson Kuhn, RISKS-13.04)

The posting made in RISKS-13.04 concerning AT&T machines seems to have been a little over-inflated and wrongly put by the writer. If he had indeed spoken to the VAR he would have been told that the date problem existed SOLELY on AT&T 6300 models - these were made around 83 and have 8088 CPUs. The company did not expect these machines - in their current configuration to last as long as they have (one point for us). It is a simple matter to upgrade the bios or use the date patch [Let us note that this warning is made clear to users if they ever read manuals]. I thought this list existed for the purpose of discussing risks, not for editing of the truth to make a story YOUR OWN...

Chris Traynor, AT&T Bell Labs

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

Date: Tue, 21 Jan 92 7:28:02 MST From: djy@inel.gov (Daniel J Yurman) Subject: Re: AT&T machines and dates (Thomson Kuhn, RISKS-13.04)

In RISKS-13.04 Thomson Kuhn notes that AT&T PCs cannot set the date to 1992. The reader may be referring to and old, and well known "feature" of the XT class AT&T 6300. This MS-DOS machine, based on the Intel 8086, had a clock chip which ran out of gas at the end of 1990. Many PC user groups have since circulated several software patches to this problem which effectively add five years to the clock chip date. These programs typically are loaded in the config.sys file and the user may merrily compute with the '6300 until the device falls apart from age.

The application to RISKS is that users, especially small businesses and home users, do not care about double declining depreciation schedules nor the technology refreshment rate of Intel-based personal computing. Once they've bought a machine this class of users has every intention of running it into the ground until it is no longer functioning, or, passing it on to their children. The manufacturer of the AT&T 6300, which as the Italian firm Oliveti, built the '6300 like a tank and mine, built in early 1986, is still surviving the assaults of four teenagers and one freelance writer. The only thing it objects to is temperatures below 65 F. Obviously, the engineers who designed the system thought any user worth his salt would give the '6300 the old heave ho within five years and so limited the clock chip accordingly.

Dan Yurman, Idaho National Engineering Lab., PO Box 1625 MS 3900 Idaho Falls, ID 83415 Phone: (208) 526-8591 Fax: (208) 526-6902

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

Date: Tue, 14 Jan 92 14:06:04 MET DST From: "Kai-Mikael J\d\d-Aro" <kai@nada.kth.se> Subject: A Tale of Risk Avoidance

[Disclaimer: I'm not trying to sell anything (in fact, none of the stuff I mention can be bought anyway), I just had a fascinating experience I'd like to share with you.]

I had been toying around with vtalk (an Ethernet-telephone for SPARC-stations from Oki Elektric Industry, Co.) and tried to add some bells and whistles to it.

Now, in the line of my studies came the exhortation "Be formal!". I have been a bit dubious of formal methods, they have seemed as a lot of sweat for obvious results. But anyway, I thought it could be nice to at least draw a little automaton so that I could have a pretty picture of all signals going back and forth between the processes of the parties.

I had Anneli Avatare, a coworker from SICS, over and we both worked for perhaps an hour drawing up an automaton on the wyteboard and trying to account for all signals. This wasn't a very large design, so after having both gone over it we were satisfied that it seemed sound.

Now Anneli suggested that we test the design in the Graphical Concurrency Workbench, GCW, on which she had worked. I had used the Concurrency Workbench before and disliked it, but the GCW was a new acquaintance. I got in to SICS the next morning, where Anneli had already drawn most of the automaton.

A little background is in order: CWB, the Concurrency Workbench is a tool developed by the Swedish Institute of Computer Science and the University of Edinburgh which allows the user to enter definitions of concurrent communicating processes and validate them, check for deadlocks, minimise the state space and so on.

As the name suggests, GCW is a graphical front-end to CWB and is implemented as an application on top of LOGGIE, a meta-tool for generating language-oriented graphical editors.

We finished up the automaton and toyed around a bit, fascinated by the (relative) ease with which we could neaten up the graph, redoing nodes and signals.

Then we got to testing the design. We created a pair of the automata and connected them to each other as the two parties.

We could then simulate the design by "sending signals" to the processes and see how little pucks moved from one state to another. To our surprise we soon managed to run the processes into a deadlock. We stared at the trace and realised we had forgotten to handle the reply signal from a sequence of hangings up and callings up. It was obvious what the fix was, and we could just add the missing vertex to the graph.

Now we tried automatic deadlock finding and watched as GCW ran through the state space moving the pucks along and found two more potential deadlock situations, both in which the fix was as trivial as in the first case.

Now, the moral of this story is perhaps not so much How Formal Methods Carried The Day And Saved My Program, but something more on the psychological side: I had been exposed to formal methods all through my professional education, but I had never realised the point of them and generally regarded them as a nuisance. Now, suddenly there was a way for me to work out the definition of a process *interactively*, easily amending any problems in the process, the graphic display giving me a clear picture of *why* my ideas were faulty, showing me *how* I got in the mess I was in and suggesting ways to get out of there. Perhaps the moral can be stated as: When Formal Methods Are Fun And Simplify Your Work, Then You Will Also Want To Use Them.

Kai-Mikael J{{-Aro, IPLab, NADA, KTH, S-100 44 Stockholm SWEDEN +46 8 790 91 05

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

Date: Mon, 13 Jan 92 01:03:21 -0500 From: aps@world.std.com (Armando P. Stettner) Subject: A little knowledge can lead to understanding the universe

While purchasing some pre-recorded cassette tapes for my mother for Christmas, the clerk placed all 15 of them down on one of those pads that have a big sign reading "Don't place credit cards or ATM cards on or near this device!"

I asked "if this thing can cause damage to the magnetic info on cards, is it safe for other things magnetically encoded to be placed on it?" After conferring with another clerk (while the tapes continued to sit on the pad), the first clerk said it is better to be safe than sorry and started to move them.

Upon hearing this short discussion, a third, more pompous clerk came over and said that these pre-recorded tapes can't be damaged by this device. She went on to say "there is this little plastic tab" on the back edge of the cassette, which, when punched out, "prevents *any* inadvertent erasure or recording!"

I did not know where to begin.... But clearly an example of a little knowledge can be dangerous. aps.

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

Date: Tue, 14 Jan 92 01:01:35 +0100 From: bowen@dag.uni-sb.de Subject: Risk of computer-generated overhead foils Reply-To: Jonathan.Bowen@comlab.ox.ac.uk

A mildly amusing incident happened during the opening talk by O J Dahl today at a workshop on Software Construction here at Schloss Dagstuhl in Germany. He started his talk and a few minutes in, whilst fumbling with his foils, he suddenly realised that they had all been printed the wrong way round on the attached paper side rather than the transparency side. Always check your computer-generated slides before your talk! The replacement talk used good old hand written foils and thus avoided this (50%?!) "risk". :-)

Jonathan Bowen, Oxford University Computing Laboratory

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

Date: Tue, 21 Jan 92 08:46 GMT From: Randall C Gellens <0005000102@mcimail.com> Subject: MacNeil/Lehrer Report on Phone System Risks

[Forwarded from the Telecomm Digest by <Marc_Rotenberg@washofc.cpsr.org>] TELECOM Digest Tue, 21 Jan 92 19:31:53 CST Volume 12 : Issue 68

The MacNeil/Lehrer News Hour for Monday, January 20 contains a report (about twenty minutes or so in length) on the risks of the phone system ten years after the breakup. It includes the fire at the Chicago POP of all three carriers, the power failure in New York, the spate of software-induced outages, and lots more. Interviewed are executives from AT&T, MCI, and Sprint (the Sprint and MCI execs say how scared they were when the New York power failure hit, because if it could happen to AT&T it could happen to them), workers talking about staff cutbacks, FCC officials, Congressmen, phone users, and others. It includes footage of hearings, shots of a 4ESS, fiber trenching, and horrendous amounts of cable inside a switching center.

If you missed it live, you can order a transcript or a videotape. I forget the address for transcripts ($4), but the videotape number is (800ed) 328-PBS-1 (no price mentioned). (I have no connection with PBS or MacNeil/Lehrer). Randy

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

Date: Sun, 12 Jan 1992 14:05 EST From: Marc Shannon <R602MS5U@VB.CC.CMU.EDU> Subject: Re: Automated bill collectors, privacy, ... (MacKinnon, RISKS-13.03)

I have had a similar call to Bryan's (an automatic credit dunning system). When I received the message saying "if you are John Doe, press <1>", I pressed <1>. The system then informed me that listening to this message was an invasion of privacy and if I really wasn't John Doe, I'd be in serious trouble.

How can this be so? *They* called *me*! Don't I have the choice of what I want to do with a call that is placed to my number?

My intention in finding out that poor Mr. Doe had a credit problem was simply to find the number of the company that originated that message and inform them of the error in their database, which I did do. The woman with whom I spoke about the problem was very sympathetic to my concerns of receiving unwarranted phone calls and assured me that their database would be corrected. It must have been fixed as I have not received any more calls from them since.

The bottom line: I *HATE* these computer generated phone calls. If someone is calling with personal information, it had better be a person so that such errors can be detected (and apologized for) before the personal information is given out to someone it shouldn't be. At least, to the benefit of this company, they did give me a contact number. I have, in the past, received such calls telling me that I (no name given in that message) was in trouble with company X and I should send in payment immediately. They didn't leave a number to discuss it with a human.

Sigh...are we starting to rely on computers a bit much?

--Marc Shannon

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

Date: Tue 21 Jan 1992 16:58 -0500 From: <Bob_Frankston@frankston.std.com> Subject: Re: Ohio justices fight over computer snooping (Harding, RISKS-13.04)

Snooping is not new. What is, perhaps, new, is naivete about the accessibility of information. Back in the old days of Multics, security was viewed as a key system facility. This wasn't just because of ARPA funding, but also because the computer utility had to embody social conventions beyond those needed in a calculator. The default access to a user's information was no access. This was in keeping with the convention that one doesn't paw through another's desk. While one can argue that locking desks is not the norm, the ability to surreptitiously browse from another terminal requires something beyond simple trust.

Unfortunately, many newer systems in a misguided attempt to be friendly either ignore access control entirely or default the systems to give the world, or at least, colleagues read access.

The moderator and other readers can provide more details of the evolution of these conventions. And I'm sure newspaper staffers can tell about the entertainment of reading others' drafts.

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

Date: Wednesday, 22 Jan 1992 10:44:29 EST From: m16143@mwvm.mitre.org (Tony Zawilski) Subject: IEEE Software Safety

I am writing as Vice Chair of the IEEE P1228 Working Group on Software Safety. We have been working since October of '89 on a standard for Software Safety Plans. The SSWG has some 150 members, and we are now very close to submitting final draft to the IEEE standards hierarchy for balloting. We will be mailing out this last draft to our SSWG membership for review and comment this week. All comments would be due back at the end of February, and then the final version would be completed at our March 6 meeting. We would like to assure a broad base of comments, so if any of the readers of RISK would like to be included on the mailing list to receive this draft, please have them email their mailing address, email address, and telephone number to: zawilski@mitre.org [ERROR FIXED in ORIGINAL MAILING] Their names will be added to the mailing list for future mailings. Thank you for your courtesy. Tony Zawilski

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

Date: Tue, 21 Jan 92 17:55:27 EST From: mclean@itd.nrl.navy.mil (John McLean) Subject: Oakland Preliminary Program

1992 IEEE SYMPOSIUM ON RESEARCH IN SECURITY AND PRIVACY PRELIMINARY PROGRAM MONDAY

8:45--9:00: Welcoming Remarks: Deborah Cooper, John McLean

9:00--10:30: DISTRIBUTED SYSTEMS: John Rushby, Session Chair 9:00-- 9:30: On Inter-Realm Authentication in Large Distributed Systems Virgil Gligor, Shyh-Wei Luan, Joseph Pato 9:30--10:00: Integrating Security in a Group Oriented Distributed System Michael Reiter, Kenneth Birman, Li Gong 10:00--10:30: Authorization in Distributed Systems: A Formal Approach Thomas Woo, Simon Lam

10:30---11:00: BREAK

11:00--12:00: COVERT CHANNELS: Tom Berson, Session Chair 11:00--11:30: Lattice Scheduling and Covert Channels Wei-Ming Hu 11:30--12:00: The Influence of Delay Upon an Idealized Channel's Bandwidth Ira Moskowitz, Allen Miller

12:00--2:00: LUNCH

2:00--3:00: INVITED SPEAKER: John McLean, Session Chair SPEAKER AND TITLE TO BE ANNOUNCED

3:00--3:30: BREAK

3:30--5:00: CRYPTOGRAPHIC PROTOCOLS: Dan Nessett, Session Chair 3:30--4:00: Encrypted Key Exchange: Password-Based Protocols Secure Against Dictionary Attacks Steven Bellovin, Michael Merritt 4:00--4:30 On Message Integrity in Cryptographic Protocols Stuart Stubblebine, Virgil Gligor 4:30--5:00: Roles in Cryptographic Protocols Einar Snekkenes

6:00: POSTER SESSIONS

TUESDAY

9:00--10:30: SECURITY MODELS: George Dinolt, Session Chair 9:00-- 9:30: The Typed Access Matrix Model Ravi Sandhu 9:30--10:00: A Resource Allocation Model for Denial of Service Jonathan Millen 10:00--10:30: Non-Monotonic Transformation of Access Rights Ravi Sandhu, Gurpreet Suri

10:30--11:00: BREAK

11:00--12:00: INFORMATION FLOW: Dale Johnson, Session Chair 11:00--11:30 A Logical Approach to Multilevel Security of Probabilistic Systems James Gray, Paul Syverson 11:30--12:00 Using Traces of Procedure Calls to Reason About Composability Catherine Meadows

12:00--2:00: LUNCH

2:00--3:00: INTEGRITY: Richard Kemmerer, Session Chair 2:00--3:00 PANEL: Report of an Integrity Working Group Panelists: Marshall Abrams, Edward Amoroso, Leonard LaPadula, Teresa Lunt, James Williams

3:00--3:30: BREAK

3:30--5:00: CONCURRENCY CONTROL: Tom Haigh, Session Chair 3:30--4:00: A Multilevel Transaction Problem for Multilevel Secure Database Systems and Its Solution for the Replicated Architecture Oliver Costich, John McDermott 4:00--4:30: A Two Snapshot Algorithm for Concurrency Control Algorithm in Secure Multi-Level Databases Paul Ammann, Frank Jaeckle, Sushil Jajodia 4:30--5:00: Alternative Correctness Criteria for Concurrent Execution of Transactions in Multilevel Secure Database Systems Sushil Jajodia, Vijayalakshmi Atluri

5:00: TC MEETING

6:00: POSTER SESSIONS

WEDNESDAY

9:00--10:30: SYSTEMS: Tanya Korelsky, Session Chair 9:00-- 9:30: Evolution of a Trusted B3 Window System Prototype Jeremy Epstein, John McHugh, Rita Pascale, Charles Martin, Douglas Rothnie, Hilarie Orman, Ann Marmor-Squires, Martha Brandstad, Bonnie Danner 9:30--10:00: A Neural Network Component For An Intrusion Detection System Herve Debar, Monique Becker, Didier Siboni 10:00--10:30: An Optimal Solution to the Secure Reader Writer Problem Glenn Benson

10:30--11:00: BREAK

11:00--12:00: DATABASE SECURITY: John Dobson, Session Chair 11:00--11:30: Security for Object-Oriented Database Systems Jonathan Millen, Teresa Lunt 11:30---12:00 A Natural Decomposition of Multi-level Relations Frederic Cuppens, Kioumars Yazdanian

12:00--12:15: AWARDS 12:15: SYMPOSIUM ADJOURN

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

End of RISKS-FORUM Digest 13.05 ************************