Don’t hesitate to contact us if you can’t find an answer
to your problem
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:
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:
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.
(Protection profiles for secure signature creation device – Part 2: “Device with Key Generation”)
(Protection profiles for secure signature creation device – Part 4: “Extension for device with key generation and trusted communication with certificate generation application”)
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.
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:
The IEC 62443 describes 4 levels of security functionality:
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:
- Owns and operates one or more IACS
- Easy to define a target security level
- Offers a frame of reference to evaluate existing security
- Builds IACS for the Asset owner
- Clear understanding of security requirements
- Simple to define a system security capability
- 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.
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:
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
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.
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. )
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. )
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 .
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:
The Evaluator:
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):
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.
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.
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:
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:
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.
(Protection profiles for secure signature creation device – Part 2: “Device with Key Generation”)
(Protection profiles for secure signature creation device – Part 4: “Extension for device with key generation and trusted communication with certificate generation application”)
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.
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:
The IEC 62443 describes 4 levels of security functionality:
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:
- Owns and operates one or more IACS
- Easy to define a target security level
- Offers a frame of reference to evaluate existing security
- Builds IACS for the Asset owner
- Clear understanding of security requirements
- Simple to define a system security capability
- 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.
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:
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. )
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. )
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 .
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:
The Evaluator:
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):
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.
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.