The RISKS Digest
Volume 8 Issue 86

Thursday, 29th June 1989

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…


o SPADOC Modernization Effort
Chris McDonald
o Are are nuclear weapons useable? How can one test this?
Dennis L. Mumaugh
o NASA tests video system that may lead to windowless cockpits
Karl Lehenbauer
o Air Force to upgrade missile launch command computers
Jon Jacky
o Missile launch — upgrades degrade ?
Clifford Johnson
o Strategic weapon software development practices
Stan Shebs via Jon Jacky
o Rotting Landsat data
Jonathan Patrick Leech
o Info on RISKS (comp.risks)

SPADOC Modernization Effort

Chris McDonald ASQNC-TWS-RA 678-4176 <>
Mon, 26 Jun 89 11:59:53 MDT
The General Accounting Office (GAO) has issued a report, 20 Apr 89, entitled
"Management and Technical Problems Delay Operation Center Acquisition"
(GAO/IMTEC-89-18).  The 50+page report discusses the Air Force Space Defense
Operations Center modernization effort at Cheyenne Mountain.

The following is from the Executive Summary:

    "The SPADOC program has been marked by management problems, unrealized
expectations, and program delays.  The Air Force has invested over $235 million
in a system that is now more than 4 years behind schedule and far from meeting
its required operational capability. 

            . . .

    At the root of SPADOC's technical problems is the Air Force's attempt
to achieve controlled mode security.  Software development tasks designed to
achieve this form of multilevel security are time-consuming, technically
demanding, and still undergoing much research and development.  In SPADOC's
case, functions such as notifying national decision makers that a satellite is
under attack take as much as four times longer to complete than required."

Interested parties can call 202-275-6241 to obtain a free copy.  In the
interest of fairness the DoD/Air Force response is included within the report.

Are are nuclear weapons useable? How can one test this?

Thu, 22 Jun 89 20:17 CDT
My uncle is a conspiracy and doomsday person and several friends have worked in
the "business".  They have given me an education.  My own experiences in a
military organization have confirmed their observations:

The major problem is that only a couple of times has our nuclear arsenal been
tested under field conditions (to the public's knowledege).  Even then it has
not really been under battle conditions.

The major problem is that today's military rarely have surprise tests.
Operational Readiness Tests(ORT) would have to simulate a true war.  This would
include a lot of collateral information and details, lack of warning, and other
items.  Anything less than firing random rockets would not be a real test.
Also there are cross checks to make sure other missiles are being fired.

The current worry is that 1).  The missile crews might freeze or panic. 2).
The missile would explode on the pad or fail to fire.  3).  It wouldn't get
airborne - blast through the silo lid.  4).  It would cartwheel in the air or
explode (as one recent test did). 5).  It wouldn't hit the target.

The problem is testing this because any commander who has word of an inspection
or a ORT will prep his equipment and men.  The phemonena of the perfect troop
of military is well known to inspecting generals and chiefs of state as well as
the GIs who are told to prepare for a "surprise inspection".

The risk?  How do you test a doomsday machine.  Can any system be tested for
"ultimate load" or "emergency conditions".

=Dennis L. Mumaugh
 Lisle, IL  ...!{att,lll-crg,attunix}!cuuxb!dlm  OR

NASA tests video system that may lead to windowless cockpits

Karl Lehenbauer <>
22 Jun 89 23:16:33 CDT (Thu)
NASA and McDonnel Douglas are testing a helmet-mounted, visual approach and
landing system that could have applications for future aircraft without cockpit
windows, according to the June 19, 1989 issue of Aviation Week and Space
Technology (pages 126 and 127).  The system uses two fixed-position monochrome
video cameras mounted in the aircraft's nose.  Video and graphics processing is
performed, and digitized pictures are relayed to the helmet display.

According to Mark S. Rolwes, principal investigator for McDonnell Douglas, the
use of a fixed sensor suite offers advantages such as high reliability (because
there are no moving parts) and redundancy.

