Subject: RISKS DIGEST 13.50

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

RISKS-LIST: RISKS-FORUM Digest Sunday 17 May 1992 Volume 13 : Issue 50

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

Contents:
Food stamp computer misbehaves in Maryland (Joseph E. Richardson)
Spelling checker advocates massive drug abuse (Randy Lindsey)
Credit card databases prefer St. to zip codes (David C. Kovar)
Risk of TRW Not Having Enough Information (S. Peter Loshin)
Re: Free TRW Credit Report (R. R. Hauser)
Yet more Software-in-the-Air scares (Simon Marshall)
More on the F-22 crash: pilot error now blamed (PGN)
Re: F-22 crash, cont'd. (Daniel P. Johnson, Larry, Bob Rehak)
Final Announcement for IFIP/Sec '92 (Guy G. Gable, Carlos Delgado Kloos)
FTC Newsletter Volume 9 (FTCS-92 + workshop on Fault-Tolerant Par.Dist.Sys.)

The RISKS Forum is moderated. Contributions should be relevant, sound, in
good taste, objective, coherent, concise, and nonrepetitious. Diversity is
welcome. CONTRIBUTIONS to [email protected], 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 folks. REQUESTS please to [email protected].
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: Wed, 13 May 92 09:43:21 EDT
From: [email protected] (Joseph E. Richardson)
Subject: Food stamp computer misbehaves in Maryland

Food Stamp Computer Clogs in Md. -- Overloaded System Causes Long Lines
By Retha Hill - Washington Post Staff Writer [Washington Post, 13 May 1992]

Maryland food stamp clients using a new electronic benefit system were unable
to buy groceries [on 6 May 1992 <JR>] after the state-of-the-art computer
system failed, causing long lines at hundreds of stores in the state.

The system, which the U.S. Department of Agriculture has said it plans to use
as a model for the rest of the coutry, became overloaded for the second time in
a month and shut down for about two hours as hundred, and possibly thousands,
of recipients tried to use their plastic benefit cards to make purchases.
Typically, the first few days of the month are heavy shopping days because that
is when clients receive benefits.

The system "reached a point where it clogged," said Helen Szablya, a
spokeswoman for the Maryland Department of Human Resources. She said that she
did not know if other benefits that are encoded on the plastic cards, such as
welfare payments and child support, were affected.

About 31,000 Maryland residents in Montgomery, Prince Georges and Cecil
counties and Baltimore now have the cards. Clients in Baltimore, Howard and
Anne Arundel counties are to get the cards by mid-summer, and eventually
200,000 recipients will use them.

