Slashdot Mirror
US Needs Secure Coding Office
Trailrunner7 writes "If the United States wants to remain competitive in the global economy and prevent widespread penetrations of its strategic, corporate, and commercial networks, enterprises and government agencies should stop relying on commercial software and go back to writing more of their own custom code. 'If we're going to maintain our place in the world, software is not a strategic problem, it is the strategic problem going forward,' security expert Marcus Ranum said in a speech Tuesday. 'Covert penetration becomes something that you think about on a five, 10, or 20-year scale. Why don't we have a government coding office? We have a government printing office. Why don't we have a strategic software reserve? Our own software is probably a greater threat to us than anything other people can do to us.'"
Why don't we have a government tinfoil hat office? Clearly we're under great threat of alien mindrays.
In house software for government jobs is the way to go.
1) You own the code
2) You're goal is to have software that works for a long time. You vendor does not share that goal. They want you to rebuy software every 5 years.
3) It's a lot cheaper to maintain.
4) It's written to get a job done. Once that's done, you don't have to worry about some revising the requires new hardware.
The Kruger Dunning explains most post on
1. Why indeed, Marcus, "coding" and "printing" are so similar.
2. And the shelf-life of that software "reserve" is...
It must have been something you assimilated. . . .
"Why don't we have a government coding office? We have a government printing office."
That comparison is ridiculous. A proper comparison would be "We engineer our own government printing presses and copiers, why don't we engineer our own software?" But of course the government doesn't engineer printing presses...
Better known as 318230.
Unfortunately, they got fired: http://www.infoworld.com/t/platforms/openbsd-contract-suspended-due-world-events-727
Why don't we have a government coding office? We have a government printing office. Why don't we have a strategic software reserve?
We do. It's called open source. And it's run by a militia just like the one that started this country.
Who is John Galt?
Seriously. WTF. How can anyone ask that question and expect to not be laughed at.
I've seen some of the code produced at big shops like that. Not Halliburton, but Northrop Grumman started the project I am currently working on. After they lost their last round of bidding, my employers company picked it up. They lost for very good reasons. We inherited unbelievably bad and broken code.
Hire the OpenBSD boys. They have a proven track record.
SELinux has a pretty good track record too, and they wouldn't even need to outsource.
Really that's what they ought to be doing anyway: Not rewriting internal government clones of proprietary software, but giving the spooks a mandate to improve the security of open source software, and then use that.
Meh.
Just mandate genuinely open source software for all government work.
You don't have to rely on your government to analyze code and submit the fixes back to the original author - anyone can look at the code. And you don't have to rely on the original author to incorporate the fixes - anyone can. And you don't have to trust that the binaries you're running actually match the code you're looking at - just compile your own.
The big problem with all of this isn't necessarily that the code is crap or anything like that... It's that the stuff is closed-source. We're basically trusting that the code does what it is supposed to, and we've got very little ability to verify that.
"Work is the curse of the drinking classes." -Oscar Wilde
There are some big reasons why this might be a good idea:
1. Vendors have every incentive to pull the rug out from under you support-wise and make you buy their product again every few years.
2. Having people in-house who _actually know_ everything about how a system works really helps with debugging. Oracle, for example, is the king of finger-pointing when it comes to blaming some other part of the system for crashing a database.
3. Custom code would still have holes, but at least they wouldn't be the exact same ones being exploited in the private sector.
There's also some really good reasons not to do it:
1. You will still need to source an OS from somewhere. Whether $LinuxDistribution, IBM, Sun/Oracle, HP or Microsoft, ti wouldn't make sense to build a single purpose OS unless you were working on embedded systems. This OS would still have the same problem of limited-time support, publically available security exploits, and crappy support when you do get it.
2. Government organizations are very bad with communication. At the state level, practically every department sets their own standards. How could you get agencies with very different priorities to sign on to something that centralized?
3. Quality of code (see below.)
I work in systems integration, and have done so for many large companies. This is the place where we take applications, figure out how they can fit together, and merge them into a platform of clients/servers/network connections/databases. Software written by in-house IT is often the biggest bug-filled, resource hogging mess to get working. This goes double if the dev work is outsourced to a provider that doesn's know about the environment the app will run in. Think about the in-house apps you use -- the order entry client that requires a dual core processor and 2 GB of RAM, or the app that crashes with no explanation or a dialog box that says "You should never see this message." It's not all that bad, and some apps actually work really well. But developer training and skill levels are all over the map. At the very least, a vendor is responsible for their code, and can be persuaded/paid to fix bugs instead of letting them fester. A vendor specializes in building software meant to be used outside of their little corner of the world, so some companies do take time to make sure bugs are fixed.
This would work well when the field of software development matures a little more, and best practices aren't dictated by companies trying to sell you something. That's why IT has a very hard time being recognized as a branch of engineering - there's very few standard ways of doing anything. On the OS front, you have major vendors, hundreds of Linux distributions and other small players. On the database front, you have a few huge vendors that take totally different approaches.
By definition you've only seen the bad code that comes from such outfits. As so, you don't have a full picture of the quality of code from 'big shops.'
It may be a niche language, but it's still really good in areas where safety is a concern. The 777 uses it for the control software - http://www.adaic.org/atwork/boeing.html
Government doesn't expand in terms of power and revenue because it's getting better, it expands because the economy is expanding.
http://www.nationalpriorities.org/Federal%20outlays%20and%20revenues
Take a look at Reflections on Trusting Trust, where Ken Thomson basically admitted to introducing a backdoor into a commercial operating system by hacking the compiler. The conclusion of the paper, in his own words, was not to trust commercial software to be secure -- the only secure code is code you control from the ground up. That paper was published in 1983.
Palm trees and 8
For every example of software failures discussed above, you can come up with a fine example of a government system that worked great. I'm not going to spend a lot of time digging up examples, but here's one: the Navy's Aegis Combat System. Aegis is just Skynet's littler (and nicer) brother - it's vastly complex, and under certain circumstances is capable of conducting difficult anti-air battles more-or-less autonomously. It detects, tracks, and engages subsurface, surface, air, and ballistic missile threats. And yes, this was a program run by the government.
As the parent points out, the common thread in massive software implementation failures isn't that the customers were government agencies - it's that they didn't have their requirements nailed down before they started shoveling money at their problems. There's plenty of that going on in the private sector as well.