Slashdot Mirror
Losing Track of Nuclear Materials
As it so happens, I know a bit about accounting for nuclear materials at DOE facilities, since I've written a system to do just that (not the one in question, fortunately for me). There's a good basic description of the flawed inventory system available from a Russian site. It's a custom application built on Windows NT and SQL Server, and the application itself was almost certainly not written by Microsoft but by some consulting firm hired by the Department of Energy. (I don't know that it wasn't Microsoft who did the consulting, but it would surprise me.)
So rather than being a "risks of Microsoft software" story, this is a story in general about the risks of highly complex, closed-source code.
About ten minutes after Little Boy turned Hiroshima into an ex-city, the U.S. realized the importance of tracking the raw materials for nuclear weaponry. Enriched uranium and plutonium, primarily, but also many other materials that are fissionable or can be used in nuclear weapons. (Incidentally, you can possess uranium ore in its natural state without a Nuclear Regulatory Commission license - only if you try to enrich it do you run into problems. :)
Accounting of U.S. nuclear materials is handled through a system/organization called NMMSS, the Nuclear Materials Management and Safeguards System. This database was started in the Days of Yore, when men were men and computers were room-sized with lots of blinkenlights. This database was originally designed to accept 80-column punch-cards - lots and lots of punch-cards. Each punch-card could be part of an inventory received from some U.S. facility that handled nuclear materials, or part of a transaction indicating the transfer of nuclear materials from one facility to another, or any other data that needed to be entered into the database.
At the end of the day, the system would grind over the data entered, looking for problems. For instance, facility X says they sent 10 kilos of plutonium to facility Y, and facility Y says they received 9 kilos of plutonium from facility X - red flags go up, alarms ring, troops are dispatched.
The system has been modernized once or twice, and modified many, many times to take account of changing developments in nuclear science ("hey, this isotope can be used in making super-bombs - better track it too!"), changing regulations, and changing technology. But no one wants to screw it up, so modifications are always the minimum needed. So today, DOE facilities don't send punch-cards anymore - they can send their information via encrypted email or secure dial-up connections. But the data transmitted is still in 80-column formats, a legacy of the punch-cards. Each facility runs some sort of inventory system which tracks things at their facility, and submits various reports up the chain to NMMSS. It's all computerized - but there are massive legacies of the predecessor systems.
After the end of the Cold War and Soviet break-up, the U.S. DOE starting sweating about poor Russian control of nuclear materials. The U.S. has sent significant assistance to the former Soviet Union to aid them in accounting for and tracking materials that could be used in building nuclear weapons. The U.S. has also purchased a large amount of "excess" nuclear material from the former U.S.S.R., and the U.S. and Soviet inventory systems are at least partially merged now - at least some Soviet facilities submit inventory reports to NMMSS now, and so transactions of materials between U.S. and Russian facilities can be handled much the same way as transactions between two U.S. facilities. Naturally the U.S. donated their custom facility inventory software, which was probably developed at extraordinary expense, running on NT and SQL Server.... and now we're back to the original article.
At this point you know as much as I do. I don't know what flaw caused the loss in inventories that was described in the article, whether it was a flaw in SQL Server or the custom application written on top of it. I do know that any significant inventory loss would almost certainly be detected elsewhere in the chain -- NMMSS would note that the inventory was X kilograms one month, (X-Y) kilograms the next month, and wonder what happened, even if no one at the actual facility did. So my suggestion is to take the $1 billion estimate in the article with a grain of salt. Probably the flaw isn't that bad, probably it occurred in a repeatable manner and the data can be found or reconstructed (there are many checks and safeguards built-in to all of these systems to detect errors or attempted fraud). The most probable "attack" against the inventory system was a bad employee, attempting to divert nuclear material for financial gain. But the safeguards should suffice to detect systemic errors as well.
This is the first reference I could find on Google. If you search, you will find others. These are the largest, documented, publicized nuclear fuel thefts.
http://www.arabmedia.com/jnucler.html
[snip]
The most notorious instance, fully uncovered by the American intelligence in 1967, involved the Israeli theft of several hundred pounds of enriched uranium from the U.S. Nuclear Material and Equipment Corporation (NUMEC) facility in Apollo, Pennsylvania with the alleged help of its American director, Zalman Shapiro.4 While the evidence was not sufficient to convict the principal involved, there was a "clear consensus" within the CIA that the nuclear materials in question had been diverted to Israel and used by the Israelis for nuclear weapons manufacture.5 Indeed, Shapiro was known to have maintained extraordinarily intimate relations with the Israeli government and its nuclear scientific community during his tenure at NUMEC. Other known instances of Israeli theft of nuclear materials include hit-and-run tear-gas attacks by the Israelis against uranium-laden trucks belonging to the government of France, their former nuclear benefactor.
British nuclear cargo was similarly hijacked by individuals suspected of working for Israeli intelligence. A fourth instance involves the temporary seizure of a ship registered to what was then West Germany, from which 200 tons of yellowcake (uranium used as nuclear fuel) subsequently disappeared, an instance the U.S. intelligence has also attributed to Israel.
[snip]
it was actually trackn~1.dll
Apparently, this has been going on for about 10 years.
From the actual story:
By [the Russians'] calculations, an enormous amount of Russia's nuclear material... would disappear from their accounting records if Russia were to use the flawed U.S. software program for 10 years.
Please, please, please read what you're writing about before you write about it!
-- Old Man Kensey
Pu 239 has a half-life of approximately 24,000 years, so for all practical purposes it is stable and doesn't need to be rotated.
However, inside each weapon is a small device called the initiator. The initiator is made of beryllium and polonium-210, and is inserted in the center of the plutonium sphere.
When the bomb is detonated, the plutonium sphere implodes, crushing together and mixing the beryllium and polonium. The polonium gives off alpha radiation, and beryllium emits neutrons when hit by alpha radiation. One reference says that the number of neutrons given off by the initiator is around five or six. All it takes is one neutron to start the fission chain reaction.
The initiator only has a few microseconds to emit the necessary neutrons. It's considered to be one of the most critical and difficult aspects of nuclear weapon design. A great deal of information has been published about nuclear weapon design, but information about initator design is never published.
Polonium has a half-life of only 138 days. So, even though the plutonium itself decays very slowly, it is the initators that must be regularly replaced.
Somebody is going to set up... eh fuck it.
--
I don't think that opening the code is automatically a bad thing, but in this case I don't think it would help too much. Open source code improves when people look at it, and people look at it when they use it and have problems with it. This was a custom system written for exactly one customer, and you can bet the DOE could have (and maybe did) get the source code if they wanted to. Making this system open source wouldn't have helped much since there really wouldn't be enough eyes looking at it to make the bugs shallow. In the worst case, the only people looking for flaws would be the people with something to gain from the flaws - black hats. You really only want something to be open source if you can be sure that there will be enough white hats contributing to balance out that risk, or if it's a program that has very minimal security implications, like gEdit or something like that.
That's assuming that the problem really was in the custom app and not in NT or MSSQL, but I assume any bugs where MSSQL quietly "disappears" certain information would be common knowledge by now...
Your right to not believe: Americans United for Separation of Church and
it's a feature. This way, the US can actively reduce both nuclear stockpiles without the hassle of a treaty. =)
---------The early bird gets the worm, but the second mouse gets the cheese.
There's been a well known bug in TrackNuclearShit.DLL since Win 3.11, and MS has refused to patch it.
I think if you upgrade to IE 4.1 128 bit security, then disable javascript, but be sure to install MSN wallet software, then things work.
UNLESS, you're on SP 3 Win NT 4, at which point install the ATI drivers for the All in wonder card from a command line ONLY. Then remove the card with some BBQ tongs and put it in a shed. Do not look at the card for 3 weeks, then quickly put it back in wrapped in tinfoil. Turn the computer upside down. Leave it along for 8 minutes, then quickly apply mayonnaise to the front panel.
There, that should do it.
So does this mean that data about radioactive materials itself has a half-life? No wonder I can't remember my college physics classes! All my memories decayed!
I have zero tolerance for zero-tolerance policies.
Constitutionally Correct
In addition to supposed lost Russian nuclear material, actual lost US nuclear weapons and accidents are equally worrisome and more common than anybody realizes, with over a dozen VERY major incidents detailed here. There's even a monument to the 1957 Broken Arrow incident in New Mexico. If you've got $20 to blow, you can even get a nostalgic guided tour of all these Broken Arrow events narrated by Batman himself, Adam West.
I also fully agree that since no rogue nation has ever detonated a bomb in downtown Manhattan, it is obvious that it can never happen. History proves that it is completely impossible, so we should just stop sweating it.
So if somebody stole material that was recovered, it would be a one time deal.
Sure, I mean, why should we really care, since if they blew up Jerusalem once, they couldn't possibly do it twice. We'd track that software bug right down in that case. All those people killed in the blast and subsequent radiation posioning can rest easy in the knowledge that at least the same bug won't be exploited again. Probably.
It does when you're dealing with what is patently a piece of Safety-Critical software. I spent a little while working on railway signalling software, and the whole methodology is meant to eliminate this sort of vulerability.
Microsoft wrote a dodgy database server and a leaky OS. But they didn't make the decision to use those products as the basis for a piece of S-C software. They didn't write the software, design the SP's, build the data abstraction layers, create the failsafe routines.
What I find disturbing in particular is: where was the testing? Where was the useage simulation? How did a piece of software which turned out to have data integrity issues ever get a Safety Certificate?
For the Jubilee Line extension signalling, we didn't just limit development to ADA, there was a specified subset of permitted constructs, there were function point limits, a specified compiler, a specified runtime environment, there was rigorous analysis, code inspection, traceability, self-correcting feedback, three copies of everything which all had to match or the system stopped. There were no less than 3 teams of independent testers.
And even then it took a very long time to get the Safety Case signed off.
Microsoft shouldn't produce flaky tools, no question. But the very serious culpability here lies not with the creators of the shoddy toolset but with those who chose to implement a Safety-Critical application using these shoddy tools, and those who passed it for use.
Basic professional skill no. 1: know the right tools for the job in hand
TomV
When I was in high school in the mid-1980s, the idea of a massive nuclear exchange between the US and USSR seemed very real. We had all grown up with the assumption that a nuclear World War was just around the corner.
Now we're more concerned with the rogue state or terrorist nuclear weapon.
I wonder if someone even 10 years younger than I am can understand how much things have changed?
** The opinions expressed here are my own, and do not reflect those of my employers - past, present, or future**
Actually, not even a cigarette. Knowing the source code doesn't compromise security per se, provided that the coders can distinguish their arse from a hole in the ground and didn't hard code database access information into the code.
Look at encryption. Software like GnuPG and to a lesser degree PGP are open source. The algorithms applied are well documented and accessible to anybody.
Can you crack a GPG encrypted message? Not likely and it doesn't matter at all. Because security is not in the algorithm, but depends entirely on the key, possibly the chosen algorithm and the precaution of the sender and receiver.
Security through obscurity is about as dumb as it comes.
ich bin der musikant
mit taschenrechner in der hand
kraftwerk
It's not very stable though, the core's it generates tend to glow in the dark.
This is exactly why I, dictator of a small island country, instruct my military to get all our nuclear bomb-related software from Freshmeat.
You don't know adrenaline til you guide a nuclear missile with gnuke 0.913 (unstable).
I agree. It sounds like the database may have a flawed relational key structure. In such a case, certain data entry errors for a parent record can cause related child records to become "lost". The child records are likely still there, but are not related to the intended parent.
More broadly, there are likely to be 2 implied issues with this software:
1. If the software is 10 YO, it is likely that it was written with less than full attention to modern relational principles, such as database normalization , application partitioning, etc.
2. It is certain that the database was changed, ported (*), etc. over its 10 year life. It is again certain that the changes were less than optimal. Some probably even introduced errors.
* - If the application is 10YO, it is certain that it was NOT written for NT/SQL Server, as SQL Server is not a 10YO application.
It probably will make sense for the database to be reviewed and rebuilt. In general, applications should be reviewed and re-engineered periodically.