BASIC RESEARCH REPORT

November 1998, Number 98.6

The Bug in the Bomb:

The Impact of the Year 2000 Problem on
Nuclear Weapons

By Michael Kraig

Table of Contents

Acronyms and Abbreviations

Preface

Executive Summary

Introduction

Definition of the Problem: Y2K and the Department of Defense

Y2K and Nuclear Weapons: Systems within Systems within Systems

The DoD’s Program of Action: Methods for Correcting Potential Bugs

The Original Management and Organizational Structure of the Y2K Program

The Current State of Y2K Programs Inside the Pentagon

Russian-American Interactions on Y2K and Nuclear Arsenals

Conclusion

Endnotes

Sources and Suggested Readings

Y2K World Wide Web Sites

Acronyms and Abbreviations

Preface

BASIC is proud to present this probing and disquieting report on the prospects that computer software date fields and embedded systems may interpret the year "2000" as "1900" with the consequent malfunctioning of defense security systems. If such computer glitches may adversely affect defense readiness, the resulting errors, though serious, can be safely corrected over time. If the affected software involves nuclear weapons control systems, however, the consequences could be calamitous.

As an urgent matter, therefore, the United States and Russia, who possess the vast bulk of nuclear weaponry, should convene a joint team of civilian and military experts to assess the gravity of the risk and the manner in which potential disaster can be avoided.

In some instances, the only prudent course may be to de-alert or even de-activate those nuclear missile systems where date-related malfunctioning in associated command, control, and communications systems poses even a remote possibility of accidental launch. The information derived from this expert review should of course be shared with the public and other nuclear powers – Britain, France, and China – who may be faced with a smaller but still significant problem. Not only will this approach provide Y2K remediation, but it will accomplish what should be done in any case to advance the course of nuclear arms control.

Ambassador Paul C. Warnke
President, US Council
British American Security Information Council

"Probably one out of five days I wake up in a cold sweat thinking [Y2K] is much bigger than we think, and then the other four days I think maybe we really are on top of it. Everything is so interconnected, it’s very hard to know with any precision that we’ve got it fixed."

Deputy Secretary of Defense John Hamre
19 October 1998¹ 

 

"We may not be able to find all the computer and network interfaces that have date dependent processing. We have to expect that we will not get everything fixed and there will certainly be the ‘known unknowns’ – known problems with unknown solutions – and a few ‘unknown unknowns.’"

Lt. General William Donahue
Air Force Communications and Information Center Commander
13 October 1998² 

Executive Summary
This report is a first step towards assessing the impact of the Year 2000 computer date change –otherwise known as the "Y2K problem" or the "Millennium Bug" – on both nuclear weapons arsenals and national security structures. Although primary emphasis is placed on the recent experiences of the United States Department of Defense, a comprehensive analysis of the issue will require examination of the entire nuclear weapons cycle for all nuclear powers, from production of weapons to deployment to dismantlement.

Initial research findings by a number of different agencies and teams of experts, both inside and outside the Department of Defense (DoD), have resulted in no confidence that the Pentagon's present program will meet the Year 2000 challenge. The DoD weapons and communication systems utilize millions of "embedded systems" in the form of microchips and microprocessors. These semi-independent systems- within-systems are hard to locate and difficult to fix, and the ultimate effects of multiple breakdowns in embedded systems are poorly understood. There is no general theory or methodology for assessing the "Y2K compliance" of software, chips, or microprocessors on a mass basis; suspected systems must be inspected line-by-line and chip-by-chip.

Moreover, 31 December 1999 and 1 January 2000 are not the only dates that present problems; many such "bugs" exist for dates that occur prior to, or months and years later than, the year 2000. Finally, even if a particular system is made completely free of Y2K computing errors, interfaces or connections to other "infected" systems could introduce bad data, causing the "fixed" system to produce erroneous information or even shut down completely. Because of these subtle, yet insidious inter-system effects, Deputy Secretary of Defense John Hamre has admitted that "Everything is so interconnected, it’s very hard to know with any precision that we’ve got it fixed."

Nuclear systems are not exempt from Y2K-related problems. A recent Memorandum from Secretary of Defense William Cohen mandated that US Strategic Command (STRATCOM) give a detailed report on the status of Y2K repairs for all nuclear command and control systems. Although it was produced in mid-September 1998 as an unclassified document, it has not been released to the public. Congressional access has also been extremely limited. This reluctance to provide information raises deep concerns about the ability of STRATCOM and the armed services to fix both the weapons themselves and the all-important support systems such as launch platforms, communications networks, logistics channels, and safety systems. According to one Congressional staff person, "These decisions constitute a concerted effort to censor information on Y2K progress. If there is anything bad, the immediate response is to cover it up, rather than taking care of the problem."

