Contents

Isoiec 15408Edit

ISO/IEC 15408, commonly known as the Common Criteria, is an international framework for evaluating the security properties of information technology products. It provides a structured approach to specifying, validating, and certifying that a product’s security functions and assurance measures meet predefined objectives. The standard is especially influential in government procurement and enterprise buying, where buyers want predictable risk, clear baselines, and cross-border recognition of certifications. Within the framework, products are evaluated against a target of evaluation (TOE) using documented security targets and, often, a protection profile that standardizes expectations for families of products.

The Common Criteria is designed to reduce uncertainty in security claims and to enable buyers to compare products on a like-for-like basis. It emphasizes not only what a product can do (security requirements) but how confident evaluators can be that those claims hold up under real-world use (assurance). The framework is international in scope and operates under the Common Criteria Recognition Arrangement (CCRA), which harmonizes national evaluation schemes and allows CC certificates to be recognized across participating countries. See for example Common Criteria and CCRA for more on cross-border recognition.

Overview

  • The standard defines core concepts such as the target of evaluation (TOE), the security target (ST), and the protection profile (PP). These documents articulate, in precise terms, the security objectives, the functional requirements, and the assurance measures that the product must satisfy. See Target of Evaluation and Protection Profile for deeper definitions.
  • Security requirements are expressed as Security Functional Requirements (SFRs) and assorted assurance requirements that guide how thoroughly a product is designed, implemented, and tested. See Security Functional Requirements and Security Assurance for details.
  • Evaluation results are assigned an Evaluation Assurance Level (EAL) from EAL1 to EAL7, indicating the depth and rigor of the assessment. Higher EALs imply more extensive verification of development, testing, and security analysis. See Evaluation Assurance Level for specifics.
  • The framework is used across many domains, from secure operating systems to hardware security modules, embedded devices to critical software platforms. The approach seeks to create a common language for security claims that is understood by buyers and evaluators alike. See Security Target and Protection Profile for examples of how these concepts are applied.

History and development

The Common Criteria emerged from earlier IT security evaluation efforts and built on lessons learned from prior standards such as ITSEC in Europe and TCSEC in the United States. The initiative consolidated diverse national approaches into a single, interoperable scheme to support reliable product evaluation in a global market. This history reflects a practical preference for a standards-based, market-friendly pathway to risk reduction in information security, rather than ad hoc, one-off certifications. See ITSEC and TCSEC for historical context.

Over time, the CC framework evolved to emphasize modularity (with reusable Protection Profiles) and international collaboration (through the CC Recognition Arrangement). This evolution has been driven by governments and industry alike who seek a balance between rigorous assurance and reasonable cost, with the goal of enabling secure product adoption in a competitive market without unnecessary regulatory bloat. See Protection Profile and Common Criteria Recognition Arrangement for governance details.

Structure and key concepts

  • Security Targets and Protection Profiles: A Security Target (ST) states the security objectives and claims of a given TOE, while a Protection Profile (PP) provides a reusable template for families of products with similar security needs. Vendors can reuse PP templates to streamline evaluation of multiple products. See Security Target and Protection Profile.
  • Target of Evaluation: The TOE is the actual product under assessment (e.g., a secure OS, a cryptographic module, or a secure firmware image). The evaluation verifies that the TOE fulfills the stated ST/PP requirements. See Target of Evaluation.
  • Security Functional Requirements and Security Assurance: SFRs describe what the product should do in security terms, while assurance requirements detail the rigor of the development and testing processes. See Security Functional Requirements and Security Assurance.
  • Evaluation levels and methodology: EALs provide a scale for the depth of evaluation, with higher levels corresponding to more thorough formal analyses, testing, and design review. See Evaluation Assurance Level.
  • Roles in the process: The process involves developers, evaluation labs, and certification bodies, all operating within the CC framework to produce a certified result recognized by CC adherents. See Evaluation Laboratory and Certification Body.

Evaluation process and implications

A typical CC evaluation progresses from a formal ST/PP specification to an independent assessment of the TOE against those claims. An accredited lab conducts testing, code analysis, and documentation review, culminating in a certification decision by a recognized body. The final certificate is intended to be portable across jurisdictions that participate in the CC scheme, enabling buyers to import and rely on evaluations performed elsewhere. See Certification Body and Evaluation Laboratory.

For buyers, the value proposition rests on risk reduction and transparency: a credible CC certificate provides a defensible claim that a product’s security properties have been independently verified. This can translate into lower risk premiums, smoother procurement, and clearer budgeting for security investments. See Procurement and Risk Management.

Applications and impact

The Common Criteria is widely used by government agencies and large enterprises to establish baseline security expectations for commercially available products. It helps standardize what “security” means in a way that procurement officers can compare across vendors and regions. In practice, CC evaluations are often a prerequisite for vendors seeking to do business with national governments, critical infrastructure operators, or international organizations. See Government Procurement and Critical Infrastructure for context.

Examples of domains where CC evaluations are common include hardware security modules, secure operating systems, trusted execution environments, and embedded security in consumer devices. The framework’s emphasis on reusable protections (PPs) and rigorous assurance can help speed up risk-aware purchasing decisions for complex systems. See Hardware Security Module and Trusted Platform Module for related areas.

Controversies and debates

  • Cost and complexity: Critics argue that pursuing high EALs or developing tailored Security Targets can be costly and time-consuming, potentially pricing smaller firms out of important markets. Proponents counter that the cost is a predictable trade-off for higher assurance and lower risk in mission-critical deployments. See Cost of Security for related discussion.
  • Real-world effectiveness: Some skeptics question whether CC evaluations always map to real-world security under complex threat environments. Supporters contend that the CC framework’s emphasis on evidence, reproducibility, and independent testing provides a credible foundation for trust, and that the protections can be tailored to actual risk profiles through STs and PP definitions. See Threat Model.
  • Innovation vs. standardization: There is a debate about whether strict evaluation frameworks stifle innovation by forcing products to conform to predefined profiles. Advocates argue that standards actually accelerate innovation by clarifying requirements, reducing ambiguity, and enabling competitive differentiation through verifiable security properties rather than marketing claims. See Innovation.
  • Export controls and market access: Some critics worry that heavy certification regimes can create barriers to entry in global markets or distort competition toward larger players with the resources to navigate the process. Proponents note that widely recognized standards can facilitate cross-border trade and reduce political risk for buyers, especially in security-sensitive sectors. See Global Trade.
  • Relevance for small or niche products: In fast-moving sectors (e.g., certain IoT devices), the time to certify against a stable PP can lag behind rapid product iterations. The community has looked to adaptive processes and lighter-weight assurance paths for such cases, while preserving core guarantees for more critical systems. See IoT Security and Niche Markets.

See also