FAQ What is Common Criteria?

You can find all the functional and assurance requirements, as well as explanations of all the terminology and structure of the CC standard in four documents: the CC Standard Parts 1, 2, and 3, and the Common Evaluation Methodology, or CEM. All versions of these documents can be found on the Common Criteria Portal.

CC Part 1 discusses the general structure of Common Criteria; CC Part 2 contains the standard Security Functional Requirements (SFRs); and CC Part 3 contains the standard Security Assurance Requirements (SARs).

The CEM is like the “answers to the test”, and is used by the lab evaluators to help them review the documentation submitted by the vendor, and to test the product according to the CC Standard. So, the vendor can read this document to figure out what it is the lab evaluator is going to be looking for in the documentation and product testing, and be more prepared for the evaluation.

Hundreds of technology product vendors use CC to describe the security functionality of a specific version of a product (called the Target of Evaluation, or TOE), and have it tested by one of the accredited labs, in order to receive a certificate. These vendors can then sell their certified products to government agencies, financial industry companies, and healthcare providers who have requirements to purchase only CC-certified products.

There are a lot of good reasons to get your products CC-certified:

1. There are a lot of government requirements that point to CC, so the governments won’t buy Commercial Off-the-Shelf (COTS) products unless they are CC-certified.
2. You get mutual recognition of a single security certification across 28 countries, so you only have to certify once to sell to many different countries. This will save you money in the long run.
3. CC is a market differentiator. Your competitors may already have it, and are out-selling you to these governments. A lot of companies in the financial sector and healthcare industry also prefer to purchase CC-certified products. So, you need to at least meet the level of certification your competitors have to have a chance at competing in these marketplaces. Even if your competitors don’t already have CC, if you get it, you will have another tool in your belt to outsell them.
4. Getting a security certificate like CC demonstrates to your customers that you are committed to incorporating security into your products. This gives them confidence that they have little to worry about when they buy your product. And customers also appreciate the fact that your product was evaluated by a third-party. They don’t have to just take your word for it that your product provides the security features you claim it does.
5. A lot of your customers really just want to buy something to meet their business needs. They don’t want to have to worry about the details of what specific security features it has. They probably have a “check box” to check off that says they have to buy a CC-certified product. So, if you have one all ready for them, you make their jobs easier.
6. Another bonus you get from having your product evaluated is that, by going through the process, you can identify improvements that you can incorporate in your product and company going forward. You will end up with a better product at the end of the evaluation.

Many national governments, financial industry groups, and healthcare providers require that products purchased for use be CC-certified. For example, the US’ Committee on National Security Systems (CNSS) Policy #11 states that all IA IT products acquired for use by the US Government to protect National Security Systems must be CC-certified. There are other requirements defined by the US Department of Defense, the European Union, NATO, and others.

Vendors who develop any software or hardware product that can potentially be used by agencies of the participating governments, or by financial industry or the healthcare industry should consider getting their products CC-certified. The products do not have to be security products; they must simply include security features such as auditing, identification and authentication, cryptography, etc.

The original sponsoring organizations were Canada, France, Germany, Netherlands, the UK, and the US.

CC’s roots go all the way back to 1983, when the US Department of Defense (DoD) Trusted Computer System Evaluation Criteria (TCSEC), or “Orange Book”, was published in the USA. This was the first real set of security standards published by a governmental organization in the US. Later, the European Communities published their own security standards, called the Information Technology Security Evaluation Criteria (ITSEC) in 1991. Then, in 1992, the US agencies NIST and NSA published a first draft of the Federal Criteria as a replacement for TCSEC, but it never moved beyond the draft stage. Canada followed suit in 1993 with the Canadian Trusted Computer Product Evaluation Criteria (CTCPEC). These countries then decided to band together to create a single international standard. In 1993, they established the CC Editing Board to do this. They used TCSEC, ITSEC, and CTCPEC as the basis for the new “Common Criteria”. In 1996, the first draft of the Common Criteria was released for comment.

Prior to CC, all the different national standards were making it difficult for vendors to sell to many countries, and also making it difficult for those countries to easily purchase many different products. If a product was evaluated in the US, it could be sold to the US government, but not to the European or Canadian governments. Similarly, if a product was evaluated in Europe, it could not be sold in North America. This was frustrating to the vendors and the governments. So, six of these countries got together and decided to create a common set of criteria for security evaluations that everyone could point to, instead of having to re-evaluate products in every country or community.

