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 prerequisite 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 take a 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))

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, who are already prepared for such IT security challenges or welcome the work which leads to a globally acceptable high-end security certification.

CCLab is accredited by the Italian Scheme OCSI (Organismo di Certificazione della Sicurezza Informatica) and also the German Scheme BSI (Bundesamt für Sicherheit in der Informationstechnik), which are  part of CCRA and SOGIS as well.

• EN 419 211-2 (Secure signature creation device - Part 2: Device with key generation) / BSI-CC-PP-0059-2009-MA-01, Version 2.0.1

(Protection profiles for secure signature creation device – Part 2: “Device with Key Generation”)

• EN 419 211-3 (Secure signature creation device - Part 3: “Device with key import”) / BSI-CC-PP-0075-2012 (Protection profiles for 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”) / BSI-CC-PP-0071-2012, Version 1.0.1

(Protection profiles for 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”) / /BSI-CC-PP-0072-2012, Version 1.0.1
• (Protection profiles for secure signature creation device – Part 5: Extension for device with key generation and trusted communication with signature creation application)
• EN 419 211-6 (Secure signature creation device - Part 6: Extension for device with key import and trusted communication with signature creation application) / BSI-CC-PP-0076-2013 (Protection profiles for secure signature creation device - Part 6: Extension for device with key import and trusted channel to 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)
• CIMC PP Certificate Issuing and Management Components Protection Profile, Version 1.5
• Protection Profile for Application Software, Version 1.3, 1 March 2019 (NIAP) 
• Protection Profile for Certification Authorities Version 2.1, 2018-12-01
• Collaborative Protection Profile For Network Devices, Version 2.2e, 2020-03-23
• Protection Profile Module For Stateful Traffic Filter Firewalls Version 1.3, 2019-09-27
• Protection Profile- Module For Private Network (VPN) Gateways, Version 1.1, 2020-06-18
• Protection Profile For Mobile Device Fundamentals, Version 3.2, 2021-04-15
• General Purpose Operating Systems Protection Profile/ Mobile Device Fundamentals Protection Profile Extended Package (EP) Wireless Local Area Network (WLAN) Clients, Version 1.0, 2016-02-08
• Protection Profile For Application Software, Version 1.4, 2021-10-07
• Functional Package For Transport Layer Security, Version 1.1, 2019-02-12

ISO / SAE 21434 covers all parts of the vehicle lifecycle, from design to decommissioning of cyber security techniques.This concerns all electronic systems, components, and software in the vehicle, and any external connectivity.

ISO21434 is important, because the connectivity in vehicles and the development of autonomous cars increase the risks of cyberattack and subsequent damage too. The purpose of the standard is to provide a structured process to ensure that cybersecurity considerations are incorporated into automotive products during their lifetime. The standard requires automotive manufacturers and suppliers to demonstrate due diligence in the implementation of cybersecurity engineering and that cybersecurity management is applied throughout the supply chain to support it.

We offer “zero to hero” and integration services which help manufacturers/developers to achieve cybersecurity compliance.

Our comprehensive services help from planning through implementation. They provide a clear path to compliance through methodology based on internationally recognized standards.

Integration services build on customers’ already implemented management systems that comply with relevant industry standards. Integration services help customers to utilize their already implemented processes instead of creating new ones.

• Gap analysis
• Risk management
• Vulnerability testing (testing and training)
• Preparation for certification
• Technical advice & consultation,
• Checking & evaluating technical documentation,
• Preparatory audit
• Preparation of technical reports,
• Complete type-approval process management.

• We provide what we do best - we know all the requirements of the CBs, so our experiences are the guarantee for an efficient compliance project.
• We are familiar with the format and content a certification body requires, so we can minimize the risk and project time for our clients.
• Smooth transition to ISO/SAE 21434 is guaranteed in a “one-stop shop”.
• Dedicated professionals’ guidance will streamline the process and shorten project time.
• Real value provided for reasonable pricing.

