ABOUT | FAQ | SOURCES | VARIABLES | DATABASE
How do I use the database?
How do the filters work?
What time period does the database cover?
What do the different variables mean?
How was the data collected?
What were the criteria for inclusion?
What sources were used?
How do I determine which references apply to which cases?
Do you have additional information not presented in the current online version of the database?
I know of a case that is not included but seems to fit your criteria. Can I let you know about it?
I found a factual error in the database. How did this happen?
How do I use the database?
Cases can either be selected from the chronology tracking map at the top of the tool or they can be browsed and viewed by order of occurrence in the list beside the incident description field.
How do the filters work?
The filters are set to include all cases by default. By clicking the “Apply a filter” button the filter menu can be accessed and the range of cases can be narrowed by clicking on and deactivating undesired case characteristics. Selected characteristics tabs appear red, while deselected characteristic tabs are decolorized and appear gray.
What time period does the database cover?
The database is not artificially limited and simply spans from the first credible case identified in 1961 to the most recent case in late 2014.
What do the different variables mean?
The variables featured in the current web version of the database indicate first the nature of the action taken against the facility in each case (“Incident Type”). This could be an armed incursion not attempting to abscond with nuclear material (“Assault”), an insider action, typically furtive, not aimed at theft of material (“Sabotage”), an attempt to illicitly remove nuclear material from a site (“Theft”), a physical penetration of facility security devoid of violence or larcenous intent (“Breach”) or may not have been determined for the case at hand (“Unknown”). The Incident Type may also be followed by “(Plot Only)” which denotes that, while no kinetic action was taken against the targeted facility, the perpetrator is known to have planned an exploit and is thought to have had the intention to go through with it. The next variable indicated in each profile is whether or not the perpetrator in a particular case was successful in their attempted exploit (“Success”). Given that measuring success as whether or not the perpetrator successfully breached any facility security was too close to being the same distinction as the “(Plot Only)” designation, the success variable represents whether or not the intruder is thought to have achieved their ostensible goals. The motivating ideology of each perpetrator is another variable indicated for each case (“Motivation”). New motivation coding options were added each time a case with a distinct ideological motivation was encountered in the course of research. The full list of motivations represented, and the definition of each type can be found in the “Motivational Categories” section below. Cases that featured characteristics of more than one Incident Type or multiple possible Motivations were coded according to what were believed to be the most salient Incident Type and Motivation. Whether or not the incident involved the participation of a facility insider is the final filterable variable in the current iteration of the web database (“Insider”). Cases are either coded as “Yes,” “No” or “Unknown.” “Unknown” was only used when researchers found there to be suspicion of insider involvement or when they felt particularly unable to make a determination either way based upon the evidence available.
Definitions of the all currently included variables can be found here
Pending availability of funding, future versions of the database will incorporate other variables recorded in the research effort, such as the type of facility breached, geographic region, the level of facility penetration, the level of threat posed by the incident and the veracity of sources as distinct and filterable case characteristics.
How was the data collected?
The data collection effort was aimed at identifying all potentially relevant cases of security breaches at facilities housing or designed to house fissile materials. For each potentially viable case, an attempt was made to collect sufficient information to populate a predetermined profile template. The template outlined what information was sought for every attack and plot, establishing as accurately as possible such features as: where and when incidents took place, the type of facility targeted, whether the infiltrating actors’ identities and motives were known, as well as how far into and by what means they penetrated facility security. The database ultimately included only those cases: a) that were deemed relevant to the scope of the research; b) for which sufficient information was available to populate at least several variables in the profile template; and c) that were reported in sources regarded as meeting at least a minimal threshold of credibility (see below for more detail).
What were the criteria for inclusion?
Each potential case was evaluated and coded on the basis of how well it was corroborated across independent sources and the credibility of the sources that reported it. In addition to having to meet the criterion of a breach (i.e., an actual or substantively planned attempt to compromise the security of a facility), where it was clear that the facility did not contain any nuclear materials at the time of the incident, an incident was excluded from consideration. Where there was some doubt as to whether materials were present or not, the incident was included and coded with the appropriate veracity value to indicate the uncertainty. Some exceptions to this exclusion rule were made for cases wherein nuclear materials appeared not to have been present but breaches occurred such that the future disposition of nuclear materials was likely affected. These cases specifically are the attacks which occurred against the Lemoniz and Bataan nuclear power plants, all of which occurred before the plants were fueled but contributed to reactor activation efforts being abandoned. This process ultimately led to the identification of 80 reported incidents of actual or planned breaches of security at relevant facilities.
What sources were used?
The search for relevant cases began with the National Consortium for the Study of Terrorism and Responses to Terrorism’s Radiological and Nuclear Non-State Adversaries Database (RANNSAD) (Ackerman, Blair, Sorrells, 2011), an effort that yielded 10 cases relevant to the security of nuclear facilities. Seeing as RANNSAD focused on perpetrators rather than incidents and only covered the period up to 2011, academic research portals and open source government document repository resources were the next sources examined. While the body of extant official and academic literature provides useful insight into the state of nuclear security practice, planning, and theory, it offered only occasional anecdotal references to particular past instances. At this point, the search shifted to draw primarily from media reports of nuclear facility breaches, involving the use of multi-source and single outlet-specific media archives.
How do I determine which references apply to which cases?
The title of each case is preceded by a number. These numbers ascend chronologically and correspond to a number on the references page. Under the corresponding number and title on the reference page, citations for all sources used to inform the case profile in question can be found.
Do you have additional information not presented in the current online version of the database?
The various substantive aspects of each case (as referred to in the “How was the data collected?” section) were coded, together with several supplemental variables to aid analysis (alluded to in part in the “What were the criteria for inclusion?” section). The first of these supplemental variables made a distinction between attacks that actually occurred and those that were merely plots. Furthermore, while information tended to be fairly abundant on challenges to nuclear facility security that occurred within the last 25 years, earlier cases often lacked much in-depth information or were uncorroborated. Reconciling this limitation with a desire to compile as chronologically comprehensive a database as possible, required that the veracity of each case be determined. This was accomplished by creating a three-level metric (1-3) representing an ascending scale of case veracity based on the reliability of the sources, the degree to which the case was corroborated across multiple sources and the extent to which the incident was substantiated by available evidence. In addition to this veracity metric, although all the incidents are instructive to some degree, the researchers wanted to distinguish between those incidents that were clearly never intended to cause or facilitate major physical harm to the broader public, such as vague threats or protest events by anti-nuclear groups, and those that held the potential for more severe outcomes, such as the misappropriation of fissile material or the dispersal of radiological products. Thus a “threat level” variable was coded for each incident. While the determination of which incidents fall into the latter category of “higher” threat cases is ultimately subjective, delineating the extant cases in this way at least provides a basis for examining whether there are significant differences between “higher” and “lower” threat incidents in terms of their geographic dispersion, frequency, success rates and so forth.
The substantive variables that are currently not independently indicated or available as variables that can be filtered, such as facility type and level of breach attempt progression, will be implemented into the tool in later versions, dependent on future funding for the project.
I know of a case that is not included but seems to fit your criteria. Can I let you know about it?
Users of the database who are aware of a case that is not featured in this database but might warrant inclusion are strongly encouraged to contact the researchers responsible for the database. Please direct all potential additions to START researcher James Halverson at jhalvers@umd.edu.
I found a factual error in the database. How did this happen?
The researchers who assembled the database attempted only to include data believed, with a certain degree of confidence, to be accurate. Even so, a number of the cases featured were sparsely reported on and some variables, even after consulting with outside experts, may have been misinterpreted. If, as a user of the database, you find some piece of information that you believe to be incorrect or out of date, please contact James Halverson at jhalvers@umd.edu to convey your observation so that it can be verified and the information updated if necessary.