In 2000, the six countries that developed the CC signed an agreement saying that an evaluation done in one of the countries would be recognized by all the other countries. This agreement is called the Common Criteria Recognition Arrangement, or CCRA.

There are now 28 signatories of the CCRA. Seventeen of them are certificate-authorizing members with certifying bodies called “Schemes”: Australia, Canada, France, Germany, India, Italy, Japan, Malaysia, Netherlands, New Zealand, Norway, Republic of Korea, Spain, Sweden, Turkey, United Kingdom, and United States. The rest are certificate-consuming members, meaning they recognize the certificates but do not have labs to evaluate products or a Scheme to serve as a certifying body for certificates. These countries are: Austria, Czech Republic, Denmark, Ethiopia, Finland, Greece, Hungary, Israel, Pakistan, Qatar, and Singapore.

Some financial industry groups and the healthcare industry prefer to purchase CC-certified products.

In 1999, v2.1 of the CC Standard became ISO/IEC 15408. They have both been updated several times since then, and we are now on version 3.1 revision 5.

Each lab is vetted and licensed by at least one Scheme to perform evaluation and testing of the security functionality vendors claim their products provide. Some labs are accredited by more than one Scheme.

NVLAP is the National Voluntary Laboratory Accreditation Program, which is run by the US National Institute of Standards and Technology (NIST). NVLAP accredits testing laboratories in the US, including the US’ Common Criteria evaluation labs. You can find out more about NVLAP at: NVLAP.

You can go to the Common Criteria Portal to see a list of all the accredited labs by Scheme. The contact information for each is listed here: CC Labs .

The lab you contract with to do your evaluation will review the documents you submit to them, review them per the requirements in the CC Standard and CEM, and then provide you with “verdicts” regarding areas of concern they have identified in the documents. You must address these verdicts and return updated documents to them. They will continue to do this until all their concerns have been addressed. They will then submit a report to the Scheme that includes all their verdicts and how they were addressed. Once their reports contain all “passes” for all requirements, your product will be deemed ready for certification. In addition to documentation reviews, the labs perform testing of the product(s) and one or two site visits to your facilities to review the processes and test cases you have described in your documentation. They may provide verdicts based on their site visit(s), as well.

There are currently 70 labs around the world (accredited by the Schemes) where you can go to get your product evaluated. You can also hire a CC consultant to help you through the process, and/or you can use SalusSec’ CCAdviser for a less-expensive alternative to navigating the process. Here is a brief explanation of the evaluation process:

1. Determine what you want to have evaluated. A certificate is issued for a specific version of a product, or portion of a product, or set of products that work together. The functionality you are having evaluated is called the Target of Evaluation, or TOE. It is important to get this right. You can look at the Common Criteria Portal (Certified Products) to find out what your competition has done with regard to CC certification, and start there.
2. Determine whether or not a Protection Profile (PP) exists for your product type. A PP is a document that defines the functional and assurance requirements that should be met for a particular class of products, such as routers or Intrusion Detection Systems. If a PP exists, you need to read it and determine whether your product will meet the requirements. If it will, or can be modified to meet them, you may choose to conform to that PP. If it can’t meet the requirements of the PP, you can choose to write your own set of requirements for your product and conform to an Evaluation Assurance Level (EAL). Keep in mind, though, that some Schemes will not do an evaluation on a product unless it conforms to one of their approved PPs. You can find a list of mutually-recognized PPs here: Protection Profiles. Each Scheme’s website also has a list of the PPs that Scheme recognizes. You can find links to the Schemes’ websites here: CCRA Members.
3. Decide where to have your evaluation done (which Scheme). Each Scheme has its own rules about what it will accept into evaluation, so you need to find out what these are for any Schemes you are considering. For instance, the US Scheme, called CCEVS, which is run by NIAP, requires that a product conform to a PP that is approved by NIAP. You can see a list of these on the NIAP website (NIAP-approved PPs). If there is no NIAP-approved PP for your product type, you can contact NIAP to find out if a certification is necessary for you to sell to the US government. Otherwise, you can look into other Schemes. You will need to find out the requirements for evaluation in those other Schemes, as well. You might be able to do your evaluation against a “unique Security Target”, which is a document that outlines your TOE and its security features and does not conform to a PP.
4. Hire a lab that is accredited by the Scheme you have chosen. You can find a list of these on the Common Criteria Portal, with their contact information: Labs. Be sure to ask the candidate labs lots of questions about what they will do for you for the price you pay them. Some will only do a certain number of iterations of review on each document you submit. Some offer consulting services at an additional cost. And some will practically do the entire thing for you. Make sure you know what you are getting before you sign any contracts.
5. Write your Security Target (ST). Remember, this is the document that outlines your entire evaluation, with a list of the security features your TOE provides, a description of the TOE, the level of assurance your evaluation will provide, and whether you are conforming to any PPs. Once you’ve written the ST, you submit it to the lab for review. Then they will let you know if you need to make any changes, and, once it is complete, will send it to the Scheme for approval.
6. Draft and submit to the lab the rest of the CC evidence documentation, including:
1. Life-cycle documents, such as Configuration Management, Secure Delivery, Development Security, Life-cycle Definition, Tools and Techniques, and Flaw Remediation;
2. Development documents, such as Security Architecture, Functional Specification, and TOE Design;
3. Testing documents, such as Coverage, Depth, and Functional Tests;
4. Guidance Supplement;
5. Entropy (in some cases).
7. Execute the test cases in the ATE documents against the evaluated configuration of the TOE. Provide the results to the lab.
8. Give the lab access to your product so the evaluators can run tests against it.
9. Host the lab for a site visit. The evaluator will verify the processes and tools you use in the development and delivery of your product. They will also witness your QA team doing some of the CC testing. This is NOT an audit, though. The evaluator just wants to verify that what you’ve written in your CC documentation with regard to Life Cycle processes is correct. If there are any discrepancies, the evaluator will let you know, and you can either fix the documentation to match the processes, or you can change your processes to match the documentation.
10. Respond to final questions from the lab and the Scheme.
11. Receive your certificate!

Then you will have to write a “unique ST” and conform to an Evaluation Assurance Level (EAL). EALs are predefined packages of assurance requirements that vary in the degree of assurance provided by for each category of requirements. In other words, EAL 2 is more rigorous than EAL 1. The levels go from EAL 1 to EAL 7. EALs 1 and 2 are mutually recognized by all signatories of the CCRA. Higher EALs may or may not be recognized by all countries. Higher EALs may or may not be recognized by all countries.

It depends. If you have tools to help you, you can probably get it done in nine or ten months. But if you try to do it without any help, you will have a lot to learn before you even start, it will take some time to figure out how to write it all up so that you meet all the requirements, and you will probably have to go through several iterations of each document with the lab, in order to address all their concerns and allow them to “pass” them. The evaluation process could easily take a year and a half or more.

It depends. Technically, because the certificate is for a single, specific version of the TOE, it is valid forever. However, your certificate will be removed from the “active” list on the CC Portal after, at most, five years. At that time, the products will be moved to the Archived Certified Products list on the CC Portal.

Some Schemes publish a list of products that are currently undergoing evaluation in that Scheme. Once the product is certified, it is removed from this list and placed on the Scheme’s certified products list.

Assurance Continuity is the process a vendor may follow to determine if a product is eligible for Assurance Maintenance, or must instead go through a Recertification effort in order to remain on the Scheme’s evaluated products list. Assurance Maintenance may be undertaken when the changes to a TOE have no impact on the SFRs or security architecture of the TOE as described in the previous evaluation. If this is the case, the vendor need only provide an Impact Analysis Report that describes in detail all changes to the certified TOE, and a justification for why each change does not affect the security of the TOE. This is then submitted directly to the Scheme for review. If the Scheme agrees that the security functionality of the TOE has not been adversely affected by the changes, it will issue a Maintenance Report and post this on the Scheme’s website alongside the original certification report and Security Target. The Scheme will forward the Maintenance Report to be posted on the CC Portal, as well. If the Scheme disagrees with the vendor’s assessment, then the vendor will have to perform a full recertification of the TOE, which will require that revised documentation be submitted to a lab, which will then re-review all the documentation. This should result in a new certificate being issued by the Scheme.