In fact, there are severe and recurring problems across the entire DoD Y2K remediation program, including ill-defined concepts and operating procedures, ad-hoc funding and imprecise estimates for final costs, lax management, insufficient standards for declaring systems "Y2K compliant," insufficient contingency planning in case of Y2K-related failures, and poor inter-departmental communications. There is no credible and concise evidence that all mission-critical systems will be repaired and tested on time. Moreover, February 1998 saw a mass exodus of qualified civilian managers from the Office of the Assistant Secretary of Defense for Command, Control, Communications, and Intelligence (OASD/C3I), the branch of the Office of the Secretary of Defense responsible for monitoring and guiding Y2K remediation efforts. This exodus included many experts on Information Technology (IT), leaving the entire program rudderless for several months. It is still not clear that recent organizational restructuring and new civilian appointments have adequately addressed the need for rational and consistent central management. According to one Congressional staff person who has been monitoring the DoD’s progress, "The ongoing response to the Y2K bug is symptomatic of catastrophic mismanagement throughout the DoD."

This state of affairs has been exacerbated by a lack of Congressional attention to Y2K-related defense matters. The majority of Y2K hearings and bills have been initiated by non-defense-related domestic lobbies. Only a very few Congressional members are tracking nuclear systems.

The dearth of external oversight of Y2K and defense systems extends to Congressional support agencies as well: the Congressional Research Service (CRS) is only monitoring the problem at the broadest levels; the Congressional Budget Office (CBO) believes that the issue is outside its mandate; and the General Accounting Office (GAO) has thus far reported only on general DoD procedures and management, rather than on specific nuclear systems. The GAO will not consider the results for individual systems until the DoD completes all "verification" activities by mid- to late-1999. This leaves little time for the formulation of alternative international policies to avert a crisis should major malfunctions occur in the nuclear arsenal and related systems.

The Pentagon has already announced the existence of "high risk" systems that may not be repaired or tested in time, and for which repairs may ultimately be impossible. Problems may not be eliminated by 2000 no matter what resources and money are devoted to them.

Finally, Russia’s decaying nuclear systems are also in danger of Y2K failures, and US decision-makers are currently planning to share early-warning information (and even exchange key military and civilian personnel) to guard against a purposeful launch based on faulty surveillance data. However, information sharing assumes that at least US systems will be fixed and verified on time.

The dangers of a Y2K meltdown, even if restricted to a few key systems, are intensified by the Russian and American policy of "launch on warning." This policy calls for nuclear retaliation after detection of another country’s launch of missiles, but before the impact of the attacker's warheads. If Y2K breakdowns produce inaccurate early-warning data, or if communications and command channels are compromised, the combination of hair-trigger force postures and Y2K failures could be disastrous.

For all of these reasons, there should be a "safety first" approach to Y2K and nuclear arsenals. All the nuclear weapons states should stand-down nuclear operations. This approach should include taking nuclear weapons off alert status or de-coupling nuclear warheads from delivery vehicles. Whatever option is chosen, policymakers must be given as much time and latitude as possible for making important decisions in an environment beset with Y2K difficulties and uncertainties. By verifiably taking forces off alert on a multinational basis, leaders could be highly confident that there is no danger of a preemptive attack, thereby lessening the importance of reliance on C3I systems that might succumb to Y2K failures. The Clinton Administration and Congress must abandon the current "wait and see" approach, which relies on the Pentagon to complete its Y2K process before evaluating options. Because there is no guarantee of success, US decision-makers must take steps now to preclude disaster should the Pentagon fail.

Serious attention is also warranted for all nuclear activities under the Department of Energy (DoE), including warhead testing and modernization facilities at Sandia National Laboratories and other sites. The Y2K problem can affect every aspect of the DoE’s "cradle to grave" nuclear program. More information is also needed about the Y2K-related activities of other nuclear-weapons states. The Clinton Administration should work with other countries to improve Y2K compatibility and to provide information on overall progress.

