Frequently Asked
Questions

Don’t hesitate to contact us if you can’t find an answer
to your problem

get in touch

Common Criteria

What is Common Criteria?

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.

Who recognizes CC certificates?

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.

What is the CC evaluation process?

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

What gets evaluated?

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.

What is a Security Target?

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/

What is a Protection Profile?

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/

What is a Collaborative Protection Profile (cPP)?

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

What is an Evaluation Assurance Level?

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.

How long does evaluation take?

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.


What happens when a certified product changes?

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.


What is Assurance Continuity?

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

Why buy Common Criteria certified products?

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

Which protection profiles do CCLAB work with?

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

What is a common criteria certification good for?

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.

Who needs common criteria evaluation?

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.

Which Common Criteria scheme does CCLAB work with?

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.


Most common protection profiles

  • 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

Automotive solutions

What is ISO/SAE 21434 and why is it important?

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.

How can CCLab support Automotive Manufacturers?

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.

What complex solutions does CCLab offer for the Automotive Industry?

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

If I choose CCLab, what benefits can i get?

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

Industrial Control System Security

What standard applies to industrial control system security?

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.

What’s a Rich Text element?

The rich text element allows you to create and format headings, paragraphs, blockquotes, images, and video all in one place instead of having to add and format them individually. Just double-click and easily create content.

Static and dynamic content editing

A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!

How to customize formatting for each rich text

Headings, paragraphs, blockquotes, figures, images, and figure captions can all be styled after a class is added to the rich text element using the "When inside of" nested selector system.

What do ISA/IEC 62443 series of standard include?

What’s a Rich Text element?

The rich text element allows you to create and format headings, paragraphs, blockquotes, images, and video all in one place instead of having to add and format them individually. Just double-click and easily create content.

Static and dynamic content editing

A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!

How to customize formatting for each rich text

Headings, paragraphs, blockquotes, figures, images, and figure captions can all be styled after a class is added to the rich text element using the "When inside of" nested selector system.

What services does CCLab provide in the field of Industrial Control System Security?

  • 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

What’s a Rich Text element?

The rich text element allows you to create and format headings, paragraphs, blockquotes, images, and video all in one place instead of having to add and format them individually. Just double-click and easily create content.

Static and dynamic content editing

A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!

How to customize formatting for each rich text

Headings, paragraphs, blockquotes, figures, images, and figure captions can all be styled after a class is added to the rich text element using the "When inside of" nested selector system.

How many levels of security functionality are described in ISA/IEC 62443?

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 

What’s a Rich Text element?

The rich text element allows you to create and format headings, paragraphs, blockquotes, images, and video all in one place instead of having to add and format them individually. Just double-click and easily create content.

Static and dynamic content editing

A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!

How to customize formatting for each rich text

Headings, paragraphs, blockquotes, figures, images, and figure captions can all be styled after a class is added to the rich text element using the "When inside of" nested selector system.

What organizational roles are responsible for responding to ISA/IEC 62443 requirements?

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 

What’s a Rich Text element?

The rich text element allows you to create and format headings, paragraphs, blockquotes, images, and video all in one place instead of having to add and format them individually. Just double-click and easily create content.

Static and dynamic content editing

A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!

How to customize formatting for each rich text

Headings, paragraphs, blockquotes, figures, images, and figure captions can all be styled after a class is added to the rich text element using the "When inside of" nested selector system.

How many chapters does ISA/IEC 62443 have and what are these?

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.

What’s a Rich Text element?

The rich text element allows you to create and format headings, paragraphs, blockquotes, images, and video all in one place instead of having to add and format them individually. Just double-click and easily create content.

Static and dynamic content editing

A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!

How to customize formatting for each rich text

Headings, paragraphs, blockquotes, figures, images, and figure captions can all be styled after a class is added to the rich text element using the "When inside of" nested selector system.

Which chapters of ISA/IEC 62443 does CCLab have the competence for?

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

What’s a Rich Text element?

The rich text element allows you to create and format headings, paragraphs, blockquotes, images, and video all in one place instead of having to add and format them individually. Just double-click and easily create content.

Static and dynamic content editing

A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!

How to customize formatting for each rich text

Headings, paragraphs, blockquotes, figures, images, and figure captions can all be styled after a class is added to the rich text element using the "When inside of" nested selector system.

Medical Devices

MDR Medical Devices Regulation

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

IVR In Vitro Diagnostic Medical Devices Regulation

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

Why do medical devices need cybersecurity?

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.

What are the current cybersecurity regulations on medical devices in the EU?

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

How can manufacturers ensure medical device. security compliance?

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.

How can CCLab support medical device manufacturer companies in compliance to the latest regulations?

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.

What is the purpose of the usage of standards?

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.

How long does a medical device evaluation period take?

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.

How do i request a cybersecurity evaluation offer for my medical?

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 . 

Smart Metering Recommendations for Manufacturers

Recommendations to fulfil the OT Matrix - (Protected Object-Threats)

  • 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

Recommendations to fulfil the checklist: (How, where)

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

Recommendations to delivery of the toe

  • 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

Recommendations for manufacturer documentation

  • 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

Documentation issues which delay evaluation

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

Evaluation flow issues which delay evaluation

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

Swiss Smart Metering

What documentation helps Manufactures to get prepared for the test process?

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

What documentation helps Manufactures to get prepared for the test process?

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

What documentation helps Manufactures to get prepared for the test process?

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

Which documentation should I submit?

