Common Criteria FAQs

This FAQ is intended to address questions pertaining to Common Criteria.

            What is Common Criteria?

            Why do I need Common Criteria?

            What’s involved?

            Why do I need a consultant?

            Why use CC Eval Prep?

            How do I get started?

WHAT IS COMMON CRITERIA?

Common Criteria (CC) is an international standard for evaluating security functionality within products that are either primarily focused on providing information assurance capabilities (e.g. firewalls) or are focused on providing a specific functionality type that relies upon certain information assurance capabilities (e.g. email servers). In addition, the CC standard requires review of the developer's configuration management procedures, delivery processes, and development security controls in place to adequately ensure the evaluated product is properly maintained and securely delivered to the end-user.

The CC standard, its evaluation methodology, and the assurance processes in place by each respective evaluation authority, scheme, and CC Testing Laboratory (CCTL) provides adequate assurance to an end-user that they may securely retrieve the evaluated product and use it in the manner indicated by product's Security Target and supporting evaluated configuration guidance.

The level of assurance provided in the evaluation of a product is indicated by the Evaluation Assurance Level (EAL) chosen for the product's evaluation. CC defines EALs 1-7, however, the supporting evaluation methodology only provides guidance for evaluations at EALs 1-4. Therefore, evaluations higher than EAL 4 require direct support, if not complete involvement, from the respective evaluation scheme for those assurance requirements that exceed EAL 4.

CC is a harmonized standard deriving from previous information assurance standards such as:

Trusted Computer Security Evaluation Criteria (TCSEC), also known as the "Orange Book", was published by the United States National Computer Security Center (NCSC)as "Trusted Computer System Evaluation Criteria, DOD standard 5200.28-STD" in December of 1985 superseding CSC-STD-00l-83. The Orange Book was one of many other computer security standards pertaining to the process in the evaluation of trusted systems, referred to as the "Rainbow Series". However, the Orange Book was the focal point for the evaluation criteria. TCSEC included evaluation assurance levels of A -D, with A being the highest level of assurance and D being the lowest.

Canadian Trusted Computer Product Evaluation Criteria (CTCPEC), also known as the "Canadian Criteria", was developed by the Communications Security Establishment (CSE) and published by the Government of Canada in January of 1993. The CTCPEC was published to define a set of technical hardware/firmware/software criteria for trusted products which is consistent with the Security Policies and Information Technology Security Standards under development by the Government of Canada. CTCPEC  included evaluation assurance levels T-0 through T-7, with T-7 being the highest level of assurance and T-0 being the lowest.

Information Technology Security Evaluation Criteria (ITSEC), was published by France, Germany, the Netherlands and the United Kingdom in May of 1990 which derived from the previous computer security standards developed by each respective country. Such standards included the French Criteria, German Criteria, and the UK Confidence Levels. Similar to CC, ITSEC was also accompanied with evaluation methodology, known as the Information Technology Security Evaluation Methodology (ITSEM). Also, ITSEC requires a Security Target as a baseline for defining the functionality to be evaluated along with the evaluation assurance level. ITSEC defines evaluation assurance levels E0 - E6, with E6 being the highest level of assurance and E0 being the lowest.

In order to gain international acceptance of the Common Criteria standard and recognition of Common Criteria certified products, a historic recognition arrangement for Common Criteria-based IT security evaluations was signed on October of 1998. This arrangement, which was known as the "Arrangement on the Mutual Recognition of Common Criteria Certificates in the Field of IT Security", was signed by government organizations from the United States, Canada, France, Germany, and the United Kingdom.

The objectives of this arrangement are to:

Ensure that evaluations of IT products and protection profiles are performed to high and consistent standards and are seen to contribute significantly to confidence in the security of those products and profiles.

Increase the availability of evaluated, security-enhanced IT products and protection profiles for national use.

Eliminate duplicate evaluations of IT products and protection profiles.

Continuously improve the efficiency and cost-effectiveness of security evaluations and the certification/validation process for IT products and protection profiles.

