BASIC RESEARCH REPORT

The Bug in the Bomb:

The Impact of the Year 2000 Problem on
Nuclear Weapons
(Part 2)

Y2K and Nuclear Weapons:
Systems within Systems within Systems

The pervasiveness of Y2K problems applies to nuclear arsenals as well as conventional weaponry. No nuclear power can plausibly declare itself to be immune to Y2K-induced failures in key systems. Simply put, there is no conclusive technical evidence that the Millennium Bug is unique to the United States’ nuclear arsenal and Strategic Command (STRATCOM). In principle, the century change has the potential to undermine force readiness and nuclear safety for France, India, Israel, Pakistan, the Peoples’ Republic of China, Russia, the United Kingdom, and the United States. For instance, a recent report by the Russian "State Communications Committee" and Russian Foreign Ministry stated that possible disruptions could happen in computer systems for Russian defense forces, and that about 51,000 of the more than 96,000 computers in Russia will be susceptible to disruptions at the turn of the century.¹³ Specifically, the report estimated that half of the 50 operating systems and 100 software programs used by Russian government structures are facing serious problems due to the Millennium Bug. Additionally, the British Ministry of Defense (MOD) has been implementing its own extensive Y2K remediation plan since September 1997.

There is a popular misconception that nuclear weapons are somehow simpler or more streamlined in their production and deployment than conventional systems. In reality, the fielding of a capable nuclear arsenal is a complex and enormous task requiring several interdependent steps, each of which in turn depends upon its own network of computer and IT systems. All steps in the design, production, maintenance, testing, deployment, and dismantlement of nuclear weapons must be examined for Y2K compliance. Within each of these separate program areas there exists a multitude of bureaucratic organizations and computer-based technologies, including everything from databases and payroll services to flight testing and launch control.

For instance, starting at the "systems of systems" or macro vantage point, the entire nuclear weapons complex and the sum total of its procedures, software, and hardware can be viewed as one gigantic "system," within which is nested entire organizations such as Sandia National Laboratories in Albuquerque, New Mexico, the Minuteman III (MM III) missile wing in Minot, North Dakota, and the North American Aerospace Defense Command (NORAD) in Colorado. Moving one step lower on the ladder, we can list individual systems within these organizations, such as the launch control facilities for missile or bomber wings, or the testing facilities at Sandia, or entire nuclear weapon and delivery systems such as Trident I-II submarines, B-52 bombers, B-2 bombers, MX/Peacekeeper Intercontinental Ballistic Missiles (ICBMs), and Minuteman III ICBMs. Descending one step lower again, one finds weapons or laboratory "subsystems," such as warheads, missiles, planes, and individual maintenance and testing tools, such as the advanced and newly-acquired IBM computers that will be utilized by the Department of Energy (DoE) for simulating nuclear explosions.

Finally, each of these subsystems can be viewed as an entire system within itself. For instance, missiles can hold numerous reentry vehicles that contain the nuclear warheads, along with components that determine trajectory and environmental conditions. Of particular concern for Y2K are the "Ballistic Reentry Body Programmers" and "Missile Warhead Programmers," which rely on ‘User Input’ functions in regard to mission timing, flight profiles, fuzing options (for arming of the warhead), and "command disables." These devices manage all other warhead subsystems and functions, such as radar, telemetry, Environmental Sensing Devices (ESDs) (which determine the correct environmental conditions for warhead explosion, including trajectory and acceleration), and Permissive Action Links (PALs) (which ensure that only authorized personnel can transport, arm, launch, or dismantle a weapon). The Reentry Body Programmers and Warhead Programmers process data utilizing microprocessors, and it is not clear that these "embedded systems" are free of Y2K errors.¹⁴

For ICBMs, moving down to the level of the smallest "intelligent" subsystem eventually leads to individual components such as the Minuteman III and Peacekeeper "Missile Electronic and Computer Assemblies" that monitor telemetry for "guidance sets." These computer assemblies determine the trajectory and location of the weapons system by utilizing time-based calculations, and these mathematical operations may include the year, month, and day in determining their final solution.¹⁵