You don’t HAVE to do it, but you might want to. And the answer depends on the Scheme, but typically they require that Assurance Continuity be performed within two years of the original certification date. Otherwise you will be required to just do a full recertification (put your product through the full evaluation process again).

If the changes to the TOE are in fact minor, as required to do Assurance Maintenance, then it should take only a few weeks from start to finish, depending on the Scheme’s workload.

You can see a full list of all certified products, including those that have been archived, on the Common Criteria Portal: Certified Products. You can also see lists of the products that were certified by specific Schemes on those Schemes’ websites.

Yes.

The vendor may only claim that the certified version is CC Certified. If the vendor wishes to sell a later version of the product as a CC-certified version, then the vendor must either do Assurance Maintenance or a recertification of the TOE.

You don’t HAVE to use cryptography in your product, but it is highly recommended. And if you conform to a PP that has cryptographic SFRs in it, then you WILL have to include cryptography in your product. Usually, if you get your cryptographic module FIPS 140-2 validated, this will take the place of any required CC testing for the cryptographic functionality, and you won’t have to repeat that. However, if you don’t have your cryptographic module FIPS 140-2 validated, then you will have to perform the cryptographic testing yourself.

There are eleven Security Functional Classes:

1. Security Audit (FAU)
2. Communication (FCO)
3. Cryptographic Support (FCS)
4. User Data Protection (FDP)
5. Identification and Authentication (FIA)
6. Security Management (FMT)
7. Privacy (FPR)
8. Protection of the TSF (FPT)
9. Resource Utilization (FRU)
10. TOE Access (FTA)
11. Trusted Path/Channels (FTP)

There are nine Security Assurance Classes:

1. Protection Profile Evaluation (APE)
2. Protection Profile Configuration Evaluation (ACE)
3. Security Target Evaluation (ASE)
4. Development (ADV)
5. Guidance Documents (AGD)
6. Life-cycle Support (ALC)
7. Tests (ATE)
8. Vulnerability Assessment (AVA)
9. Composition (ACO)

TOE stands for Target of Evaluation. This is the specific product, part of a product, or set of products that are being evaluated.

TSF stands for TOE Security Functionality. This is the part of the TOE that enforces or supports the claimed security functionality in the evaluation.

TSFI stands for TOE Security Functional Interface. TSFIs are the interfaces to the product that reside on the TOE boundary: where outside entities gain access to the TSF of the TOE. “Outside entities” can be other applications, the Operating System, other hardware products, or humans interacting with the TOE. TSFIs either enforce or support the claimed security functionality of the TOE.

A Security Target (ST) is a document that defines the parameters of a product’s CC evaluation. It contains all the Security Functional Requirements, Security Assurance Requirements, the TOE Boundary, Security Problem Definition, and mappings among these items. The ST describes the security features of one version of one product. An ST can either conform to one or more Protection Profiles (PPs), or it can be “unique”, which means it does not conform to any PP and the security features are defined by the ST author.

ADV is the class of assurance requirements relating to the “Development” or architecture of the TOE. Families within the ADV class include Security Architecture (ARC), Functional Specification (FSP), Implementation Representation (IMP), TSF Internals (INT), Security Policy Modelling (SPM), and TOE Design (TDS).

ALC is the class of assurance requirements relating to the Life-cycle Support processes a vendor employs when developing or delivering the TOE to customers. Families within the ALC class include Configuration Management Capabilities (CMC), Configuration Management Scope (CMS), Delivery (DEL), Development Security (DVS), Flaw Remediation (FLR), Life-cycle Definition (LCD), and Tools and Techniques (TAT).

ATE is the class of assurance requirements relating to the testing activities of the TOE. Families within the ATE class include Coverage (COV), Depth (DPT), Functional Tests (FUN), and Independent Testing (IND).

AGD is the class of assurance requirements relating to the user and administrative guidance provided to the purchaser of the TOE. Families within the AGD class include Operational User Guidance (OPE) and Preparative Procedures (PRE).

