RISKS-LIST: RISKS-FORUM Digest Thursday 29 June 1989 Volume 8 : Issue 86 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: SPADOC Modernization Effort (Chris McDonald) Are are nuclear weapons useable? How can one test this? (Dennis L. Mumaugh) NASA tests video system that may lead to windowless cockpits (Karl Lehenbauer) Air Force to upgrade missile launch command computers (Jon Jacky) Missile launch -- upgrades degrade ? (Clifford Johnson) Strategic weapon software development practices (Stan Shebs via Jon Jacky) Rotting Landsat data (Jonathan Patrick Leech) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. * RISKS MOVES SOON TO csl.sri.com. FTPable ARCHIVES WILL REMAIN ON KL.sri.com. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line (otherwise they may be ignored). REQUESTS to RISKS-Request@CSL.SRI.COM. FOR VOL i ISSUE j / ftp KL.sri.com / login anonymous (ANY NONNULL PASSWORD) / get stripe:risks-i.j ... (OR TRY cd stripe: / get risks-i.j ... Volume summaries in (i.j)=(1.46),(2.57),(3.92),(4.97),(5.85),(6.95),(7.99). ---------------------------------------------------------------------- Date: Mon, 26 Jun 89 11:59:53 MDT From: Chris McDonald ASQNC-TWS-RA 678-4176 Subject: SPADOC Modernization Effort 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. ------------------------------ Date: Thu, 22 Jun 89 20:17 CDT From: cuuxb!dlm@att.att.com Subject: Are are nuclear weapons useable? How can one test this? Re: Gary Chapman, RISKS-8.83 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 dlm@cuuxb.att.com ------------------------------ Date: 22 Jun 89 23:16:33 CDT (Thu) From: karl@cs.utexas.edu (Karl Lehenbauer) Subject: NASA tests video system that may lead to windowless cockpits 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 terrifying. 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 retained. ------------------------------ Date: 23 Jun 1989 11:19:12 EST From: JON.JACKY@GAFFER.RAD.WASHINGTON.EDU Subject: Air Force to upgrade missile launch command computers 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. ------------------------------ Date: Fri, 23 Jun 89 14:29:16 PDT From: "Clifford Johnson" Subject: Missile launch -- upgrades degrade ? 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. ------------------------------ Date: 29 Jun 1989 11:00:41 EST From: JON.JACKY@GAFFER.RAD.WASHINGTON.EDU Subject: Strategic weapon software development practices 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 1988: 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... :-) ) ... ------------------------------ Date: 29 Jun 89 22:14:04 GMT From: leech@Apple.COM (Jonathan Patrick Leech, Apple Integrated Systems) Subject: Rotting Landsat data 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." ------------------------------ End of RISKS-FORUM Digest 8.86 ************************