Text File

19-Jun-87 00:25:59-PDT,29118;000000000000 Return-Path: <NEUMANN@F4.csl.sri.com> Received: from csl.csl.sri.com (CSL.SRI.COM) by F4.CSL.SRI.COM with TCP; Fri 19 Jun 87 00:23:39-PDT Received: from F4.CSL.SRI.COM by csl.csl.sri.com (3.2/4.16) id AA12019 for RISKS-LIST@f4; Fri, 19 Jun 87 00:23:52 PDT Message-Id: <8706190723.AA12019@csl.csl.sri.com> Date: Fri 19 Jun 87 00:23:11-PDT From: RISKS FORUM (Peter G. Neumann -- Coordinator) <RISKS@csl.sri.com> Subject: RISKS DIGEST 5.3 Sender: NEUMANN@csl.sri.com To: RISKS-LIST@csl.sri.com

RISKS-LIST: RISKS-FORUM Digest Thursday, 18 June 1987 Volume 5 : Issue 3

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

Contents: Australian ATM troubles... (David Purdue, Dave Horsfall, John Colville) Not paying by Access can ruin your credit limit! (Mike Bell) Ex-Directory [Arrested by unwristed phone mumbers!] (Brian Randell) Risks of Computerized Airport Gate Signs (Chuck Weinstock) DMV Computer Changes Names (John Mulhollen) UHB demonstrator flight aborted by software error (Kenneth R. Jongsma) Aircraft Transponders and Errors in Setting Codes (Joe Morris, Paul Suhler) On the bright side, at least my computer still works... (Jon Jacky) Human Factors and Risks (Lindsay F. Marshall) Re: Risks of so-called ``computer addiction'' (John Mackin) Directions and Implications of Advanced Computing (Douglas Schuler) Software Risk Management (Dolores Wallace)

*************************************************************************** * RISKS' HOST NAME HAS CHANGED. NOTE NEW FTP ADDRESS. Incoming mailer * * should accept OLD ADDRESSES for MAIL to RISKS and RISKS-REQUEST. * *************************************************************************** * THE EASIEST WAY TO EXPLAIN THE ABSENCE OF RISKS-5.1 IS TO ASSUME THAT * * IT NEVER EXISTED. OTHER SYSTEM PROBLEMS CONTINUE as we STILL try to * * recover from our earlier system disasters... (Governor Dever signed * * signs all over the state, "Please Pardon the Inconvenience While * * Massachusetts Forges Another Link in Her Great Highway System." -- * * including one maliciously attached to the Nantucket Sound Light Ship.) * * SORRY FOR CONFUSION & ANNOYANCE. Some incoming mail was lost Sunday. * *************************************************************************** * RISKS STILL BACKLOGGED, but stuff on old subjects seems less relevant * * the longer it takes me to get at it. (I'm just back from travels.) * ***************************************************************************

The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, nonrepetitious. Diversity is welcome. (Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM) ===>Back issues Vol i Issue j available in F4.CSL.SRI.COM:<RISKS>RISKS-i.j.<=== Volume summaries for each i in max j: (i,j) = (1,46),(2,57),(3,92),(4,97).

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

Date: Tue, 16 Jun 87 16:53:04 est From: munnari!csadfa.oz!davidp@seismo.CSS.GOV (David Purdue) To: risks@csl.sri.com Subject: Australian ATM troubles...

First some background: The Westpac Bank installed a new software system for its ATM's which did not do proper checking. Thus it allowed people to withdraw more than the daily maximum allowed ($200). It even allowed the withdrawl of more than was held in the account. The ATM's were supposed to allow customers of the Commonwealth Bank to access their accounts, but this access was denied by the new software.

From "The Canberra Times", Tuesday, June 16, 1987.

BANK LOSES HEAVILY IN AUTO-TELLER 'HICCUP' ------------------------------------------

Westpac's recent automatic-teller-machine "hiccup" cost the bank more than a red face. According to Westpac's electronic banking manager, Mr Bill Paget, the bank would lose several hundred thousand dollars of overdrawn cash.

Westpac's troubles began on Saturday, May 30, when programmers installed the IMS version 2.2 of IBM's software. The following Thursday, after a week long crisis, Westpac decided to close all its automatic tellers throughout Australia, suspecting widespread fraud. Because of the costs of recovering debts, Mr Paget said the bank would probably not take legal action to get its money back from people who were unable to repay it.

