Foreword
The Canadian Common Criteria Program Instructions is an UNCLASSIFIED publication intended for testing labs operating in the Canadian program. This document supersedes all previous instructions for the Canadian Common Criteria Program, from either the Canadian Centre for Cyber Security or the Communications Security Establishment.
Effective date
This publication takes effect on March 1, 2023.
-
Revision history
- 1.0 September 30, 2019
First revision of a harmonized set of program instructions.- Incorporated all scheme instructions into a single document
- Reformatted the document using a Canadian Centre for Cyber Security template
- Updated content of instructions to reflect process changes
- 1.1 June 11, 2021
Revision of section on cryptographic functionality. - 1.2 October 25, 2021
Added sections for “Core and essential functionality”, “Remote testing” and “Assessing and addressing vulnerabilities” - 1.3 December 6, 2021
Revised the section on “Evaluation eligibility”, added a reference document for approved cryptography, updated interim evaluation milestone requirements to remove approval confirmation from the Cyber Centre, amended Testing milestone date to PiE + 4.5 months, de-coupled remote testing proposal from the eligibility stage, harmonized terminology - 1.4 December 31, 2021
Incorporated comments from certification body review - 1.5 January 7, 2022
Update to Eligibility section - 1.6 February 21, 2022
Updates based on feedback from the testing labs - 1.7 March 25, 2022
Updates based on feedback from the testing labs - 1.8 June 8, 2022
Formatting changes - 1.9 January 20, 2023
Updates to sections on missing milestone deadlines and on crypto requirements for EAL-based evaluations where crypto is primary TOE functionality - 2.0 February 12, 2023
Several minor edits for added clarity and document consistency
- 1.0 September 30, 2019
Overview
This document contains all instructions related to evaluations within the Canadian Common Criteria program.
1 Introduction
The Common Criteria for Information Technology Security Evaluation, (also referred to as the Common Criteria, or CC) is an international standard for specifying security requirements for Information Technology (IT) products. The Canadian Centre for Cyber Security (hereafter the Cyber Centre) operates the national Certification Body (CB) for Common Criteria evaluations performed in Canada.
This document includes detailed topics for Common Criteria Testing Laboratories (hereafter testing labs) related to the evaluations performed within the Canadian program.
2 Evaluation eligibility
The Cyber Centre accepts evaluations into the Common Criteria program in the following order of priority:
- Evaluations to Common Criteria Protection Profiles, including:
- International collaborative Protection Profiles developed by the international technical community; and
- Selected Protection Profiles and PP-Modules developed by one of the member countries to the Arrangement on the Recognition of Common Criteria Certificates in the field of Information Technology Security (PDF) (CCRA).
- For technology types where there are no suitable Protection Profiles, other evaluations that fall within the scope of the CCRA; at the time of writing this includes evaluations up to Evaluation Assurance Level (EAL) 2.
The Cyber Centre will also consider accepting evaluations beyond the scope of the CCRA on a case-by-case basis. This includes EAL 3 or EAL 4 evaluations.
3 Core and essential functionality
For Evaluation Assurance Level (EAL)-conformant evaluations, where the specification of Security Functional Requirements (SFRs) has not been pre-determined by a Protection Profile, it is important to ensure that the evaluation covers a meaningful set of security functionality. This includes both Core Functionality and Essential Functionality, as described below.
3.1 Core functionality
Core functionality is defined as the primary purpose of a product based upon how it is marketed. This includes any advertised interfaces. This may require the creation of extended SFRs in cases where the core functionality of the Target of Evaluation (TOE) cannot be represented by existing SFRs. Any included functionality/interfaces should be related to cybersecurity.
3.2 Essential functionality
Essential functionality can be defined as functionality that has been deemed important to the cybersecurity of the product (based on the nature of the TOE) by the Cyber Centre, such as Secure Management and Inter-TOE communication.
3.3 Specification of requirements
Evaluations are required to include the Core Functionality of the TOE and any included Essential Functionality (or lack thereof), and the onus is on the testing lab to provide a rationale for any perceived deficiencies.
4 Timelines for evaluations
The Cyber Centre recognizes that consumers require security assurance for current versions of IT products, so evaluations need to occur in a timely manner. Modern product lifecycles can be short and the amount of time that a product remains “in evaluation” needs to reflect this.
The Cyber Centre believes that advanced preparation for evaluations - such as a functional gap analysis prior to evaluation – are a necessary part of modern evaluations. As such, the Cyber Centre introduces evaluation milestones and timelines that testing labs must meet for evaluations.
4.1 Evaluation milestones
The Cyber Centre recognizes the following milestones within evaluations:
- Security Target
- Design/Entropy
- Testing
- Final Evaluation
4.1.1 Security target milestone
The Security Target milestone requires that the testing lab complete all evaluation activities associated with the Security Target Evaluation assurance class.
Once the Security Target milestone is complete, the Cyber Centre lists the product on the program’s Products in Evaluation list. The date that this happens is the Product in Evaluation (PiE) Date for the product.
4.1.2 Design/entropy milestone
The Design/Entropy milestone requires that the testing lab complete all evaluation activities associated with the Development assurance class and where required to meet the claimed Protection Profile (PP), an entropy analysis.
4.1.3 Testing milestone
The Testing milestone requires that the testing lab complete all required functional and penetration testing.
4.1.4 Final evaluation milestone
The Final Evaluation milestone requires that the testing lab successfully complete all evaluation activities.
4.2 Milestone deadlines
The Cyber Centre applies the following deadlines to the evaluation milestones described in Section 4.1:
Design/Entropy: PiE Date + 2 months
Testing: PiE Date + 4.5 months
Final evaluation: PiE Date + 6 months
In order to ensure that the Cyber Centre has adequate time to review the Final Evaluation deliverable, it must be received no later than 2 weeks prior to the milestone deadline.
4.3 Requesting extensions to milestone deadlines
The Cyber Center will consider requests from testing labs for milestone deadline extensions. The testing lab shall detail why they are unable to meet the deadline, propose a reasonable extension period, and describe the measures they will take to meet the new date.
4.4 Missing milestone deadlines
When an evaluation misses a milestone deadline, taking into account any deadline extensions that have previously been granted, the Cyber Centre will remove the IT product from the Products in Evaluation list. However, the testing lab may continue with the evaluation, and the evaluation will remain eligible for certification.
The Cyber Centre reserves the right to terminate the evaluation. Factors affecting such a decision may include the length of evaluation delays or changes to the evaluation parameters that the Cyber Centre deems unacceptable.
5 Evaluation of cryptographic functionality
The Cyber Centre leverages the results of the Cryptographic Module Validation Program (CMVP) and the Cryptographic Algorithm Validation Program (CAVP) to ensure that evaluators adequately evaluate cryptographic modules and algorithms within the scope of an evaluation.
Note: The Cyber Centre jointly manages the CMVP and CAVP in partnership with the United States National Institute of Standards and Technology (NIST).
5.1 Cryptographic functionality
- For PP-conformant evaluations, a CAVP certificate is required for the cryptography claimed.
- For EAL-conformant evaluations where the primary purpose of the TOE is cryptography, a CMVP certificate is required for the cryptography claimed.
- For EAL-conformant evaluations where the environment provides cryptography in support of TOE functionality, a CAVP certificate is required for the cryptography claimed.
- For EAL-conformant evaluations where the TOE provides cryptography used for supporting functionality, a CAVP certificate can be used for the cryptography claimed. Under certain conditions, testing using a Known-Good implementation may be acceptable in lieu of CAVP.
In all cases, only Cyber Centre approved cryptography is to be used. ITSP.40.111 – Cryptographic algorithms for UNCLASSIFIED, PROTECTED A, and PROTECTED B Information identifies and describes approved cryptographic algorithms and appropriate methods of use.
5.2 Verification of cryptographic implementations
The Cyber Centre requires that evaluators verify the presence of all cryptographic implementations claimed by the vendor. It is not sufficient for testing labs to merely point to a CAVP/CMVP certificate. This verification can take various forms depending on the type of implementation and the level of access the evaluator has to the underlying functions of the TOE.
5.3 Entropy assessment
The Cyber Centre requires an entropy assessment whenever there is a conformance claim to a protection profile that includes random number generation (RNG) requirements performed by the TOE. These protection profiles clearly state the cases where the Security Target must claim the RNG functions.
6 Remote testing
Testing labs are expected to perform testing of products at their facility. In exceptional circumstances, this might not be feasible. What follows are the conditions and requirements of when testing labs may conduct remote testing of products.
6.1 Conditions
Under exceptional circumstances, testing labs may request to test remotely under the following situations:
- If the costs involved in testing/shipping/setup the TOE are prohibitive;
- If the TOE setup/environment is overly complex and requires significant support from the developer;
- If the testing requires specialized tools/equipment that the vendor possesses but cannot provide to the testing lab; or
- Other conditions subject to Cyber Centre approval.
6.2 Requirements
In order to gain approval from the Cyber Centre for remote testing, the testing lab must provide the following details:
- A detailed justification:
- If claiming cost, provide a high-level breakdown of the costs involved.
- If claiming complexity, provide a rationale as to why the TOE setup/environment is overly complex.
- If claiming specialized tools, provide details about the tools and why the testing lab cannot procure them.
- An explanation as to how the evaluator will meet the requirements for AGD_PRE.
- How testing will be performed by the evaluator.
- How control of the test environment will be maintained by the evaluator.
- How witnessing will be accommodated.
Remote testing requests should be submitted as early as possible, preferably during the eligibility stage. The Cyber Centre has final approval of any remote testing requests.
7 Assessing and addressing vulnerabilities
All potential vulnerabilities discovered during the public domain search or automated tool-based discovery process shall be assessed by the testing lab using criteria provided by the Cyber Centre. The assessment process shall be sufficiently detailed to determine whether the product and its components are free of security-relevant vulnerabilities.
7.1 Assessment
All potential vulnerabilities discovered during the public domain search or automated tool-based discovery process shall be assessed by the testing lab using criteria provided by the Cyber Centre. The assessment process shall be sufficiently detailed to determine whether the product and its components are free of security-relevant vulnerabilities.
7.2 Addressing
Any actual vulnerabilities identified in the evaluated product shall be addressed. If a vendor patch addressing the vulnerability exists, it needs to be applied. If a vendor patch does not exist, vulnerabilities may be handled by:
- Removing the affected functionality (Preferred);
- Disabling the affected functionality and issuing a public notice advising of the issue; or
- Providing a vendor plan for addressing the vulnerability.
The Cyber Centre has final approval on any approaches taken to address vulnerabilities.
8 Supporting content
8.1 List of abbreviations
- CAVP
- Cryptographic Algorithm Validation Program
- CC
- Common Criteria
- CCRA
- Common Criteria Recognition Arrangement
- CMVP
- Cryptographic Module Validation Program
- CSE
- Communications Security Establishment
- EAL
- Evaluation Assurance Level
- GC
- Government of Canada
- IT
- Information Technology
- ITS
- Information Technology Security
- NIST
- National Institute of Standards and Technology
- OSP
- Organizational Security Policy
- PCL
- Product Compliance List
- PiE
- Product in Evaluation
- PP
- Protection Profile
- RNG
- Random Number Generation
- SFR
- Security Functional Requirement
- ST
- Security Target
- TLS
- Transport Layer Security
- TOE
- Target of Evaluation