Embedded World 2024 Closing – Thoughts about Cyber Resilience in a Connected World

I’ve been thinking about this for three days at Embedded World. Numerous debates and conversations with my peers and the other cyber experts present at the show inspired me to share a few thoughts with you. Just the time to write a few lines before traveling for a series of workshops across Europe with NXP, Avnet, Witekio, and Keyfactor among others.

Cybersecurity is not a new topic. Dealing with some level of formalism in cybersecurity neither: Common Criteria certifications, for instance, have been around for more than 20 years, and are internationally recognized thanks to various mutual agreements such as the CCRA (and in Europe the SOG-IS) that allow a country to recognize the certificates produced by another country.

These evaluation and certification processes ensure that some level of robustness against state-of-the-art attacks is reached, and are essential to provide trust in sensitive devices we use every day to secure our payments, identities, and communications.

The catch is that these cybersecurity evaluations are really focused on security products, such as smartcards, TPMs, HSMs, … but not your everyday connected device.

The same goes of course for industries, governments and critical infrastructures. Thus the need for cybersecurity for seemingly innocuous products is there. And several years of certification are definitely not in order.

Another key difference is that security devices like smartcards are not designed to be updated: a Common Criteria certification targets a device in a specific configuration with specific software.

Change a line of code: there goes your certificate. Not only do you have to certify your product, but also each update, from the ground up. This makes sense for a critical device that is not exposed to the public networks, but is completely unrealistic and counter-productive in more dynamic setups where products are connected and open-source software represents more than 90% of the products code, and where the whole security community is working to identify vulnerabilities in these components: the updates need to be fast and efficient.

This does not mean that cybersecurity certification schemes for less critical devices should not be considered: the European Cyber Security Act mandated the ENISA to produce European Certification Schemes to provide an uniform way of assessing the cybersecurity of the products across all member states, as a more flexible and efficient alternative to the Common Criteria and SOG-IS agreement, and foundational components such as the hardware and operating systems should definitely be certified under such a scheme.

Then we need a lighter approach for leveraging the security guarantees brought by such certifications in finished products built upon these hardware and software components.

Cybersecurity risk assessment: the manufacturer must formalize its security problem, and bring a suitable security solution. In concrete terms, it means that they must have identified the attack surface of the product (all possible ways to interact with it and available to an attacker), the threats that target the product (what are the feared events and what would their impacts be), the attack paths (how an attacker could use the attack surface to realize some threat), and for each relevant attack path (in that it is considered realistic in a given attack model) an assessment regarding how to counter it (using dedicated security mechanisms or policies) or why it is not dealt with (e.g. because a full attack requires another ingredient that is already mitigated).

There are several formalisms that help doing this kind of assessment (e.g. the french EBIOS, or the STRIDE method), but the key element here is someone with an external point of view, that will be able to thinks as an attacker and uncover unexpected behaviours that were not identified by the development team.

Vulnerability management: the manufacturer must be aware of any vulnerability that may target its product all along its lifetime, and take action if these vulnerabilities introduce new attack paths that were not identified during the initial cybersecurity risk assessment.

To achieve this, they need to know upside down the software components that are included in their products. In the smartcard world, where every line of code is carefully crafted by the developer this is granted, but the price to pay is the one of obscurity: the security community will never audit your code, and you will need to leverage other means (sound static analysis tools, thorough code reviews, security tests) to gains confidence in your code.

For most products though open-source and off-the-shelf software components are the main building blocks of the products. This comes with “free” security oversight provided that you are using broadly used packages, but the flip side of this coin is that you’re not the only one that can do this. Thus you must deal with these components’ vulnerabilites before an attacker does.

Authentication: the software updates must only be delivered by trusted channels, and only to properly identified products. This authentication process comes with several implications in terms of cryptography and key provisioning, which need to be identified and dealt with by the risk assessment.

At the end of the day the Cyber Resilience Act takes a pragmatic, if somewhat more radical, approach towards reaching its end goal which is uniformly raising the cybersecurity level in Europe.

The mandatory aspect (and associated penalties) will succeed in creating the necessary incentives for product vendors to take control over the security of their products, demonstrate it to their customers, and publicly share information regarding vulnerabilities.

There is hope that this virtuous circle will also result in more refined and actionable requirements, both from the development and the certification standpoint.