The Federal Treasury ordered an immediate inquiry on the situation as it developed. "We were concerned for the cardholder where there was a technical malfunction and the cardholder lost money," a Treasury official said. However he warned that the Treasury might get involved again if legitimate customers had rights abused during that period.

It seems the "hiccup" was more extensive than first reported. "Computing Australia" was told by Mr John Kosh, assistant manager of electronic banking for the Commonwealth Bank, that the Westpac system was malfuctioning for the whole of the week before Westpac closed the machines.

Because of this, he said, Commonwealth cardholders had been unable to use Westpac automatic tellers. At first, the Commonwealth believed it to be a communications problem. "We didn't know what was happening," he said.

The SWIFT network for the international transfer of funds was also hit, with Westpac unable to send funds overseas while the host computer was down. Mr Paget said this caused "some inconvenience" to corporate customers.

Westpac has blamed insufficient software testing for the disaster and maintains it will reinstall the offending software later. Mr Paget admitted that "somehow or other the testing didn't cover the problem".

"The new software is back with the technicians: we're saying we don't like what happened, and we don't want this to happen again," he said. "There's no doubt it will go back in at some stage, but they've got to find out why it didn't work and try to work out how to fix it. From where I sit, we'll be looking at test upon test upon test."

He said Westpac would not seek compensation from IBM. "When you are in a long term relationship with a supplier, this is going to happen," Mr Paget said. "Our people were involved with the software all the way along. We have to be big boys and live with it." DavidP

Mr. David Purdue Phone ISD: +61 62 68 8165 Dept. Computer Science Telex: ADFADM AA62030 University College ACSNET/CSNET: davidp@csadfa.oz Aust. Defence Force Academy UUCP: ...!seismo!munnari!csadfa.oz!davidp Canberra. ACT. 2600. ARPA: davidp%csadfa.oz@SEISMO.CSS.GOV AUSTRALIA JANET: davidp@oz.csadfa

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

Date: 11 Jun 87 09:29:38 +1000 (Thu) From: munnari!astra.necisa.oz!dave@seismo.CSS.GOV (Dave Horsfall) To: risks@csl.csl.sri.com Subject: Australian ATMs... [Another version!]

Although stories about bank ATM's swallowing customer's money are common enough, you don't see too many stories about the opposite situation happening. Here is a story from the "Sydney Morning Herald" (Sydney, Australia) dated Friday 5th June:

The day Westpac's computer gave away money

Westpac Banking Corporation is believed to have lost millions of dollars in international transactions, and will be forced to recover an undisclosed amount from customers who withdrew unauthorised cash from automatic teller machines, following a serious fault in the bank's computer system.

A major failure in a new software system introduced last weekend forced the closure of all the bank's 650 automatic teller machines (ATMs) across Australia yesterday. The fault also affected other ATMs with which the Westpac computer is linked.

After the fault developed earlier in the week, customers suddenly found themselves able to make multiple withdrawals of amounts beyond the usual daily limit of $200, even if the account held no money. They were also able to withdraw from cheque accounts they did not have.

The article went on to describe how "normally impoverished inner-city types (were) suddenly treating themselves to cocktails in expensive restaurants and buying new clothes at the QVB (a trendy boutique)", and that the SWIFT system (Society of Worldwide International Financial Transactions) was inaccessible. However, the bank denies losing millions of dollars this way.

Apparently, parts of the new software could not cope with carrying three or four times the number of transactions they had been tested for, and the ATMs were forced to work in isolation, unable to communicate with the host processor. This raises a few important points:

1) Why was the real-life situation so much worse than what had been expected? Don't banks test software until it fails?

2) Why were the ATMs permitted to work on their own, happily dispensing cash from empty accounts?

And more importantly ...

3) Assuming these ATMs have an internal audit trail, how much reliance can be place on them, in order to recover the money from customers who (knowingly) defrauded them? I can see the court case now:

"But, m'lud, Westpac has ALREADY ADMITTED that its software was at fault. How can we trust these little bits of paper inside their machine, claiming that my client had defrauded them?"

ATMs *DO* have an internal audit trail, don't they?

Dave Horsfall (VK2KFU) TEL: +61 2 438-3544 FAX: +61 2 439-7036 NEC Information Systems Aust. ACS: dave@astra.necisa.oz (also CSNET) 3rd Floor, 99 Nicholson St ARPA: dave%astra.necisa.oz@seismo.css.gov St. Leonards NSW 2064 UUCP: {enea,hplabs,mcvax,prlb2,seismo,ukc}!\ AUSTRALIA munnari!astra.necisa.oz!dave

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

