A Common Criteria Primer

This is an expanded version of a document that I wrote for Red Hat internally. I’m now sharing it with all of you because I find myself reciting this information at least once a week. I hope you enjoy it. Please keep in mind that I’m not a lawyer, DAA, or procurement officer. All the information contained in this post has been cobbled together from years of working with government procurements. It’s hopefully useful. It’s definitely not authoritative. It definitely has nothing to do with my employer.

Common Criteria is an internationally recognized process for evaluating the security features of a product. The certifications are focused on IA and IA-related software. Operating systems, directories, firewalls, etc. The high-value stuff. If you’re asking yourself “What software isn’t IA or IA-related?” hang in there. This is going to get hilarious.

In the US, Common Criteria is handled by NIAP. Other countries have their own CC authorities. Each authority certifies CC labs, which do the actual work of evaluating products. Once certified by the authority, based on the evidence from the lab and the vendor, that certification is good in every country that participates in Common Criteria.

When you get something certified, it’s for a “security target” or the “target of evaluation” (TOE). The target is a combination of software, documentation, and sometimes hardware. In the documents, the vendor claims that the target meets one or more Protection Profiles. There’s a list of them here:

http://www.commoncriteriaportal.org/pp_OS.html#OS

You can also make up your own protection profile if one doesn’t exist.

When you’re certified, it’s at a particular “Evaluation Assurance Level,” which (roughly speaking) represents the “strength” of the certification. So we’re more sure of EAL4 than we are of EAL2 for a given profile. Most folks just pay attention to the assurance level, and completely ignore what you’re being assured of, which is a mistake. The EAL is meaningless unless you know the profile (what claims your making) and the target (what you’re making claims about).

The evaluation itself takes months and can cost millions of dollars. The labs will pour over the claims, the target, and the vendor itself. They want to make sure you exist, that you’re using good development practices, and that your software does what you say it does. It’s a tremendous effort.

So.

Most customers only care about CC because their security or procurement folks are bugging them about it. Sometimes, CC isn’t strictly required but is still useful because it will make an accreditation process simpler: DCID 6/3, DIACAP, etc. But where does this requirement actually come from?

NSTISSP (National Security Telecommunications and Information Systems Security Policy) #11 was issued by the Committee on National Security Systems (CNSS) in 2000. These guys set national information assurance policy. They say that when anyone in the Executive Branch buys a commercial product that does information assurance, that product has to be Common Criteria certified. That rule gets implemented through other policy, like the DCAS-1 procurement rules, but NSTISSP #11 is where all the other policy flows from.

So who needs to be certified, really? Great question. The answer is in Section II, Question 1 of the NSTISSP #11 FAQ. Go read it. I’ll wait.

Got that? If you’re using “IA or IA-enabled” software, Common Criteria is mandatory. Here’s your buying guide:

1. Buy a product certified with a US Government-developed protection profile. If that doesn’t exist, go to step 2.
2. Buy a product certified with another government’s protection profile. If that doesn’t exist, go to step 3.
3. You buy a product and contractually obligate the vendor to eventually certify under a protection profile that has the capabilities you need.
4. There is no step 4.

Note that there’s no provision for something that isn’t certified. That’s because it’s not allowed. Even if you have to develop your own protection profile, you need to use a certified product, or a product that’s “in evaluation” to be certified.

If that sounds expensive for the vendor and the government buyer, you’re right.

So back to the question you asked earlier: “Isn’t everything IA or IA-enabled?” Basically, yes. Check Section III, Question 3 of the FAQ. This is the problem. Even in their answer, they mention that “security-enabled web browsers” have to be certified. Do you know how many browsers have actually been certified? I’ve looked, and I’m pretty sure the answer is zero.

When these rules were developed, security technology wasn’t as pervasive as it is now. The original idea, and it’s a good one, is that things like operating systems and firewalls should be certified, but Microsoft Word is off the hook. But we now live in a world where even Microsoft Word can use cryptography to sign documents, authenticate authors, and so on. So you can make an argument that just about any software that requires a username and password must be Common Criteria certified.

This is, of course, impractical. It’s expensive for vendors to certify their products, and that makes it more expensive to buy those products. Requiring certification also significantly narrows the field of available products. So in practice, DAAs (the security guys) will straight-up ignore the policy. The buyers will do their best to not ask questions. Vendors do their best to avoid being labelled “IA or IA-enabled” and thus avoid getting thrown on the Common Criteria track. This is too bad, because there’s obviously a need for some kind of certification.

There are many other failings of the current Common Criteria regime, but I want to keep this post pretty basic and won’t go into them here. If you’re interested, Chris Salter wrote an excellent whitepaper in January 2011 for the Common Criteria community describing these problems, and some of the ways we can solve them.

I hope this primer was useful. As pervasive as this requirement is, there are many, many misunderstandings and I wouldn’t be surprised if I got some of this wrong. Please let me know in the comments if there’s anything I’ve missed, misinterpreted, or should expand on.