The ISA/IEC 62443 is a series of standards that address cybersecurity for operational technology in automation and control systems. It addresses  technical and process-related aspects of cybersecurity for industrial service providers, industrial systems, and components in industrial systems. The standard is designated as “horizontal” by IEC. It provides an achievable model to create security focused processes, handle risks and mitigate cybersecurity threats.

The standards are divided into four parts:  

• GENERAL (62443-1) - Overview of the IEC 62443 security process.
• POLICIES AND PROCEDURES (62443-2) - Guidance for creating and maintaining a secure system. 
• SYSTEM (62443-3) – Includes cybersecurity technologies, risk assessment methods for system design along with the description of system security requirements and security levels 
• COMPONENT (62443-4) - Describes the technical functionality levels and development life cycle requirements for IACS components.

‍

The IEC 62443 describes 4 levels of security functionality:

• SL 1 – Protection against causal or coincidental violation
• SL 2 – Protection against intentional violation using simple means with low resources, generic skills and low motivation
• SL 3 – Protection against intentional violation using sophisticated means with moderate resources, IACS specific skills and moderate motivation
• SL 4 – Protection against intentional violation using sophisticated means with extended resources, IACS specific skills and high motivation

• Readiness assessment
• Gap analysis
• Consultation and support the preparations for certification
• Development process audit & certification (4-1)
• Product evaluation & certification (4-2)
• Online and on-site workshops
• Documentation review
• Process support by auditors

SL1-  Protection against causal or coincidental violation

SL2- Protection against intentional violation using simple means with low resources, generic skills and low motivation

SL3- Protection against intentional violation using sophisticated means with moderate resources, IACS specific skills and moderate motivation

SL4- Protection against intentional violation using sophisticated means with extended resources,IACS specific skills and high motivation 

‍

There are three organizational role, who have responsibility:

• Asset Owner / End-user: 

- Owns and operates one or more IACS

- Easy to define a target security level

- Offers a frame of reference to evaluate existing security

•  System Integrator/ Implementer

- Builds IACS for the Asset owner 

              - Clear understanding of security requirements 

              - Simple to define a system security capability 

•   Product Manufacturer/ Supplier 

- Designs and creates the components for the System Integrator to build IACS.

              - Simple to define a product security capability

              - Easy to differentiate from competitors 

The standard is divided into 4 parts: General, Policies and Procedures,System, Component, which are denoted by the suffixes from 1 to 4. 

• General (62443-1) - Overview of the ISA/IEC 62443 security process. 
• Policies and Procedures (62443-2) - Guidance for creating and maintaining a secure system. 
• System (62443-3) - Includes cybersecurity technologies, risk assessment methods for system design along with the description of system security requirements and security levels. 
• Component (62443-4) - Describes the technical functionality levels and development life cycle requirements for IACS components.

Together with our partner company, another member of QTICS Group, we provide the following services from preparation to getting certified for 62443-4-1 - Product development requirements and for 62443-4-2 Technical security requirements for IACS components:

• Readiness assessment
• Gap analysis
• Consultation and support the preparations for certification
• Development process audit & certification (4-1)
• Product evaluation & certification (4-2)
• Online and on-site workshops
• Documentation review
• Process support by auditors

IoT devices are the nonstandard computing devices that connect wirelessly to a network and have the ability to collect, store and transmit data. Embedded with technology, these devices can communicate and interact over the internet. They can also be remotely monitored and controlled. 

As technology continues to advance, anything can be turned into part of the IoT. There are many different types of IoT devices, some examples include

• Computers: Desktop computers, laptops, tablets, and smartphones 
• Consumer Electronics: televisions, DVD players, and video game consoles
• Communication devices: telephones, cell phones, and radios.
• Smart Home appliances: washing machines, refrigerators, and air conditioners.
• IoMT devices: Electronic devices worn on the body, such as smartwatches, fitness trackers, and smart glasses.
• IIoT devices: some of the connected devices are used to control Industrial Automation and Control systems. These devices are devices used in factories and industrial settings to automate and control processes, such as programmable logic controllers (PLCs) and sensors.
• Automotive Electronics: Electronic devices used in vehicles, including navigation systems, engine control units, and collision avoidance systems.

