Common Criteria: What Some Vendors Don’t Tell You

via webdesign-guru.co.uk

…and some New Developments.

A Little Background

Since the European ITSEC and US TCSEC product security evaluation mechanisms were merged into the Common Criteria in around 1998, lots of vendors’ product literature has sported EAL numbers regarding how well-tested their products are. What isn’t typically seen in such documents, though, is detail of the properties the products are tested against.

In reality – as described at the definitive source of All Things Common Criteria, http://www.commoncriteriaportal.org/ – a Common Criteria Certification involves a Target of Evaluation (TOE), this being a defined configuration of hardware and software, which is tested against a set of Protection Profiles (PPs) to a degree of rigour specified by a numeric Evaluation Assurance Level (EAL). This testing is done in the UK, Canada, Australia and New Zealand by an organisation certified to operate as a CLEF, and in the US by an organisation certified to operate as a CCTL; other nations which have signed up to the Common Criteria scheme (Canada, France, Germany, Austria, the UK, the US, Australia, New Zealand, Finland, Denmark, Greece, the Czech Republic, Israel, Italy, the Netherlands, Norway, Sweden, Spain, Japan, South Korea, Malaysia, Singapore, Turkey and Pakistan, at the time of writing) have their own certified testing organisations, but it’s probably CCTLs and CLEFs which do most product testing.

The Question at Hand…

So, if a Certification involves a TOE, one or more PPs and an EAL, why do vendors typically only quote the EAL?

The short answer is “I don’t know”.

The longer answer goes along these lines:

Targets of Evaluation

TOEs, as they involve both hardware and software, tend to be pretty large documents and can date quite quickly; this is probably why vendors don’t quote them. A Common Criteria certification at EAL4 typically takes 12-18 months, and as motherboards (especially in the x86 world) have a product lifetime between release and being superseded which can be shorter than this, a TOE for a general-purpose computer rather than an a bespoke appliance can often refer to kit which has been end-of-lifed. In these circumstances, the TOE can still be a useful guideline as to whether a certification can still be considered valid on newer hardware, in terms of commonality of CPU type, network adaptor type, RAID controller and storage type, etc, but it’s only definitive for the hardware it specifies.

Practically, for customers with security policies which insist on Common Criteria certified products, it’s down to the vendor and the customer’s Security Officer to get together and agree whether the differences between the evaluated configurations in the TOE and the configurations being sold, are acceptable or not.

Protection Profiles

Over the last couple of years, there’s been a bunch of changes around Protection Profiles; these define the security properties which are tested in the evaluation and certification process, and the full set can be found at http://www.commoncriteriaportal.org/pps/ .

A PP set you’re still likely to see mention of, owing to their longevity and therefore the number of general-purpose operating system products certified against them, are the Controlled Access Protection Profile (CAPP), the Role-Based Access Control Protection Profile (RBACPP) and for environments which can handle multilevel and cross-domain security, the Labelled Security Protection Profile (LSPP). While these profiles were retired a couple of years ago, the properties they pertain to have effectively been subsumed into sections within the Operating System Protection Profile (OSPP). Briefly, they deal with the following:

CAPP is mostly abut keeping unauthorised users out of a system – and out of parts of a system they aren’t supposed to be in – so it concentrates on authentication mechanisms. Once valid users are authenticated to a system, it also covers elements of discretionary access control, in terms of file ownership and access permissions, and coarse-grained user privilege.

RBACPP deals with finer-grained user privilege models in the context of roles, users being able to assume and relinquish roles securely, the management of user role assignment, and auditing of user activity.

LSPP deals with labels (which are typically mapped to Government protective markings, codewords etc), their assignment to devices, separation of data and activity at different labels, controls and mechanisms for moving data between labels, and mandatory (rather than discretionary) access control.

After these PPs were retired, they were superseded by Medium- and High-Robustness Protection Profiles (MRPP and HRPP) in an attempt to simplify and re-characterise the PP system for operating systems; disagreements meant that these PPs never really “took off”, and so OSPP seems to have now come to the fore. In fact, the news which prompted me to write this article is that Solaris 11 has just been put into evaluation against OSPP with a set of extended packages: AM – Advanced Management EIA – Extended Identification and Authentication, LS – Label Security, VIRT – Virtualization.

While I have yet to read OSPP in detail, it seems a reasonable assumption that EIA and elements of AM packages functionally replace RBACPP, and LS replaces LSPP.

Back to that Question…

So the question remains, why don’t vendors typically quote the PPs their products are certified against? Listing a few PP acronyms along with an EAL doesn’t strike me as onerous – although OSPP now complicates things for CC “old hands” as they will also need to ask about extended packages – and realistically, an orphaned EAL without a PP to associate it with, is effectively meaningless unless there’s a “+” on it.

(A “+” on the EAL, by the way, simply means that it includes adherence to ALC_FLR.2, which is a US Government requirement for a vendor to provide timely maintenance patches over the lifetime of the product. The UK has typically ignored the “+”, but I suspect people here are now starting to recognise its value.)

Also, the international Common Criteria agreement requires signatory nations to accept certifications performed in other member countries up to the level of EAL4; this is one of the reasons why most product certifications aren’t done to greater rigour. If you see a product certified to an EAL >4, be sure to ask whether the higher-assurance certification has been done in your country; you can’t assume it will be considered >4 if done elsewhere.

A possible answer to the question is that Common Criteria certification doesn’t have to be performed against a PP listed in the standard set; a vendor can write their own, although with the exception of virtualisation (until recently) the standard ones were preferred, as many of them were written by organisations such as the NSA and are therefore necessarily unbiased. For example, virtualisation was a special case until SKPP, the Separation Kernel Protection Profile, came along, as the other PPs simply didn’t ask the questions about guest environment isolation most pertinent to virtualisation security. A product listing well-known PPs along with its EAL would naturally look “better” than one not doing so, even though it might not be – an appropriate interpretation of a lack of listed PPs would be to ask what they are in any case, and if vendors state in response that they wrote their own, then those profiles should be examined to get a view on their comprehensiveness.

If you want to take a look at the definitive set of product certifications, including TOEs, you can find them at http://www.commoncriteriaportal.org/products/ . TOEs – and especially PPs – are very detailed documents, though, so be prepared to spend several hours with a mug of your favourite caffeinated beverage, reading.

Some Final Context

It’s also worth being aware that, while Common Criteria has Protection Profiles which cover cryptographic products, these don’t actually get used much; for Government use, most nations have their own schemes (in the UK, hardware security modules and in-line data encryptors are typically certified under the CAPS scheme, which is run by the very nice people at CESG), and in financial services, where the primary goal is meeting PCI-DSS requirements, the US-originated FIPS 140 standard has become the de-facto one.

Finally, it hardly needs saying that Common Criteria certification ages with the product; certification at a point in time is no guarantee of resilience in the face of future threats.