Also pertinent are embedded chips that keep track of missile maintenance schedules. Most missiles have subsystems designed to record information about the monthly or yearly servicing of various components, and these chips can block military operations if an unacceptable amount of time has passed since the last maintenance check. Robin Guenier, former-Executive Director of the UK government’s "Taskforce 2000," has admitted that both American and UK military officials are worried about the Y2K vulnerabilities of these chips. It is possible that the interpretation of "00" as "1900" will trick the embedded system into thinking that the last maintenance was almost a century in the past, thereby rendering the missile inoperable.¹⁶

For the purpose of assessing the effects of Y2K, one should also look at the level of specific missions. This includes multiple and diverse systems performing the entire range of operational tasks. As mentioned above, the DoD has the eventual goal of mission-level testing to verify the seamless integrated performance of diverse military systems under real-time conditions. It is unclear, however, when such tests will be performed on nuclear systems.

It would also be worthwhile to assess groupings of support programs for each individual system. For instance, under the purview of the DoD, the DoE is conducting several non-Y2K-related programs to modernize, re-fit, and maintain nuclear warheads and their complex array of sub-components. Alterations and modifications are underway on almost all warhead types, involving the entire range of DoE installations. For example, there are currently 384 W-88 warheads deployed on Trident II (D-5) missiles. Several W-88s in the reserve stockpile are being utilized in hydrodynamic tests and stockpile surveillance testing, with limited re-manufacturing of "pits" being scheduled at Los Alamos in FY2001. In addition, the MX/Peacekeeper missile relies on W87 warheads, of which 500 are currently deployed and 25 are in reserve. The W87 is slated for a Life Extension Program to add enhancements for structural integrity, including a series of annual hydrodynamic tests, various laboratory tests, standard stockpile-surveillance tests, and ground-based "Retrofit Evaluation" tests for eventual placement on the MM III.

In a similar vein, various components or designs are also being modified and improved for warheads used on B-52H bombers (the B84), Air-Launched and Advanced Cruise Missiles on the B-52 bomber (W80-1/ALCM and W80-1/ACM), Submarine-Launched Cruise Missiles (W80-0/SLCM), Minuteman III missiles (W78 and W62), the B61-7 and B61-11 gravity bombs for strategic and tactical delivery vehicles, and the B61-4/5/10 gravity bombs for the F-15E, F-16, and F-117 delivery vehicles.¹⁷ This multifaceted and interdependent network of testing, re-manufacturing, retrofitting, and storage relies on information systems and other computer programs that are potentially vulnerable to the Millennium Bug. A similar grouping of support programs can probably be produced for almost every major weapons, communications, or logistics system under the Pentagon. This demonstrates the scope of Y2K’s effects on national security.

As a final example, consider the inherent complexity of the international network of Command, Control, Communications, and Intelligence systems (C3I). The United States’ ability to monitor Russia's daily nuclear activities, detect missile launches at sea or on land, observe invasion of airspace by strategic bombers, and track the flight and delivery of warheads is based upon a highly interdependent conglomeration of radar arrays, satellites, communications networks, and data processing stations.¹⁸

For instance, the TRW-built Defense Support Program (DSP) satellites have been the space-based backbone of NORAD’s Tactical Warning and Attack Assessment system since the 1970s, allowing immediate detection of missile launch. These space-borne sensors depend on receivers and computer networks on the ground in much the same way as the more well-known network of Global Positioning System (GPS) satellites. Information transmitted by these satellites cannot be processed, integrated, and relayed to the relevant personnel without functioning computer systems at both ends. The prevalence of Y2K problems in the Navy’s receivers and processing systems for GPS (see "The Current State of Y2K Programs Inside the Pentagon" on p. 20) raises serious questions about DSP early-warning satellite systems. Similar questions can also be asked about data processing and reception stations that support the Ballistic Missile Early Warning System ground-based radars (BMEWS) in the United Kingdom and Greenland, the radar lines in Alaska and elsewhere, the Navy’s Precision Acquisition of Vehicle Entry-Phased Array Warning System (PAVE PAWS) arrays in Cape Cod, the newly-developed Milstar communications system (comprising satellites and mobile ground terminals), and all communications systems under the Minimum Essential Emergency Communications Network (MEECN) and the Ground-wave Emergency Network (GWEN).

In an article on Y2K and its possible effects on nuclear systems, especially C3I, nuclear expert John Pike of the Federation of American Scientists has noted that:

In principle, the STRATCOM and USSPACECOM operating environments, as well as those of supporting intelligence activities, represent discrete highly-visible mission-critical implementations which are obvious candidates for robust Y2K compliance. In practice, this strategic nuclear warfighting infrastructure is a vast system-of-systems that constitutes the single most complex automated information system currently in existence. . .¹⁹

According to Pike, strategic bombers and other systems are now dependent on and tied-into the Global Command and Control System (GCCS), a recent policy initiative that may complicate Y2K remediation efforts even as it allows simpler coordination of different services’ weapons and warfighting plans.

This technical and organizational complexity is exacerbated by the "launch on warning" force posture maintained by the US and Russia. This policy requires that nuclear weapons be launched after the first indication of an attack but before the impact of enemy warheads on US (or Russian) territory. The window for action under this posture is extremely brief: 25-30 minutes for strategic ICBMs and roughly 15 minutes or less for forward-deployed submarine weapons (SLBMs). The US posture is driven by STRATCOM's requirement for a response to a Cold War-type "massive attack" scenario, and by policies of first use and flexible response. In various scenarios, each of these policies can require the preemption of enemy nuclear weapons with highly accurate counterforce nuclear strikes. Depending on the option selected from the Single Integrated Operational Plan (SIOP), US nuclear weapons might be expected to take out hundreds of industrial, conventional military, and nuclear targets. Russia has recently adopted the same operational stance, although the declining condition of its arsenal sharply limits its capabilities.

At present, the US guards against human and technical C3I errors by requiring multiple sources of verification for a suspected nuclear attack, and by making communications systems highly redundant. Judgements on the likelihood of an attack in progress require positive data from different organizations and technologies, including at least one infrared satellite (verified by receiving station crews in Australia, Colorado, or Europe, in addition to the commander of NORAD), ground crews for at least one radar array (such as BMEWS or PAVE PAWS), and positive ratings from intelligence officers monitoring political and military events in the days running up to the potential attack. This covers the "intelligence" or surveillance side of C3I. In regard to communications, entire systems exist for each leg of the nuclear Triad, and none of the armed services depends on only one system for the sending and receiving of information. Finally, in regard to command and control, the pre-delegation of launch authority allows the US to maintain command in the event of C3I "decapitations" in a surprise nuclear attack. If, for instance, the central political authorities and Joint Chiefs were to be taken out in a nuclear strike, lower military officials with prior authorization can give a targeting plan (selected from the extant SIOP), a coordinating reference time, authorization for launch, and unlock codes for PALs.²⁰

Despite these redundancies, the breakdown of even a few components in the C3I network could cause partial early warning blackouts that would severely truncate the decision time available to political leaders and military officials. For instance, the failure of some or all of the ground receivers and data processing stations for the Defense Support Program (DSP) satellites could cause an inability to detect missile launch at the source, in which case the first signals of an attack would be provided by ground-based radar networks such as BMEWS and PAVE PAWS.²¹ This late detection would cut decision times by five to ten minutes. As all data retrieval, processing, analysis, and interpretation are to be concluded by NORAD in the first 10 minutes of an incoming nuclear strike, (to give political and military leaders at least 10-15 minutes to consider and disseminate launch orders), any delay could, theoretically, be disastrous.²²

Alternatively, infrared satellites might continue to operate while one or more radar fields shut down in response to Y2K errors. If a missile attack occurred in the corridor covered by a BMEWS radar array that failed due to Y2K problems, for example, officials would be hard-pressed to verify the initial launch evidence given by DSP satellites. Data sources would then include only the first indications of attack by satellite, prior intelligence indications of preparatory military maneuvers, and the explosion of one or more warheads on US territory. This would represent a seriously unstable and potentially catastrophic development under a "launch on warning" regime, for several reasons. First, pre-launch intelligence is notoriously faulty and deficient. Many Soviet alert periods were missed entirely by the CIA in the 1960s-90s, and Russian wargames sometimes generated fears of real attack when no immediate threat existed. Second, DSP satellites often malfunction or temporarily black out for non-Y2K-related reasons, such as unusual solar activity. Y2K-related failures exacerbate this problem. Third, erroneous DSP satellite data already frequently lead to the US military raising its alert status. In hundreds of cases, the director of NORAD has called "missile event conferences" involving military commanders, only to be dropped after further evidence from radar arrays or strategic intelligence showed the DSP satellite data to be false or misleading.²³