Sec. 2.1 Required documents describe which documents should you submit at the beginning of the test process.

What shall I know about the checklist as the Manufacturer?

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


What about the IT security concept documentation (item 5.1 in the testing methodology)? Is this a part of RL-DSP Annex 2 (RL-DSP-CH_A2_1045)?

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 in Die Prüfmethodologie (Evaluation methodology) and in Annex 1 (RL-DSP-CH_A1_1045) are different. How will annex 1 be considered in the test process, if it is considered at all?

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.

How will a requirement be evaluated?

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.

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.

What is the definition of ‘Vulnerable data’? Is it a secure material (e.g. keys)?

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.

Requirement 5.5.1.5 (a): Safe deletion… is a general requirement for all components. How will it be tested?

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.

How can I choose CCLab for our Test Lab?

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

Do I have to send to CCLab the HES test system too?

There is a possibility to set up the HES in our laboratory. We can also test the HES with remote access.

What is the lifecycle of the test samples?

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.

What are my options if I have the same device but with several different configurations. E.g. different size of memory, storage, communication modules, enclosure?

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.

Cybersecurity Evaluation (HW AND SW)

What CCLab can recommend if you need a hardware of software evaluation?

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

What is the advantage of an evaluation based on flaw hypothesis methodology?

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.

What security evaluation services can CCLab offer?

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

Are there evaluations for mobile applications?

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.

How long does a Hw or Sw evaluation takes at CCLab?

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.

Common Criteria

What is Common Criteria?

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.

Who recognizes CC certificates?

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.

What is the CC evaluation process?

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

What gets evaluated?

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.

What is a Security Target?

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/

What is a Protection Profile?

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/

What is a Collaborative Protection Profile (cPP)?

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

What is an Evaluation Assurance Level?

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.

How long does evaluation take?

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.


What happens when a certified product changes?

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.


What is Assurance Continuity?

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

Why buy Common Criteria certified products?

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

Which protection profiles do CCLAB work with?

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

What is a common criteria certification good for?

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.

Who needs common criteria evaluation?

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.

Which Common Criteria scheme does CCLAB work with?

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.


Most common protection profiles

  • 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

Automotive solutions

What is ISO/SAE 21434 and why is it important?

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.

How can CCLab support Automotive Manufacturers?

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.

What complex solutions does CCLab offer for the Automotive Industry?

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

If I choose CCLab, what benefits can i get?

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

Industrial Control System Security

What standard applies to industrial control system security?

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.

What do ISA/IEC 62443 series of standard include?

What services does CCLab provide in the field of Industrial Control System Security?

  • 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

How many levels of security functionality are described in ISA/IEC 62443?

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 

What organizational roles are responsible for responding to ISA/IEC 62443 requirements?

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 

How many chapters does ISA/IEC 62443 have and what are these?

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.

Which chapters of ISA/IEC 62443 does CCLab have the competence for?

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

Medical Devices

MDR Medical Devices Regulation

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

IVR In Vitro Diagnostic Medical Devices Regulation

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

Why do medical devices need cybersecurity?

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.

What are the current cybersecurity regulations on medical devices in the EU?

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

How can manufacturers ensure medical device. security compliance?

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.

How can CCLab support medical device manufacturer companies in compliance to the latest regulations?

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.

What is the purpose of the usage of standards?

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.

How long does a medical device evaluation period take?

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.

How do i request a cybersecurity evaluation offer for my medical?

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 . 

Smart Metering Recommendations for Manufacturers

Recommendations to fulfil the OT Matrix - (Protected Object-Threats)

  • 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

Recommendations to fulfil the checklist: (How, where)

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

Recommendations to delivery of the toe

  • 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

Recommendations for manufacturer documentation

  • 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

Documentation issues which delay evaluation

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

Evaluation flow issues which delay evaluation

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

Swiss Smart Metering

What documentation helps Manufactures to get prepared for the test process?

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

What documentation helps Manufactures to get prepared for the test process?

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

What documentation helps Manufactures to get prepared for the test process?

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

Which documentation should I submit?

Sec. 2.1 Required documents describe which documents should you submit at the beginning of the test process.

What shall I know about the checklist as the Manufacturer?

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


What about the IT security concept documentation (item 5.1 in the testing methodology)? Is this a part of RL-DSP Annex 2 (RL-DSP-CH_A2_1045)?

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 in Die Prüfmethodologie (Evaluation methodology) and in Annex 1 (RL-DSP-CH_A1_1045) are different. How will annex 1 be considered in the test process, if it is considered at all?

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.

How will a requirement be evaluated?

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.

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.

What is the definition of ‘Vulnerable data’? Is it a secure material (e.g. keys)?

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.

Requirement 5.5.1.5 (a): Safe deletion… is a general requirement for all components. How will it be tested?

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.

How can I choose CCLab for our Test Lab?

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

Do I have to send to CCLab the HES test system too?

There is a possibility to set up the HES in our laboratory. We can also test the HES with remote access.

What is the lifecycle of the test samples?

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.

What are my options if I have the same device but with several different configurations. E.g. different size of memory, storage, communication modules, enclosure?

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.

Cybersecurity Evaluation (HW AND SW)

What CCLab can recommend if you need a hardware of software evaluation?

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

What is the advantage of an evaluation based on flaw hypothesis methodology?

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.

What security evaluation services can CCLab offer?

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

Are there evaluations for mobile applications?

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.

How long does a Hw or Sw evaluation takes at CCLab?

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.