Common Criteria for IT Security (CC, ISO/IEC 15408) Evaluation and Certification Service

Common Criteria for IT Security Evaluation

The Common Criteria for IT Security Evaluation (referred to as Common Criteria or CCis an international standard (ISO/IEC 15408) for information and communication technology (ICT) security certification.

Common Criteria is a framework in which ICT users can specify their security functional and assurance requirements (SFRs and SARs respectively) in a Security Target (ST), and maybe taken from Protection Profiles (PPs). 

Developers can then implement or make claims about the security attributes of their products, and testing laboratories can evaluate the products, dependent on different assurance levels, to determine if they actually meet the claims. In other words, Common Criteria provides assurance that the process of specification, implementation and evaluation of an ICT security product has been conducted in a rigorous and standard and repeatable manner at a level that is commensurate with the target environment for use. Common Criteria maintains a list of certified products, including operating systems, access control systems, databases, and key management systems.

  • ISO/IEC TR 15446 Information technology — Security techniques — Guidance for the production of protection profiles and security targets

Referred international standards:

  • ISO/IEC 15408-1 Information security, cybersecurity and privacy protection — Evaluation criteria for IT security — Part 1: Introduction and general model
  • ISO/IEC 15408-2 Information security, cybersecurity and privacy protection — Evaluation criteria for IT security — Part 2: Security functional components
  • ISO/IEC 15408-3 Information security, cybersecurity and privacy protection — Evaluation criteria for IT security — Part 3: Security assurance components
  • ISO/IEC 18045 Information security, cybersecurity and privacy protection — Evaluation criteria for IT security — Methodology for IT security evaluation
  • ISO/IEC TS 19608 Guidance for developing security and privacy functional requirements based on ISO/IEC 15408
  • ISO/IEC 19989-x Information security — Criteria and methodology for security evaluation of biometric systems 
  • ISO/IEC TR 20004 Information technology — Security techniques — Refining software vulnerability analysis under ISO/IEC 15408 and ISO/IEC 18045
  • ISO/IEC 19790 Information technology — Security techniques — Security requirements for cryptographic modules
  • ISO/IEC 24759 Information technology — Security techniques — Test requirements for cryptographic modules
  • ISO/IEC 20543 Information technology — Security techniques — Test and analysis methods for random bit generators within ISO/IEC 19790 and ISO/IEC 15408
  • ISO/IEC TR 19791 Information technology — Security techniques — Security assessment of operational systems

Common Criteria evaluations are performed on ICT security products and systems.

  • Target of Evaluation (TOE) – the product or system that is the subject of the evaluation. The evaluation serves to validate claims made about the target. To be of practical use, the evaluation must verify the target's security features. This is done through the following:
    • Protection Profile (PP) – a document, typically created by a user or user community, which identifies security requirements for a category/type of security devices (for example, smart cards used to provide digital signatures, or network firewalls) relevant to that user for a particular purpose. Product vendors can choose to implement products that comply with one or more PPs, and have their products evaluated against those PPs. In such a case, a PP may serve as a template for the product's ST (Security Target, as defined below), or the authors of the ST will at least ensure that all requirements in relevant PPs also appear in the target's ST document. Customers looking for particular types of products can focus on those certified against the PP that meets their requirements.
    • Security Target (ST) – the document that identifies the security properties of the target of evaluation. The ST may claim conformance with one or more PPs. The TOE is evaluated against the SFRs (Security Functional Requirements. Again, see below) established in its ST, no more and no less. This allows vendors to tailor the evaluation to accurately match the intended capabilities of their product. This means that a network firewall does not have to meet the same functional requirements as a database management system, and that different firewalls may in fact be evaluated against completely different lists of requirements. The ST is usually published so that potential customers may determine the specific security features that have been certified by the evaluation.
    • Security Functional Requirements (SFRs) – specify individual security functions which may be provided by a product. The Common Criteria presents a standard catalogue of such functions. For example, a SFR may state how a user acting a particular role might be authenticated. The list of SFRs can vary from one evaluation to the next, even if two targets are the same type of product. Although Common Criteria does not prescribe any SFRs to be included in an ST, it identifies dependencies where the correct operation of one function (such as the ability to limit access according to roles) is dependent on another (such as the ability to identify individual roles).
      1. Class FAU: Security Audit 
      2. Class FCO: Communication 
      3. Class FCS: Cryptographic support 
      4. Class FDP: User Data Protection 
      5. Class FIA: Identification and Authentication 
      6. Class FMT: Security Management 
      7. Class FPR: Privacy 
      8. Class FPT: Protection of the TSF 
      9. Class FRU: Resource Utilization 
      10. Class FTA: TOE Access 
      11. Class FTP: Trusted Path/Channels 

The evaluation process also tries to establish the level of confidence that may be placed in the product's security features through quality assurance processes:

  • Security Assurance Requirements (SARs) – descriptions of the measures taken during development and evaluation of the product to assure compliance with the claimed security functionality. For example, an evaluation may require that all source code is kept in a change management system, or that full functional testing is performed. The Common Criteria provides a catalogue of these, and the requirements may vary from one evaluation to the next. The requirements for particular targets or types of products are documented in the ST and PP, respectively.

    1. Class APE: Protection Profile Evaluation 
    2. Class ASE: Security Target Evaluation 
    3. Class ADV: Development 
    4. Class AGD: Guidance Documents 
    5. Class ALC: Life-Cycle Support 
    6. Class ATE: Tests 
    7. Class AVA: Vulnerability Assessment 
    8. Class ACO: Composition 

  • Evaluation Assurance Level (EAL) – the numerical rating describing the depth and rigor of an evaluation. Each EAL corresponds to a package of security assurance requirements (SARs, see above) which covers the complete development of a product, with a given level of strictness. Common Criteria lists seven levels, with EAL 1 being the most basic (and therefore cheapest to implement and evaluate) and EAL 7 being the most stringent (and most expensive). Normally, an ST or PP author will not select assurance requirements individually but choose one of these packages, possibly 'augmenting' requirements in a few areas with requirements from a higher level. Higher EALs do not necessarily imply "better security", they only mean that the claimed security assurance of the TOE has been more extensively verified.

During the evaluation, the verbs check, examine, report and record are used with a precise meaning in the CEM.

Verb Definitions
Check Generate a verdict by a simple comparison.
Evaluator expertise is not required. The statement that uses this verb describes what is mapped.
Examine Generate a verdict by analysis using evaluator expertise.
The statement that uses this verb identifies what is analysed and the properties for which it is analysed.
Record Record retain a written description of procedures, events, observations, insights and results in sufficient detail to enable the work performed during the evaluation to be reconstructed at a later time.
Report Include evaluation results and supporting material in the Evaluation Technical Report (ETR) or an Observation Report (OR).
  • The verdict (pass, fail or inconclusive) statement issued by an evaluator with respect to a CC evaluator action element, assurance component, or class.
  • Evaluation technical report: a report that documents the overall verdict and its justification, produced by the evaluator and submitted to an evaluation authority.
  • Observation report: report written by the evaluator requesting clarification or identifying a problem during the evaluation.

Who should apply

  1. The ICT product developer;
  2. The ICT product manufacture

Plan a CC evaluation and certification 

CC Evaluation and Certification process 

Supporting services

We provide but not limited to the following services to support your CC evaluation and certification: 

  1. CC standard training;
  2. Preliminary assessment on CC project feasibility (includes TOE scope)
  3. Support to develop CC required technical documents;
  4. Support to improve the development site and manufacture site security certification (when above EAL3);
  5. Support to communicate and respond to the comments from the laboratory and certification body.

Promotion certification programme:

The following information is required for initiate the service discussion: 

  1. Target market (i.e. country, region) and customer-specific requirements (i.e. legal, PP, EAL);
  2. Product description (i.e. use cases, application), user and administrator manual (if applicable); 
  3. Security function specification, framework; 
  4. Product security technology specification (includes hardware, software, and firmware), particularly on cryptographic algorithms used, crypto module certification (i.e. FIPS 140-3).
Contact:Philip KU,  PGP Public Key ]

(PGP Fingerprint: BE11 C1CC BFE2 A3A9 4929  3D1C 10FF C3BE A51C 92F7)

Last modified: Monday, 19 April 2021, 2:59 PM