In the context of Common Criteria and cryptography, entropy is a term used to describe “unpredictability”, or the amount of unpredictability in a sequence of bits fed into a random number generator. An entropy source, among other things, provides seed material for Deterministic Random Number Generation (DRBG) mechanisms. This seed material is in the form of bits from a “noise source” such as a ring oscillator or interrupt timings. (The noise source is the thing that actually provides the unpredictability of the bits.)

PP stands for Protection Profile. This is a document that specifies the security requirements for a specific class of IT products, such as Operating Systems, Network Devices, or Mobile Devices. A list of the internationally-approved PPs can be found on the Common Criteria Portal: Protection Profiles. You can also find a list of the PPs approved by the specific Schemes on their websites, and you can find a list of the website URLs here: Schemes.

A collaborative Protection Profile is PP that has been sponsored by at least two schemes, and developed by international Technical Communities (iTCs) that consist of vendors, consultants, labs, Schemes, and academia. You can see a list of these here: cPPs

This is more commonly called the Threat Model. It is the combination of Threats, Assumptions, and Policies that define the security problem the TOE is trying to solve. Objectives are the summarization of the security features the vendor is targeting to provide. Objectives counter the identified threats to the TOE and its data, enforce the Policies identified for the TOE and its environment, and uphold the assumptions placed upon the TOE’s environment. TOE Objectives are formalized in the Security Functional Requirements (SFRs) chosen for the evaluation.

A Security Functional Requirement (SFR) defines a security feature or function in a standardized language that is meant to contribute to achieving one or more security objectives for a TOE. This is the foundation of the evaluation. Standard SFRs are defined in the CC Standard documentation, and can be used in a Security Target or Protection Profile to describe security features of a product or class of products. They can then be tailored to describe security features of a specific TOE by either selecting from a set of options, assigning values to an operation, refining the wording of the SFR, or iterating the SFR so that there is more than one in an ST or PP, each of which describes a different implementation of a security feature. ST and PP authors may also create their own SFRs, using the standard SFRs as models.

A Security Assurance Requirement (SAR) defines the type and rigor of proof required to show that the TOE enforces the SFRs listed in the ST. SARs can be grouped into Evaluation Assurance Levels (EALs) (predefined by the CC community), or they can be chosen by the ST or PP author one at a time for a “tailored assurance package”. The higher the EAL or level of SARs a TOE claims, the more assurance the purchaser of the TOE has that the TOE does implement the security features claimed.

Evaluation Assurance Levels (EALs) are packages of SARs defined by the CC community. The lowest level is EAL1; the highest level is EAL 7. EALs 1 and 2 are mutually recognized by all signatories of the CCRA. Levels above EAL 2 are officially recognized only by the Schemes in which the products are evaluated. However, the members of the European Union have agreed to recognize one another’s EALS up to level 4. In all cases, EALs 5 through 7 are only recognized by the Scheme in which an evaluation is done.

The National Information Assurance Partnership (NIAP) oversees the United States’ Common Criteria program for Commercial Off-the-Shelf (COTS) Information Technology (IT) products. NIAP includes the Common Criteria Evaluation and Validation Scheme (CCEVS), which is the Certifying Body for Common Criteria evaluations. CCEVS also develops PPs, evaluation methodologies, and policies with regard to CC evaluations. You can browse the NIAP website here: NIAP.

The NIAP Product Compliant List (PCL) is the list of products that NIAP/CCEVS recognizes as certified according to NIAP/CCEVS policies. You can find this list at NIAP PCL.

The CC Approved Products List is the list of products that the international Common Criteria community recognizes as having been evaluated by an accredited lab within a certificate-authorizing Scheme. You can find this list at CC APL.

“CC Certified” means that a product has undergone the required CC testing and review by an accredited CC lab with approval by a CC Scheme, resulting in the issuance of a CC Certificate to the vendor for that product. “CC Compliant” is a term that many vendors use to claim that they have met the CC requirements for their product, but have not undergone the CC certification process. This means absolutely nothing. Purchasers should only purchase “CC Certified” products, not those that a vendor has described as “CC Compliant”.

The Common Criteria Users Forum is a consortium of vendors, labs, Scheme representatives, consultants, and end-users who have an interest in promoting and improving the CC Standard. You can find out more here: CCUF.