Finally, even if all pieces of the C3I puzzle operate according to technical and organizational specifications, there is still surprisingly little that can be said about the nature and scope of a nuclear attack. In spite of this vast network of sophisticated hardware and software, C3I expert Bruce Blair has concluded that, during the Cold War, launch on warning:

compelled authorities to decide whether to retaliate and against which targets within a very short time and without a clear picture of the provocation. NORAD could not have accurately determined the number of incoming nuclear warheads, their specific targets, the objectives of the attack, the yield and height of bursts, or the resultant civil and military damage. Nor could NORAD, or anyone else, have distinguished a deliberate attack from an unauthorized one.²⁴

The potential seriousness of Y2K-related failures in this vast ‘system of systems’ was demonstrated by a 1993 simulated test by NORAD personnel. Out of curiosity, the technicians rolled the dates up to 1 January 2000. The result: total system blackout.²⁵

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

The guidelines governing Y2K efforts can be described in terms of a five-phase classification system established by the Assistant Secretary of Defense for C3I, Emmett Paige Jr., in the "DoD Year 2000 Management Plan" initially released in April 1997. According to the OASD (C3I), the entire process of remediation was to follow five clearly demarcated management phases, all of which are still in use. They are:

(I) Awareness of the Problem (i.e., education of all officers, private contractors, and in-house technicians on the seriousness and nature of the Y2K bug).

(II) Assessment of Systems. All IT networks, integrated computer systems, individual weapons systems, sub-system components, and systems’ software must be assessed, all the way down to the level of computer chips and individual lines of code. Any and all such systems must be assessed for "Y2K compliance," i.e., their ability to withstand the change of critical dates before, during, and after the year 2000. Also during this phase, each service is to identify its "mission-critical" systems, defined as those systems "whose degradation would cause a loss of core capability."²⁶

(III) Renovation. The identified problems are to be independently fixed at the lowest level of physical or operational existence, that is, at the level of an isolated weapons system, component, etc. Only "mission-critical" systems, devices, or software are to be renovated. Also, renovation may include the early retirement of older systems for which the remaining lifespans do not justify the projected Y2K repair costs.

(IV) Validation. Systems are certified as Y2K compliant as a result of stringent and comprehensive tests, as laid out in a checklist of activities adopted for use by each service and agency. Again, this testing starts at the level of the individual system or subsystem, with compliance being certified by the lowest officers/managers in charge, after which certification is widened to include interfaces with other weapons and IT networks.²⁷

(V) Implementation. Finally, all systems are certified as fully operational, both in terms of independent performance and in required interactions with the systems of other departments or services. Complete force readiness and "interoperability" are not fully certified until this phase is carried out without difficulty.²⁸

In short, the original DoD "Year 2000 Management Plan" provided "the overall DoD strategy and guidance for inventorying systems, prioritizing systems [for renovation], retiring systems, and monitoring progress."²⁹ In general, the checklists include:

whether the system successfully processes data containing dates in the twentieth and twenty-first centuries . . .whether the system accurately recognizes and processes the year 2000 as a leap year . . . and whether the DoD Component has identified external system interfaces and the type of date fields used by the [external] system [i.e., whether ‘interoperability’ has been established].³⁰

Finally, under the Management Plan, each DoD organizational component is "required to report quarterly to the Assistant Secretary of Defense (ASD) for C3I the Y2K status of their mission-critical systems." The ASD (C3I) in turn summarizes these reports and provides the results to the President through the Office of Management and Budget (OMB).³¹

William Curtis, the recently-appointed "Special Assistant for Year 2000" in the OASD (C3I), gave the following summary of this overall approach to Congress on 10 June 1998:

Systems-centric testing addresses individual systems. Functional-centric testing assures both Y2K compliant systems and functional effectiveness by end-to-end testing of DoD functional activities (accounting and finance, etc.). Mission-centric tests assure end-to-end performance of systems and interfaces to maintain the mission effectiveness of U.S. forces. . . .[Functional evaluation] . . . includes a combination of interoperability and laboratory testing across components, departments, and where feasible, NATO and allies. The nuclear community is a good example of collaboration to develop an end-to-end evaluation of the nuclear C4I system of systems. The process will demonstrate interoperability from sensor to shooter.³²

