|Volume 19, Number 2||The CPSR Newsletter||Spring 2001|
National Missile Defense: The Trustworthy Software Argument
by William Yurcik
The National Missile Defense (NMD) system being developed by the U.S. revisits many of the technical software engineering arguments surrounding the Strategic Defense Initiative (SDI, or known as "Star Wars" to critics). Unfortunately in the public NMD debate thus far, questions of technical capability have been ignored focusing instead on non-technical factors. While acknowledging non-technical factors are relevant and perhaps predominant in the final decision-making, we feel a special obligation to specifically raise technical software engineering issues in this CPSR forum because the NMD policy-making process needs input from computing professionals who both understand and can communicate these issues. I have included a list of these non-technical factors for completeness.
The stated purpose of NMD is to protect the US from a limited attack by strategic (long-range) ballistic missiles armed with weapons of mass destruction (conventional, nuclear, chemical, biological). The scenarios for such a limited attack of a few to tens of missiles include: (1) an accidental or unauthorized launch from Russia; (2) an accidental, unauthorized, or deliberate attack from China; or (3) a deliberate attack from other countries that have or may acquire long-range missiles (e.g., North Korea, Iraq, Iran). Ballistic missiles are rocket-driven missiles that have three distinct stages: (1) the boost stage from launch within earth's atmosphere to space; (2) the midcourse stage in the vacuum of space; and (3) the terminal stage reentering the earth's atmosphere to the target. Ballistic missiles propulsion occurs only in the boost stage then the missile follows a path according to the laws of physics in the Earth's gravitational field to its target. Thus NMD has only limited capability and is vulnerable to both being "underflown" by short-range missiles and cruise missiles as well as being "overflown" by intelligent ballistic missiles that do not follow the laws of gravity but rather can intelligently maneuver.
The NMD system being developed would use a combination of ground-based radars and satellite-based sensors to detect a missile launch and track the missile and its warhead(s). The ground-based missile interceptors will be layered to engage incoming attacks at different stages in their flight paths to enable a shoot-look-shoot strategy . If one system fails to stop a missile at one stage, other systems may have another chance to shoot it down. Small land-based, aircraft-based, and sea-based interceptors will engage attacks closer to the source at the boost stage. Theater defenses are focused on defense at the terminal stage. Although space-based lasers are still many years away, the intermittent research of the past two decades seems likely to continue.
The NMD software engineering issues revolve around the issue of trustworthy software. The term "trust" in software can have different contexts. The oldest use of the term refers to the DOD "Trusted Computer Systems Evaluation Criteria" (the Orange Book) which defines levels of trust protection (C to A). To address software integrity issues during SDI, the Trusted Software Development Methodology (TDSM) was developed to define trust levels (1-5) based upon 25 trust principles . TSDM has much in common with the Software Engineering Institute (SEI) Capability Maturity Model (CMM) for software development in that rather than being based on product testing it is focused on the software development process. It is generally accepted that reliability cannot be "tested into" a software system but rather planned and developed in parallel with the software system itself. Unfortunately, risks in the software development process have gotten worse since SDI with many examples of complex system software failures .
Even critics now concede that an NMD system is a possible task but the over-riding question is whether the software can confidently be expected to work when it is needed. If the NMD system cannot be trusted then it may actually reduce strategic security since subsequent actions by other nations will be based on prudent assumption of reliability. Factors that inspire human trust in software include: (1) extensive past experience under actual working conditions; (2) ultimate safeguarding of critical operations by human operators; and (3) a fully specified, predictable, and stable environment for design, testing, and actual operation. None of these factors will be present in the final NMD system.
Some may argue that NMD testing is currently taking place. On closer inspection, the tests thus far have not been very meaningful. The tests are actually "hardware-in-the-loop" simulations with unrealistic conditions (reduced closing speeds, lack of credible countermeasures) and very few unknown variables (known launch times, target trajectories, target and decoy signatures) . So far, 2 of 4 NMD tests have failed to intercept, 1 had a successful intercept despite a software failure, and 1 test was completely successful. For perspective, military systems that require destructive testing are rarely tested enough to provide a statistically significant measure of their reliability so this information must be gained from combat experience. Ironically, it is reasonable to assume that NMD will receive little if any combat experience but its development test schedule is being compressed. For perspective, the submarine-launched Polaris missile system (the backbone of US Cold War nuclear deterrence) failed its first 11 tests. On the other hand, the NMD requirement for an interceptor 85% kill probability can be contrasted with the well-maintained B-2 bomber which is capable of performing its mission only about 45% of the time. The Patriot anti-missile system actually had a perfect test record (17 for 17) but in the Gulf War the Iraqi Scud missiles did not fly predictable smooth test trajectories - they broke apart upon reentry and the Patriot success rate estimates vary widely from 70% to below 10% despite military and media hype .
The con-SDI trustworthy software argument first stated by David Parnas in 1985 [1,6] and later echoed by others (including CPSR ) are still valid for NMD . Parnas stated in 1985 that it is not possible to construct SDI software that could confidently be expected to work when needed [1,6]. He makes this argument, independent of software size, based on (1) lack of specifications, (2) lack of realistic testing, and (3) lack of backup system capability given time constraints (no "real-time debugging" is possible). Since 1985, not much has changed to nullify this argument. Software engineering principles are still based on precise specifications for requirements. Although computing power has improved and formal methods have been introduced, testing multi-million line programs is still beyond our current capability. Errors in large software system is still the norm, Peter Neumann has a large archive of examples .
A new trustworthy software argument that was alluded to by Parnas in 1985  has been introduced for NMD. This argument is based on the fallacy that since NMD is a subset of the SDI mission then it is possible to "overengineer" NMD into being trustworthy. "Overengineering" is based on the continuous system concept of tolerance in which small system changes do not result in large changes in output behavior due to overcapacity protection (e.g., extra safety margins for bridge construction). For discrete systems, the concept of tolerance does not hold -- an error of one bit may be as catastrophic as an error of 1000 bits. While new fault tolerant software techniques have been introduced to address software decay and software aging the dilemma is that adding functionality to solve these problems results in software that is even more complex and thus difficult to verify and validate .
Finally, NMD has the unique requirement that it must work perfectly on first use. This is an unprecedented requirement for any system approaching the size and complexity of NMD. Comparable systems include the US Navy's Aegis anti-missile system, Lucent's 5ESS telephone switch software, and the Microsoft Windows operating system. These systems have had decades to find and debug errors and yet all have had, and continue to have, significant failures. In fact, new software upgrades on these proven systems rarely perform reliably despite rigorous testing and simulation. Thus it is indeed likely that NMD will experience a software failure upon first use -- the question is will this software error prove catastrophic to overall intercept functionality.
In conclusion, an NMD system can be built but will its software ever be trusted? The idea of a national shield is a simplistic solution to a complex problem with many factors. Non-technical factors will dominate the final political decisions unless technical factors are introduced into the debate. I urge CPSR members to look closer at the technical software argument I have raised here and get involved in the policy process. There is the dual responsibility to protect against massive loss of human life, terrorist blackmail, and strategic military interests if it can be accomplished and yet the responsibility to prevent dependence upon untrustworthy software that actually decreases national security. The administration's current position is the rapid deployment of an expanded version of NMD regardless of test outcomes.
William Yurcik (firstname.lastname@example.org) is an Assistant Professor within the Department of Applied Computer Science at Illinois State University in Normal Illinois USA. Prior to his academic career, he worked for organizations such as the Naval Research Laboratory, MITRE, NASA, Verizon, and MITRE.
Appendix: Non-Technical Factors in the NMD Debate
© Computer Professionals for Social Responsibility
|[ top ]||Newsletter Index|
Created before October 2004