The Common Criteria for Information Technology Security Evaluation, aka. CC, is an international endeavor and arrangement that involves a multitude of Certificate Authorizing Schemes to “provide grounds for confidence in the reliability of the judgments on which the original certificate was based by requiring that a Certification/Validation Body (CB) issuing Common Criteria certificates should meet high and consistent standards.”

A nonexclusive license of the Common Criteria version 3.1 (CC 3.1) is granted to ISO/IEC for the continued development/maintenance of the ISO/IEC 15408 international standard (Information technology — Security techniques — Evaluation criteria for IT security), which comprises three major parts:

• Part 1: Introduction and general model (ISO 15408-1)
• Part 2: Security functional components (ISO 15408-2)
• Part 3: Security assurance components (ISO 15408-3)

Functional and Assurance Requirements

There are two types of security requirements defined in CC: security functional requirements (SFR) and security assurance requirements (SAR). Security requirements are specific descriptions of the security objectives a target of evaluation (TOE) should achieve to address the security problems. A security problem is defined by enumerating threats that may break organizational security policies (OSPs) under a specific operational environment or use cases.

Security Requirements are grouped into classes, families, and components.

Terms and definitions common in the CC

Security Problem, Objective, and Requirement

• security problem — statement which in a formal manner defines the nature
  and scope of the security that the TOE is intended to address.
  This statement consists of a combination of:
  — threats to be countered by the TOE and its operational environment,
  — the OSPs enforced by the TOE and its operational environment, and
  — the assumptions that are upheld for the operational environment of
  the TOE.
• security objective — statement of an intent to counter identified threats
  and/or satisfy identified organisation security policies and/or assumptions
• security requirement — requirement, stated in a standardised language,
  which is meant to contribute to achieving the security objectives for a TOE

Object and Subject

• object — passive entity in the TOE, that contains or receives information,
  and upon which subjects perform operations
• subject — active entity in the TOE that performs operations on objects

Trusted Path and Trusted Channel

• trusted path — means by which a user and a TSF can communicate with the
  necessary confidence
• trusted channel — a means by which a TSF and another trusted IT product
  can communicate with necessary confidence

Formal, Semiformal, and Informal

• formal — expressed in a restricted syntax language with defined semantics
  based on well-established mathematical concepts
• semiformal — expressed in a restricted syntax language with defined
  semantics
• informal — expressed in natural language

Explain, Describe, Demonstrate, and Prove

• explain — give argument accounting for the reason for taking a course of action.
  This term differs from both “describe” and “demonstrate”. It is intended to answer the question “Why?” without actually attempting to argue that the course of action that was taken was necessarily optimal.
• describe — provide specific details of an entity
• demonstrate — provide a conclusion gained by an analysis which is less rigorous than a “proof”
• prove — show correspondence by formal analysis in its mathematical sense

Determine, Confirm, and Verify

• determine — affirm a particular conclusion based on independent analysis with the objective of reaching a particular conclusion.
  The usage of this term implies a truly independent analysis, usually in the absence of any previous analysis having been performed. Compare with the terms “confirm” or “verify” which imply that an analysis has already been performed which needs to be reviewed
• confirm — declare that something has been reviewed in detail with an independent determination of sufficiency. The level of rigour required depends on the nature of the subject matter. This term is only applied to evaluator actions.
• verify — rigorously review in detail with an independent determination of sufficiency.
  Also see “confirm”. This term has more rigorous connotations. The term “verify” is used in the context of evaluator actions where an independent effort is required of the evaluator.

Reference

• The Common Criteria Portal
• Part 1: Introduction and general model
• Part 2: Security functional requirements
• Part 3: Security assurance requirements
• The National Information Assurance Partnership (NIAP)
• TPM 2.0 Security Evaluation Trust and Confidence
• Palo Alto Networks NextGeneration Firewall with PAN-OS 10.0