While all of this seems impressive and orderly, there have been severe problems with the Pentagon’s Y2K process from the beginning. Early difficulties were reflected in critical reports by the House Committee on Government Reform and Oversight. Representative Stephen Horn, chair of the Committee's Subcommittee on Government Management, Information, and Technology, gave the DoD’s Y2K efforts "F" and "D" grades in February and May 1998 because of the numerous program delays and reports of mismanagement.³³

The bad grades apparently did little to improve the Pentagon's programs. On 5 June 1998, the DoD Inspector General’s office (DoDIG) completed and published a highly critical audit of DoD methods of remediation. The purpose of the audit was to "determine whether the year 2000 certification process is adequate to ensure that mission-critical technology systems will continue to operate properly after the year 2000" and to evaluate "the year 2000 certification process" through a random sample of systems already certified as compliant by the individual managers in charge.³⁴

The audit uncovered two separate but related problems in DoD implementation of the Management Plan. First, many systems were certified as compliant when in fact no adequate justification for such assertions existed. The Inspector General (IG) estimated that only 109 of the 430 systems reported as compliant by November 1997 were in fact adequately validated according to the five-phase process. Three of the 22 systems in the sample for which a completed and signed checklist was provided were not in fact fully certified through testing, even though renovation probably had been completed. Two of the 22 systems had not even reached the validation phase. In addition, 14 examples in the 83 point sample taken by the IG "were inspected without testing (such as a manual review of the system’s software code);" seven of the 83 systems were considered Y2K compliant based on a statement from another organization; and 30 systems were labeled compliant without any inspection, testing, or statement from another source.³⁵

These inconsistencies were in turn traceable to a second problem: the ambiguity of definitions and procedures outlined by the first version of the Management Plan. For instance, validation through testing was not actually required before a lower manager certified a system; the only real requirement was that the manager sign the slip. This left much to the individual discretion of officials directly overseeing the Y2K renovations. Also, the "oversight requirements or processes" for the OASD (C3I) were not clearly defined, including the rights and duties of the Assistant Secretary in regard to DoD organizational components actually carrying out the certification process.³⁶

As a result there have been many dubious reports of progress made to the President’s Office of Management and Budget (OMB) and Congress in the past, even though the specificity and rigor of reporting requirements and the visibility of the OASD (C3I) in the whole process has been on the rise.³⁷ (See "The Current State of Y2K Programs Inside the Pentagon," p.20.)

This ambiguity even extends to the central concepts and terms utilized in the Y2K remediation community, including statements given to DoD project managers by private vendors. In practice, it has been hard to determine precisely what is meant by the terms "certification," "compliance," "system," "subsystem," and "mission-critical."³⁸ For instance, in regard to the definition of ‘systems’ and their required placement on the DoD’s shared Y2K database, the OASD (C3I) attempted to clarify the issue in August 1998 by stating that:

. . .mission-critical systems, migration systems, legacy systems, systems with an annual operating budget over $2 million, and any system that interfaces with the previous criteria must be reported to DIST [Defense Integrated Support Tools database]. All other systems must be accounted for in a ‘one-line entry’ to the ASD/C3I office.³⁹

However, this description still skirts the basic issue of what constitutes a system. At what point does the hardware, firmware, and software of one (sub)system end and another begin? It is still not clear that a succinct technical answer has been provided, although such ambiguity may exist simply because every ‘system’ is so unique that no general criteria can be offered for identification.

In addition, there has been much uncertainty about the criteria for naming a system "mission critical."⁴⁰ As the Y2K program has proceeded, many such systems have disappeared from the central database, not because of successful completion of the five managerial phases and final certification, but because they were re-identified as "non-critical" to DoD "core capabilities." Thus, DoD "progress" has in many ways been predicated on a reshuffling of cards rather than on completion of Y2K technical objectives. In addition, the GAO noted in an April 1998 report that "[the Pentagon] is spending limited resources fixing nonmission-critical systems even though most mission-critical systems have not been corrected."⁴¹

GAO representative Keith Alan Rhodes recently gave the following summary of the confusion surrounding the term "Y2K compliance:"