Date: Fri, 12 Jun 87 09:17:42 EST From: munnari!nswitgould.oz!colville@seismo.CSS.GOV (John Colville) To: RISKS@csl.csl.sri.com Subject: Australian ATMs...

[...] Since then they have been running large ads in the newspapers with a funny drawing of an ATM with 'HIC' coming from its dispenser slot.

Westpac tried the new version of IMS2 against their test data transactions but not against a load approximating anything like the actual loads. (One of my students, who works with another of the Big Four banks, says that his bank always tests against live load levels before they bring in changes: perhaps reasonable validation does take place sometimes)

John Colville, N.S.W. Institute of Technology, colville@nswitgould.oz.AUS

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

To: comp-risks@ukc.ac.uk From: Mike Bell <mcvax!camcon!mb@seismo.CSS.GOV> Subject: Not paying by Access can ruin your credit limit! Date: 12 Jun 87 09:24:03 GMT

The UK Consumers' Association magazine Which? has the following cautionary tale about use of credit cards [precis].

"Sally Allen booked into a hotel near Paris for the night. As well as taking her passport overnight, the hotel asked for her Access card. They took an imprint on a payment voucher, even though she had no intention of paying by Access, explaining that it was a safeguard against non-payment of her bill."

"When she returned home and tried to use her Access card she was refused credit, even though she had next to nothing charged on her card. She contacted Access and demanded an explanation. Apparently the hotel in France had *reserved credit* on her account for the cost of her stay, and been given an authorisation number from the Access computer in the UK. The amount reserved had been deducted from her credit limit. The only way her credit could be restored was for the hotel to contact them, and to cancel the transaction. She wrote to the hotel immediately, but it took six weeks for the credit to be restored."

Which? reports that Access and Visa both think the hotel was operating outside the agreed conditions of use, but that because they have no direct contract with the French hotel, all they can do is lobby their respective international organisations (Mastercard and Visa International) for a ban.

Anybody else come across this problem of uncancelled "transactions"?

It seems very wrong that someone can screw up your credit without you ever signing or agreeing anything, and that the matter can't be put right because of the national boundaries involved.

Mike Bell --Email: mb%camcon.co.uk Phone: +44 223 358855 UUCP: ...seismo!mcvax!ukc!camcon!mb Organization: Cambridge Consultants Ltd., Cambridge, UK

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

From: Brian Randell <brian%kelpie.newcastle.ac.uk@Cs.Ucl.AC.UK> Date: Wed, 17 Jun 87 10:41:34 bst To: RISKS@csl.sri.com Subject: Ex-Directory [Arrested by unwristed phone mumbers!]

I've been told that seven terrorists (belonging to Action Directe?) were recently caught in France after the police took possession of an electronic wrist-watch/calculator in which one of the terrorists had stored a set of telephone numbers. Can anybody confirm this, and provide details? I don't recall discussion in RISKS of any such incident, and its a nice Gallic equivalent to the Irangate archived messages incident, if it's true.

Brian Randell - Computing Laboratory, University of Newcastle upon Tyne

ARPA : brian%cheviot.newcastle.ac.uk@cs.ucl.ac.uk UUCP : <UK>!ukc!cheviot!brian JANET : brian@uk.ac.newcastle.cheviot

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

Date: 18 Jun 1987 11:12-EDT From: Chuck.Weinstock@sei.cmu.edu To: risks@csl.sri.com Subject: Risks of Computerized Airport Gate Signs

Last night I had the pleasure(?) of trying out United Air Lines new O'Hare terminal. The terminal is extremely modern, complete with computerized departure signs for each gate (in a red color that can't be read when the sun backlights it!) In the closet behind each gate check-in counter there is an IBM PC (I think) with a menu driven program used to set the information on the departure sign. Unfortunately, any gate computer can control any gate sign, and the result is that a simple operator error can cause lots of trouble. In particular, last night, while I watched, the Pittsburgh flight indicated behind the counter turned magically into one for Columbus.

I should also point out that the low tech solution of a sign board to be slipped into a slot took only about 30 seconds per flight changeover. I watched the attendent take almost 5 minutes to changeover under the new and improved high-tech solution. (To be fair, the terminal has only been operating since Monday.)