Introduction
The ramifications of the change of century for computer software, firmware, hardware, and information technology systems has been widely debated at a general level. The debates have involved specialists in fields as diverse as computer engineering, economics, finance, and business management. However, few consistent or definitive conclusions have been reached. In general, one can identify two highly polarized schools of thought on the subject. On the negative side, the "pessimists" believe that many worst-case scenarios are eminently plausible: airplanes falling out of the sky; sewage treatment and water purification plants failing across the world; electric power grids going down; cars and other vehicles that rely on computer chips stopping dead in their tracks; and electronic banking systems shutting down.

In contrast, the "optimists" are of the opinion that the Y2K problem is the product of exaggerated (and even irresponsible) media hype. According to this viewpoint, those business consultants and computer specialists producing books on the subject are exploiting the technical vagaries of the date change for profit and notoriety. Optimists argue that specialists and the general public have not given enough credit to the common engineering practice of building fail-safe devices for complex systems. The optimists believe that any systems engineer with an advanced degree (computer or otherwise) has been trained to prepare for the possibility of major systems failures in the event of natural or unnatural disasters. This leads to the assumption that most programs and devices will "fail gracefully," meaning that systems will shut down with little harm or injury to the people relying on them. For instance, elevators are equipped with brakes that automatically engage when electronic programs crash. Temporary inhabitants of the elevator will simply have to wait until a rescue team arrives to let them out.

On the issue of nuclear weapons, optimists and pessimists again diverge. The prototypical "worst case" scenario – a nuclear weapon exploding or a missile launching directly because of Y2K-related failures – is not plausible. The safety and security systems inside nuclear warheads and missiles, such as Permissive Action Links (PALS) and Environmental Sensing Devices (ESDs), will prohibit either outcome. However, there are realistic worst case scenarios.

The optimists’ worst-case scenario is that some weapons and systems will simply freeze up, particularly in Russia. The US and Russia have taken some steps to address the greatest concerns, about Russian early warning systems. (See "Russian-American Interactions on Y2K and Nuclear Arsenals", p.24.)

Pessimists' worst case scenarios fall into two broad categories. First, what happens if both US and Russian early warning systems shut down or malfunction, at least in part? With both countries maintaining a high-alert, "launch on warning" posture, highly unpredictable Y2K-related failures could lead to the nightmare scenario of one country intentionally launching an attack based on faulty early warning data. Second, what kinds of failures are possible for the numerous support systems around nuclear weapons? Is there a chance of a "fire in the cockpit," which could lead to a non-nuclear detonation of the explosives surrounding the weapon's plutonium or uranium? If so, radioactive material could disperse and contaminate wide swaths of territory.

In the absence of more detailed knowledge, neither the optimists’ nor the pessimists’ philosophies can be fully embraced as the correct assessment of Y2K outcomes. To resolve this dispute, and assess its importance to national and international security, two sequential questions must be answered. First, what is the nature of the Y2K problem? Second, how successful is the Department of Defense's (DoD) program to solve it? This report will describe the nature of the Y2K bug for DoD systems, summarize available facts on the Pentagon’s projects, evaluate emerging evidence of costs and the management practices of the DoD, and recommend several policy options for nuclear arsenals that are not currently being considered by the DoD.

Definition of the Problem:  Y2K and the Department of Defense
The "Millennium Bug" is usually understood as being connected to the use of only two digits to represent the century and year in software date fields (mm/dd/yy), with the implication that a change in the current century would be interpreted incorrectly as "1900" rather than "2000." In turn, this dynamic could lead to the partial or total malfunction of all programs utilizing dates.

However, the nature of the problem is even more complex and less amenable to easy solutions than it would initially appear. First, much of the affected software is based on virtually extinct programming languages, so that locating the necessary expertise is often a costly and time-consuming enterprise.³ Second, in some instances, the source code that provides the base for future alterations has been lost, with only the "compiled" program as a base. In these cases, amendments to the existing code may be impossible. Third, both processors and chips can be affected. Many computer systems (which can span entire organizations or operations) rely on subsystems, which in turn may be difficult to locate and isolate for repair. In these cases, entire functions are effectively "blackboxed" into smaller units, so that rather than one large program there are multiple interdependent systems, each of which may have its own unique reactions to the century change. More importantly, many such subsystems depend on "firmware" or "embedded chips," in which the programming code has been hardwired into the actual computer chips. Even if firmware is not a major problem, the chips themselves may contain inherent date dependencies, whether or not more complex code is embedded in them. Finally, even in those cases where computers and operating systems do not depend on date fields for their own internal operations, most systems utilize time synchronization to "talk" to one another externally.⁴