What I would say is that the data that are out there are suspect. The numbers that are presented are not uniform. We are – in the General Accounting Office we’re having trouble finding clear definitions . . . Compliance – you say tomato, I say tomato. There’s a great deal of people who say four things you can hear from a vendor. One you probably will never hear, and that is ‘certified Y2K compliant’. . . .Second point would be just ‘Y2K compliant.’ That’s going to come to you from the General Counsel [of the DoD]. And it will be a large document, and I promise you you won’t understand it when you’re done. Third thing’s ‘Y2K ready.’ I have no idea what that means. The fourth one is, we don’t foresee a problem; and if you have one, call us.⁴²

In this vein, one of the faulty practices of project managers has been to rely on statements from private vendors as to the "compliance" of chips, software, and operating systems. A February audit report from the DoDIG highlighted this issue, arguing "Because vendor claims on the compliance of commercial off-the-shelf products can be incomplete or erroneous, the information may have little real value to system management and technical staff."⁴³ These practices may now have been significantly curtailed under the new programs initiated by the OASD (C3I) and the OSD. (See "The Current State of Y2K Programs Inside the Pentagon" on p. 20.)

The Original Management and Organizational Structure of the Y2K Program

The lax technical and managerial practices described in the preceding section were probably inevitable given the initial organizational response to the issue. Early in the Y2K process, it was decided to combine centralized management (in reality, a minimum of central coordination) with decentralized implementation of Y2K assessment and repair work. Furthermore, these localized efforts were to be funded entirely out of existing funds for each weapons system, IT network, and department. This undermined any feelings of urgency on the part of local managers. Officers were in effect implicitly encouraged to continue their focus on currently-funded modernization projects even as the existing systems being "improved" were in danger of collapse due to the Y2K problem.⁴⁴ For the local officer making a decision on the diversion of funds, to increase dramatically Y2K remediation efforts was to take funds directly from ongoing projects. This is not likely to happen in the absence of a clear and concise top-down order by superior officers or by the OSD itself.

Finally, although this funding approach has worked well for systems undergoing upgrades through new modernization funding, it has not benefited systems with standard maintenance funds allotted in the FY1997 and 1998 budgets, nor has it always provided the necessary funds for conducting interface or "systems of systems" testing.⁴⁵ For instance, the Defense Science Board concluded in February 1998 that all of the Commanders in Chiefs (CINCs) were "heavily dependent on the Y2K activities by the Services and agencies in order for the CINCs to meet their mission requirements," and that the CINCs’ own budgets for ensuring "adequate interface and interoperability testing" were too small for the task at hand. This judgement applied to the nuclear forces under STRATCOM as well as to the more visible conventional forces under regional CINC control.⁴⁶

Funding was not the only difficulty. The original management style led to a poorly integrated effort with little information sharing between services and agencies, even when clear cases of cross-agency computer systems integration could cause vulnerabilities to the Y2K bug.⁴⁷ The only point of coordination was the Defense Integrated Support Tools (DIST) database, where entire systems were listed on the web. On a regular basis, the status of systems’ progress was to be updated and shown in terms of the above five categories (awareness, assessment, renovation, validation, and implementation), thereby allowing each service or organizational unit to view related developments in other areas. Most importantly, DIST was to summarize any and all "interfaces" between the system in question and other software or hardware, both within the service and between services. This was supposed to indicate to individual project managers all potential points of vulnerability that would eventually have to be addressed on a cross-system or "integrated" basis.⁴⁸

However, according to the GAO and the DoD Inspector General’s office, DIST did not always meet these goals.⁴⁹ For instance, in the case of the Navy, the GAO found that "Of 819 mission-critical systems in the database, 6 systems failed to identify which stage of remediation they were in, 23 did not provide the name of the system or describe its function; and 118 failed to show an expected compliance date."⁵⁰ In fact, DIST generally had a high level of "duplicate, outdated, and erroneous information," according to various DoD Component and service-level Year 2000 teams, and the number of systems on DIST for each service often differed from the services’ own independent estimates by hundreds of systems. According to the GAO, the Army did not "trust the data in DIST" and would continue to rely on its own database, a practice that continues to this day.⁵¹ The GAO’s general assessment by August 1997 was that:

Many systems in DIST do not have complete status and descriptive information. Each entry in DIST is supposed to include over 140 data elements, such as name, size, system manager, software, hardware, and interfaces. But for many systems, managers responsible for the systems have merely entered ‘placeholder’ information, that is, the bare minimum of information required to get the system into the database. In some cases, this may mean that only the system name appears in the database. . . .[For instance] 55 percent of the migration systems did not identify interfaces with other systems, 77 percent did not disclose the computer installations where the system operated, 68 percent did not indicate the computer hardware on which the system operated, 61 percent did not disclose the system software, and 26 percent did not identify the organization responsible for the system.⁵²

Finally, in line with the decentralized nature of Y2K remediation, data sharing arrangements between organization components failed to take a DoD-wide or "system of systems" level of analysis. The DoD Inspector General’s office found that detailed information on the "validation," or testing stage, was especially lacking. This is a major fault given the fact that project managers are tasked to augment their independent system tests with simulations or live exercises involving other "external" systems.⁵³ As the DoDIG argued in February 1998:

The Y2K testing information shared on the Internet is tailored for individual DoD Component requirements and is not organized for implementing Y2K solutions from an overall DoD perspective. Additionally, it is difficult for DoD Component personnel to locate relevant and accurate Y2K test-related information.⁵⁴

Whatever its faults, this method of information sharing was dismantled on early February 1998. The National Security Agency (NSA) decided that the listing of contact points between systems was an open advertisement of the Pentagon’s potential and real security vulnerabilities, possibly laying the groundwork for "information terrorism" or state-led efforts to cause havoc in US systems.⁵⁵ For this reason, the NSA classified DIST top secret, severely limiting access by those local personnel (private contractors and lower-ranking officers) most in need of information on systems’ exposure to other devices or software outside their own immediate area of responsibility. Any incomplete cross-department remediation efforts being carried out by staff without top secret clearance were effectively halted in midstream.

The Navy was the hardest hit of all, as it had total dependence on DIST for crucial information on both its own progress and the status of other services’ efforts.⁵⁶ In effect, the classification of DIST destroyed what little integration and coordination had been achieved between and within services. This increased the disconnected nature of Y2K program management and implementation. As late as June 26, the Defense Information and Electronics Report was stating that "the intentionally vague information contained in the new [highly classified] database, combined with the limited access being offered to the services and agencies, vexes some Y2K workers, who can no longer look to OSD for help ascertaining the status of systems with which they interface."⁵⁷ In a June 29 audit, the DoDIG argued that "Currently, DoD has no viable repository of year 2000 information that DoD managers can use for tracking, reporting, monitoring, and overseeing DoD year 2000 compliance efforts."⁵⁸

It is perhaps because of the additional burden caused by the DIST reclassification that six key officials left the OASD (C3I) in February 1998, although none have aired any overt and explicit complaints in public. The lengthy list included Anthony Valletta, acting Assistant Secretary of Defense (C3I); Cynthia Rand, principal director for information management under Valletta; ASD (C3I) Information Technologies (IT) director Sam Worthington; Daniel Grulke, director for plans and systems integration at OASD (C3I); James Soos, deputy ASD (C3I); and Dennis M. Nagy; director of C4I integration support activity.⁵⁹ All of these departures were planned or announced in the weeks surrounding the distribution of a key memo instructing DoD Components to regard all information on DIST as "Secret."

This exodus was particularly odd in the case of Cynthia Rand, as a year earlier she gave a glowing report of her responsibilities and mission at the OASD (C3I). In a 3 March 1997 interview, she said that "[Y2K] keeps me awake at night . . . But you’ve got to understand that’s a professional high and excitement for me." She also added that "I want to be directly involved . . . in priority projects or initiatives in any job I take."⁶⁰ Upon early retirement, Rand stated simply that she "could not pass up" the $25,000 buy-out plan of the DoD.⁶¹

Valletta cited his long service record and need to make room for new blood. No public statements were given by the other four officials upon leaving their offices.⁶² These sudden and almost simultaneous departures led the Information Technology Association of America (ITAA) to remark that "No one is well placed to make decisions. You can’t have GS 14 and 15s running around getting this job done in a big agency like DoD."⁶³

"The Bug in the Bomb" continued