Szablya said the electronic benefit transfer system is better than the old
method [Electronic systems are always "better", aren't they? :-) JR] of issuing
coupons to clients and said that problems are going to happen because it is the
first of its kind in the country. The system last stopped working April 11 for
about two hours. "It's going to have a few blips. We are happy with the fact
that we haven't had more," she said.

Shoppers and grocery store officials complained of long lines and carts loaded
with groceries abandoned as checkout stations. Food stamp clients were given
$50 vouchers to make purchses, but cashiers had to call a toll-free number to
verify each transaction.

"We just think it's unfortunate that this happens and that it inconveniences
our customers," said Mitchell D. Herman, senior vice president for corporate
affairs for Shoppers Food Warehouse. [How true, how true. -- JR]

Joseph E. Richardson, Berard Software Eng., Inc., 101 Lake Forest Blvd,
Ste 360, Gaithersburg, MD 20877-2611 (301) 417-9884 [email protected]

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

Date: Tue, 12 May 92 12:57:56 PDT
From: Randy Lindsey <[email protected]>
Subject: Spelling checker advocates massive drug abuse

It is not uncommon in large companies to require an annual "payout", in which
each employee picks up their paycheck in person, displaying ID. I think this
is to guard against payroll padding.

At the facility where I'm doing a project, all 1,500 employees received a memo
ordering them to report to the cafeteria for their annual "peyote". Peyote
appeared several times in the memo, and even in the title line! Eventually
one of my colleagues ran "payout" through the spelling checker, and sure
enough it suggested "peyote" as the alternative.

Perhaps the spelling checker writers are junior staff with closer ties to their
college counter-cultural days than to corporate terminology...
Randy Lindsey

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

Date: Wed, 13 May 1992 09:38:32 -0400
From: "David C. Kovar" <[email protected]>
Subject: Credit card databases prefer St. to zip codes

About two years ago, I started getting some credit card statements a few days
late. All of them had an incorrect zip code and the post office had corrected
them by hand and resent them. I called up the offending credit card companies
and tried to correct the problem. Two of them corrected it, one of them
couldn't/wouldn't. I eventually cancelled the card belonging to the bank that
couldn't get the address right.

Well, for various reasons, I've taken my time in paying off the account, so I
still get statements from them, still with the wrong zip code. Apparently the
Post Office is cracking down on bad zip codes because both AT&T and this
particular bank called me up this week to verify my address.

About three months ago I finally figured out what I thought was the problem.
I live on Broadway, and my zip code is 02174. People frequently want to know if
it is Broadway Rd, Broadway St, Broadway Ln? It's just Broadway. All of the
offending statements had my address as Broadway St, and my zipcode as 02111.
Someone's database, somewhere, mapped Broadway St. to a 02111 zip code and, if
the zip code was corrected but the street address wasn't, it would modify the
zip code again to what it believed was correct.

So, I explained all this to the person from the bank, had her change the
street address and the zip code, and we'll see if it works.

If anyone has any more information on this problem, I'd be interested in
hearing about it. I don't have enough time at the moment to track down which
database these guys are using. If anyone is curious, the bank is Chase
Manhattan.
-David Kovar

[We have had a spate of similar tales of woe in the past. In this case,
please send responses to David. If anything exciting comes up, I am sure
he will share it with us. PGN]

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

Date: Tue, 12 May 1992 16:20:00 EDT
From: "S. Peter Loshin" <[email protected]>
Subject: Risk of TRW Not Having Enough Information

This might be of some interest, as I recently was denied credit (temporarily)
due to inability of the credit grantor to verify my address. I cleared that up
by sending copies of utility statements to the credit grantor, but out of
curiosity I took advantage of the free copy of the TRW credit report that
caused the denial.

Maybe I'm just different - I use my middle name and don't use my given first
name, and I use a PO box for as much correspondence as possible - but the
report was VERY sparse. My address was three years out of date and they had no
info on my employer or on any of the credit cards that I customarily use.
There were NO negative reports from any of the institutions listed, and only
one neutral report.

Overall, I was fairly pleased with the lack of complete information on me -
unless it was all a ruse to lull me into a false sense of security about my
privacy.

Peter Loshin | [email protected] | 555 Technology Sq Cambridge MA 02146

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

Date: Fri, 8 May 1992 13:03:45 -0500
From: [email protected] (R. R. Hauser)
Subject: Re: Free TRW Credit Report (RISKS-13.46 and 47)

Three credit reporting agencies exist (to my knowledge): TRW,
Transunion (Merchants), and Holloway Credit Bureau.

Since I happen to have my credit report in hand (Holloway) which
lists address/phone for Transunion and TRW, I called TRW
long-distance and spoke with a representative about the free
credit report. She gave me this number 1-800-392-1122.

The risk seems low IF you do the following rather than trusting
some bulletin board posted P.O. Box address.

Go to a local credit bureau and get your report (~$10) or borrow
someone's to get valid address/phone for TRW. Call and inquire.

Since this may cost a bit you could call the 1-800 number I got
from TRW and wait until a representative comes on. The risk
in trusting this posted phone number can be reduced by waiting
until a person comes on rather than trusting a computerized voice.

When questioned, the TRW representative (how knowledgeable?)
implied that _establishing_ any kind of credit had nothing to
do with this service. Also, a bill is not necessary ... just
anything with the name-address linkage. Hmmm...

Seems that the risk of someone easily obtaining your credit report
from TRW may be higher now.

R. R. Hauser DOMAIN: [email protected]

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

Date: Sun, 17 May 1992 16:06:12 +0000
From: Simon Marshall <[email protected]>
Subject: Yet more Software-in-the-Air scares

Here are yet more stories concerning flight control software going wrong in
commercial passenger aircraft. It is taken from the front page of the UK
``Sunday Telegraph'' May 17, 1992, a so-called ``quality newspaper''. The
article is quoted in its entirety.

Air scares over computers", Robert Matthew and Christopher Elliott.

A spate of software errors forcing planes into sudden changes of speed and
direction has rekindled concern about the use of computers by the aircraft
industry. An internal British Airways document discloses 10 serious
incidents involving computer errors in January, including:

- January 13, when the flight-management system on a Boeing 747-400 from
Washington to Heathrow suddenly ordered a speed reduction of 50 knots.

- January 26, when a Boeing 747-200 flying to Gatwick from Barbados
experienced a sudden increase in thrust due to a software error.

- January 27, when a Boeing 747-200 from Manchester to Islamabad suddenly
pitched upwards. The crew had to turn off the auto-pilot to bring the
aircraft back into normal flight.

Other computer errors have led to navigational deviations and to the
auto-pilot wandering from the correct route.

British Airways said action had been taken to rectify the problems, which did
``not present any threat to the safety of the aircraft''. A spokesman added
that the software had Civil Aviation Authority approval and had been tested
by BA for more than 100 hours before entering service.

But leading computer experts are worried that there is no adequate way of
testing the enormously complex software routinely used by the aircraft
industry.

The British Computer Society will call this week for international standards
on the design of safety-critical software, and for special qualifications
from [sic] those working the field.

Professor John Cullyer, of Warwick University, chairman of the society's
Safety Critical Systems Task Force, said: ``We haven't for enough highly
educated and trained checkers. We actually know what we ought to be doing but
we just don't have enough men and women sufficiently qualified.''

Professor Bev Littlewood, of City University, London, has told the American
Association for Computing Machinery that the aircraft industry could not
substantiate claims for computer reliability."

There are couple of things that made me post this article. Firstly, the number
of incidents - 10 in a single month with BA. This implies that software is not
working in normal, routine, flying conditions, where you might expect the
behaviour of such systems to be correct. There are no suggestions in the
article that "the pilot flew to low", "the pilot applied full thrust too late",
and so on, but that the systems themselves failed to perform correctly in
normal conditions.

The second is that at least some of the "software errors" were within
auto-pilot control systems (it may be all, the article is not clear - maybe BA
does not fly any fly-by-wire aircraft anyway, I don't know). These systems
are, as I understand it, typically not used for takeoff or landing, but to fly
from A to B once airborne. Given the number of years these systems have been
around, it worries me to think that these relatively simple systems fail at
this frequency, while fly-by-wire, with its increased complexity and the
increased reliance upon those systems for the safety of the aircraft, is now
being applied to commercial aircraft.

The third is that the software had "CAA approval", as if this is meant to make
us feel any better, and that it had been tested by BA themselves (not the CAA),
for "100 hours before entering service". This does not seem particularly
rigorous to me!

The fourth came with the old call for qualifications for those working in
safety-critical software design; lack of suitably trained people. Maybe the
CAA and aircraft manufacturers should be training their software personnel?

Simon Marshall, Dept. of Computer Science, University of Hull,
Hull HU6 7RX, UK Email: [email protected] Phone: +44 482 465181

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

Date: Thu, 14 May 92 12:10:56 PDT
From: "Peter G. Neumann" <[email protected]>
Subject: More on the F-22 crash: pilot error now blamed (RISKS-13.46)

Those of you who read RISKS-13.46 noted that computer software seemed to be
implicated in the crash of the only flying F-22 prototype. A later report now
suggests pilot error. As usual, the real causes are probably some combination
of a poorly designed human interface, software design and implementation
problems, hardware-software system response delays, and pilot problems
(training, complexity, etc.).

An AP report somewhen during 11-13 May (while I was in D.C.) had these
statements (starkly excerpted):

A new Air Force videotape of the crash, shot from the plane's side, shows
the radar-eluding aircraft with its landing gear down as it nears the runway at
the California base. The landing gear is then drawn back up about the same
time the afterburners go on. The plane then bucks wildly before hitting the
pavement, sliding several thousand feet and burning. [...]
Congressional sources, who requested anonymity, said the Air Force now
suspects that pilot error caused the crash. A final report is not expected for
several weeks after the Air Force completes its investigation.

Air Force Chief of Staff Merrill McPeak [quoted in RISKS-13.46 as hoping
that it was software, because that would be "relatively straightforward" to
fix] testified before Congress he suspected the crash was the result of a
mechanical malfunction in the plane's computer system. "I am utterly convinced
personally that this is a very meritorious design," said McPeak [...]. The Air
Force chief of staff said he saw no need to change the program, which calls for
650 of the fighter planes to become operational in 2002.

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

Date: Mon, 11 May 92 09:08:43 CDT
From: [email protected]
Subject: Re: F-22 crash (Watson, RISKS-13.47)

I haven't entered this discussion because there are a lot of people with more
solid credentials, but there are some elementary points to be made. If I get my
ears pinned back, so it goes.

When something goes seriously wrong in a control system, a common result is
that the system goes unstable. The wild motions of the tail are due to
positive feedback between the control system, the pilot, and the aircraft
responses. As to what caused the instability, it can be almost anything,
software error, design error, hardware failure.

A likely explanation would be that the aircraft had some unexpected
aerodynamic characteristics in the low altitude, high weight regime that it
was flying (to be expected in a prototype aircraft, that's how test pilots
earn their pay). The result was a "PIO" (Pilot-Induced Oscillation).

One can view this as a software error since the fix is to change the software
to allow for the unexpected dynamics, or as a pilot error since he was part of
the positive feedback loop, but it is better to classify it as a design problem
since one of the goals of the design is to avoid creating a situtation in which
a PIO is possible.

Daniel P. Johnson, Honeywell Systems and Research Center, MN65-2500, 3660
Technology Drive, Minneapolis, MN 55418 [email protected] 612-782-7427

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

Date: Wed, 13 May 92 13:23:50 MDT
From: <[email protected]>
Subject: Re: F-22 crash, cont'd. (Watson, RISKS-13.47)

I recorded the same footage and played it several times in slow motion to
observe the porpoising motion of the ship. A flash from the cockpit (assumed to
be the ejection system) could be seen at the end, just before the ship kissed
the runway.

I believe you'll find that large, rapid movements of control surfaces are a
common feature of modern fly-by-wire control systems for fighters. It is
necessary because of the complex flying modes involved, particularly on
take-off and landings, which limit control surface effectiveness. Special
[non-linear] servo modes are involved.

Such problems are likely to be exacerbated on the YF-22 which is probably an
unstable design to begin with (to achieve maximum maneuverability) stabilized
by the computerized control system.

> Odd that the software should be seen as a possible cause of the crash, ...

You can almost bet that the pilot was NOT the problem. The handful of people
who can qualify as test pilots are not the sort to make the mistake of extreme
pilot input. Many have been known to cooly report problems and symptoms in the
last few seconds of their lives.

As for software, someone observed that if buildings were constructed like
programs, the first woodpecker to come along would destroy civilization!
(Still, I would expect this particular control program to be a state of the art
example of good software..)

> I though most aircraft could dump/vent excess fuel, you don't have to be at low
> altitude to do this, do you?

That's another problem. Suppose we suddenly reduce the flight weight of a
fighter by a significant percentage? It seems reasonable that the ship might
need to be retrimmed quite a bit after a major fuel dump, so it is probably not
prudent to do it at low altitudes.
Larry

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

Date: Mon, 11 May 92 10:15 CDT
From: Bob Rehak Ext. 3-9437 <[email protected]>
Subject: Re: F-22 an speaking out of turn (Watson, RISKS-13.47)

All well designed aircraft have a fuel jettison system for dumping fuel. Most
fuel is dumped at higher altitudes so that it evaporates before it hits the
ground; however, if your aircraft is in distress and is at a low altitude and
you are someplace isolated like the F-22 was, who cares if you jettison the
fuel.

The claim that the F-22 was doing these low altitude high speed passes to
reduce its fuel load so it could land with a greater saftey margin sounds bogus
to me. If the aircraft was in distress these aren't the kind of maneuvers a
prudent pilot would be doing.

Also, what about the risks of speaking out of turn. I feel Gen. McPeak's
statements are a bit premature and could bias the accident investigators. I
don't how many times I have gone done the wrong path in tracking down a
software problem because I was biased by the information given to me by a
software developer (who's judgement, expertise, ect. I trusted). Moral of the
story, start at the beginning and follow your judgement not theirs. If the
investigators were to think: Hey, let's look at the s/w and computers because
that's where the Gen. says the problem is... well you know what happens next.

Bob Rehak, DBA At Large, [email protected]

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

Date: Sat, 16 May 92 07:24:36 SST
From: "Dr. Guy G. Gable, IFIP/Sec '92 Program Chair" <[email protected]>
Subject: Final Announcement for IFIP/Sec '92

THE IFIP/SEC'92
8th INTERNATIONAL INFORMATION SECURITY CONFERENCE

May 27-29, 1992
Raffles City Convention Centre
Singapore

[FULL TEXT IS FTPable from CRVAX, cd RISKS: , file IFIP.1992 , or get
it from Guy Gable. PGN]

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

Date: Thu, 7 May 92 19:47:27 +0200
From: [email protected] (Carlos Delgado Kloos)
Subject: IFIP'92 registration form

[FULL TEXT IS FTPable from CRVAX, cd RISKS: , file IFIP.1992 , or
get it from Carlos Delgado Kloos. The DEADLINE FOR EARLY REGISTRATION
DISCOUNT is 25 May. NEXT MONDAY!!! PGN]

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

Date: Thu, 23 Apr 92 11:34:32 CDT
From: [email protected] (FTCS NEWS)
Subject: FTC Newsletter Volume 9

ELECTRONIC NEWSLETTER ON FAULT-TOLERANT COMPUTING

VOLUME 9, APRIL 1992

EDITOR: Prith Banerjee, University of Illinois

CONTENTS: (Each item can be searched by keyword ITEM
and separated by a line of =========)

1. GENERAL INFORMATION AND REGISTRATION FOR FTCS-92,
7-10 JULY 1992, The Lafayette Hotel, Boston, Massachusetts USA
2. ADVANCE PROGRAM FOR FTCS-92
3. WORKSHOP ON FAULT TOLERANT PARALLEL DIST. SYS.
Campus Center Hotel, Amherst, Massachusetts USA, July 6-7, 1992
4. CALL FOR PAPERS (HICSS-26) DEADLINE EXTENSION
5. COURSE ANNOUNCEMENT (FAULT-TOLERANT DISTRIBUTED COMP.)

[Full text of this issue can be found on CRVAX, cd RISKS: ,
file FTCSNEWS.9 , or from [email protected] (FTCS NEWS).
The deadline for discount registration for FTCS-92 is 25 June. PGN

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

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