Aside: if you are unfortunate enough to have to connect from United gates E-F to United gates B, plan on missing your flight unless you've added an extra 15-20 minutes for the hike. The terminal won't be fully operational until 1989, though much UAL operations will switch there in August of this year.

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

From: "IMS/John Mulhollen" <johnm@afsc-bmo.arpa> Subject: DMV Computer Changes Names Date: 11-JUN-1987 16:33 PDT

Article in 11 June 1987 Los Angeles Times:

"N.J. Computer Gives Drivers the Business

"Trenton, N.J. - Hundreds of drivers who notified Department of Motor Vehicles last month of new addresses found that a computer had changed their names -- to Watkins Leasing Co.

"The computer error has been corrected and new address labels are being sent this week to all of the drivers affected, a department spokesman said.

"Watkins Leasing Co. is a truck dealership and leasing concern with offices in Chester, PA and Wilmington and Harrington, Del."

Interesting. Why Watkins Leasing Co since apparently Watkins isn't even located in New Jersey??? JohnM

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

Date: Thu 18 Jun 87 21:12:52-PDT From: Peter G. Neumann <Neumann@csl.sri.com> [from Kenneth R. Jongsma] Subject: UHB demonstrator flight aborted by software error To: RISKS@csl.sri.com

On 18 May 87 a demonstrator flight of the McDonnell Douglas UHB twin-jet (with one GE prototype unducted fan engine) was cut short when a cockpit light indicated a potential problem with the UDF engine. The warning was triggered by a pressure sensor when the aircraft climbed above 12,000 feet. Subsequent testing showed there was a software error in the annunciation logic.

[Source: Aviation Week & Space Technology, 1 June 87, courtesy of Kenneth R. Jongsma]

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

To: risks@csl.csl.sri.com Subject: Yet another air-traffic-controller foul-up (revisited) Date: Mon, 15 Jun 87 11:33:42 EDT From: Joe Morris (jcmorris@mitre.arpa) <jcmorris@mitre.arpa> Organization: The MITRE Corp., Washington, D.C.

A short tutorial on aircraft transponders...

In RISKS 5:2 Roy Smith asks:

>> ...why isn't the plane part of the info sent by the on-board transponder? >> Aren't these id's simply the flight numbers assigned by the airlines? Why >> should it require any manual intervention to assign an id to a blip?

The transponder presently in use by all aircraft in the US has been around for many years. It has the ability to:

- Receive an unaddressed query pulse from a ground radar site and respond with a pulse of its own.

- Include with its response the transponder code set by the pilot. (This is the code which was incorrectly assigned at O'Hare.) The code is a 4-digit octal number, and has no relationship to the aircraft registration number or the (airline-assigned) flight number.

- Report if a special button (marked IDENTIFICATION) has been pressed within the past few seconds. This can be used by a controller to positively identify an aircraft, since its receipt causes the radar display to change the shape of the blip which represents the return.

- Report the pressure altitude of the aircraft, referenced to a barometer setting of 29.92" Hg. This ability is not required in low-altitude flights and is an extra-cost feature.

Work is being completed by the FAA on a replacement for the present transponder design. The new transponders (called "Mode S") will include a permanently- assigned identification, unique to the aircraft, which will be transmitted along with the other data when the transponder decodes a query. Until the Mode S gear comes into use, however, we are still limited to a transponder code address space of 4096 discrete codes to identify an aircraft.

The effective address space is smaller, since several blocks of 100(8) are reserved for special purpose. Code 1200 is the general VFR (visual, not under radar control) code; 75xx, 76xx, and 77xx are emergency codes, and so forth.

A feature of most radar display systems is the ability to use the transponder codes to DE-select a return so that a controller's display does not show the transponder data for aircraft not under his/her jurisdiction. Such aircraft might be separated horizontally (in another controller's sector) or vertically (as in an overflight above an airport). In places like Southern California, this can be used to suppress the clutter caused by VFR (code 1200) aircraft which would otherwise obscure the returns of controlled aircraft. It has been reported (and denied) that the controller involved in the Cerritos crash had suppressed the VFR returns such as that of the intruding Piper.

