Slashdot Mirror
DoD Wary of That "Open" Word
joabj writes, "Why is the U.S. Defense Department still reluctant to use open source software, despite assurances from within the DoD itself? Blogging for Government Computer News, I found at a recent D.C. conference that to some extent the roadblock might be with that word 'open'."
I gather it is because of the act of taking on the responsibility of making a solution fit the problem. In a commercial or consulting role, someone claims to have a solution ( or be capable of creating one) that will solve the problems at hand. When a manager ( especialy within the DoD) gives the okay for a canned solution, the responsibilites are already diluted, meaning that if the solution has already been working for others, it is safe to assume that it will work for your organization. If it fails to do so, the manager can point to the other successful implementations and list the differences between your actual needs and the products capabilities. The vendor can then tailor the app more closely to your needs and the manager still looks good.
If we apply the same standards to Opensource, we can look at established projects like Apache, Mysql or even Openoffice and they are still safe because others are successfully using the software, it is not really a matter of a central point for support. For a manager to okay a more obscure project for implementation means taking on a much greater and unknown responsibility.
Kindness is the language which the deaf can hear and the blind can see. - Mark Twain
Because the DoD allegedly likes freedom and wants to promote it. It is their reason for existance. If "Open Source" is hurting the adoption effort use the original name "Free Software".
Just change it to "Public Source". More descriptive as well.
...is why OpenBSD is so infamous for being insecure.
http://mediagoblin.org/
Sadly, this is a fallicy that is widespread in people who are clueless about security. Take a closed source product from Microsoft for example. How many people within MS have access to that code? How many still work for MS? How many outside the US both have had access to the code and no longer work for MS?
How many are pissed that they were fired or laid off?
You have to look at security as a cost v. reward thing. It may be very expensive to obtain and reverse engineer a binary program which is used as part of a security system. But if it uses "Security through obscurity", you only have to do it once. If you use a real security system, it has to be cracked every time the keys change.
The problem is that an Open Source project would quickly become a proprietary project anyway. Take, for instance, VISTA (medical records). Yes, it's open source, hell, it was even developed by the government. However, since the VA's mission is decidedly NOT to provide tech support to the rest of the government, other departments that might use that system are left holding the bag to fully support it IN HOUSE, and that includes a metric ass-load of customization.
Where "Open Source" is really competing is in vertical, single-source support and in that department, it usually doesn't have an advantage. It's not that government is averse to using the stuff, it's just that they don't want to end up with something like the VA and VISTA where they have hundreds of full-time developers devoted to keeping it alive. They'd prefer to sign a vendor on to provide it as a service so they can get on with fulfilling their mission, not pretending to be a software development company.
The benefit of open source is that you "own" the code in the sense of having unfettered access to it and can continue developing it even if the original owner ceases to exist. However, owning the responsibility of perpetual development is precisely what government agencies DON'T WANT -- and, frankly, for good reason. They're not software companies and they're very bad at pretending to be so (take a look at the FBI case management system, for instance). When people make the case for open source on those grounds, you've just presented them with the worst nightmare imaginable, so don't be surprised if they scream and run away.
What happens if overall foreign-policy strategy, and even discrete military tactics begin revolving around a similar notion: that you use the correct means and you know the ends will be Good Things even if you can't list those Things in advance.
I'd expect you might find that you'd get the same thing that happens in software: most of the time, it's not the best product that "wins", it's the one that's fastest to market and fastest with new features, even crappy, bug-ridden features. If you have a really good army that can't manage to do anything on a timetable, you may find yourself constantly surprised that someone else has gotten there first, which is an especially compelling problem when it's lives that are at stake rather than market share.
It's better to have something that works well when it's ready, than to have a rushed half assed job that's ready much earlier, but doesn't do the job...
Especially in the military, would you want hurriedly built planes falling apart over enemy territory?
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
"When the source code is available to everyone, that also means that it's easier for the enemy to find security holes to exploit.
"Security through obscurity" isn't a bad thing. If you can manage to keep tight control over who has access to the source code, you've eliminated one more security issue. Obviously, the quality of the code is more important. But still."
Only on Slashdot would this be modded as flamebait. Use some logic people! Open source does not necessarely equal more secure. It often can, but it isn't a guarantee. Open source software usually presents an advantage only when a piece of software is popular enough to have enough devs poking at it. Yes, I know, all it takes is one person to find an exploit but I'm just trying to show that OSS is not inherently more secure.
Take this example: You have two software applications for, I don't know, missile tracking and detection. One is open source, one is closed source. Assume for now that they are equally secure. (Yes, this is possible!) Now assume that you are trying to compromise this system. You can grab one application on sourceforge while the other is completely secret. You have no idea how it works - for all you know it could do things completely different than the open source software. Which one will be easier to compromise? Now, I grant this logic doesn't really work for things like Windows XP where Microsoft and not the DoD create and maintain the software but the point remains for a number of situations that I can imagine.
I still don't understand why this whole "Security through obscurity is evil!" sound bite started. Everyone loves steganography around here, right? And I know the concept of hiding things in plain site is often discussed here in a favorable light. Are these not forms of security through obscurity (minus steganogaphy+encryption)? Would you prefer to store your Rolex in a closet safe or in a hidden compartment in the front panel of your dishwasher? And if you do choose the safe, should you advertise it? Maybe post a sign in the front of your house that says "The safe is in the bedroom closet on the right and contains a $20,000 watch. Come test my great security!" (Obviously a well hidden safe combines the best of both worlds here.)
Security through obscurity is not inherently bad. It has merit in *some* situations and to say otherwise is juvenille.
(...) we could spend a $xxx,xxx and purchase a Microsoft SQL Server license instead. When we pushed the issue, we were told that we were welcome to submit MySQL to NMCI for approval but that no one knew how to file the paperwork and no one had ever seen any software approved before.
Now, in a sane system you would ask "Show me the documentation that is the basis for Microsoft SQL Server's approval, and we'll provide equal documentation." The reason it probably does not work is that the documentation involves a large check.
Live today, because you never know what tomorrow brings
I must say, I'm really not unhappy with that. In fact, I would dislike it very much if any of my open source contributions would be used by the military (of any country). I even once considered blocking access to my web site from .mil domains. I didn't because it would be completely silly, and there is no reason to block only .mil and let all the other military through. And after all, "open" is "open", and anyway, I have neither the time nor the moral authority to decide who is "good" and who is "bad".
But nevertheless, if the military would rather not use any of my "open" code, it makes me feel better, even if it is not rational.
#include
Good lord, I actually have something to contribute!
In a nutshell, the DoD *really* doesn't like that they don't know who wrote the software, and they also don't like the lack of a central point of contact. They'd rather hire, say, $defense_contractor to write a similar piece of software, because they get a couple of reassuring beliefs (we will not attempt to discuss the VALIDITY of these beliefs, please):
1) that $defense_contractor is using properly trained, vetted programmers, with security clearances if need be; and
2) that if anything goes wrong, they can sue the tar out of $defense_contractor.
These two factors are VERY important to the DoD. Now, you can probably see the utility if the DoD has requested, say, software for their Death Ray [1], but isn't that overkill if they're trying to buy a web browser? Yes it is--but they can't help it. The DoD has LOTS of finicky aquisition rules, and they're pretty much the same whether you're buying Death Ray Guidance Software or a web browser.
In my day job, I am, among other things, involved with the government's Common Criteria Evaluation and Validation Scheme (CCEVS). Due to the DoD's acquisitions rules (DoD Instruction 8500.2), in almost all cases all Commercial Off-The-Shelf (COTS) software must have undergone a CCEVS evaluation. As you might imagine--we are after all dealing with the government--CCEVS evaluation is really REALLY expensive and takes frickin' forever.
Now, this is no barrier to Microsoft, which has had enough money and time to get Windows {2000, 2000 Server, XP, XP Pro, 2003 Server} evaluated. But, as you might imagine, it's a pretty damn big barrier to open source products. Those that have been evaluated (SuSE, Red Hat) have been lucky enough to have some heavyweight patrons (IBM and Red Hat, respectively) on their sides.
Nor is a CCEVS certificate the end of the game. DoD agencies typically must justify why they've chosen solution X over solution Y; and, while cost is a factor, it's far from the most important one. Open source products tend to come with a list of disclaimers as long as your arm (OpenSSL's FIPS 140-2 certificate, for example, says that the certificate is only good for THIS version of the source code, compiled with THAT version of gcc, THESE SPECIFIC static libraries compiled in, etc., etc.), and the guy writing up the justification paper is probably an overworked lieutenant prone to thinking "Fsck this. No one got fired recommending Microsoft."
[1] The notion of a DoD "Death Ray" is entirely a fabrication of my own fertile (if perhaps deranged) imagination. Any similarity to any actual research, prototypes, and/or super-double-secret weapon is entirely coincidental. Please don't put me in GITMO. Thanks.
Fair enough in this specific case I suppose -- however, my comments apply to any organization, particularly any large organization (as they have more money, and thus more leverage).
By way of an example, back in 2005 I attended a Health Informatics conference in Toronto, where a colleague of mine asked a panel of self-described "doers" whether or not they had considered Open Source software. I blogged about it here. In essence, they too were treating Open Source software as if it were a product that sat on the shelf, and not as something that you, as a customer, can demand. It is interesting to note that they discussed all sorts of development and partnership problems that OSS could solve for them, however collectively their attitude was pretty much to look for an existing OSS solution to their problems, and when they didn't find one, go to a commercial developer and use whatever license that developer dictated to them.
This is where organizations are going wrong with OSS. There is nothing wrong with using a commercial developer -- just mandate that the development they do for you is licensed under an OSS license. Canada Health Infoway claimed at the time they had $1.8 billion to spend in the field.
And maybe it's just me, but the customer with $1.8 billion should be the one calling the shots. The problem isn't that they lacked the clout -- only that they lacked the knowledge to know what to ask for. They are at the whim of the development companies they contract out (which has bit these people on the butt before -- there have been a number of cases in this field where organizations have spent millions of dollars and spent years having a custom solution developed, only to find that it no longer suits their current needs (which have changed since development began), and/or won't run on their current deployment environment anymore, necessitating scrapping it and starting all over again).
Yaz.
Battles are not won or lost by whoever has the best terms and conditions from the manufacturer. If you're losing, you won't be around to complain, and if you're winning, you generally won't care.
Every time a major power (such as the US) has paid more attention to giving kickbacks to corporate sponsors than it has to producing successful products or successful missions, that power has had its arse well and truly kicked. Sometimes the power wins anyway, but it is not because of its unimaginative and self-serving attitude, it is despite it. It's not very hard to win when you have total land, sea and air supremecy, and can do round-the-clock carpet-bombing campaigns. (But even then, failure of imagination is lethal. Operation Market Garden got slaughtered because of such egotism.)
Personally, I dislike military structures. I find the notion of winning an argument by having the winner define what the argument was to be primitive and tribal. However, if we're going to have such organizations, we might as well make sure they're functional and concious, rather than degenerately repeating every mistake history has ever recorded.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)