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.'"
Hire the OpenBSD boys. They have a proven track record.
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.
We have Halliburton.
We don't make enough food, we starve to death, we don't make enough software we.......?
At the end of the day software is just yet another export product, while it would be bad for the economy if the software industry wasn't competitive (just like it would be bad for the economy if the car/toys/foresting industries wern't competitive) the country doesn't literally die if it fails, you'll just have to live with it being slightly less prioritized.
Who says the government code wouldn't be open source?
For the people, by the people eh?
Having worked in government IT, and worked for government military contractors I dont think that the software is the issue.
I would start by upgrading all the equipment that went EOL (End Of Life) more than 5 years ago! (90%+ of the hardware they run) /var/log directory.
Then move to the equipment that is EOL now.
I would then work on implementing a proper patching and patch management plan.
Documentation would be useful as well, Stop expecting the new IT staff to understand how AIX v3 works on the H50's you are running. Especially when the old IT staff thought it was good security to replace the login with one that used a password file stored in the
Security through obscurity is all that would happen if the government tried to make all systems code come from an internal group. I am sure we all know how well that works!
I say mandate that the government groups run only opensource software. Then hire select coders to quick patch any problems or security issues that are found and make the parches available to everyone. That way the government can be secure as well as any other company or person that runs the same software.
A better idea would be to have an office that analyzes the code of existing software for security issues, develops solutions, and hands them over to the software owner.
Owner doesn't want to share the code? Don't use their software for government work.
But redeveloping from scratch at this point does not make fiscal sense any more. We stand on the shoulders of 30 year tall giants. There is no need to rewrite the TCP IP stack from scratch, to write a word processor from scratch, to write a web server from scratch, etc.
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
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.
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.
Its actually not: printing and software development are both services that most government agencies regularly need, but that in general most don't need the same subtype of the broader service enough to justify retaining the capacity to meet all their needs in-house without outsourcing, but where the needs of the government as a whole would be more able to justify maintaining resources centrally and then making them available to individual agencies.
The fact that the necessary resources in the case of printing involve a mix that is heavier on physical capital than human capital, while the resources in the case of software development is a mix that is heavier on human capital than physical capital is a difference, but its not a difference that is particularly relevant to the point of the analogy.
You'd probably have a better case if you argued that the "strategic software reserve" was a bad comparison. Software isn't an physical resource with an interruptible supply that you can horde in advance against a future crisis. OTOH, I can see a useful "strategic software reserve" in one sense -- not a reserve of software but of software-related IP. If you accept as a baseline the current US system of fairly strong software-related creator IP rights (copyright and patent, most particularly), it might make sense for the government to strategically exercise the power to acquire property for the public use by eminent domain with a payment of the fair market value to "buy out" existing IP rights where there is a substantial public good to be served by doing so. This might -- structured properly -- be a system that serves the public interest and the Constitutional purpose of IP protections better than either maintaining the status quo without such a system, or just weakening IP protections generally.
IMO the place to start if you want to fix computer security is with the culture of software use rather than the software itself.
There are plenty of places where security can be made better technically, and it is our nature as "software guys" to focus on those, but most significant break-ins come from the way people treat software and password information.
are all bigger problems than
Not because the latter aren't issues that need work, but because those are issues that get recognized and fixed quickly. As far as I know, there is no widely accepted way of fixing the social problems that plague computer security.
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
Marcus is something of a muckracker. At one time, he was in charge of whitehouse.gov website security, and has at times been incredibly critical of the US Gov - see his book The Myth of Homeland Security in which I think he rips every major division of federal government (but especially the DHS) a new asshole.
As such, many beltway types have tuned Marcus out. He's almost always right, but he goes about telling us the problems in the most confrontational manner possible.
A) You generally need a history of bad work to get fired. This is true. I also think this is generally how it shoudl be everywhere.
Before we had laws to protect people, it was like that. people could hire and fire for any reason. This lead to sweat shops and people working them selves to death.
No thanks, I perfer a decent civilization.
For the record, I read proposal from small companies for contract work in the government. The 'hoops' aren't that bad. The hoops are there because the government want to keep the risk low that they are going to get screwed.
The hoops are there because the public hold the government responsible for their decisions. So there need to be some sort of frame work to minimize risk.
Yes, that is a good thing.
The Kruger Dunning explains most post on
Sorry, but the COTS battle started in the 80s and has been over for a while. Nobody builds when they can buy anymore. If you believe your business is utterly unique and needs custom-written software... well, you are wrong. And nobody outside of a few folks just emerging from college really believe that way.
Would it be better if the government (and businesses) paid for software development rather than paying for packaged software? Maybe, but it would cost more - it certainly did in the 70s and 80s. The difference for nearly everyone today is they are buying a package for $500 instead of paying a year or two salary for a programmer. Sure, when the project was done there would be something else to do - this is a basic maxim that work expands to fill available staff. But today just about everyone has figured out that COTS is the only way to go. The buyer is isolated from personality quirks of the developers and isolated from the development process itself. The buyer also never has to worry about being held hostage by some lone wolf developer.
Yes, there can be the dreaded upgrade cycle where support for really old creaky software is discontinued no matter what the desires of the customers. And it does mean that the package you bought in 1993 for Windows 3.1 absolutely does not work on Windows 7 x64. But the world does not stand still and there generally needs to be some movement on the upgrade front.
Yes, it works well, and an implementation has been part of the ubiquitous GNU compiler collection for several revisions: gcc.gnu
The government already funds software development and the past results of that funding predict the would-be future success of a government coding office; It would be a massive, expensive failure. The Census Bureau IRS, FBI and FAA have records of incredible, mind-boggling, massive failure in producing software. Not to mention state funded universities, the University of Wisconsin being the most recent travesty.
The unstated assumption that government involvement in software production would improve, and not degrade, the quality of software is ludicrous in light of evidence from past results.
But it would not only fail. As with other government agencies, it would be subverted by special interests for nefarious causes. Patents and Trademarks, established to promote creative works, are abused by patent trolls to threaten innovation and by politicians who extort campaign donations in return for incremental, perpetual copyright extension. The Department of Agricultural, now a wholly owned subsidiary of ADM, runs welfare-for-millionairs programs. Oh, and have you heard of Fannie Mae and Freddie Mac?
Government coding office? What could possibly go wrong with that?
Ceci n'est pas une signature.
Obvious jokes aside, the government doesn't innovate very well. It has clear limits to its power under the Constitution, and this would just be another example of it stepping outside of those bounds... Kind of like this little red star. All in the name of security? Yeah right.
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
We need a few special-purpose boxes that are highly secure, as examples. The components exist. There are hypervisors certified to EAL-7. They show up in industrial systems, DoD systems, and avionics. They should be showing up in routers, firewalls, DNS servers, and ATMs.
A push by Homeland Security to increase the security level of critical infrastructure would not be out of place.
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
So ... you are saying ... software is hard to do, so let's go to the least reliable source for it ... ?
Both commercial software (off the shelf ... COTS) and open source (also off the shell ... FOTS) are full of bugs. At least open source is subject to peer review (in a wider peer space) and gets bugs fixed sooner (there's rarely a coverup of bugs in open source, unlike commercial).
One big problem is that the internal review process, that still has to be done inside the government, will be weaker at this job because the people who would know how best to do that won't be working in the kinds of jobs that would be in a track to the analyst positions that can do these reviews. At least one reason to have an in-house programming team in the government is so that some of them can move up to being top level analysts without being biased in favor of certain commercial interests.
now we need to go OSS in diesel cars
I work as a defense contractor, and most of the stuff we work on these days has a software component (whether commercial off-the-shelf, commercial/custom, or gov't developed). I'm pretty sure I don't want my missiles being launched by gnuFireControl or KLauncher. For one thing, there aren't all that many people with expertise in military software development outside of the existing M-I complex. And yes, military software is considerably different from other business software - for one thing, there are very complex safety requirements that have to be met, and if you don't know what they are, you won't be able to do it. More importantly, a lot of the military software in use today is classified - if you could look at the source, you'd get a lot of information about our own forces' capabilities and limitations, plus you'd be able to infer intel data on what we know about adversary systems. Not the kind of thing I want available to Boris and Natasha (or whoever our favorite bad guys are this week).
So you'd have to establish at least some exceptions to the all open-source rule. And once you start allowing exceptions, it can be hard to know where to stop.
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.
"Government doesn't expand in terms of power and revenue because it's getting better, it expands because the economy is expanding."
That's an interesting perspective given that the chart you referenced clearly shows Federal government spending as less than 5% of GDP in 1930, and ~25% of GDP right now.
Recall also that government spending is part of GDP. Therefore, showing spending and revenue as a % of GDP tends to obscure the picture of the size of government relative to the private sector. A $3.6T budget is ~24% of a $15T GDP, but ~31.5% the size of the real productive economy which has to bear the burden.
I also love the little inflection points showing that in the next few years the deficit is going to drop from 10% of GDP to 5% of GDP. I'd like to see it happen, but I see no evidence of any leadership or political will to make that happen.
I'll agree with one point however:
"Government doesn't expand in terms of power and revenue because it's getting better . . ."
It expands because it's filled with a bunch of self-serving parasites.