Due to the importance of embedded chips, much of the DoD’s emphasis has been on "COTS," or "Commercial-Off-the-Shelf" chips and processors. It is prohibitively expensive to ask private contractors to create chips from scratch (some estimates claim $100,000 for each new design). Therefore, many DoD weapons and C3I systems have traditionally relied on cheap and readily available mass-produced chips. However, because of their generic nature, many of these chips are suspected of having time functions ingrained in their operation. This might be true even in those cases where the operation of the larger (sub)system does not utilize date fields in everyday operations. Thus, the absence of direct date functions in a communications network or weapons system is not necessarily an accurate indicator of future success in weathering the change to the year 2000.

In general, computer scientists estimate that between two and five percent of all chips in existence will experience these problems. Although this low failure rate would seem to indicate limited Y2K effects, five points should be kept in mind:

1) the malfunction of embedded chips could lead to the partial or total failure of a subsystem, which could then lead to partial or total failure of the larger system, which could then debilitate all other external systems with which it "interfaces;"

2) no one knows which chips will fall into this two to five percent figure;

3) even if the original manufacturer can be identified (which may not be possible in many instances), that particular firm may be out of business or otherwise defunct;

4) many (sub)systems have been built over successive periods (and perhaps even in separate locations), with the result that many distinct sources of chips and processors have been utilized over the years for each single system in question; and

5) that two to five percent figure may include some core systems whose failure could lead to human fatalities or casualties.⁵

In short, to be considered invulnerable, the DoD has to test nearly every chip and every line of computer code for systems that depend on dates for operations. For those military items considered "critical to core mission requirements," every chip may have to undergo examination just to be certain of force readiness, even when the larger system in question does not overtly utilize dates.

Deputy Secretary of Defense John Hamre has emphasized these points in an important briefing of the Senate Armed Services Committee on 4 June 1998. In his remarks to the Senate, Hamre stated that:

Worldwide, an estimated 15 billion microchips –most of which contain timing devices – are embedded in appliances and machines ranging from clock radios to ATMs. . . .The failure of an embedded microchip in a discrete, localized computer or machine, such as a wristwatch or the air-conditioning system in a building, can be merely inconvenient. However, failure of a microchip in a critical, large, or dangerous piece of machinery –loss of air pressure in an F-15 or a submerged submarine – can be devastating and even life-threatening.⁶

The latest DoD Quarterly Y2K Progress Report has also stressed this issue, noting that:

Given the number of military bases, weapons systems and weapons systems platforms owned and operated by the Department of Defense, the number of embedded systems in infrastructure appears to be under-reported. DoD’s concerns include incomplete inventory data, lack of information from commercial suppliers, and the scarcity of specialized tools for the identification and replacement or remediation of embedded chips. Another pervasive issue to all users of commercial, off-the-shelf (COTS) computer microchips are that the same equipment – elevators, for example – produced by the same manufacturer, may contain chip sets from different suppliers, and thus require different means of remediation. Clearly COTS embedded systems offer complex Y2K challenges across the board.⁷

Finally, the Chairman for President Clinton’s Council on Year 2000 Conversion, John Koskinen, has remarked that "The Department of Defense has some of the largest challenges in the government. They really have a corner on the market on the microprocessors or embedded chips. All of those smart weapons are smart because they have embedded chips in them."⁸

Costs have thus far been in the low billions for the repair and testing of these embedded military systems. However, there exists a real potential for escalating expenses as embedded components are identified and assessed for Y2K vulnerabilities. In a briefing to the House of Representatives in March 1997, the DoD admitted that "The solutions to the year 2000 problem may require replacement of the old chips with new chips. New production lines for new, year 2000-compliant chips may be required. This could take significant time and be very costly."⁹

In addition to the prevalence of embedded subsystems and the inherent difficulties of finding and fixing them, traditional software code still remains a significant source of trouble. Dates may be used in subtle, indirect fashions that are not immediately apparent. For instance, the Defense Information Systems Agency (DISA), a primary overseer and creator of Information Technology (IT) networks, databases, and related information programs for the DoD, has included the following "indirect" methods of date usage in its Y2K system compliance checklist:

a. Dates embedded as parts of other fields

b. Dates used as part of a sort key

c. Usage of values in date fields for special purposes that are not dates (e.g. using 9999 or 99 to mean ‘never expire’)

