Software problem in shuttle software

Nancy Leveson <leveson@cs.UMD.EDU>Thu, 28 May 92 06:29:42 -0400

(forwarded from Marty Kaszubowski)
In this week's Aviation Week and Space magazine, there is an article entitled
"Mission Control Saves Intelsat Rescue from Software, Checklist Problems." In
the article it is stated that:
Analysis of the problem showed that it occurred when IBM, with NASA
approval, made pre-launch changes in rendezvous software. ``It didn't work
exactly the way they thought it would work,'' [launch director] Hale said.
The problem not only threatened the rendezvous, but also raised questions
about the entire shuttle guidance and control software. ... ``We were
concerned about the safety of all the other software on the orbiter — if the
computers don't work, nothing on the orbiter works.''

The Thin Edge of the Wedge?

BARRY JOHNSON <WB15471@ibrdvax1.bitnet>Thu, 28 May 92 18:18:00 EDT

The Town of Vienna is a small bedroom-community enclave of about 15,000 people
in the northern Virginian suburban overflow of Washington DC. Although
dependent on the surrounding Fairfax County for many services (most notably
schools and, for the sake of the second story, the cable franchise), Vienna
does have its own police force.
Vienna is proposing to maintain a voluntary-entry next-of-kin database for
all town residents, to be used only in the event of death or medical
emergency. Contacting next-of-kin has been a serious problem in cases of
recent fire victims. Opponents see this as a further incursion into privacy.
[This paragraph starkly excerpted by PGN from "The Washington Post" FAIRFAX
WEEKLY Section - May 21, 1992, `Next-of-Kin Plan Splits Vienna Residents', by
By Whitney Redding - Washington Post Staff Writer. See also "The
Connection", a local freebie weekly - May 6, 1992, `Police data base has some
Vienna residents irked', by Darcy Nair, and a letter in the same issue. PGN]
The impression I get from this and other stuff that appeared was that a lot of
it arose because a larger budget (several thousand dollars?) was originally
requested to implement a "database"(? - and is it any coincidence the way this
term seems to be bandied around?). My impression was that a proposal without
the `computer' dimension (say, storing 3"-by-5" index cards in street address
order) might not have caused such debate. Barry Johnson WB15471@IBRDVax1

The Federal Government and Civilian Encryption

Larry Hunter <hunter@work.nlm.nih.gov>28 May 92 11:24:06

The lead article in today's Government Computer News (5/25/92, v.11, n.11),
entitled "NIST standing firm on digital signature," describes the efforts of
the National Institute of Standards and Technology to defend its harshly
criticized proposed standard, DSS. It contains some particularly important
comments by the Chairman of the House Judiciary Committee, Jack Brooks, on
executive branch actions regarding use of secure technology by the American
public.
During the hearings, vendors and industry experts kept hammering at what they
described as critical flaws in the DSS proposal. The Director of NIST, John
Lyons, testified before the House Judiciary Subcommittee on Economic and
Commercial Law that DSS is being established strictly for federal agency
applications and should not impede the development of technology within the
private sector. Under questioning, Lyons admitted that "Any standard
improperly formulated can slow down and stifle technology."
At an earlier hearing, Assistant Comptroller General Milton Socolar (from the
General Accounting Office) testified that DSS is weaker than a popular
commercial signature verification product developed by RSA Data Security, Inc.
of Redwood City, CA. He questioned whether requiring federal civilian agencies
to use NIST's DSS, if it is less effective than commercial alternatives, would
serve a useful purpose. He also said that the National Security Agency and the
FBI pressured NIST into proposing a weak standard to ensure that NSA and FBI
can crack it, and thereby forge digital signatures.
The chair of the House Judiciary Committee, Jack Brooks (D-Texas) agreed,
stating that FBI Director William Sessions had told the subcommittee that the
FBI is "against having security encryption devices that they could not break.
They did not want any system that they could not have a key to," Brooks said.
"They said it would give drug dealers, terrorists and buggers an advantage.
That's what they said publicly, and there's no use dissenting on it."
[It certainly does give those buggers an advantage.... -lh]
Brooks said Congress must be wary of White House efforts to grant intelligence
agencies a greater role in civilian security matters.
[The rest of us should be vigilant, too.]
Larry
Lawrence Hunter, PhD., National Library of Medicine, Bldg. 38A, MS-54
Bethesda. MD 20894 (301) 496-9300 (301) 496-0673 (fax) hunter@nlm.nih.gov

White House records

<kittlitz@osf.org>Wed, 27 May 92 20:18:01 EDT

In RISKS-13.52, "White House Fights to Erase E-Mail Backups", it is noted that
`In 1978, Congress made clear that the law applied to presidential records,
including "electronic or mechanical recordations".' Does the executive branch
use voice-mail? Will they have to re-program it so that old messages cannot be
deleted; they just fade away to the archives? Think of all the telephone
pranks (a la Bart Simpson) which might result. Spoofing of computer backups
may also become more likely as their volume grows; will we need digital
signatures (!) on the documents?
E. N. Kittlitz kittlitz@world.std.com kittlitz@osf.org
(contracting at OSF, not representing their positions)

Computer virus insurance

John Mello <jmello@igc.org>Fri, 29 May 92 12:32:10 PDT

Followers of the Risks conference aren't the only ones worried about
computer risks. So's your friendly neighborhood insurance agent. Several
insurers have launched programs to protect businesses against computer
mischief, namely computer viruses. And one, the Aetna Casualty and Surety
Company of Hartford, Connecticut, has gone much further.
The major reason carriers aren't shying away from virus insurance is
they don't expect to get whacked with significant losses. That certainly has
been the experience of two companies that offer virus protection, the St. Paul
Companies of St. Paul, Minnesota, and the Allstate Insurance Companies of
Northbrook, Illinois. In 1991, St. Paul's losses were less than $15,000.
Allstate has had to pay off on its virus coverage but nothing in excess of
$5000. A typical small business computer policy from Allstate, which would
automatically include virus insurance, would cover an exposure of $25,000 to
$50,000 and have an average premium of $250 to $750.
An ambitious computer crime insurance program has been launched by
Aetna. Called ACCENT (Aetna Coverage for Computer and Electronic Network
Technology), the program, limited to financial institutions and service
bureaus, includes protection against phone fraud, computer viruses, software
piracy, and threats to set off "time-bomb" viruses, disclose security codes,
and other forms of extortion.

The risks of telling the truth about viruses

fc <FBCohen@DOCKMASTER.NCSC.MIL>Sat, 30 May 92 09:39 EDT

I probably shouldn't be writing this entry until I have time to cool down about
it, so FLAME-ON=> ISPNews just published a tiny piece derived from an article I
wrote them on benevolent viruses, and left my name attached. I think I will
sue for liable and slander. If you get a chance to read this piece, please
realize that they mangled it to promote the protection business. The main
point of the article (which was written before the Michelangelo scare but only
published this week) was that benevolent viruses are possible and that only the
computer security industry wants to claim they are not - and the reason is so
they can scare you into paying them. The article had a counterpoint to each
point of an abusive article written in a previous issue, but of course the
counterpoints were all removed and replaced by a single sentence saying you
should support good viruses. The claims that you could write safe viruses were
included, but the reasons why were removed. The article it criticized was
given great placement, but the counterarticle was placed in a hard to find area
and given half the space of the original article it criticized.
If you get ISPNews, write to the editor and tell them that you know about the
hatchet job they did on my article. Tell them that you no longer trust them to
tell you about integrity protection in computers, since they obviously don't
have any integrity and care more about money than truth (they will probably
agree with that one). Cancel your subscription, and pull your advertising!
(just kidding)
The point of all this is not that they mangled my article - I am used to that -
but rather that there is a tremendous risk in an uncontrolled protection racket
that goes by the name of "computer security". If I told you your house would
burn down unless you paid me $100/year, you would probably report me to the
police (and wonder why I charged so little). If someone in the protection
rackets tells you your computer will crash and you will lose all your data
unless you pay them $100/year, how is that any different? There's a finite
probability your house will burn down, and there's a similar probability you
will suffer damage at the hands (bytes) of a computer virus. If you think the
person will burn down your house by lighting a fire, you should be aware that
some computer virus defenders have sent copies of viruses out to their
customers on demo disks (along with an order form for the cure).
I would like the FTC to look into truth in advertising in the computer security
industry, but I can't convince them that there is any false advertising, since
they seem to think that nobody could be fooled into thinking that Norton
antivirus would actually protect them from all future viruses (old ad), or that
central point caught ALL 150 viruses (that they knew about - I knew about a lot
more).
Oh well - so much for now. FLAME-OFF...

C-17 problems attributed to software diversity

David G. Novick <novick@cse.ogi.edu>Wed, 27 May 92 10:45 PDT

C-17 Program Faces Problems in Manufacturing, Software
(Excerpted from Aviation Week & Space Technology, May 18, 1992, p. 31)
The C-17 [military aircraft] program encountered manufacturing problems in
flight control surfaces and criticism by the General Accounting Office of
software development last week. [...]
Reviewing the status of C-17 embedded computer systems, GAO said the program is
"a good example of how not manage software development when procuring a major
weapon system." The Air Force waived or ignored many Pentagon software
standards and guidelines, gave Douglas Aircraft Co. control over software
development, limited its own access to software information, and restricted its
ability to require correction of problems, even after critical problems were
evident, GAO said.
"In essence, the Air Force assumed that software was a low-risk part of the
C-17 program and did little to either manage its development of to oversee the
contractor's performance," GAO said. "Douglas (with the Air Force's
concurrence) to a number of shortcuts that have substantially increased the
risk of not successfully completing software development and testing and may
result in substantially higher software maintenance costs with the C-17 is
eventually fielded.
[The first C-17 in 9/91 had all safety software but only 34% of avionics
software. The complete software is supposed to be provided with the second
aircraft in 6/92. The GAO lays the blame on proliferation of languages in the
project. The systems were supposed to have been written in Ada, but Douglas
had been working in JOVIAL. Further,]
... Douglas had trouble finding subcontractors who would use JOVIAL, however,
and the Air Force "allowed the subcontractors to develop software in whatever
language they chose." As a result there are six languages, four of them using
existing as well as newly developed code and one of them proprietary to General
Electric Co. Many subsystems contain more than one language. There are three
in the flight control computer, for example.
[The Air Force now plans to convert all this code to Ada, which may be
difficult because of inadequate documentation.]
David G. Novick, Computer Science and Engineering, Oregon Graduate Institute of
Science and Technology, 19600 N.W. Von Neumann Drive Beaverton, OR 97006-1999

