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)
Re:OpenBSD (Score:4, Interesting)
Unfortunately, they got fired: http://www.infoworld.com/t/platforms/openbsd-contract-suspended-due-world-events-727 [infoworld.com]
Re:OpenBSD (Score:5, Insightful)
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.
Re: (Score:2, Insightful)
Why does one always find the argument "X must spend more on open source software" ? It's ridiculous, especially when, as usual, right next to "open source software is free !" ?
Re: (Score:3, Insightful)
Open source software is free, retraining staff to use it is not. Neither is hiring uber-expensive consultants when something goes wrong (which in the case of OSS can actually mean the ONE person still involved who wrote some of the original source).
Don't believe me ? I worked for a travel company for about 10 years, and when we had some database optimization issues, one of the actual lead coders from the project came and spent 2 days in our office. Nice guy though, optimized our queries and indexes like you
Re: (Score:2)
Tinfoil hats (Score:4, Funny)
Why don't we have a government tinfoil hat office? Clearly we're under great threat of alien mindrays.
Re: (Score:2)
Already forgotten NSA?
In case you live in the US.
Anyway - if everyone uses the same software it means that everyone knows how it works which also means that more people are able to crack any security measures involved. This also makes it easy for people making malicious software.
A more mixed environment causes other types of trouble. So what's necessary is to find a balance between standard software and custom softwares.
Not a case for tinfoil (Score:5, Informative)
Re: (Score:3, Funny)
In theory, in practice you'll have to live with that secure software is a dream you'll never achieve.
If I had to choose between the Government using a large well known OS like Windows 7 or something they hacked together themselves, I'd much prefer Windows 7 because you can be reasonably sure it won't randomly implode and if it had glaring backdoors we'd know about them by now. (Though I'd probably feel even better if they'd use something linux based)
Re:Not a case for tinfoil (Score:5, Insightful)
General purpose commercial software packages raise a yellow flag for security as far as I am concerned. They are not necessarily a problem, but there are risks. The general purpose nature is itself a problem; a system that is intended to be used to schedule appointments should not have the capability to execute a shell, nor should it even have a shell installed. The problem with general purpose systems is that they ship with a lot of code that is never needed for a specific installation, but which an attacker could potentially make use of. This is the basic concept behind a "return to libc" attack, or more generally "arc injection."
Re:Spending is the goal (Score:4, Informative)
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 [nationalpriorities.org]
Re: (Score:3, Insightful)
"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
Agreed (Score:5, Insightful)
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.
Re: (Score:2)
They want you to rebuy software every 5 years.
I don't disagree that many vendors do; but it seems in the past, that wasn't always the way it was, or something... because there are a lot of servers still running some pretty old software.
I'm thinking primarily of IBM stuff... but I guess IBM sold support, too, so they still got money, even if you didn't rebuy.
Re: (Score:3, Insightful)
It's clear you've never seen the government at work. There's two issues with the govenrment writing it's own software.
1) Each individual part of the government only needs custom made software once every 5 years or so
2) Every government in the known history of mankind has been utterly incompetent in cross-department communication
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 while there's on demand and that tradition
Re: (Score:3, Interesting)
Re:Agreed (Score:5, Informative)
There's a third issue: salaries. Programming talent is used to silicon valley pay grades, not military pay grades. How many employees would be willing to leave their current position and take a 50% pay cut to work for the government? Would you be willing to trust the code of someone working for $40K/year?
Actually, there are a lot of government programming jobs that pay decently. I work at a government research lab, and the pay is competitive with industry (though no stock options, etc.), and I've seen a lot of FBI/NSA/CIA job postings for computer scientists that advertise 6-figure salaries.
Re:Agreed (Score:5, Insightful)
I did. I make less money, 75K as opposed to 120K, but I get more time to enjoy my life.
after 25 years, I was real tired of pointless 60 hour weeks and day long meetings.
You really don't understand people. I pity someone that places all value someone could possible have on their salary.
Re: (Score:2)
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.
Re: (Score:2)
When I was working as a contractor for NASA, all of the Government computer jobs were contracted out (the "smaller government" initiative) so the people who were left could concentrate on the business of running NASA. This was through the 90's into the early 00's. Don't know how it is now.
[John]
Re:Agreed (Score:4, Insightful)
There is one thing forgotten. For the most part, US government "GS" jobs have job security. Unless someone commits a felony on the job, they know that their badge and CAC will work the next day. Private industry has higher salaries, but there is always the chance of being pitched out like last night's garbage if a PHB decides to swallow outsourcing/offshoring Kool-Aide.
And people know this. Government jobs have a lot more competition going for them than private jobs in a lot of places, from what I've seen.
Don't forget benefits. A $60k/year job may not be as alluring when one realizes that they have to spend $15k a year after taxes for health insurance for them and their family.
Re: (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 hap
Re: (Score:2)
It should be noted that I base this mostly of experience with the Swedish low level government, but I get the impression government work pretty much the same everywhere.
"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."
It doesn't matter if that sort of thing happens in the private sector
Re: (Score:2)
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.
1) We own the government, so we all own the code?
2) It seems to me that vendors are more interested in selling you support for the software. That has no end of life.
3) Until the folks who wrote it leave for other jobs, and they leave behind all that lovely documentation....
4) Until someone makes new *faster* hardware that has no compatibility with the old hardware.
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.
Re: (Score:2)
In house software for government jobs is the way to go. 1) ... 4) ...
You seem to have left off 'junkets to the tropics' from your list. Perhaps that was an oversight.
Re: (Score:2)
That's an accounting problem, not a technical problem. It can be solved quickly and easily. Raise the pay to whatever is necessary to attract appropriate talent. HR departments across the world somehow manage to figure this out. I know government jobs are fond of pay grades and other such nonsense, but if our legislators gave a crap about the security and prosperity of our nation they could fix the issue in an afternoon.
What? (Score:4, Insightful)
1. Why indeed, Marcus, "coding" and "printing" are so similar.
2. And the shelf-life of that software "reserve" is...
Re:What? (Score:5, Insightful)
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.
Re: (Score:2)
I would argue that the more general the software, the longer the shelf-life, the more specific the shorter. The main reason for in-house (or custom) software is specific purpose application. The two examples you provided have very general use - in the sense that Math and editing are general and constant over the long term. But, for example, network / system monitoring or battlefield management software is
Re: (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 cont
Re: (Score:2)
Re: (Score:2)
1. Why indeed, Marcus, "coding" and "printing" are so similar.
Sure, the end products are pretty different... But most folks just buy off-the-shelf paper for their needs. Or maybe outsource the custom printing to someone else. Just like most folks buy off-the-shelf software or outsource the custom coding to someone else.
If you move enough paper... Or have unique needs... Or are concerned about the authenticity/security of your printed documents... Then moving it in-house makes a lot of sense.
Similarly, if you use enough code... Or have unique needs... Or are co
Re: (Score:2)
Where do you get this idea? Upgrades are not mandatory. They're often not needed at all.
Obviously it depends on the software...
Nobody is going to force you to upgrade the copy of Microsoft Word installed on your home computer.
But the HIS software we run at work has to be at the latest version if we want to be able to receive support. And support is kind of a big deal for us.
Re: (Score:2)
shelf life is a good point
If you want to consider software that is immeadiately vital, you would look first at software that was directly embedded in the physical production process. Just looking at current popular concerns that match this, consider electrical utilities and freight transportation.
If you are looking at electrical utilities, you see 50 year old software, which is pretty good for a shelf life.
On the other hand, in a sensible society, you produce a lot of machine tools, and you make lots of co
Poor comparison (Score:5, Insightful)
"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...
Re: (Score:3, Insightful)
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...
We do engineer the documents though. We specify what kind of paper, what kind of markings, what kind of anti-forgery devices.
Of course, I was under the impression that we also specified what kind of code to write... Is this no longer true? Is the government just basically buying off-the-shelf software these days?
Does Intuit make some kind of IRS Edition of QuickBooks?
Re: (Score:2)
In general, we don't specify strong enough requirements and we don't do sufficient validation. Of course, validation of software is hard when you have the source and is nearly impossible without it.
Re:Poor comparison (Score:4, Informative)
Actually yes there was a big push for COTS software in government a whiel ago. The idea was that it would reduce costs, but it was a short term cost reduction with a long term significant cost increase. The problem is that those doing procurement often are not responsible for long term negative effects, because they will be long gone.
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 re
Re: (Score:2)
Except neither you, nor the author of the TFA, seems to realize that Government Printing Office isn't a printer (in the normal sense of the word, though it does
Re: (Score:3)
Actually, I do realize all of those things, it was just a lot easier to say "printing" than "the set of tasks that the
Re: (Score:2)
That assumes that there are developers in IT.
Because we don't need one. (Score:2, Funny)
Re:Because we don't need one. (Score:5, Insightful)
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.
Re: (Score:3, Insightful)
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.'
Just what we need ... bring back Ada !!! (Score:2, Insightful)
That worked so well, I mean it's just ubiquitous now with overwhelming support right?
Re:Just what we need ... bring back Ada !!! (Score:5, Insightful)
Re: (Score:2, Insightful)
While you're at it (Score:2)
Don't forget about hardware.
Oh, wait...
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.
Re: (Score:2)
Eek.... 3.2.5.x? That should have been killed off with a flaming chainsaw a decade ago. Heck, even an old 220 with the abacus in the back would run 4.x without issue, much less a vintage H50 still in the rack.
Here is what I'd do (assuming a perfect world):
In the hardware department, I'd see if the old AIX machines can't be upgraded (I've seen some embedded applications that depended on a hardware/OS stack which could not be upgraded without a complete retool of a lot of physical robotic hardware, so even
Re: (Score:2)
I've seen people do the same thing but with hostnames. And because the in-house apps had the names hard-coded, it was well nigh impossible to change them. At least adding proper names in DNS helped mitigate that a bit once I convinced the PHBs that naming the DNS servers "dns1" and "dns2" instead of zwerty and azerty (not using the real hostnames) were not going to have any impact to the security of the institution.
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: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.
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
Re: (Score:3, Insightful)
When I said "genuinely open source software" I did not mean that it necessarily had to be released under the GPL and publicly available on an FTP site somewhere.
I mean that upon delivery of the software to whatever government office, full source code was provided as well.
Maybe the government wouldn't do a thing with it... But at least they'd be able to compile their own binaries and check them against those that were delivered. Or just use them instead of the binaries delivered. And they could easily aud
Re: (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 t
Analyzing the code is not enough (Score:2)
No, the highest security systems must be based on a codebase that is controlled by the government from the ground up, and implemented in languages that are not as susceptible to bugs and mistakes as C++ is.
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: (Score:2)
This country was not started by a militia, you idiot. It was started by people who managed to sway the public to march and die for a cause that really didn't exist.
Re: (Score:2)
A bunch of anti-royalist terrorists.
More like a bunch of anti-Corporatist terrorists. At least if you ask MS or some of the other Corporations that are ruling this country.
Re: (Score:2)
The people who do open source are decidedly not like the founders of this country, whose primary beef was taxation without representation and the continued stationing of British troops here--in people's homes no less.
I think it's far more similar than you give credit (Microsoft Tax). Proprietary code, formats and protocols encumbered with anti-capitalist monopolist IP protections versus open code, open formats and open protocols that allow capitalist competition based on products meeting consumer needs. The incumbents in the tech industry, just like those in the content creation industry, are trying to use anti-capitalist IP laws to control the industries so they don't have to compete in the new technologies that are ma
What the hell is a strategic software reserve? (Score:4, Insightful)
Seriously. WTF. How can anyone ask that question and expect to not be laughed at.
Re:What the hell is a strategic software reserve? (Score:5, Funny)
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."
You mean like Magic Lantern? (Score:2)
We've had this. It was called Magic Lantern [wikipedia.org]. Really, I think we can do without any more of it.
And where will the secure coders come from? (Score:2)
I concede the point that government and industry are awash in misconfigured, insecure, and buggy code. However, I fail to see how developing more code in-house will result in code that is more secure and less buggy. Where will the expertise in secure coding come from? From TFA:
So, if that is true, how exactly will it coding in-house help? There's no one in-house who can do it
Re: (Score:2)
Re: (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
We already have a secure coding office... (Score:2)
Here's the link: http://www.nsa.gov
Re: (Score:2)
That just sweeps vulnerabilities under the rug... (Score:2)
Re: (Score:2)
"You now have isolated code custom built for each group"
How would having many small software piece that is open and used throughout the country lead to that?
"At least with commercial software there is a larger audience
false.
" to find and fix security holes "
ohn yeah, corporation are real well know for jumping on security holes~
" exploited there is an accountable party to hold responsible for fixing it."
yeah, try holding a private company to that. good luck.
With a government body there is a specific person y
So where does the OS come from then? (Score:5, Insightful)
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.
What's that expression... (Score:2)
Something about not reinventing the wheel.
Ahhh Marcus.... (Score:3, Funny)
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.
The COTS battle is over, get over it (Score:3, Insightful)
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.
Isn't it obvious? (Score:2)
WTF? (Score:3, Insightful)
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?
Re: (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
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.
Not a proper role for government (Score:2, Insightful)
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. [bbc.co.uk] All in the name of security? Yeah right.
Re: (Score:2)
Government doesn't need to innovate in software. The point of a GSO isn't to create new products, it's to provide secure services to government agencies. Nothing they would need to do would be more complicated than building existing functionality in approved ways--and if the NSA can do it, then a more general government department could as well.
Seriously, the IRS doesn't need innovative software, it needs to be brought up to 2005.
We need a few very secure systems (Score:3, Insightful)
We need a few special-purpose boxes that are highly secure, as examples. The components exist. There are hypervisors certified to EAL-7. [lynuxworks.com] 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.
Thanks Ric Romero, the Government is Incompetent (Score:2)
Basically the article is saying that the government is incompetent and then comes to the logical conclusion that adding a new layer to the government will fix the incompetence. It's completely rational!
Well, no. (Score:2)
"Our own software is probably a greater threat to us than anything other people can do to us.'"
No.
The greatest threat of all was that our own business leaders would decide to ship millions of engineering jobs to China and India.
Re: (Score:3, Insightful)
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.
Re: (Score:2)
we don't make enough software we ......?
Re: (Score:2)
we don't make enough software we.......?
It isn't a matter of making enough software. Nobody is suggesting that the government code up five different word processing packages and sell them to the highest bidder. It's about knowing that the software running our essential government functions is reliable.
At the end of the day software is just yet another export product
No it isn't. It's a tool that lets people get their jobs done.
the country doesn't literally die if it fails, you'll just have to live with it being slightly less prioritized.
Depends on what fails.
If the word processor on some senator's desktop dies, I doubt if anyone is terribly inconvenienced.
If something big and important breaks at the IRS, it may very w
Re: (Score:2)
fall back into a 3rd world, fail to be able to support are current society, and loose are place at the big boys table.
IN general, the US provides plenty of food. We are now past that.
Re: (Score:2)
Because inhouse software is famous for being so much better in those respects?
I don't know how it works in the US, but in Sweden when the government needs some sort of custom software made they write down the exact specifications they want and get it ordered. That is as far as I can tell the exact same process you'd go through when ordering it inhouse.
It's irrational to believe that the contractors would be any worse at writing the code then inhouse.
Re: (Score:2)
That really depends on what you're trying to do. I think it's ludicrous to expect the government to write it's own OS/browser/text editor. When you're doing some generic task then generic off the shelf software is best for the job. Custom software is only viable when you're doing something rather specialized.
utilities (Score:2)
I'm in Canada, so things are a bit different. Generally I've found that things that are "utilities" (that is, basically necessary for normal living) are provided quite efficiently by the government.
My car insurance is via the provincial insurance company and the rates are some of the best around.
My phone and internet service is via the provincial telco. The rates are competitive and there is no usage cap.
Electrical and natural gas rates are via the provincial corporations and their rates are among the lowe
Re: (Score:3, Insightful)
Who says the government code wouldn't be open source?
For the people, by the people eh?
Re: (Score:2)
However, for security reasons, the software has been declared secret under the states secret act.
Re: (Score:2)
Not necessarily, take SE Linux, for example.
Re: (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 jo
Re: (Score:2)