A magnetic tracking device is used to measure the pilot's head movements.
Based on where the pilot is "looking", a 30 by 40 degree field of view is
selected, processed and displayed on the helmet's eyepieces.

There is a 17-millisecond delay in getting an image from the cameras to
the eyepieces.  Rolwes said the delay is imperceptible and that it doesn't
affect pilot performance.

All four pilots in the tests were able to successfully land NASA's Boeing 737
Transport Systems Research Vehicle aircraft using the landing system, coming
within 500 feet of a specified target after making several practice approaches.
A second pilot was present to set up the approach and be ready to take over and
fly the aircraft visually if there was a problem with the landing system.

I won't belabor RISKS readers by enumerating a bunch of the obvious potential
problems with such a system.  Suffice to say that the possibility of crashing
an airplane because of a failure in the video system, coupled with the
inability to look out the window (because the plane doesn't have one) is

The article specifically mentions future hypersonic flight vehicles as aircraft
that may not have, or be able to have, conventional cockpit windows.  Also, it
says that the system could have applications in current military aircraft in
which crew eye protection during combat is important.

For commercial aircraft, the system would supposedly be useful for obviating
window area restrictions and for providing night vision capabilities.  Although
this touches on a whole kettle of risks that have been undergoing periodic
discussion in this forum (risks from too much going on in the cockpit, etc), I
think that such a system, if well-designed, could help to reduce the
possibility of an accident, as long as a manual backup system (a window) was

Air Force to upgrade missile launch command computers

23 Jun 1989 11:19:12 EST
Here are excerpts from FEDERAL COMPUTER WEEK, May 8 1989, p. 10:

``Air Force to Upgrade Missile Control Systems'' by Bob Brewin

The Air Force plans to upgrade the computer and communications systems that
run the launch control centers of the US long-range missile arsenal.  The
$507 million project will streamline the authentication of war order messages
as well as missile retargeting and launch authorization, according to the
Air Force.

Under the Rapid Execution and Combat Targeting (REACT) contract, the Air
Force plans to automate for the first time the processing of emergency war
order messages by the two-man intercontinental ballistic-missile launch
control center crews.  Part of the job includes improvements in the
1960s-vintage weapons system control computers that manage the launch and
retargeting of all missiles in a wing.

Although the REACT system features an electronic interface between the war
order message processing function and weapon control systems, an Air Force
official said, ``The nuclear assuredness aspects of the system will remain
the same.  Man will remain in the loop.'' ...

Bruce Blair, a former launch control center (LCC) officer who studies nuclear
command and control systems for the Brookings Institution, said that while
the REACT program ``will reduce human judgment at [the LCC level] by some
factor,'' its impact will be minimal ``because most of the human judgments
are made at the NORAD or National Command Authority level.'' ...

LCC crews receive war order messages through three digital communications
channels: very low frequency radio, the Air Force Satellite Communications
System and the SAC digital information network.  According to Brooking's
Blair, the crews must then take these messages and manually authenticate
them with secured code books.  The computerized message processor would
handle these tasks, including sorting through duplicate messages,
automatically.  ``We're going to let the machine sort through all the messages
and then present the information on the screen to the crew member,'' (Col.
Michael) Mazzaro (a REACT program manager) said.  After authenticity
checks are completed, the processed messages, together with retargeting
information, are passed via an electronic interface to the weapons system
control element.  Mazzaro said that although the system has been automated,
``this is not the stuff of the `War Games' scenario.  Man is in the loop
the entire way.  He makes the decisions''...

The planned modifications ``will permit LCC's to stay on alert beyond the turn
of this century,'' (the Air Force) said. [The article explained the new
system would be used with Minuteman, MX, and possibly future Midgetman and rail
garrison MX missiles]. 

REACT consists of two different but related programs managed by the Electronic
Systems Division (ESD) and the Ballistics Systems Division (BSD) of the Air
Force Systems Command.  ESD will manage development of the higher-authority
communications and rapid message processing element for which GTE government
systems was awarded ... $33.7 million. ... BSD awarded Ford Aerospace ... $71.3
million for development of the Weapon System Control Element, which includes
rapid retargeting systems, voice communications, control consoles and displays,
the weapons system processor and modifications to existing LCC trainers. .  BSD
officials ... estimated the total value (of the upgrade effort) at $507 million
...  Ford based its architecture on the Raytheon MilVax.  BSD officials have
said they have not determined whether to use existing code or new code for the
weapons system control element. 

- Jon Jacky, University of Washington.

Missile launch — upgrades degrade ?

"Clifford Johnson" <GA.CJJ@Forsythe.Stanford.EDU>
Fri, 23 Jun 89 14:29:16 PDT
Jon's posting re SAC's REACT missile launch ugrade is just another relentless
turn of the hair-trigger screw.  Another turn is reported in this month's Air
Force Magazine, which is all about AF electronics.  An article reports:

    The Ground Wave Emergency Network (GWEN) [is] a
    multi-stationed net of LF radio towers and receivers...
    Electronic Systems Division (ESD), working with RCA, has
    nearly completed installing an initial, 56-node "thin-line"
    segment for flashing [one-way] emergency messages [launch
    orders] to Strategic Air Command units.

With glasnost and perestroika afoot, and the JCS visiting the U.S.S.R., must we
reduce SAC's standing response time from over to under a minute?  Is anyone
seriously weighing the concomitant risks?

[By the way,] for those who don't know, on May 1 this year I filed a lawsuit
against the Strategic Air Command's chain of command for launching Minuteman
and MX missiles, including the launch crews, alleging that their standing
orders, to launch the missiles immediately upon receipt of cryptologically
valid launch orders, are inherently reckless and dangerous.  In particular, I
allege with particularity the risk of mistaken computer prompts causing the
accidental launch of nuclear missiles.  The suit was endorsed by the board of
Computer Professionals for Social Responsibility.

In a motion to dismiss based on the pleadings, which presumes that all facts
alleged be taken as true, here is Commander In Chief General Chain's
(minion-attorney's) key argument:

   The allegation of "high risk" may affect the amount of
   speculation but only marginally, and it does not move the
   allegation into the realm of injury in fact.  At most,
   plaintiff makes the general assertion that some government
   officials may act in a manner contrary to law.

Strategic weapon software development practices

29 Jun 1989 11:00:41 EST
Several recent postings in this digest have speculated about the
accuracy/quality of strategic weapons guidance systems.  Apropos of that, I
offer the following excerpts from an article by Stan Shebs, about working on
cruise missile guidance, that appeared in the CPSR/Seattle Newsletter, June

      from ``My Life in a Megadeath Corporation'' by Stan Shebs

Upon graduation from Texas A&M in 1981, I accepted an offer from Boeing
Aerospace in Seattle ... I was re-assigned to work on the cruise missile. 

I went off to Seattle (Kent actually) and started work. This involved
fingerprinting (a surprise) and the long long form to fill out (for a
clearance, even though I never did anything classified).  Next thing was to
jump in on the work, which was to help finish up and deliver "mission planning"
software - a giant mass of undocumented Fortran intended to run on IBM
mainframes at SAC headquarters in Nebraska.  My first task was to finish
testing the FORMVO module, which had to do with figuring out which VOs
(Vertical Obstructions - like trees and telephone poles) were likely to be in
the path of the missile as it flew along. 

If this is confusing, well, it was to me too.  After about a month, I went to
the official orientation and indoctrination, which lasted about two days.
Boeing was building the Air-Launched Cruise Missile (ALCM), essentially a robot
airplane about 6 meters long and 1/2 in diameter, powered by a jet engine of
just the right size for a go-cart, and carrying a 400-kiloton fusion bomb.  The
idea was that B-52 bombers would fly up to the edge of the USSR, launch the
ALCMs, and fly away again.  The missiles would then fly about 2000 km or so,
low to the ground and beneath radars all the way, to detonate at some target.
... Now the onboard software was basically done; where I came in was to help
with the software that figures out if an intended route was actually doable.
The onboard computer has only a very limited capacity, so you need a lot of
"mission planning" software to decide where to turn, how high to fly, when to
look at the ground to see if you're on course, and so forth.  Another piece of
software then makes up the cute little cassette tapes that the bomber crew
loads into the missile before launching it.  It's tricky, because how tight a
turn the missile can make depends on how much fuel it's used already, it could
run into telephone wires if it's flying too low at the wrong moment, the little
maps that it uses for navigation mustn't be too far apart, and so forth. 

The difficulty of all this apparently didn't occur to anybody until after
the missile was working, so the mission planning software got hacked out in
a real hurry, the people that did it departed for greener pastures, and
then the rest of us were picking up the pieces and trying to turn all this
into a reasonably reliable 40,000 lines of Fortran.  The day-to-day work
was like regular software stuff; debugging a program that took map data
from tapes and put them into VSAM files, writing the "Program Design" for
an already-written program (is that stupid or what), figuring out how to
compute the intersection of two polygons in space.  We supposedly had a
"model" software engineering methodology; what I remember most clearly is
that half the work was done on one flavor of IBM OS, and the other half
done on a different flavor, and file transfer between the two was tricky
and time-consuming.

The fragility of something like the cruise missile and its software is
something I've spent a lot of time wondering about, and don't really have any
idea.  The nuclear safety aspect seemed pretty good - there was at least some
effort to get accurate estimates of the chance of going off at the wrong time
(was 1 in 2^64 chance, I think).  Navigation is considerably more problematic.
Like most missiles, ALCM relies on inertial navigation, but the error
accumulation over 2000 km is immense, and you had to be sure to have navigation
maps spaced so there would be a reasonably good chance they would be found.
("3-sigma" was the standard - position assumed to be a normal distribution.)
Now that I think about it, the 3-sigma test (98% chance) would have to be
multiplied for each map, and there might be 10-20 of them, meaning as much as
40% of missiles might not make it through all the maps...  Calculations on a
sphere were a perennial problem - there was a standard joke that the safest
place in the world during a nuclear exchange was the North Pole, because the
lat/long singularity makes it impossible to target, and the worst place was 0
lat, 0 long, because the software would divide by 0 or overflow or something
while passing over the North Pole and reset to all 0s...  The precision and
formality of the software was very low, but it was exhaustively tested over and
over and over again.  I suppose the greatest risk of failure derives from
things that weren't anticipated during testing, such as a Siberian snowdrift
changing the topography on a navigation map...

(Regarding) statistics on software quality, the closest thing we had was maybe
a count of problem reports (hundreds, but each report ranged from one-liners to
one-monthers in terms of effort required).  ... the humongous requirements
document that was our bible for how the program was supposed to work (was)
alternately entertaining and horrifying. Nothing classified, we had the odd
situation that the *data* was classified, but the *program* wasn't even rated
"confidential"! (Theory was that the Russians were supposed to get a copy,
which would set them back ten years... :-) ) ...

Rotting Landsat data

Jonathan Patrick Leech, Apple Integrated Systems <leech@Apple.COM>
29 Jun 89 22:14:04 GMT
    From the June 16 _Science_ article "Early Data: Losing Our Memory?":

    "Allen Watkins, director of the USGS center in Sioux Falls, SD,
    where Landsat tapes are kept, says, "90% of the data collected
    before 1979 are now inaccessible." The reason: the data tapes were
    recorded on old Xerox computers which can no longer be operated.
    In addition, the satellite location and timing data were recorded
    on a kind of video tape deck that no longer exists. Tape renewal
    is another problem that looms in the future. Magnetic images
    "bleed" through the layers as time passes, and tapes must be
    recopied at least once every 10 years to make them usable. Watkins
    says the task is already formidable, and wonders what will happen
    when the Earth Observing System begins sending back the equivalent
    of an entire Landsat archive every 2 weeks."

Please report problems with the web pages to the maintainer