‍

A large percentage of electrical and electronic devices that surround us are connected (IoT) devices. 

When the IoT technology is intended for individuals, rather than organizations, these devices are called consumer IoT products. 

A wide range of devices and systems can collect, store and transfer health-related data. They are called IoMT devices, which can either be used by individuals or organizations. 

IIoT devices refer to a wide range of devices and systems including products and machinery used for industrial or manufacturing environments.

‍

One of the key challenges in the IoT device market is cybersecurity. Because IoT devices are connected to a network, they are vulnerable to cyber attacks that can compromise the confidentiality, integrity, and availability of the device, and the information it processes. This can have serious consequences, especially for devices that handle sensitive information or are critical to the operation of a system.

To address these challenges, it is important for manufacturers and other stakeholders to implement robust cybersecurity measures and follow relevant regulations and standards. This can help to reduce the risk of cyber-attacks and ensure the security of IoT devices.

‍

ETSI EN 303 645 is a technical specification developed by the European Telecommunications Standards Institute (ETSI) that provides guidelines for the security of Internet of Things (IoT) devices. ETSI EN 303 645 is the first globally applicable Cybersecurity Standard for Consumer IoT Devices. 

This standard covers consumer IoT devices that are connected to network infrastructure and their interactions with associated services, like smart tv’s, CCTV cameras, speakers, connected home automation devices, IoT gateways, base stations, HUBs, wearable health trackers, baby monitors, IoMT devices, connected home appliances like smart refrigerators and washing machines, or connected alarm systems, door locks, smoke detectors, among many others. 

ETSI EN 303 645 contains a set of 13 cybersecurity categories and some provisions specifically focused on Data Protection.

In addition to providing guidelines for device security, ETSI EN 303 645 also includes recommendations for the management of security risks, including the identification and assessment of risks, the implementation of controls to mitigate those risks, and the ongoing monitoring of risks.

‍

CCLab provides consultation, testing, and certification services for Consumer IoT devices.

• Training/Consultancy: We offer workshops to guide developers on their journey to ETSI EN 303 645 compliance. We provide insights and document templates for preparing the ICS, IXIT, and additional documentation needed for an evaluation.
• GAP Analysis: We assess the products to determine the differences between the current security implementation and the provisions defined in ETSI EN 303 645.
• Product Evaluation: We evaluate the product based on the applicable provisions of the ETSI EN 303 645 and will issue a conformance evaluation report as well as the identified security gaps.
• Statement of Conformity: CCLab issues a Statement of Conformity when the evaluated product meets the requirements defined in ETSI EN 303 645.

‍

Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, amending Directive 2001/83/EC, Regulation (EC) No 178/2002 and Regulation (EC) No 1223/2009 and repealing Council Directives 90/385/EEC and 93/42/EEC (Text with EEA relevance. )

https://eur-lex.europa.eu/eli/reg/2017/745/oj

Regulation (EU) 2017/746 of the European Parliament and of the Council of 5 April 2017 on in vitro diagnostic medical devices and repealing Directive 98/79/EC and Commission Decision 2010/227/EU (Text with EEA relevance. )

https://eur-lex.europa.eu/eli/reg/2017/746/oj

As medical devices get smarter features providing more efficient and easy-to-use solutions to patients the used technologies can introduce additional risks for patient health and their personal data. These smart features are usually implemented with software, internet connection and other IT technologies. These technologies introduce cybersecurity risks in the medical device and based on the device’s features, functionality and the data it handles it can become a target for cybercriminals. Health data is considered sensitive personal information therefore in case of a cyberattack where the attackers steal patient data or harm patient safety the manufacturer/developer of the device can face serious fines.

EU regulations on medical devices have been adopted and entered into force on 25 May 2017. 

These are:

MDR 745/2017 - MDR Medical Devices Regulation; EU 2017/745

