Common Criteria — Part 1

By Seth Ross

Evaluating and buying computer security products can be a daunting process. Hundreds of vendors sell thousands of products across dozens of product categories, many of which are new: firewalls, Virtual Private Networks (VPNs), Intrusion Detection Systems (IDS’s), Public Key Infrastructures (PKIs), secure operating systems, tokens, biometrics, etc. Even figuring out basic security needs and requirements is a challenge, especially for new kinds of products that respond to new types of threats. Once the requirements are successfully analyzed, it is difficult for buyers to match their requirements to the assurance measures offered by vendors, which are often expressed in vendor-specific or niche-specific terms.

Assuming that buyer requirements can be aligned to seller offerings, buyers must still beware: Computer security products are complex. This affects buying in two ways. First, the computer security market is full of snake oil offerings, products that sound good enough in marketing literature but fail basic security and quality tests in the field.[1] Second, one-by-one product evaluation is time-consuming, expensive, and unavoidable unless the buyer is willing to fall back on vendor reputation, which is difficult to measure.

Wouldn't it be great if buyers and sellers could reference a common language for describing what they need or have to sell? Wouldn't the efficiency of the marketplace be improved through a certification system in which products are evaluated by trusted third parties using consistent methods? Shouldn't such a system be accepted and useful across international boundaries, so that buyers and sellers can trade goods globally?

These are rhetorical questions since such a system exists: The Common Criteria Evaluation and Validation Scheme (CCEVS, or just "Common Criteria" for short). Designed in the 1990's to replace a series of US Department of Defense guidelines and various schemes implemented by the defense agencies of Western nations, the Common Criteria provides for the evaluation of computer security products by trusted third party labs according to a standardized set of criteria.

The Common Criteria is an international standard (ISO 15408) that was developed by the United States, Canada, France, Germany, the United Kingdom, and the Netherlands. The standard has been additionally recognized by Australia, New Zealand, Italy, Spain, Norway, Finland, Greece, Sweden, Austria, and Israel. In the US, the program is managed by the National Information Assurance Partnership (NIAP), a joint activity of the National Institute of Standards and Technology (NIST) and the National Security Agency (NSA).

You can find out more about the Common Criteria at the NIST web site:
http://niap.nist.gov/cc-scheme/index.html
or at
http://www.commoncriteria.org/

The Common Criteria provides a universal set of requirements for the security of information technology products. It speaks to the protection of information against unauthorized disclosure, modification, or loss of use; in other words, the C-I-A of computer security: Confidentiality, Integrity, and Availability.

The standard is built around a 354-page encyclopedia of security components (Part 2 of the standard).[2] The components are concerned with four general areas:

1. The security environment that the product runs in, including the physical environment, the information assets that need protection, the purpose of the product, the threats present, assumptions about the environment, the organization security policies;
2. Security objectives that address the threats, assumptions, and policies;
3. IT security requirements that address the security objectives;
4. The product specification that addresses the IT security
   requirements.

+ physical environment
+ assets that need protection
+ purpose of product
= security environment

+ security environment
+ assumptions
+ threats
+ policies
= security objectives

+ security objectives
+ CC requirements catalog
= security requirements

The security requirements, in turn, become the basis of a product
specification.

In a typical certification scenario, a product vendor will submit the product, a summary specification, and the Security Target document to a government-approved but independent evaluation lab. The lab evaluator first evaluates the Security Target, and then evaluates the product against the Security Target. If the product passes, the lab will report to a government validator, and if the validator accepts the lab's report, the product vendor is awarded a certificate. In addition, the certificate, Security Target, and other reference materials are posted to a site run by, in the US case, NIST. You can find a list of products certified in the US here: http://niap.nist.gov/cc-scheme/ValidatedProducts.html

There are many more complexities in the Common Criteria scheme, including Protection Profiles — a type of Security Target that formalizes the buyer's perspective ("this is what I need") — and Evaluation Assurance Levels (EALs), a coarse grading system that runs from one to seven. I will cover these in the next issue. For now, I'd like to finish with a simple analogy designed to provide the feel of how the Common Criteria process works.

Imagine that you have a valuable jewel. You want to protect it. It's currently kept in a room in your house. You make the assumption that the jewel is valuable enough for others to want to steal. Professional jewel thieves present a threat to the jewel. So do some of the visitors to your house (the handyman, friends of friends, a child). As a matter of course, you want to control access to the jewel at all times so that only you, or someone you authorize, can pick up or handle the jewel.

By analogy, the jewel is an information asset, and the paragraph above is the opening section of a Security Target, defining assumptions, threats, and policies.

Working from assumptions, threats, and policies, you establish a security objective: you want to lock down the jewel. The jewel will be stored in a container secure enough to prevent casual theft and accidental loss. Given these objectives, you set requirements for the container: it will have a unique key; the key will be portable so that you can keep it on your person; in case you lose the key, the container supplier can issue a replacement key given that you store information about the container and the key in a secure location. The amount of effort required to break open the container should exceed the value of the jewel. The value of the container will not exceed the value of the jewel.

Armed with these requirements, you start shopping for a container. You can compare the specs for various lockboxes and safes against your requirements: you can't afford to build a bank-style safe, but you want to prevent an opportunistic thief from gaining ready access. You find a container from a reputable vendor that claims to provide 1) a lockbox that will resist an unskilled attacker for several hours; 2) a lockbox with a unique keying system, and 3) customer service on replacement keys, all at a price that's less than 20% of the value of the jewel. Should you buy the container?

In an ideal world, the vendor has submitted the lockbox to a trusted third party evaluator — it's already certified for the kind of protection you need. You buy the lockbox. Otherwise, you could take a sample lockbox, the specs, and your Security Target (statement of requirements) to a third party who would evaluate your requirements (are they complete and valid?) on their own and against both the lockbox itself and the lockbox specs. If it passes, you buy the lockbox. Alternatively, you could study metallurgy and locksmithing and evaluate the lockboxes yourself.

While very few buyers rigorously vet home lockboxes, the lockbox buyer faces the same dilemma as the IT buyer: how can you make a rational decision about buying an IDS, a firewall, or a VPN product -- there are dozens of competing products in each category — without becoming an IDS, firewall, and VPN expert yourself, designing test plans, and setting up a test network running all the competing products?

Clearly, it helps to have a standardized language and scheme for describing complex computer security products and a system of trusted laboratories that certify the C-I-A assurances that the products provide. Is the Common Criteria a panacea for IT buyers? In short, the answer is "no". While the Common Criteria is ambitious and flexible, it falls short of providing a complete basis for making purchasing decisions. One key missing element: a framework for economic analysis weighing the cost of security vs. the value of the protected assets vs. the risk of loss. The economic stipulation illustrated above — that the lockbox be significantly less valuable than the jewel — would not be part of a Common Criteria analysis.

I will address some of the foibles and drawbacks of the Common Criteria system as well as some real world evaluation experiences in the next issue of the Securius Newsletter. 'Til then, keep your guard up!

NOTE:
This is newsletter issue is dedicated to discussing and analyzing the Common Criteria certification system. Note that our disk encryption product — Encryption Plus Hard Disk 7.0 — is currently in evaluation.
— STR

REFERENCES

[1] See Matt Curtin's "Snake Oil Warning Signs: Encryption Software to
Avoid" at
http://www.faqs.org/faqs/cryptography-faq/snake-oil/

[2] The entire corpus of Common Criteria documentation can be found at
http://www.commoncriteria.org/cc/cc.html

[3] The list of Common Criteria Testing Labs can be found at
http://niap.nist.gov/cc-scheme/TestingLabs.html