Slashdot Mirror
SUSE Awarded EAL4 Certification
An anonymous reader writes "Following in the wake of its previous certifications, Novell's SUSE Linux Enterprise Server 9 has achieved EAL4 certification on 'an IBM eServer.' This puts SLES9 in the same league as Windows 2000 for sales in the government sector and is the first Linux distro to achieve an EAL4 certification."
Also means it's surpassed windows XP and 2003. These as far as i know (big statement) have not made these certifications yet.
Not likely to happen soon. Just because it's been EAL4 certified doesn't mean that is allowed to be operated on a Federal network. In the case of DoD network, it still needs a CTO (Certificate To Operate) before being allowed to be connected to the network. A CTO requires a whole DITSCAP session, formal documentation, evaluation and recommendation. For an operating system, it could literally be years before a CTO is produced. An interim CTO could be generated, but I don't think any major commands are willing to risk issuing one for such an unknown as this.
CC evaluation is not an automatic thing. The sponsoring company (in that case Microsoft) pays for the evaluation. A target is generated, which details hardware and software configurations. This can take months. Then the actual platform itself is evaluated, which can also take months, especially if deficiencies are found and corrected. Win2k was released in 2000, but didn't get CC evaluation until 2004. There's a hint.
Copy/paste from the link under EAL4 :
"The evaluation levels are ordered hierarchically in increments beginning from EAL1 to EAL7, with each level requiring a more advanced and intense means of testing. To date, EAL4 is the highest level certification awarded to any security product in the market."
Sig (appended to the end of comments you post, 120 chars)
The EPL (Enterprise Product List) only lists software that is allowed to run on a Federal network. As long as the system isn't connected to a Federal network and meets the requirements of the contract in terms of reliability, security and auditability, there is nothing to say that a contractor couldn't use SuSE or even RHES (was evaluated EAL3) unless it was expressly forbidden in the contract.
That was Windows NT, and the setup also mandated that there be no removable media. However, that was for a secure non-networked workstation, which have their uses in some cases.
You can never go home again... but I guess you can shop there.
Have fun !
There aren't any battleships currently in commission in the US Navy, all have been either scrapped or mothballed. You're probably thinking of the prototype cruiser that made all the headlines. It was running NT, bluescreened and the ship was stuck. Not that the bluescreen was not an OS error, but an error due to a divide by zero from the application, and it wasn't written well enough to handle that error nicely, so the OS did what it was supposed to. The ship was rushed anyway, and supposed to have Unix backends for all the C^2 functions. NT is just for the user workstations.
The US retired the Rainbow Series a while ago, but EAL4 is about a close approximation to C2.
it is expensive and has a certain cache
It's cachet, not cache. Cache is storage; cachet is that certain attraction.
Cache is pronounced "cash" cachet is "cashay".
Get it right, people!
Linux didn't achieve it.. a specific distribution by SUSE did. The documentation and implmenetation designs are by suse.
The certification doesn't require documenting all the code.... it's more about overall system design,the security model, user authentication, etc.
Amongst the things required to make Windows NT 3.5 C2 compliant were disconnecting the removable media, removing the network connection and disabling the OS/2, POSIX and DOS subsystems. Amongst other things.
After you were done doing this, of course, NT 3.5 was only useful as a kiosk. Most applications that would benefit from C2 certification in the past were 'stovepipes' that don't interact with other applications, so this was okay.
This isn't poking fun at MS. This is how it got certified. Then, they assumed that 3.5 being C2 certified meant NT 3.51 and 4.0 were. They were incorrect.
HBI's Law: Frequency of calling others Nazis is directly correlated with the likelihood of the accuser being Communist.
I don't know where you are getting your information from... But I work for the DoN and the DoD and we are in the process of deploying a large number of Red Hat Enterprise Linux boxes right now. The EAL4 certification means QUITE a bit, we could have deployed SOME Red Hat with only EAL3 certification, but we couldn't deploy Red Hat at any deeper classification level without EAL4.
FIPS is a compliance level for encryption, and seeing as that it isn't hard to add this ability to applications, I'm not seeing that as a problem. We are already allowed to run apache and apache2 on Red Hat, actually, we haven't really run into any application we aren't allowed to run because of it failing to meet any certification level.
As for NMCI, last time I checked they don't support ANY Unix/Linux. Maybe its just where I work, but I have a feeling it isn't. Also, they aren't failing to support Unix/Linux because it doesn't meet any certification levels, they are failing to support Unix/Linux because they don't have the resources to do so. At my installation, this is the exact reason they mentioned.
Disclaimer: I work for the IBM Linux Technology Center; any comments I make are entirely my own.
It's really a matter of money and time.
And blood, sweat, and tears. You're talking to a guy who spent countless hours drafting hundreds of pages of low-level design documentation on the Linux kernel and set of trusted userspace applications in order to help satisfy the CAPP/EAL4 requirements. True, IBM paid me to do it, but the effort is far from trivial, and Linux's reputation gets a nice bolster when things like security certification happen.
Back when my team achieved CAPP/EAL3 certification, the general attitude on Slashdot was, ``Great, but wake me up when we get EAL4.'' Well, now we've got EAL4. We have a secure protection profile ironed out, documented, and deployed, which helps immensely with setting up a locked down Linux box. We have engineers who have been given the job to review thousands of lines of source code and to write and run a battery of tests to verify that Linux kernels and applications really do, from a security standpoint, just what they claim to do, and they do it right. But I think, more than anything, that this is a strong indication of Linux's maturity. For the public sector, this satisfies a core requirement of many contracts. For the private sector, this is one more thing to impress the boss when advocating Linux solutions.
An unjust law is no law at all. - St. Augustine
But Novell/SuSE also deserves credit for running a top-notch configuration management system (Autobuild), having controls and procedures for keeping track of where which patches that get incorporated come from, and for having a patch notification and publication process that enables customers to get timely notification of necessary patches.
The business processes surrounding manufacturing the distribution and supporting customers on a global basis are valuable Novell/SuSE contributions.
Disclaimer: I work for Novell and work with the folks at SuSE on a daily basis.
Security? That thing has more holes than swiss cheese! All applications are run on a single box, with clients connecting via Citrix. That box is typically Windows. Windows doesn't have Orange Book B-grade compartmentalization. This means that if you were to break into that box, you would see absolutely everything that everyone is doing.
Connections are secure, using client-side and server-side certificates. That's the one piece of competent engineering in the whole bundle. However, because of the total centralization on an insecure platform, it is totally wasted. The security is no better than the weakest link. Beefing up the network security is good, but because clients and servers are all insecure systems, what good is it?
The next part of NMCI is the enforced seperation between unclassified and classified networks. That is good, but it was largely the practice anyway so that offers no advantage.
Lastly, NMCI install contracts tended to be politically awarded, rather than based on technical merit. The installers had minimal or no clearance. Anybody could be an installer. It was a minimum wage (or less) job. With anybody being able to do the installs, and nobody with any skills wanting to, any of those machines might have a rootkit or a stealth virus. There would be no way of knowing and, frankly, I wouldn't trust any of those I worked with to be able to run the necessary tests.
Result? The security benefits are practically nil, because you can't trust anything that does work, and you can't even trust any component of the system TO work.
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)