The Cryptographic Module Users Forum is a “sister” organization to the CCUF that promotes the use of cryptographic modules in technology products. It is also a consortium of vendors, labs, consultants, and end-users. Many vendors who pursue Common Criteria certifications and FIPS 140-2 validations are members of this group.

The ATE SARs define what is required for testing your CC product. In addition, many modern Protection Profiles have “assurance activities” included in them to define exactly how each SFR must be tested in order to conform to that PP. Basically, every Security Function must be tested, and the easiest way to do that is to test each element of each SFR.

As part of the AVA SAR class, the lab will do a Vulnerability Assessment on the TOE. The purpose of this is to determine the exploitability of flaws or weaknesses in the TOE in the operational environment. This determination is based upon analysis of the evaluation evidence and a search of publicly available material by the evaluator and is supported by evaluator penetration testing. However, it is advisable for the vendor to also perform penetration testing and do a search of publicly available material to identify any vulnerabilities their TOE may have, so actions can be taken to mitigate these vulnerabilities before the lab finds them.

The “evaluated configuration” of your TOE is the set of options and environmental dependencies your TOE requires in order to meet all the claimed security requirements. Your TOE must be tested in its “evaluated configuration” in order for the testing to be valid for CC purposes. Your guidance documentation must define what the “evaluated configuration” for CC is; this can be done in the form of a guidance supplement produced just for the version of the product that is CC certified.

There are 28 signatories of the CCRA. Seventeen of them are certificate-authorizing members with certifying bodies called “Schemes”: Australia, Canada, France, Germany, India, Italy, Japan, Malaysia, Netherlands, New Zealand, Norway, Republic of Korea, Spain, Sweden, Turkey, United Kingdom, and United States. The Schemes oversee the evaluations performed by their accredited labs.

Although the CC standard is just that: a standard, each Scheme has its own rules and policies that govern how evaluations are done in that country. For example, some Schemes have deadlines by which a product must undergo Assurance Maintenance. If this deadline is not met, the product must undergo a full recertification instead.

Some Schemes will only do evaluations against products that conform to an approved Protection Profile (e.g., NIAP/CCEVS). Other Schemes will perform evaluations against the defined EALs (e.g., most European and Asian Schemes). The bottom line is, if you want to try to sell your CC-certified product in the US or another Scheme that only takes products that are conforming to a PP, then you really should use that Scheme or another one that recognizes the same PPs, and also conform to one of those PPs. If there is no PP for your product type, and/or you don’t care about selling to the US government, then it is best to use one of the other Schemes.

The Scheme is responsible for overseeing the evaluations performed by the labs they have accredited. This usually takes the form of review and approval of the evaluation reports sent by the labs, as well as meetings to review the progress of the evaluations. The final issuance of certificates for products is done by the Scheme.

A low-level CC evaluation can be done in as little as 6 to 9 months. An evaluation at a higher level, or an evaluation against a very complex TOE, can take as much as 2 to 3 years. But even a simple TOE evaluated at a low level requires a great deal of “ramp up” to understand exactly what is required and how to do it. This is why it is important to get some good guidance to help you find your way through the process. SalusSec and CCAdviser provide training as well as specific documentation guidance to vendors seeking to do a CC evaluation.

Several members of your company will need to provide input to the evaluation, such as your development team, your QA team, your product sales and delivery teams, and your management team. One or more lab evaluators will be involved in the documentation review and product testing. And at least one member of the Scheme will provide oversight to the lab.

Some Schemes provide a list on their websites that identifies all the products that are currently in evaluation in that Scheme. This is useful to product vendors because they can point to this list to prove to their potential customers that the product is undergoing a third-party review of its security features.

The Federal Information Processing Standard Publication 140-2 is a joint U.S./Canadian government security standard used to approve cryptographic modules that are used in products. Many vendors use FIPS 140-2 validated cryptographic modules in their TOEs in order to meet the cryptographic SFRs claimed in their CC Security Targets.

Often, many of the requirements for attaining a FedRAMP ATO can be met by the issuance of a CC Certificate.

The U.S. Department of Defense frequently requires that a product be CC-certified in order to be listed on the Unified Capabilities Approved Products List for purchase by DoD departments.