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.'"
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
"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.
2. And the shelf-life of that software "reserve" is...
At least a few decades, isn't it? At least Maxima, Emacs and others work perfectly on my modern PC.
Ezekiel 23:20
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.
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.
The only thing it could possibly mean is a reserve of *coders* ready to jump at any problem or bug that arises. Oh wait, that's called the NSA. Just need to give them more resources and jurisdiction to fix any code anywhere in the government. That'd work great:
Setting: Nondescript cubicle farm full of people working an eating donuts.
Cubicle farm is suddenly stormed by a SWAT team with M16s and tablet PCs.
Team leader: "Everybody freeze! Hands off the keyboards! We've detected a buffer overrun condition! Move, move, move!"
Guys with tablets rush to the PCs and networking closet and start typing like mad. Soldiers round up all the people into the middle of the room.
A five-star general walks into the room.
General: "What's going on here?"
Team leader: "Sir! We're neutralizing a threat in the PR office happy-hour scheduling system. We should be finished soon."
General: "Good. I'll want a full report when this is over. We need to catch the idiot who's responsible for this."
A soldier escorts an intern with hands behind his head to the leader.
Soldier: "This guy did it. We found non-compliant source code on his machine."
Team leader: "Good work, sergeant. Hand him off to headquarters at 1300."
General: "Glad to see that was taken care of quickly."
Team leader: "All in a day's work, sir."
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
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