I came across this article this morning. For those of you who don't feel like reading it, basically it says that RedHat and SE (Security Enhanced) Linux are going through common criteria certification so that it can be used in the US government. Good news, right? On the surface, it would seem so - but I think it points out a problem inherent in the process. First of all, non-certified products are in use already (meaning compliance is selective anyway) and certification isn't "good news" - particularly when it comes to a "release early, release often" product like Linux.
First of all, we know it's already in use. For example, check out this article from Groklaw. Seriously, when has the fact that a platform is not EAL certified stopped it from being used by the government? After all, Mac OSX is on the federal reference architecture. The reality is: the whole EAL process (and the TCSEC process before that) is broken. As is FIPS 140. Here's why:
The DITSCAP relies on accredidation personnel within an initiative to ensure that these standards are followed. If an accreditor is not clued in to the fact that this type of certification is a requirement, they won't enforce the reg. End result: incentive for PO's to "dumb down" accreditation personnel. In point of fact, it's less expensive to have accreditors that will let something "slip by" than having accreditors that enforce. Problem #1.
Problem #2 is that these regs all but ensure that federal systems have less security than commercial systems. How is that, you ask? Specifically, a certification is invalid as soon as the product changes significantly. For example, there could be a case whereby a patch that is required to fix a security issue cannot be applied because it will invalidate the FIPS 140 or EAL cert. You disagree? Look at the list. The last version of Oracle that's certified is Oracle 9.2.0.1.0. What's the current version? How about 10g Release 2... Wow, that's a major revision. I wonder what type of security bugs have been fixed in the meantime... The same is true of FIPS 140-2. Certification trumps vulnerability fixes in every case; it also trumps common sense.
Let me tell you a little story. Back in the day, when I was working in the federal sector, the time came to deploy Citrix. This was before the CSG (Citrix Secure Gateway) used FIPS 140-2 approved cryptography. I, as the security engineer, indicated that it would be good to have cryptography on the channel due to the untrustworthiness of the network the traffic passed through. However, turning on cryptography meant that it would be a non-FIPS device; keeping it off meant it wasn't a cryptographic device and therefore FIPS 140 didn't apply. The decision? Keep cryptography off, and thereby decrease the security of the system in order to comply with the reg. In other words, don't think, just comply.
Here's my point: I think the purpose of FIPS 140 and the EAL is to keep "snake oil" out of the federal government. That's a great goal. However, in practice, I think these regs need to be applied with intelligence. Taking away the ability of security folks to use their intelligence decreases the security of the systems involved and is not a good thing.
Posted by Ed at September 28, 2005 11:37 AM