Navy Now Mandated To Consider FOSS As an Option

lisah writes "In a memorandum handed down from Department of the Navy CIO John Carey this week, the Navy is now mandated to consider open source solutions when making new software acquisitions. According John Weathersby, executive director of the Open Source Software Institute, this is the first in a series of documents that will also address 'development and distribution issues regarding open source within Navy IT environments.'"

Comments

Yeah, and the USAF uses ADA

[Liquidrage]

When I was writing software for the USAF we were required to use ADA. I worked at the USAF's largest software factory. No one there used ADA for anything.

So to me the announcement means nothing. Military doesn't always eat it's own dog food.

Why the Navy wants FOSS

[greginnj]

I'm amazed at the number of people asking for cost comparisons and going on about how there are also training costs, blah blah blah. RTFA and we see:

misconceptions about whether or not open source software qualifies as COTS (commercial off-the-shelf) or GOTS (government off-the-shelf) software has hindered the Navy's ability to fully utilize open source software.

Which, if you use your critical reading skills, would tell you that the Navy is already trying to use FOSS, but is having trouble doing so. We all know about military spending -- they don't give a rat's ass about saving 10% off the fully loaded cost. What we're talking about is Naval Engineering:

The term Seabee Ingenuity grew from deeds recorded during the Solomon campaign. A Seabee Warrant Officer repurchased equipment from customers to set up shop. Bulldozer head gaskets were fashioned from scraps of metal and paper. Waxed paper and tinfoil from cigarette packages served as condensers while 55-gallon drums replaced worn-out radiators. Tires were filled with sawdust and concrete. One Seabee turned his dozer into a piece of combat equipment and wiped out a gun emplacement in the Treasury Islands. The work accomplished by these new Construction Battalions seemed almost impossible and yet the CAN DO standards set the precedence for the battalions that followed.

Now, imagine a similar situation involving software. Your control system is acting up while you're on patrol in the South China Sea -- do you send an email to Redmond and wait for the response, or do you open the hood and fix it yourself? As the pdf memorandum said:

As with any COTS solution, the use of OSS must adhere to all Federal, DoD, and DON policies and be based on open standards to support the DoD's goals of net-centricity and interoperability.

Go Navy!

Re:Great! This is what you have to do

[jd]

There are only a handful of OS' that are considered "trusted". HP-UX BLS, Trusted Unicos 8.0, SEVMS, CS/SX, Trusted IRIX, Trusted Solaris, VSLAN, Trusted XENIX, XTS-300, XTS-400, PR/SM, SACDIN, THETA and Genesis. I see a distinct lack of OS/X, Microsoft isn't even remotely close, Linux has 30% of the RBAC requirements to be really secure in a modern environment - which is better than many, and OpenBSD is only considered watertight from external attacks - it has minimal security between users.

When you consider that you can build role-based access controls that can migrate with applications across clusters, when network connection types, network bandwidth, shared memory and inter-process communication have mandatory access controls, you really begin to see just how pathetically limited generally-available OS' really are. There's no reason for it - there's nothing that prevents a widely-available system from being harder than a diamond-encrusted pulsar.

The reason that nobody bothers much with making OS' secure is that the DoD has long-proved (by buying Windows and by failing their security audits) that security doesn't matter enough to be worth the effort. Security to this level costs big money, and only the really big corporations can afford the costs or have the market to pay for it. Companies can lose hundreds of thousands of credit cards and maybe get rapped knuckles - if they're even discovered. Only one State requires reporting - but plenty of other places have e-Commerce. System crackers - black hats especially - are a pervasive part of society with no serious effort to secure networks against them.

If the money did exist, if there was serious interest in serious prevention, host intrusion detection wouldn't be MD5 checksums (which were beaten soundly, according to the Internet Auditing Project). Plain-text passwords wouldn't exist. One-time pads and public-key encryption would be the only way to log onto Slashdot or any other web service. Zombies, Trojans and Viruses would be found in technology museums, under "extinct electronic lifeforms". If a disk drive with tens of millions of credit cards or social security numbers went missing, in a secure world that would be cause for a few minutes downtime to replace what was lost, rather than a few weeks or months of running round in circles doing nothing.

You see any of that happening? No? Then security is still regarded as an optional extra, not as a fundamental design requirement, and will never reach its true potential. Furthermore, agencies will continue buying/copying OS' based on ease of initial deployment and not on whether it'll protect the data sufficiently.

Re:Cool!!

[init100]

Of interest would be the clause about internal use - if one government agency modifies it can any other use it without requiring a broader release of the source?

No, this would not require a broader source release. Contrary to common belief, the GPL does not require that source must be published to the world when software covered by the GPL is distributed, only that the source is distributed along with the binary under the GPL. The recipient is free to publish though, so there is usually not much to gain by only distributing to your customers.