IVDR 746/2017 - IVDR In Vitro Diagnostic Medical Devices Regulation; EU 2017/746

Both regulations (MDR and IVDR) contain cybersecurity requirements. The goal of the policy makers was to create a regulation that ensures an industry standard security level without burdening market entities too much. The result is a risk-based approach where manufacturers/developers identify, analyze, and manage cybersecurity risks relevant to their product and create the necessary procedures and documentation to handle cybersecurity risks.

We offer “zero to hero” and integration services which help manufacturers/developers to achieve cybersecurity MDR compliance.

Our comprehensive services help from product design through development and MDR/IVDR certification. . They provide a clear path to compliance through methodology based on internationally recognized standards.

Integration services build on customers’ already implemented management systems that comply with relevant industry standards. Integration services help customers to utilize their already implemented processes instead of creating new ones.

Compliance to internationally recognized standards eliminates quality discrepancies. A manufacturer/developer might think that a freshly designed and planned cybersecurity activity will be compliant to regulatory requirements but during the certification process the notified body might reject the evidence because of insufficient quality. Standards are created by a group of experts on the relevant field and contain every pertinent aspect of the topic. Compliance to internationally recognized standards ensures that designed and implemented security procedures are secure. It creates a common language between the manufacturer/developer and the notified body.

As each project and product evaluation is different, there is no exact answer to this question. It depends on many factors such as product complexity and assurance claims. The certification time also depends on the selected certification body. Contact us @ info@cclab.com and we will help you put together a project plan and schedule.

Please contact our sales team, and they will help you. You can reach us by email:  info@cclab.com or mobile phone: +36 (20) 212 1664 . 

‍

• 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 Organization 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 fulfillment 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.

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: 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:

https://www.metas.ch/metas/de/home/dl/datensicherheitspruefungen.html

Sec. 2.1 Required documents describe 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 process 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 the 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 contain 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:

The Manufacturer:

• 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 

The Evaluator:

• 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.

DOES THE 5.1.4 (b) REQUIREMENT ONLY MEAN THAT DATA BETWEEN MAIN SYSTEM COMPONENTS (HAUPTKOMPONENTEN) NEED TO BE EXCHANGED IN ENCRYPTED WAY?

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.

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.

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 this 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.

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.

‍

To choose CCLab as Test Laboratory please enter the CCLab specific data to METAS Application form (Antragsformular):

• Name: CCLab Ltd.
• Abteilung: -
• Strasse: Katona Jozsef 17. III.2.
• PLZ Ort: 1137 Budapest
• Land: Hungary
• Internetadresse: https://www.cclab.com
• Kontaktperson (des Prüflabors)
• Name: Mr. Ferenc Molnár
• Funktion: CEO
• Telefon/Mobiltelefon: +36 30 280 6524
• E-Mail: ferenc.molnar@cclab.hu

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.

CCLab proposes a step-by-step approach to its clients during security evaluations, using Flaw Hypothesis Methodology based on our own Common Criteria experience.

The essence of the methodology is to set up the Flaw Hypothesis and then to test the hypothesis by analyzing the documentation in more depth and detail and finally by penetration testing.

Based on the errors found, we perform a “generalization” of the errors, eliminate or correct them and perform a re-check. 

The target security level can be reached on an increasing basis: first solving the most aching problems, then strengthening the security of the IT system gradually.

• Security by design
• Secure coding training
• Vulnerability assessment
• Penetration testing
• Hardening
• Security audit

For mobile applications CCLab proposes to follow the OWASP Mobile Application Security Verification Standard. The evaluation process is based on MASVS-L1 Standard Security level and additionally extended to MASVS-L2 Defense-in-Depth level.

‍

It depends on the product we test, and many factors such as product complexity and assurance claims. Usually a simple penetration task can take a few weeks, a complex vulnerability assessment project can take a few months, whilst a higher evaluation assurance level of Common Criteria evaluation could even take 6-12 months depending on the quality of manufacturer documents and the number of deficiencies found during the evaluation.