C-17 story, Chmn. McDonnell's reply

"GVA::MLC" <MLC@IBERIA.CCA.CR.ROCKWELL.COM>29 May 92 06:39:00 PST

Chairman McDonnell's reply to some of the C-17 criticisms follows. This was
sent to me from my brother at McDonnell-Douglas. Neither one of us is/was
involved in the C-17 work. Michael Cook [Don't reply to Michael!]
====================================================================
C-17 - The Real Story
To All Teammates: May 13, 1992
The chorus of critics has been out in force lately. Their target: our
C-17 program. These critics continue to focus on outdated, unsubstantiated
allegations, and in some cases flat untruths about the C-17. They also echo
the groundless charges that we were "bailed out" of financial difficulty by the
government. I'm angry about this partial, slanted, misleading reporting, and
you should be too. You deserve to hear the real story.
Let's begin with the C-17 wings. The critics have focused on the
Drivmatic machine, saying the rivets it installs do not fully expand all of the
time. Here are the facts. First, the C-17 wing is designed to last 60,000
hours, or twice as long as the required 30,000-hour life of the airframe.
Second, fully expanded rivets add to that 60,000 hours. Those that do not
fully expand do not detract from wing life. Beyond that, we have improved the
processes and the machines. Our own internal investigations and those of
Department of Defense agencies and the FBI found no fraud or wrongdoing. The
bottom line: There is no safety of flight issue. There was no cover-up. The
wings exceed contract requirements.
A network television reporter claimed the Drivmatic machines caused fuel
leaks in the wing. Here are the facts. None of the leaks occurred around
fasteners installed by the Drivmatic machines. We told the reporter that. We
explained in detail to him where the leaks were found. In addition, we
described the leak rate, which was less than one drop per minute; we told him
we found that out of position work had caused the problem; we told him we had
developed a new sealing process; and we told him we had taken the precaution of
doing a reinspection of all wing sealing in every aircraft on the production
line. He chose not to report the facts.
Some critics say we fired the employees who reported and investigated the
Drivmatic issue. Here are the facts. Both individuals were fully involved in
our investigation of the issue. The individual who reported the issue was
given a pay raise for his role, but then just stopped showing up for work.
After a period of months, we fired him just as we would any other employee who
failed to show up for work for extended periods. The second individual, an
internal investigator, had been identified as a part of a reduction in force
decision a month before the investigation started. He was ultimately let go as
part of our overall reductions, and not for any reason related to the
investigation.
Other critics say problems are showing up in the C-17 flaps. Here are the
facts. Early ground testing showed greater pressure on the flaps than had been
anticipated in design. The flaps were redesigned and new flaps were made
available for the first production aircraft. In actual flight, it turns out
the pressures were much less than the ground testing had predicted. Result -
the present flap exceeds contract specs. Flight testing also shows higher
temperatures than anticipated in one area of the flap. We made a relatively
simple change to more temperature-resistant materials. Those who attempt to
judge a program solely by problems found and fixed during tests seem to ignore
that one purpose of a test program is to do just that. The fact is that these
incidents are a test program success, not a failure.
Still others question our candor on the C-17. Here are the facts. We
keep our customers fully informed. We are consistently on the record with the
facts concerning our problem areas as well as successes. Most recently we
joined with the United States Air Force and the Grumman Corporation in
announcing an inspection program to detect possible flaws in composite
materials provided by Grumman.
Some alarmists claim the taxpayers will pay billions in contract ceiling
overruns. Here are the facts. This is a fixed-price type contract for
development and initial production of C-17. We believe the government is
responsible for at least some of the cost growth, and we are submitting claims
for those costs. Once our claims are resolved, we pay any difference - not the
taxpayer. As for those who project costs greater than $8 and even $9 billion,
with more than 90% of the work done, we believe our estimate of $7.39 billion
is correct.
Finally the bailout allegation. We didn't ask for a bailout, and we
didn't get one. The facts are simple. We do the work, we submit bills, and
then we get paid.
And now to conclude the real story. We are continuing to improve. We are
building each new C-17 with far fewer labor hours than the previous aircraft.
We are reducing rework. We are flying a rigorous test program - more than 200
hours so far - and passing with top grades. And in the final analysis, we will
silence the chorus of critics with our successes.
John F. McDonnell, Chairman and Chief Executive Officer

SDI Costs

<[anonymous]>Thu, 28 May 92 9:06:36 PDT

Report Questions SDI Estimates
WASHINGTON (AP)
Deploying an antimissile defense system will cost $37 billion over five
years, about $10 billion more than the Bush administration estimates, a
congressional report said Wednesday.
The Congressional Budget Office said costs for the Strategic Defense
Initiative from fiscal 1994 to fiscal 1997 would be about $8 billion a year.
President Bush has requested $5.4 billion for the system in the fiscal year
beginning Oct. 1.
SDI Director Henry Cooper has said building a system of defenses would cost
$25 billion. The government has already spent about $29 billion on the program
commonly known as Star Wars.
The CBO based its report on administration figures for research, development
and procurement of a single-site defense at Grand Forks, N.D., by late 1997.
The program would include either ground-based or space-based sensors to
detect incoming missiles, interceptors and a controlling command system.
Last year, leading defense Democrats such as Sen. Sam Nunn, D-Ga., and Rep.
Les Aspin, D-Wis., joined congressional Republicans in backing the Missile
Defense Act, which set a new goal for the program.
The law directs the administration to deploy an SDI system by 1996 or when
the technology allows that would comply with the U.S.-Soviet Anti-Ballistic
Missile treaty of 1972.
The CBO calculated the cost of alternatives to the administration's SDI
plan, including a system favored by Nunn, Aspin and several Republicans. That
system would cost $31 billion with an average annual budget of $7 billion.
The system would be deployed at a single site by 1997 and would include an
additional system of sensors known as the ground-based surveillance and
tracking system. It also would spend less money on space-based interceptors
such as Brilliant Pebbles.
The House Armed Services Committee, in its version of the fiscal 1993
military budget, approved $4.3 billion for SDI, cutting about $1 billion from
Bush's request. The panel eliminated all funds for space-based interceptors.
The CBO report acknowledges that its estimates "do not attempt to account
for cost increases that might occur during development of a technically
challenging project such as missile defense."
In August 1988, the CBO examined the cost growth of more proven weapons such
as missiles, helicopters, tanks and fighter planes. It found that concurrent
work on each program resulted in a cost growth of 193 percent to 288 percent.
Rep. Charles Bennett, D-Fla., one of four House members to request the
report, said the CBO cost estimates combined with recent comments from Cooper
that deploying an SDI system by 1997 is a major challenge, creates a "recipe
for cost overruns and operational effectiveness problems. With real defense
assets being scrapped for budgetary reasons, it is hard to justify big
expenditures for a questionable concept like SDI," Bennett said.
Aspin, Rep. Ron Dellums, D-Calif., and Rep. John Spratt, D-S.C., also asked
for the SDI report.

Risks of SDI?

neumann@csl.sri.com <Peter G. Neumann>Fri, 29 May 92 15:09:22 PDT

An AP item in the San Francisco Chronicle on 26 May 1992, p.A3 noted that at
least $7.7 billion (out of a total investment of $29B) in Star Wars projects
"never got off the ground", being "cast aside as unneeded, unworkable, or
unaffordable". These included the following:
* A surveillance satellite to detect and track hostile missiles. $1B. Dead.
* A ground-based laser to zap missiles in flight by bouncing laser beams off
relay and "fighting" mirrors stationed in space. At least $1.2B.
Mothballed.
* A Nuclear bomb-powered X-ray laser and other "nuclear-directed energy"
weapons in space. At least $1.8B. Dead.
* A pop-up "probe" to help interceptors distinguish warheads from decoys.
At least $.5B. To be mothballed in 1993, but until last year deemed
`essential'.
* A guided rocket to intercept hostile missiles inside or outside the
atmosphere. $623M. Mothballed.

New CPSR List Server

Ronni Rosenberg <ronni@ksr.com>Wed, 27 May 92 13:32:44 EDT

Computer Professionals for Social Responsibility (CPSR) has set up a list
server to (1) archive CPSR-related materials and make them available on
request, and (2) disseminate relatively official, short, CPSR-related
announcements (e.g., press releases, conference announcements, and project
updates). It is accessible via Internet and Bitnet e-mail. Mail traffic
will be light; the list is set up so that only the CPSR Board and staff
can post to it. Because it is self-subscribing, it easily makes material
available to a wide audience.
We encourage you to subscribe to the list server and publicize it widely.
To subscribe, send mail to:
listserv@gwuvm.gwu.edu (Internet) OR
listserv@gwuvm (Bitnet)
Your message needs to contain only one line:
subscribe cpsr

Call for Papers, IFIP/Sec '93

ANNOUNCEMENT AND CALL FOR PAPERS
IFIP/Sec '93 in Toronto — May 12-14,1993
IFIP/Sec'93, the Ninth International Computer Security Symposium and
Exhibition, is part of a series of international conferences devoted to
advances in data, computer and communications security management, planning and
control. It will be held May 12-14, 1993 in Toronto Canada.
This international conference, with the theme "Discovering Tomorrow", will
encompass developments in both theory and practice and is intended for computer
security researchers, managers, advisors, EDP auditors from government and
industry, as well as other information technology professionals interested in
computer security.
The purpose of the 1993 International Federation for Information Processing
Security Conference [IFIP/Sec'93] is to provide a forum for the interchange of
ideas, research results, and development activities and applications amongst
academicians and practitioners in the information, computer and systems
sciences. IFIP/Sec'93 will consists of advanced seminars, tutorials, open
forums, distinguished keynote speakers and the presentation of high-quality
accepted papers. It is hoped that there will be a high degree of interaction
and discussion amongst conference participants, as a workshop-like setting is
to be promoted.
The upcoming conference, IFIP/Sec'93, is jointly organized by IFIP/TC 11, the
Canadian Information Processing Society [CIPS] and the Toronto Chapter of the
Information Systems Security Association [ISSA].
Call for Papers
Papers are invited in the areas shown and may be theoretical, conceptual,
tutorial or descriptive in nature. Submitted papers will be referred, and
those presented at the Conference will be included in the Conference
proceedings. Submissions must not have been previously published and must be
the original work of the author(s). Possible topics of submissions include,
but are not restricted to:
Auditing the Small Systems Environment
Auditing Workstations
PC and Microcomputer Security
Security and Control of LANs and WANs
OSI Security and Management
Electronic Data Interchange (EDI) Security
Management and Control of Cryptographic Systems
Security in High Performance Transaction Systems
Data Security in Developing Countries
Software Property Rights
Trans-border Data Flow
Database Security
Risk Assessment and Management
Legal Response to Computer Crime/Privacy
Smart Cards for Information Systems Security
Biometric Systems for Access Control
Security and Privacy in Electronic Mail
Refereeing Process
All papers and panel proposals received by the submission deadline will be
considered for presentation at the IFIP/Sec'93 in Toronto. To ensure
acceptance of high-quality papers, each paper submitted will be blind refereed.
The papers presented will be included in the Conference preprint of the
Conference Proceedings, copies of which will be provided to the Conference
attendees. All the papers presented will also be included in Proceedings which
will be published by Elsevier Science Publishers B.V. (North-Holland).
Author(s) will assign copyright of the paper to IFIP. Additionally, one or
more of the authors must present the paper at the conference. Presenters of
papers are eligible for a reduced conference fee.
Instructions to Authors
Three (3) copies of the full paper, consisting of 22-26 double-spaced,
typewritten pages, including diagrams (approximately 5,000 words), must be
received no later than October 1, 1992. Diskettes and electronically
transmitted papers will NOT be accepted. Papers must be sent to the Program
Committee Co-Chairman.
Each paper must have a title page which includes the title of the paper, full
name of all author(s) and their complete address(es), including affiliation(s),
telephone number(s) and fax number(s). To facilitate the blind review process,
the author's particulars should appear only on the separate title page.
The language of the Conference is English.
The first page of the manuscript should include the title and a 300 word
abstract of the paper. Abstracts may be submitted to the Program Committee if
guidance and indication of appropriate content is required.
Full papers must be received by: October 1, 1992
Conference dates: May 12-14, 1993
Papers Submission
Mr. Graham Dougall, IFIP/Sec '93 — Program Committee Co-Chairman
c/o Concord-Eracom Computer Ltd, 7370 Bramalea Road, Unit 18
Mississauga, Ontario Canada L5S 1N6
Registration and Other Enquiries
Those interested in additional information about the upcoming conference on May
12-14, 1993 should communicate with the Organizing Committee's Chairman.
Mr. Dave Batchelor, IFIP/Sec '93 — Organizing Committee Chairman
c/o Concord-Eracom Computer Ltd, 7370 Bramalea Road, Unit 18
Mississauga, Ontario Canada L5S 1N6 FAX: (416) 672-0017
FOR IMMEDIATE HELP: Highland@dockmaster.ncsc.mil