d. Date dependent activation/deactivation of: passwords, accounts, commercial licenses

e. Date representation in the operating system’s file system (creation dates and modification dates of files and directories)

f. Date dependent audit information

g. Date dependencies in encryption/decryption algorithms

h. Date dependent random number generators

i. Date dependencies in firmware [as noted above]

j. Dates within back-up, archived, reference, and transaction history files, maintenance logs, etc.¹⁰

Adding to this complexity is the fact that 31 December 1999 and 1 January 2000 are not the only dates in question. The misinterpretation of the century change, even if not immediately, may make itself felt in later months or years due to other "roll overs" and calender anomalies. For instance, one report has summarized the conclusions of the second version of the DoD "Year 2000 Management Plan" as such:

The year 2000 also sports a leap year, so Feb.. 2, 2000 through March 1, 2000, should also be checked, as should 2/29/01, which should be rejected as it is not a leap year. . . [other dates include] Oct. 10, 2000, the first eight character date using a two digit month; Dec. 31, 2000, the 366th day of the year; Aug. 22, 1999, the first end of an epoch for GPS [Global Positioning System]; . . .‘overflow’ problems in older Unix systems; and March 1, 2101, the ‘terminal date’ used to encompass all established rules for calculation of dates and calendar events.¹¹

The Global Positioning System (GPS) is but one example of many systems that rely on relative time, or unique internal clocks that are separate from "absolute" calendar or Julian time. In these cases, the "zero point" is not 1900 but the initial start-up date of the system, which may be as recent as the 1970s. Many such systems will experience Y2K-like difficulties when their internal calendars "roll over," with similar effects to systems depending on absolute time. However, this implies that such systems may go down earlier than 2000 (as with GPS on 22 August 1999), or they may fail months or years later than the change of century. Unfortunately, this also applies to embedded chips, not all of which base their cycles on the calendar date.

In summary, there are several difficulties that the DoD shares with other organizations in the private sector, but which are somewhat unique to the Pentagon in their prevalence and magnitude. These problems are not amenable to easy scientific or managerial manipulation. First, the US armed forces constitute an immense organization with numerous computer-based ‘interfaces’ between agencies and services, all of which must be identified and assessed for Y2K vulnerabilities. Even for those systems that have been independently verified as being fully "compliant," connections or interfaces with "non-compliant" systems can introduce bad data into its operations and possibly even induce a total malfunction. The potential for "infection" by outside systems means that remediation programs for Y2K require a time and labor intensive process of inter-system technical validation. Second, the Pentagon’s systems utilize immense amounts of software that are often programmed in largely defunct languages. In many cases, the original "source code" containing the programmer’s technical remarks are missing. Third, there is a shortage of skilled labor for dealing with these out-of-date programming languages, and given the vast number of embedded chips and processors, there is also a dearth of skilled help for addressing firmware and other similar embedded systems. Fourth, there is no ‘magical fix’ that can be applied on a generic basis across systems; suspected programs must be examined line by line, and suspected chips and processors must be individually studied. Fifth, a true test of "mission level" interoperability – what the Pentagon terms "operational evaluation" – requires extensive combined exercises involving all affected systems, including communications, weapons, command and control, and logistics. At this point, it is not clear that such exercises can be organized in time for all missions, and in some cases it is even doubtful that the necessary tests are possible from a logistical standpoint. Sixth, many private vendors (chip suppliers) have gone out of business or have merged with other companies, rendering impossible any a priori judgements on compliance based upon corporate production data. Finally, as mentioned above, the armed services have traditionally cut costs by relying on ‘Commercial-off-the-shelf" chips (COTS) that are generic and may have time functions ingrained in their operation.

These negative constraints have been produced by past organizational and technological decisions by Congress and the military over the past 40 years. Most of those acquisition and deployment decisions were made on a piecemeal, incremental basis, service-by-service and system-by-system, with little thought to their ultimate implications for future years or decades. According to one Congressional source close to the DoD’s ongoing Y2K program, "There has been little planning from an overall systems standpoint in past acquisition programs, and there is still little thought on where we’re going with new [computer] systems. Most existing operational planning documents are simply junk."¹² The result is a vast web of poorly understood connections between organizational units and technically complex computer systems, all of which have some degree of interdependence in their mission-level operations. It is this inherent interdependence that transforms the Y2K computer problem into a full-fledged organizational and budgetary dilemma for the military.

"The Bug in the Bomb" continued