The EUCC scheme looks into the certification of ICT product's cybersecurity, based on the Common Criteria (CC), the Common Methodology for Information Technology Security Evaluation, and corresponding standards. The Common Criteria has proven exceptionally efficient for the certification of chips and smart cards in particular. It has contributed to enhancing the security of several types of sensitives applications such as electronic signature devices for identification, passports, banking cards, and tachographs for trucks. CC has been also actively used for the certification of the cybersecurity of ICT software products.
Certificates issued through the EUCC scheme aim to improve the European Union Internal Market conditions for ICT products and to have overall positive effects for ICT services and ICT processes relying on such products.
Certificates are delivered to specific version(s) of an ICT product which has undergone a CC evaluation by an evaluation facility (ITSEF).
But what happens to a certificate once a vulnerability is disclosed affecting the ICT product in question and how shall we handle such vulnerability ?
According to the EUCC scheme, manufacturers and providers of ICT products will have to use the general steps of ISO/IEC 30111 for vulnerability handling (preparation, receipt, verification, remediation development, release, post-release) with the following specific application rules:
First of all, manufacturers and providers are required to develop methods for receiving vulnerability information and make them public. This requirement will have a considerable impact on the way vendors are used to communicate around their security claims. A great example of a service that could be used to support such requirement is presented by VulnerableThings - a coordinated vulnerability disclosure management and reporting service for IoT security researchers, consumers and manufacturers.
If the manufacturer or provider receives vulnerability information, they are required to report immediately to the Certification Body (CB) that issued the certificate and provide a date for when a vulnerability analysis will be established. If the CB acquires the information about the vulnerability first, they will immediately inform the manufacturer or provider and request a vulnerability analysis, along with a date for this analysis.
If, for instance, the manufacturer or provider fails to inform the CB about the vulnerability or provide the vulnerability analysis, the certificate will be suspended.
Otherwise, the vulnerability analysis will be documented, and the documentation will have to be kept for a minimum of five years. It will contain Attack Potential Calculation, an indication whether the vulnerability is disproved or confirmed, the impact assessment on the ICT product and possible resolution(s) of the vulnerability (with risks of the possible attack and the level of changes which will need to be applied), and lastly, a conclusion of whether the vulnerability can be circumvented. In that case, the certificate will be revoked.
The certified ICT product may or may not include a patch management mechanism. In either case, the manufacturer or provider must decide on remediation and produce the necessary changes to the ICT product.
Once the remediation and associated changes to the ICT product are declared apt for deployment, the manufacturer or provider will proceed to their implementation or release following the requirements of Article 55.1.