Since the original signing of this arrangement, a revision was released in May of 2000 to allow for the participation of both certificate-consuming and certificate-producing nations. This enabled countries with the option to officially mutually recognize Common Criteria certified products without needing to establish an evaluation authority and scheme for conducting evaluations.

A list of currently participating countries for both certificate-consuming and certificate-producing nations can be found at the following URL:

http://niap.nist.gov/cc-scheme/ccra-participants.html

WHY DO I NEED COMMON CRITERIA?

As a product vendor, it is important to pursue a Common Criteria certification for your product to become applicable for federal government contracts, accepted within the financial industry, gaining international recognition, and a competitive advantage.

Since the Committee on National Security Systems has released the National Security Telecommunications and Information Systems Security Policy (NSTISSP) #11, vendors wishing to market their products to the government must achieve a CC certification with an assurance claim of at least EAL2, or if there is a Protection Profile (PP) available for that type of product then the product must comply with that PP.

BITS has now released a set of documents, similar to a PP, aligning the BITS security criteria in a format acceptable by Common Criteria to allow for the certification of a product that conforms to both the Common Criteria and the BITS security criteria. 

Common Criteria certified products are recognized and accepted by various countries within the international community. To support international recognition, a Mutual Recognition Arrangement (MRA) was written and signed by what was originally United States, Canada, France, Germany, and the United Kingdom in 1998 for performing and accepting Common Criteria-based IT security evaluations.

While many of your competitors may have already began or have thought to begin pursuing this similar path of certification for these similar reasons, there are still ways you can leverage an attraction over your competitors by considering your claims such as the extent of security functionality you have had evaluated, or the greater level of assurance that you claim to provide in your product, and any specific PPs you may comply with.

WHAT'S INVOLVED?

The first step in the Common Criteria evaluation process involves developing or rewriting previously developed documentation which addresses all of the assurance requirements identified by the Evaluation Assurance Level (EAL) claimed.  Such documents can include the following:

After delivering the set of evaluation deliverables required for the Common Criteria evaluation, the CCTL will review the submitted documentation and will prepare an ETR for each of the evaluation deliverables received. The ETR will address how each Common Criteria assurance requirement is either passed or failed based on the product under evaluation and the evaluation deliverables submitted. It is then the responsibility of the product vendor to ensure that all concerns brought forth within the set of ETRs received has been adequately addressed, satisfying all of the concerns identified by the CCTL.

When an evaluation of EAL2 or higher is selected, the product vendor is required to document the process in which the product under evaluation will be delivered to an end-user. Therefore to support this document, the CCTL requires the product vendor to additionally ship the product to the CCTL so that the evaluator(s) may confirm the delivery procedures that have been documented.

After the CCTL has confirmed that all major concerns identified within the ETRs have been addressed, the CCTL will proceed with the onsite visit. The onsite visit, in general, is an activity in which the CCTL will execute a subset of your test cases along with some additional tests in which the CCTL has produced.

However depending on the EAL level selected, this may also include additional activities such as, reviewing your configuration management system, development security, life-cycle processes, and source code.

WHY DO I NEED A CONSULTANT?

The Common Criteria evaluation process involves developing assurance documentation covering all of the functional aspects of the product to which you are claiming, in addition to documenting the environment in which it is developed. This requires having a great understanding as to how the functional aspects are to be identified, described, and tested to provide adequate assurance that the claims being made are consistently demonstrated, as required within Common Criteria. Therefore a Common Criteria consultant can bring the knowledge, skills, and experience needed to ensure claims identified can be quickly documented and tested in a manner acceptable by a Common Criteria Testing Laboratory.

Government contracts are usually granted to a product vendor, only if the product vendor achieves certification within the specified time frame, typically within a year. Additionally, CCEVS requires evaluations to show significant progress, as indicated in CCEVS Policy #4 and its addendum. Furthermore, product vendors rarely have internal resources dedicated to being available to assist in the certification process, as internal resources are often booked with development and quality assurance testing of future product releases. Therefore when going through the CC evaluation process, product vendors often find a consulting solution to be a necessity for ensuring that their certification can be achieved within their required time frame and with minimal support required by their development and quality assurance staff.

