US Needs Secure Coding Office 236
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.'"
OpenBSD (Score:2, Interesting)
Writing code is error-prone and expensive! (Score:1, Interesting)
Writing code is fundamentally error-prone, and expensive! Programmers, young and experienced, make mistakes. Young programmers in particular overestimate their abilities, and wildly under-test, and pretty much totally fail to think about compatibility or vulnerability. Proper management to enforce testing, reviews, documentation, security, etc. is very expensive. And once you've written the code, the marginal cost of sharing it widely is very low ... which is why I believe that this proposal will fail: it will always be cheaper to use either commercial code, or open source.
Haha, software is the anwser to it all? (Score:3, Interesting)
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.
This idea is dumb. (Score:3, Interesting)
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.
Re:OpenBSD (Score:4, Interesting)
Unfortunately, they got fired: http://www.infoworld.com/t/platforms/openbsd-contract-suspended-due-world-events-727 [infoworld.com]
We do (Score:4, Interesting)
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.
Re:Agreed (Score:3, Interesting)
Re:This idea is dumb. (Score:4, Interesting)
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.
Not so poor comparison (Score:3, Interesting)
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.
Re:What? (Score:3, Interesting)
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.
And I could argue that for software created today it could be much longer. Many things seem to have stabilized or at least compartmentalized their growth. Think air traffic control. IIRC the machines they run on now are 20+ years old as is the software. Not only that the scale of the problem has grown significantly from 20 years ago, but will we see that same growth in: computer performance, software tools and air traffic in the next 20 years? Probably not. Again, IIRC reliance on radar for air traffic control may be on the way out, but realizing that sort of modularity, seems like you could design a system where a GPS module could be added with much less pain than re-writing the whole system.
Re:Agreed (Score:5, Interesting)
Working at NASA is like working in the game industry, it's the coolest gig around and attracts tons of people which creates more competition and ultimately drives salaries down.
Mostly cultural, not technical (Score:3, Interesting)
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.
Re:Agreed (Score:3, Interesting)
1) Each individual part of the government only needs custom made software once every 5 years or so
False. maintenance is always an issue, no matter what software you have. #rd parties know this, that is why they make most there money off consultants you have to hire from then at 250 or more per hour.
"2) Every government in the known history of mankind has been utterly incompetent in cross-department communication"
Way to buy into a myth. This is false for two reasons:
1) it assumes that sort of thing never happens in the private sector
2) The US government does very well at cross communication. there are problems, but not as bad as people who sell solution would lead you to believe.
"Since you can't reasonably expect the government to hire teams of programmers to write software one year and sit on their asses for 4 years"
because the government would only ever need one application? and that application would never need new features?
Are you stupid or just blinded by fallacy's about the government you believe without question?
" trying to centralize the work leads to horror stories"
Only when centralizing work that should not be centralized. Usually done by people who don't understand how a government works.
"you can see why most governments (even the socialists) have opted for contractors."
no. The have opted for contractors becasue of political ideoolgy and ignorance, not for a trong business need.
For the record:
I worked in the private sector for over 25 year.
most of the was as a software engineer, programmer, analyst.
I have worked in the public sector for almost 5 years.
1) It isn't nearly as political as the private sector corporations
2) The people here have a breadth and depth of knowledge about the business you can't find in the private sectr any more.
3) the people I work with care and work hard to saver money and work efficiently
4) running a city is far more complex then you can imagine.
5) I work with programmers that could write circles around pretty much everyone else. Plus they document their work, and almost always write in a readable manner.
6) There is no 'up or out ' attitude. That means if you like you're job, you can keep doing it.
|
Re:This idea is dumb. (Score:3, Interesting)
Having an agency which uses public dollars to enhance and secure open source software for use both within Government and for the public at large makes a huge amount of sense. It's important that the Government not *own* the code, just provide patches/alerts to the project leaders, and customizations for internal Government use, as needed. (The reason for non-ownership is because, well, who *really* trusts the Government?)
In this way, software could become a public good and much cheaper in general rather than a profit center for a few companies and a millstone around the necks of most companies.
--PM
Re:Putting the cart in front of the horse (Score:3, Interesting)
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.
Re:WTF? (Score:3, Interesting)
Without saying so, you identified the problem: The IRS, census bureau, FBI et al. were acting like typical squirrelly clients who don't really know what they want, they just want it now and have deep pockets. There's no shortage of private sector equivalents, such as Hershey's or Coke's attempts to implement SAP resulting in billion dollar failures (and in Hershey's case the near bankruptcy of the company).
OTOH, Newell Rubbermaid had its homegrown ERP that was of a high enough quality to be one of Walmart's top tier vendors. The difference is obvious: organizations that have software development as integral parts of their business succeed, while deep pocket clients who don't really know what they want fail with consultants. So make software development an integral part of government services.
Re:Writing code is error-prone and expensive! (Score:3, Interesting)
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.
German government does this (Score:1, Interesting)
German embassies around the world use open source infrastructure to communicate with the home network. They've realized a long time ago that relying on closed source software that may contain backdoors accessible by foreign countries is a really dumb idea, so now they build their own based on open source solution, and occasionally contribute back to the community.
You need to think about this one... (Score:3, Interesting)
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.
No kidding. (Score:4, Interesting)
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.