Common Criteria (ISO/IEC 15408)
Global framework for evaluating and certifying the security of information technology products and systems.
Overview
The Common Criteria for Information Technology Security Evaluation (CC) is an international standard (ISO/IEC 15408) used by governments and industry to assess the security assurance of IT products. It provides a common language for specifying security requirements, evaluating implementations, and recognising certificates across member nations through the Common Criteria Recognition Arrangement (CCRA).
Why Organisations Care
- Required for procurement in many government and defence programmes
- Provides objective assurance claims for commercial customers
- Supports compliance with frameworks such as NIST, ISO 27001, and national schemes
- Enables mutual recognition of evaluations up to EAL2 (CCRA) or higher within regional schemes
Key Roles
- Developer / Vendor: Builds the TOE (Target of Evaluation) and evidence
- Evaluation Facility (ITSEF/CLEF): Independent lab performing the assessment
- Certification Body: Approves results (e.g., UK NCSC / CPA, BSI, NIAP)
- Consumer: Specifies requirements via Protection Profiles (PPs)
Evaluation Assurance Levels (EALs)
| EAL | Title | Focus & Typical Use |
|---|---|---|
| EAL1 | Functionally Tested | Basic assurance. Confidence gained from functional testing. Often used for low-risk commercial products. |
| EAL2 | Structurally Tested | Requires structural analysis and independent testing documentation. Suitable for products requiring moderate assurance with developer cooperation. |
| EAL3 | Methodically Tested and Checked | Emphasises development environment controls and configuration management. Common for network equipment and security appliances. |
| EAL4 | Methodically Designed, Tested and Reviewed | Most widely pursued level. Requires rigorous design documentation, testing, and vulnerability analysis. Aligns with commercial best practices. |
| EAL5 | Semi-Formally Designed and Tested | Introduces semi-formal design descriptions and comprehensive testing. Targeted by high assurance products (e.g., smartcards, military systems). |
| EAL6 | Semi-Formally Verified Design and Tested | High-level security assurance with formal methods. Used when threat risk is significant and high value assets are protected. |
| EAL7 | Formally Verified Design and Tested | Highest assurance level. Requires formal proof of correctness. Rare; reserved for exceptional cases such as TOP SECRET environments. |
Note: Mutual recognition under the CCRA is guaranteed up to EAL2 (with ALC_FLR.1). Regional schemes (e.g., SOG-IS, NIAP) may recognise higher levels for specific technology domains.
Protection Profiles (PPs)
- Implementation-independent requirements written by consumers or regulators
- Define security problem, objectives, and assurance requirements for a technology class
- Examples: Network Device Collaborative Protection Profile (NDcPP), Mobile Device Fundamentals
- Vendors conform to a PP to meet market or regulatory expectations
Security Targets (STs)
- Implementation-specific document for the Target of Evaluation (TOE)
- Describes the product, security environment, and conformity to PPs (if claimed)
- Includes functional requirements (SFRs) and assurance requirements (SARs)
- Forms the baseline for the evaluation activities performed by the lab
CC Evaluation Lifecycle
1. Preparation
- Determine applicable PP(s) and desired EAL
- Engage accredited evaluation lab and certification body
- Develop Security Target (ST) and supporting design evidence
- Establish Configuration Management (CM) baselines
2. Evaluation Activities
- Lab performs document analysis, design review, and testing
- Includes vulnerability analysis, penetration testing, and lifecycle assessment
- Findings logged in Evaluation Technical Report (ETR)
- Developer addresses observations via rework rounds
3. Certification & Maintenance
- Certification body reviews ETR, issues certificate and public report
- Products listed on official scheme portal (e.g., CCRA, NIAP Product Compliant List)
- Maintenance updates (assurance continuity) handle minor variations without full re-evaluation
- Recertification required for major releases, new platforms, or PP changes
Developer Readiness Checklist
Documentation
- Security Target (ST) aligned with chosen PP/EAL
- Design documentation (TOE architecture, interfaces, subsystems)
- Guidance documentation for administrators and users
- Configuration Management plan and evidence (baselines, versioning)
Operational Evidence
- Development Security (physical, access control, secure build procedures)
- Testing artefacts (unit, integration, vulnerability testing)
- Delivery procedures and integrity checks
- Patch management and flaw remediation processes
Comparison & Complementary Schemes
Common Criteria vs. FIPS 140-3
- CC evaluates overall product security functionality; FIPS 140 focuses on cryptographic modules
- Many products pursue both certifications for defence or federal markets
Common Criteria vs. SOC 2 / ISO 27001
- SOC/ISO assess organisational controls; CC evaluates the product itself
- Use CC to demonstrate product assurance, ISO 27001 to show organisational maturity