Yes, it would be nice if the system could set off alarms when the data became ambiguous. But at what point should it delay the alarm against the possibility of a transient failure (e.g., the second aircraft might have been changing the code setting and been on AA637's code just as the radar beam swept past)? A real problem in aviation system engineering is the incredible number of alarms which some pilots consider to be a safety risk in themselves since they can go off in combinations which distract the aircrew.

There's an O*L*D joke about the pilot who was hauled up before a board after landing his airplane with the landing gear still up. His defence was that the gear-up warning horn was so loud that he was distracted from performing the "gear down and locked" item in his pre-landing checklist.

Joe Morris (jcmorris@mitre.arpa)

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

Date: Fri, 12 Jun 87 16:07:31 cdt From: suhler@im4u.utexas.edu (Paul A. Suhler) To: RISKS@csl.sri.com Subject: Aircraft Transponders and Errors in Setting Codes [Some duplication]

Before takeoff on an IFR (instrument flight rules) flight, an aircraft's pilot is given a "squawk", a four octal digit code to enter into his transponder. This is also entered into the ATC system's computer so the code returned by the transponder when interrogated by radar is automatically translated into the airline and flight number displayed on the controller's radar scope.

As there are 4096 possible codes and probably lots more aircraft flying IFR than that, pilots sometimes have to change squawks in mid-flight when going from one region to another. And, as airlines have duplicate flight numbers that range from one to four decimal digits, they can't use those for their squawks. [...]

VFR aircraft receiving terminal radar service also use this facility, although they are only using it at the beginning and end of the flight. Also, codes 75XX are reserved for hijacked aircraft, 76XX for those with communication failures, and 77XX for those declaring emergencies, so that the total number of squawks available is actually less than 4096.

Paul Suhler suhler@im4u.UTEXAS.EDU 512-474-9517/471-3903 Organization: Univ of Texas Elec & Comp Engr Dept

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

From: jon@june.cs.washington.edu (Jon Jacky) To: ... risks@csl.sri.com Subject: On the bright side, at least my computer still works... Date: Wed, 17 Jun 87 20:36:02 PDT

I got an ad from Raytheon today for a Mil-Spec version of the VAX (built under license from DEC). It is described as an "extreme performance machine which survives tactical levels of nuclear weapons effects (NWE)."

On a related note, the June 15, 1987 issue of the trade paper ELECTRONIC ENGINEERING TIMES has an article called "Reveille for Military ASICs" (by Terry Costlow, pps. 1 and 16). It notes "Radiation hardening has been viewed largely as an aerospace application, but it is now being included in smaller weapons that are being produced in higher volumes than one-of-a-kind spacecraft. 'We're seeing more nuclear weapons being designed for tactical battlefield conditions. In the past, rad-hard was just used in weapons like intercontinental missiles. We feel this may be a nice emerging niche', says (semiconductor vendor) NCR's (director of marketing Patrick) Riley."

Jonathan Jacky

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

From: "Lindsay F. Marshall" <lindsay%kelpie.newcastle.ac.uk@Cs.Ucl.AC.UK> To: risks@csl.csl.sri.com Date: Mon, 15 Jun 87 9:49:41 BST Subject: Human Factors and Risks

Nothing to do with computers, but a very important point for system designers. I was reading a book the other day in which the author mentions the pang of fear that struck him on a plane one day, when he noticed that the screws holding the ashtray to the seat did not match. He instantly thought "Is this how they fix the engines too??".

Moral: Attention to the cosmetic details can play a great part in re-assuring users (no matter how falsely!).

Lindsay F. Marshall, Computing Lab., U of Newcastle upon Tyne, Tyne & Wear, UK JANET: lindsay@uk.ac.newcastle.cheviot ARPA: lindsay%cheviot.newcastle@ucl-cs PHONE: +44-91-2329233 UUCP: <UK>!ukc!cheviot!lindsay

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

From: munnari!basser.cs.su.oz!john@seismo.CSS.GOV (John Mackin) Date: 16 Jun 87 18:09:47 GMT To: munnari!comp-risks@munnari Subject: Re: Risks of so-called ``computer addiction'' Organization: Dept. of Comp. Science, Uni of Sydney, Australia

I'm surprised that no one has mentioned the book ``Computer Power and Human Reason'', by Joseph Weizenbaum. Weizenbaum calls the phenomenon ``compulsive programming'', and devotes quite a large part of the book to discussion of it.

John Mackin, Basser Dept of Computer Science, Univ.of Sydney, Sydney, Australia

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

Date: Thu, 18 Jun 87 13:12:36 pdt From: Douglas Schuler <douglas@BOEING.COM> To: risks@csl.sri.com Subject: Directions and Implications of Advanced Computing

DIRECTIONS AND IMPLICATIONS OF ADVANCED COMPUTING A One Day Symposium - July 12, 1987 University of Washington, Seattle, Washington

PROGRAM

On-Site Registration (8:00 - 9:00)

PLENARY SESSION (9:00 - 10:30) Robert Kahn and Terry Winograd with Gary Chapman

The featured speakers will discuss the role of funding on computer science research. How and why are projects selected for funding? What are the roles of the Department of Defense, civilian agencies and private sources? Does it matter where research money comes from?

Robert Kahn is the founder of the non-profit Corporation for National Research Initiatives, in Washington, D.C. Until 1985, Kahn was director of the Information Processing Techniques Office at the Defense Advanced Research Projects Agency (DARPA).

Terry Winograd is an associate professor of computer science at Stanford University. He is author of "Understanding Natural Language", "Language as a Cognitive Process" and (with Fernando Flores) "Understanding Computers and Cognition". Winograd is the national president of Computer Professionals for Social Responsibility (CPSR).

The discussion will be moderated by Gary Chapman, Executive Director of CPSR. He is co-editor of the book, "Computers in Battle" to be published this fall. Chapman is a former member U.S. Special Forces.

PARALLEL SESSIONS

FUNDING (11:00 - 12:00) David Bushnell - The Promise and Reality of ARPANET: A Brief History Joel Yudken and Barbara Simons - Project on Funding in Computer Science: A Preliminary Report

AI PROSPECTS I (11:00 - 12:00) Juergen Koenemann Artificial Intelligence and the Future of Work Reinhard Keil-Slawik An Ecological Approach to Responsible Systems Development

MILITARY/RELIABILITY (1:30 - 3:00) Richard Hamlet - Testing for Trustworthiness David Bella - Fault-tolerant Ballistic Missile Defense Erik Nilsson - The Costs of Computing Star Wars

EXPERT SYSTEMS (1:30 - 3:00) Matthew Lewis and Seth Chaikin - Will There Be Teachers in the Classroom of the Future? Rolf Engelbrecht - Expert Systems in Medicine - A Technology Assessment Carole Hafner and Donald Berman - The Potential of AI to Help Solve the Crisis in Our Legal System

RESEARCH PRIORITIES (3:30 - 4:30) Douglas Schuler - A Civilian Computing Initiative: Three Modest Proposals Jack Beusmans and Karen Wieckert - Artificial Intelligence and the Military

AI PROSPECTS II (3:30 - 4:30) Susan Landau - The Responsible Use of 'Expert' Systems K. Eric Drexler - Technologies of Danger and Wisdom

VIDEO Daressa Computers in Context CPSR Reliability and Risk videotape on DBNET (a computer mail network for the deaf-blind)

REGISTRATION FEES: Regular $50, CPSR Member $30, Student/Low Income $20 Proceedings only (cannot attend symposium) $15 Proceedings will be distributed to symposium registrants on day of symposium. Lunch is included.

DIAC '87, CPSR/Seattle, P.O. Box 85481, Seattle, WA 98105 Sponsored by Computer Professionals for Social Responsibility

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

Date: Thu, 18 Jun 87 08:38:21 edt From: wallace@ICST-SE Subject: Software Risk Management

The National Security Industrial Association (NSIA), in cooperation with the National Aeronautics and SpaceAdministration (NASA), DOD, the National Bureau of Standards(NBS), the Library of Congress, Society for Software Quality, the Aerospace Industries Association of America (AIA), the G-34 Computer Resources Committee of the Electronic Industries Association (EIA), and the American Society for Quality Control, is sponsoring the Fall Joint National Conference on Software Risk Management. The conference will be held September 30 - October 2,1987 in Los Angeles at the Los Angeles Airport Hilton Towers, on Century Boulevard.

Dr. Barry Boehm of TRW will be the keynote speaker of the conference beginning at 1:30 PM on Wednesday, September 30. The conference features key government officials and world renowned speakers from academe, consortia and industry.

For information on the conference program and registration, contact Jerry Smith at QSOFT, Suite 206, 2755 Hartland Road, Falls Church, VA 22046, (703) 560-4440 or Jerry Raveling, UNISYS, Sperry Park, St. Paul, MN 55164-0525, (612) 681-6800

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

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