CC development and support activities require extensive work to be performed throughout the evaluation process. Product vendors are often faced with the challenge of allocating the appropriate internal resources for creating and revising documentation that is required for the CC evaluation process. While at the same time, product vendors have to respond to what sometimes can be hundreds of Evaluation Technical Report (ETR) verdicts for each document delivered. A consulting solution can ease this burden on a product vendor by bringing the experience and knowledge needed to quickly and correctly development the assurance documentation required, while only needing minimal support from your staff.

Also feel free to review the FAQs provided by CCEVS for choosing a CC consultant.

WHY USE CC EVAL PREP?

CC Eval Prep offers staff that has assisted with the evaluations of products such as Application Servers, Firewalls, Intrusion Detection/Prevention Systems, PKIs, Secure Content Filtering, Secure Messaging, Smartcards, Stored Data Integrity Monitoring, Stored Data Deletion, and VPNs, which also includes evaluations at assurance levels EAL1 through EAL4.

CC Eval Prep offers staff that is well recognized and accepted by many of the active CCTLs. By having established a previous working relationship with a CCTL, a greater assurance can be gained that the evaluation to be performed can be completed without delays from the original schedule and within the planned budget.

HOW DO I GET STARTED?

The first step to getting your product into the evaluation process is to develop a Security Target which identifies the product(s) and functionality that is to be evaluated along with the level of assurance that is to be claimed.

The next step would be to get a CCTL under contract for the evaluation. While a Security Target does not already need to be developed before contracting with a CCTL, it will greatly support the contracting process by providing the CCTL with a pre-defined scope as to what is expected to be evaluated and at what assurance level.

Once the first two steps have been executed, the Security Target can then be submitted to the Common Criteria Evaluation & Validation Scheme (CCEVS) for approval and to initiate a Kick-Off meeting. However before a Kick-Off meeting can commence, CCEVS must review the Security Target submitted to determine if it meets the set of requirements called out within Policy Letter #10 and Policy Letter #13.

In addition to submitting a Security Target, you must also submit to CCEVS a letter of intent that is either from your U.S. Federal government customer and indicates their intent to purchase your evaluated product or from your organization and indicates the metrics involved with your business interest in pursuing an evaluation for your product. This requirement has recently been introduced within Policy Letter #12.

When the Security Target has been determined to be acceptable by CCEVS and a letter of intent has also been received, the Kick-Off meeting will be scheduled. Kick-Off meetings are typically scheduled within 4 weeks of the approval of the Security Target. The Kick-Off meeting will identify the team members assigned from the CCTL and the validator assigned from CCEVS for the evaluation of your product. In addition, you will be presented with an opportunity to provide an overview of your product to the attendees of the Kick-Off meeting. Afterwards, the validator and evaluation team may bring forward any potential concerns they foresee for your specific evaluation, if there are any. Finally, the Kick-Off meeting will close by officially accepting your product into evaluation. Your product will then be displayed as “In Evaluation” on the CCEVS website, typically within one week after the Kick-Off date.

After your product has been accepted into evaluation, the evaluation process begins. At this point, you will be expected to deliver the set of evaluation deliverables, as required by Common Criteria, within the time frames established with the CCTL during the contracting process. To ensure your evaluation will complete within the time frame defined at the beginning of the evaluation, quality documentation must be produced and delivered to the CCTL within the time frame requested. Throughout the evaluation process, it is also expected that the CCTL will find errors or concerns within some, if not all, of the documentation delivered. Therefore, adequate resources should also be reserved to provide a timely response to any concerns brought forth throughout the evaluation process.

However, this is where CC Eval Prep can offer a helping hand to you by assisting in the preparation of quality documentation, within the time constraints set forth, and can additionally assist in responding to any concerns brought forth by the CCTL throughout the evaluation process.