Frequently asked questions
The Common Criteria (CC) is an international standard, also available as ISO/IEC 15408 used when evaluating the security properties of IT products and systems. It defines a framework for the oversight of evaluations, syntax for specifying the security requirements to be met and a methodology for evaluating those requirements. The CC is used by governments and other organizations around the world to assess the security of information technology products and is often specified as a pre-requisite to procurement. See https://www.commoncriteriaportal.org/cc/ for more information or to obtain the standard.
At the time of writing the most inclusive mutual recognition arrangement is the Common Criteria Recognition Arrangement (CCRA): Currently the list includes Australia, Austria, Canada, Czech Republic, Denmark, Ethiopia, Finland, France, Germany, Greece, Hungary, India, Indonesia, Israel, Italy, Japan, Republic of Korea, Malaysia, the Netherlands, New Zealand, Norway, Pakistan, Poland, Qatar, Singapore, Spain, Sweden, Turkey, the United Kingdom and the United States as signatories. The up to date list of CCRA participant nations is maintained on https://www.commoncriteriaportal.org/ccra/members/.
Other recognition arrangements exist, for example in Europe, the SOG-IS arrangement allows for recognition between European nations with different parameters to those of the CCRA.
Bi-lateral agreements can also exist.
Other nations, for example China and some organizations may also make use of the ISO/IEC 15408 standards and paradigm
There are three parties involved in the CC evaluation process:
1. Vendor or Sponsor. The vendor/developer engages an accredited laboratory and submits their product and associated evidence for evaluation.
2. Laboratory. The laboratory performs the evaluation and reports evaluation results to the scheme. Evaluation is iterative in nature and the vendor is able to address findings during the evaluation.
3. Scheme. Certificate authorizing schemes (also known as a certification body) issue CC certificates and perform certification/validation oversight of the laboratory. Each scheme has its own policies with regard to how the CC is used in that country and what products may be accepted into evaluation
The following provides a high-level overview of what gets evaluated:
Documents defining the evaluation:
Security Target evaluation. Evaluation of the Security Target (ST) - a claims document that specifies the security functions under evaluation and the security assurance requirements being met.
Protection Profile evaluation. Evaluation of the Protection Profile (PP) - an implementation-independent statement of security needs for a technology type.
The product (technically called a Target of Evaluation (TOE). These evaluations can include:
- Design evaluation. Evaluation of design documents - at the most basic level this will simply be an interface specification. Depending on the assurance requirements this can include multiple layers of very detailed design specs and source code review (this is becoming less common).
- Guidance evaluation. Evaluation of the guidance documents that are shipped with the product and any CC specific addendum or ‘Secure Installation Guide’ for achieving the evaluated configuration.
- Life-cycle evaluation. Evaluation of configuration management practices, delivery procedures and security bug tracking (flaw remediation). Can also include development practices and site security audits.
- Functional testing. The evaluators repeat a sample of the developer’s functional tests and come up with some independent tests to confirm the operation of the security functions as specified.
- Vulnerability analysis / Penetration testing. The evaluators perform vulnerability analysis and penetration testing.
Whether a particular evaluation activity gets performed is dependent on the assurance requirements that are specified in the ST.
A Security Target is the document that defines the Target of Evaluation (TOE), that is, the product configuration and version, and scope of security functionality being evaluated. The CC allows the TOE to be all or part of a product or system. The Security Target is put together using CC constructs and includes a threat model, environmental assumptions, security objectives, security functional requirements and security assurance requirements. A Security Target may conform to a Protection Profile but may be optional in some schemes). A Security Target (written by vendor) goes beyond a Protection Profile (written by consumer) by including a description of how the product achieves the defined requirements.
Security Target examples may be found at https://www.commoncriteriaportal.org/products/
A Protection Profile is a requirements statement put together using CC constructs. Protection Profiles are generally published by governments for a specific technology type, for example, Firewalls, as part of procurement policy. A Protection Profile specifies both functional and assurance requirements. It is not necessary for a Security Target to claim conformance to a Protection Profile however some schemes will only accept products into evaluation that claim conformance with scheme approved Protection Profiles. A given product may conform to multiple Protection Profiles.
A centralized repository of Protection Profiles is published at https://www.commoncriteriaportal.org/pps/
Work is underway to develop a set of Collaborative Protection Profiles (cPP) developed by international technical communities and approved by multiple schemes. Additional information on this initiative is published at https://www.commoncriteriaportal.org/pps/collaborativePP.cfm?cpp=1&CFID=50449855&CFTOKEN=128d3f224a6fcbd2-9042B106-155D-00D0-0AA2F31A79DB3F05
An Evaluation Assurance Level (EAL) is a predefined set of assurance requirements ranging from EAL1 (Functionally Tested) to EAL7 (Formally Verified Design and Tested). A Protection Profile or Security Target may reference an Evaluation Assurance Level (EAL) or may instead specify a custom set of assurance requirements.
Evaluation projects will typically takes few months, however the time of an evaluation depends on many factors such as product complexity and assurance claims. An evaluation project includes product preparation (including testing), documentation preparation, lab engagement, lab evaluation and finally certification by the government oversight body.
CC certification only applies to the configurations and versions specified by the certified Security Target. So for example, if your product goes from v1.0 to v1.0.1, the certificate no longer applies to that new version. Some schemes may offer longer certificate validity with certain update provisions. There is however a process called Assurance Continuity to accommodate product changes.
Assurance Continuity allows minor changes to be performed to an evaluated product and subsequent versions appended to the original CC certificate. Where changes are security related (and are classified as ‘major’), Assurance Continuity allows these changes to be rapidly evaluated through ‘re-evaluation’, which utilizes results from the original evaluation.
Note: Individual schemes have differing policies regarding the use of Assurance Continuity.
Further details about the Assurance Continuity program are included in the Common Criteria Recognition Arrangement (CCRA) Supporting Documents at https://www.commoncriteriaportal.org/cc/#supporting
CC certified products have undergone a rigorous evaluation process performed by accredited third-party security labs in accordance with internationally accepted criteria and a government-managed framework. Specific advantages include:
- Security functions have been verified and tested
- Product has passed vulnerability assessment and penetration tests
- Developer processes have been assessed
- Product meets checkbox CC procurement requirements
- EN 419 211-2 (Secure signature creation device - Part 2: Device with key generation)
- EN 419 211-3 (Secure signature creation device - Part 3: “Device with key import”)
- EN 419 211-4 (Secure signature creation device - Part 4: “Extension for device with key generation and trusted communication with certificate generation application”)
- EN 419 211-5 (Secure signature creation device - Part 5: “Cryptographic Module for Trust Services”)
- EN 419 211-6 (Secure signature creation device - Part 6: Extension for device with key import and trusted communication with signature creation application)
- EN 419 241-2 (Trustworthy Systems Supporting Server Signing Part 2: Protection Profile for QSCD for Server Signing)
- EN 419-221-5 (Protection profiles for TSP Cryptographic modules - Part 5 Cryptographic Module for Trust Services)
- BSI-CC-PP-0055 (Machine Readable Travel Document with ICAO Application and Basic Access Control (MRTD-PP))
- BSI-CC-PP-0056 (Machine Readable Travel Document with ICAO Application, Extended Access Control (PP-MRTD EAC))
- BSI-CC-PP-0068 (Machine Readable Travel Document using Standard Inspection Procedure with PACE (PACE PP))
- BSI-CC-PP-0084 (Security IC Platform Protection Profile with Augmentation Packages)
- BSI-CC-PP-0087 (Machine-Readable Electronic Documents based on BSI TR-03110 for Official Use (MR.ED-PP))
- We work with agile methodologies and toolset
- We ensure quick reactions and cooperation
- We have dedicated consultants and evaluators
- We have proven CC certification in 4 months
- We are the first CCRA lab in the CEE
- We offer competitive pricing
- We have ongoing successful University programs
- We work under an innovative and professional scheme
- We are No. 1 laboratory for smartcards and HSM's
- We have 40+ certifications onboard (CEH,CISA,CHFI,OSCP,ISO)
- We have 100% client satisfaction
- We have channel Partners around the world
- We have a dynamic employee growth
- We have Fortune 500 clients
- We are members of worldwide standardization workgroups
A certification which ensures that the product itself is secure and independently verified on a desired EAL level. Common Criteria certifications are one of the common and internationally standardized information security solutions in the world. Thanks to the CCRA (Common Criteria Recognition Arrangement ) and further mutual agreements, the certified product owners are in the especial position, where selling their product worldwide not only in compliance with expected information technology security requirements (which is a CC certification in the most cases when it comes to tenders), but the evidence of the product’s compliance of up to date international professional standards.
Such certifications are mainly requested by the developers.
In case you are in the process of creating a new software or hardware product, you have probably come across the opportunity to secure your product to a certain level. Common Criteria evaluations are for those, whose are already prepared for such IT security challenges or welcome the work which leads to a globally acceptable high-end security certification.
CCLab is registered under the Italian Scheme OCSI (Organismo di Certificazione della Sicurezza Informatica), which is part of CCRA and SOGIS as well.
The “Vulnerable data” means the protected objects (assets or interfaces based on the SBA) in the test object that shall be protected (confidentiality, integrity and availability).
In the case, the key is also vulnerable data.
Swissmig created a Risk analysis document [Studie «Schutzbedarfsanalyse Smart Metering in der Schweiz»; 062016], which contains risk scenarios.
In this document, Swissmig determined the assets, the objects to be protected against threats. Prüfmethodologie's OT matrix summarizes this information.
To choose CCLab as Test Laboratory please enter the CCLab specific data to METAS Application form (Antragformular):
- Name: CCLab Ltd.
- Abteilung: -
- Strasse: Katona Jozsef 17. III.2.
- PLZ Ort: 1137 Budapest
- Land: Hungary
- Internetadresse: https://www.cclab.hu
- Kontaktperson (des Prüflabors)
- Name: Mr. Ferenc Molnár
- Funktion: CEO
- Telefon/Mobiltelefon: +36 30 280 6524
- E-Mail: firstname.lastname@example.org
Swiss Smart metering
Our Laboratory issues this Whitepaper as a brief summary. METAS provides a checklist and detailed information to the test process: https://www.metas.ch/metas/de/home/dl/datensicherheitspruefungen.html
Our Laboratory issues this Whitepaper as a brief summary. METAS provides a checklist and detailed information to the test process:
Sec. 2.1 Required documents describes which documents should you submit at the beginning of the test process.
The checklist is a requirement catalogue ("WHAT" column) that shall be fulfilled by the manufacturer ("HOW" and "WHERE") columns. "HOW" is an ADV_FSP-like description while the "WHERE" is an ADV_ARC-like description. In each HOW cell of the checklist the relevant OT tuples (“x”) from the OT matrix must be referenced (if any).
The RL-DSP-CH_A2_1045 is the recommended processes for operating a whole smart meter system. It includes among others a theoretical explanation for the “5.1 Test field IT security concept” part of Manufacturer document.
The requirements from chap. 5 of Annex 1 and the Prüfmethodologie chap. 7 are identical. Other parts of Annex 1 and Annex 2 basically contains requirements for the main components of an iMS.
The requirements are implemented by the architecture and functionality of the main components.
We will perform the testing procedure based on the requirements of the Prüfmethodologie from section 5.1 to 5.6. which refers to the OT matrix and the checklist.
Based on the Prüfmethodologie sec 5.2 which is about the checklist:
- fills the checklist of the Prüfmethodologie chap.7 Prüflistenmodule (checklist)
- (HOW - secure functionality to satisfy the WHAT requirement, WHERE – localization of the functionality in the architecture, referencing the relevant OT tuples)
- delivers the sufficient documentation of the Components
- and performs functional tests
- checks the HOW value of checklist to make sure that it gives a solution to the WHAT (correctness, efficiency, completeness, based on the filled checklist and the additional Manufacturer documents for meter system components) (Prüfmethodologie chap.7 Prüflistenmodule, e.g 5.1.4 (b)
- looks at whether the functionalities linked in the WHERE can really deliver the functionality
- determines a verdict based on steps above
- performs vulnerability analysis and penetration test to confirm the compliance
The requirements of the Prüfmethodologie will also be examined during the documentation evaluation and the penetration test process according to the steps above.
The requirement means that the assets need to be stored in encrypted format in the Smart Meter, furthermore the system must include a procedure for the secure, selective deletion of specific data. This procedure shall delete the data permanently, for example through overwriting with random data, therefore these specific data cannot be restored.
So, it is about secure storing and deleting, not exchanges.
This is a general requirement for all components, and it will be tested during the penetration test.
Usually, this process cannot be planned preliminary - a deep knowledge of the TOE is necessary.
There is a possibility to set up the HES in our laboratory. We can also test the HES with remote access.
First of all you deliver the test samples to our laboratory. We are responsible for the secure management of the test samples within the physical boundaries of the Laboratory. After the test process, we store the samples for at most one year for easier re-evaluation. After the one-year retention period, we send back the samples to you or take care of the secure disposal. Our price list contains the conditions of back delivery or secure disposal.
This can be certified within one evaluation process, but all the security relevant parts need to be tested separately. This may result in additional costs compared to a simple TOE evaluation process. If a configuration is not security relevant (e.g. color of the enclosure) no further tests are necessary. In the final test report, all possible configurations will be listed.
Smart metering recommendations for manufacturers
- Every relevant Object and Threat shall be cross-checked
- It is worth using the SDCM matrix to check the relevance (there is embedded macro logic)
- For every cross-check describe the security functionality (SF) shortly, detailed information shall be referenced in the related documentation
- The SF description should include the localisation (TOE, TOE environment or Organisation Security PAC - OSP)
- It is a good solution to use the SDCM Excel sheet as a framework to create the manufacturer’s OT matrix
- For every row, describe shortly the implementation and localisation, use references if necessarymore detailed information shall be referenced in the related documentation
- The SDCM is consistent with the OT matrix control and checklist sheet, hence the rows should be consistent.
- TOE shall be pre-configured and as exactly described in the product documentation - security settings shall be double-checked before delivery
- The operability and correct configuration of TOE shall be tested by the manufacturer before delivery
- The tested and operable credentials of the TOE and a short step-by-step login guide shall be delivered with TOE too.
- The fulfilment of the previous 3 requirements can save a lot of time during evaluations
- Proper identification of the whole TOE and main parts of the TOE are required (ID, name, version)
- A well-structured OT matrix and checklist speeds up evaluations
- In the manufacturer’s OT matrix, mark the cells where SDCM indicate “not relevant” and please justify
- One sentence for a security functionality within the OT matrix is not enough evidence. Must be supported by detailed information - referenced in the related documentation
- Appropriate reference is a must in manufacturer docs: Doc name, version, date, relevant Chapter, or section/paragraph
- The consistent referencing between the documentations and OT matrix description, checklist, OT matrix and related checklist indicated by SDCM are required.
- The OT matrix and Checklist shall focus on mandatory contents.
- Do not refer to irrelevant documents
- Preliminary acceptance checks of manufacturer documentation can be useful. (Starting an evaluation with deficient or contradictory documentation is not recommended
- Missing or inexact TOE identification
- OT matrix is not consistent with the description of security functionalities (missing fields or descriptions)
- Inexact or missing references (missing chapter, section, therefore the relevant evidence cannot be identified)
- The Checklist’s „HOW” section doesn’t answer the „WHAT” requirement
- „HOW” or „WHERE” cannot be verified (no reference to detailed documentation)
- The content of HOW and WHERE are inexact (TOE implementation differences)
- TOE is not pre-configured or tested by the manufacturer according to the product’s documentation - security settings shall be double-checked. In these cases, the laboratory has to focus and spend days on preliminary actions to set up an operable TOE.
- We recommend addressing any arising serious questions on the go, daily contact and quick reactions accelerate evaluations.