Slashdot Log In
Losing Track of Nuclear Materials
from the oops dept.
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.
Here's the largest nuke fuel thefts (Score:4)
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]
Correction (Score:5)
it was actually trackn~1.dll
Not so much closed-source as legacy code (Score:3)
Story submitters, please read what you submit! (Score:4)
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!
Re:half-life (Score:5)
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.
Uh oh (Score:4)
Re:Risks of closed source software. (Score:5)
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...
Apology (Score:3)
Thank you.
Not a bug... (Score:5)
Of course. (Score:5)
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.
Instead of stealing it, enrich it yourself (Score:3)
http://www.findarticles.com/m1111/n1782_v297/21281 407/p1/article.jhtml [findarticles.com]
Just a fun article . . .
half-life (Score:5)
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.
US Nuclear Weapons Loss Accounting (Score:5)
Re:Risks of closed source software. (Score:3)
Clue: Open Source does not mean that everyone has access to the source. GPL-style free software licenses mean that those who can get a binary can get the source for free, which in this case would've been a good idea. Then the facility in question could've found and fixed the bug long ago.
Or would you rather confidential government systems be running a closed-source solution like NT and not know who's getting what data from them?
(Well, there goes any chance of this getting up above -1 - criticizing Microsoft is a sure way to attract 'troll' and 'flamebait' ratings.)
-RickHunter
Re:Is this really something to worry about? (Score:4)
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.
Re:Why can't it be MS? App running under Windows? (Score:5)
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
how much the world has changed . . . (Score:5)
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?
Close, but no cigar (Score:5)
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 [gnupg.org] 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.
Risks of closed source software. (Score:3)
I think open source is great, and something the government should be using for non-confidential or lower classified systems.
-
Re:Not too scary (Score:3)
This is exactly backwards. Bomb design is, though not exactly kindergarden stuff, actually fairly simple and easy if you know where to look to find the right info to work with. It's manufacturing the special materials in quantity which is hard and expensive.
Around 1970, the Department of Energy (and specificaly Edward Teller) did a threat analysis program called variously The Third-Country Experiment or The n-th Country Experiment. They took three brand new physics PhDs with no specific course work or training in nuclear physics and told them to design a bomb using only open source materials. This they did, designing a compact (1-ton), reliable (was analyzed by professionals and determined to have essentially full reliability / functionality, though one was not manufactured to test) weaponized plutonium implosion device, in 18 months time. So there's been a demonstration that it can take as little as less than 5 man-years effort.
See: The Nuclear Weapons FAQ [fas.org] by Carey Sublette and the newsgroup alt.war.nuclear [alt.war.nuclear]
They need Gnuclear-Tracker (Score:5)
It's not very stable though, the core's it generates tend to glow in the dark.
Shoulda used open source (Score:5)
You don't know adrenaline til you guide a nuclear missile with gnuke 0.913 (unstable).
Re:huh? (Score:3)
I've seen plenty of bad apps written with the VB/SQL Server combination, and very few good ones, so it wouldn't suprise me that they did something dumb, like put the RI in the front-end code, or neglect to use tranactions.
I would suspect that a lack of proper RI has resulted in orphaned records, which could fit their (wierd) explanation of the problem.
Re:huh? (Score:5)
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 [microsoft.com], 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.
Not too scary (Score:3)
Weapons-grade fissionable materials in themselves are relatively easy to make. Any nation that has the know-how to build a nuclear reactor can build a breeder reactor to make weapons-grade uranium. The technology required to make the actual bomb, though, is pretty difficult to figure out. It's kind of like the DeCSS fiasco: once the technology gets out, there's nothing you can do to put it back in the bottle. Thankfully, everyone (so far) who has the tech wants to keep it private. Hope the servers they store the info on aren't running Windows!
Expecting absolute zero failure rates is absurd (Score:3)
What you are talking about is not reasonable. No matter how careful a programmer is, no matter how much testing the code goes through, no matter how many experts scan through the code, there is always the possiblity of a bug or design flaw. It cannot be expected that code written in the real world for use on real devices will be 100% fault tolerant. The same goes for anything else.
Why do you think there are so many problems with getting good, decently priced healthcare in the US? It is exactly because the doctors have to pay settlements in the millions if they make a very small mistake or a dying patient doesn't survive a very risky surgery (which the patient and family were informed of the risks). What is the result of this? Doctors/hospitals have to pay massive malpractice insurance premiums. HMOs were created, which makes getting serously ill worse, because your provider will hide possible treatments, refuse to pay for critical operations, use accountants to make decisions that only doctors should. And so on, and so on...
That is just for finacial liability. How would it be if an industry were criminally liable for not being 100.00000% perfect and 100.00000% successful at everything? I imagine it would end up like this: most of the people who are knowledgeable would run away screaming from their job, realizing they could not possibly live up to the standard and would end up in jail. Then you would only be left with clueless idiots, arrogant bastards, and con-artists. After a short time, the idiots and bastards would be in jail because they made some sort of mistake, and the con-artists would be in the Bahamas or somewhere with the millions of dollars they stole from desperate organizations trying to fill in the essential gaps in labor caused by this law. What does that leave us with? Nothing! Because we are talking about critcal industries, what would happen? I don't want to find out.
People or organizations should be punished if they hide problems or don't use resonable care, however saying that someone must be punished for everything that goes wrong is complete idiocy and shows total disregard for reality.