The Device Chronicle interviews Jeppe Bjerre, a cybersecurity compliance specialist at FORCE Technology.
Jeppe helps to unravel what the E.U. Cyber Resilience Act (EU CRA) means for connected device makers and their customers and end users. In his role at FORCE Technology, Jeppe focuses on validating implementations, including the EU CRA, NIS 2, IEC 62443, and ETSI EN303645 approvals for product cybersecurity.
Jeppe’s employer FORCE Technology is a technology consultancy and service company that strives to create positive technological change and make the world more sustainable and safer.
Chapter 1 - Practical compliance with EU CRA for OEMs
Jeppe begins by explaining that we are moving away from the days of allowing passwords or default passwords, such as admin passwords, as allowed credentials. They're becoming forbidden by law in devices. “Overall, the EU CRA will impose a set of requirements that all products that are to be made available on the internal market in the EU must adhere to the CE mark, which we use in Europe to qualify electronics that adhere to the essential requirements imposed upon them by the Commission.” This means that when an OEM is developing its connected devices, it needs to ensure it has done its due diligence about risk management for the device and that it has covered all the aspects relevant to the device, considering the environment in which it is intended to be developed. As such, it needs to consider the proper control mechanisms to be put in place in the product. It also needs to have a series of processes and services implemented in its organization. For example, vulnerability disclosure mechanisms are fundamental. The device maker also needs to have a set action plan if it get reports or discovers vulnerabilities in products in the field.
- How is the OEM going to address these vulnerabilities?
- How is the OEM going to qualify devices for the security updates?
- How is the OEM going to deploy security updates to the devices?
In essence, it means that the OEM needs to manage security both in its devices and also for the life cycle of the devices. It would help if it considered how long it will have to support a device. For that entire duration, they need to maintain the device's security. “So it's no longer just a one off deal with the customer. Until the end of the life of the device or it reaches the end of the support period, the OEM has to maintain the product, and it has to buy into the vulnerability disclosure mechanisms set in place.”
The European Union Agency for Cybersecurity (ENISA) will likely be the one to enforce this. In essence, it means OEMs must manage security in the products they sell and have processes in their organization to manage it.
Chapter 2 - Compliance for a connected product with a Linux gateway
One of the types of devices with more stringent care or requirements in the sense of conformance assessment procedures is operating systems (OS). There are stricter requirements in the sense of how a device maker validates or how they can prove that they comply with the essential requirements for operating systems.
Linux is open source, so the EU CRA implements open source software stewards, which are legal personnel for software foundations such as the Linux Foundation or Apache or some of the larger open source software providers. These stewards will be in charge of maintaining documentation and so forth that OEMs can use them in their compliance work. An OEM must get control over or at least assess the third party software components that are put into the devices.
In the case of Linux, there will likely be a set of conformance or compliance documentation an OEM can adopt and build upon in their technical construction file. This only takes care of the operating system. Then there is the hardware platform and the OEM will need to harden their interfaces and ensure that only the services necessary for essential operation are enabled by default and that there is a secure and privacy-by-default configuration.
Jeppe recalls the example from September 2023 of ASUS routers that had security flaws with some image sharing that was set on by default. He says “Those are the kinds of cases we want to eliminate.”
The OEM also needs to maintain a software bill of materials (SBOM). This is a set of documentation that proves that the OEM adheres to the essential requirements. “When it comes to cyber security, we can't just take the device and put it into our cyber security test chamber, press the button, and read it. Then ask if it is secure or not? That's different from how it works. So, there's a lot of documentation that an OEM needs to put into their technical construction file, and it is all based on a risk analysis and risk management approach. The methodology is essentially the same for all the different aspects you need to consider. There are just a few practicalities that differ in certain areas.”
Chapter 3 - Software update ability & vulnerability management in EU CRA
The EU CRA has just been passed in the European Parliament. The timeline still needs to be set in stone, and because it has just been voted through parliament, it has not been cited in the Official Journal of the EU. The official journal is for laws that are in place. Jeppe expects the EU CRA to become cited in the Journal around summer or early Autumn 2024. Once cited, two critical dates will be added to the calendar. The first will come up 21 months after implementation, where the obligations for vulnerability reporting will be enforced. One of the requirements is that if a device maker discovers a vulnerability that has been or is being actively exploited, they are obliged to report it to ENISA no later than 24 hours after discovery. They also need to do some other things, but the reporting obligations will enter into force 21 months after the citation, or it's 21 months plus 21 days. This is the rough timeline. After that, it's 36 months until the EU CRA is in force. “Three years is roughly the timeline as we approach the final text of the EU CRA. That will be interesting because, on top of those dates, a set of harmonized standards that OEMs can use for conformance assessments also need to be developed by the community.”
Chapter 4 - Implementation timelines for EU CRA
It is not defined how an OEM needs to address the EU CRA, but that the OEM needs to address it appropriately in their risk analysis for a device. As a rule of thumb, software needs to be updated or devices need to be able to have their software updated. There are use cases where software updates mean hardware replacement because that can be the most suitable solution. But overall, an OEM needs to be able to address security flaws, either update lockout devices and have systems in place to address that. Most devices, at least intranet-connected devices, will have some form of automatic update. Automatic updates are encouraged, but the European Commission also recognizes that there are use cases where automatic updates can be problematic, like, usually, an industrial installation for critical systems that suddenly reboot because then they needed to implement a security update. That’s something other than what we want to happen. OEMs want complete control, but there are requirements for communicating the availability of security updates. Bear in mind this does not concern feature updates, it is about security patches and exploitable vulnerability management. Feature updates are more of the functionality of the product. Jeppe believes they should also strongly be considered when addressing significant changes to devices because that can mean that from a compliance perspective, the device is supposed to be a new design, and you need to do a new conformance assessment for the device. Usually, this is not the case when an OEM changes small PCB board components, but with software, small changes can have a significant impact. So, there can be issues where a security patch can mean the OEM needs to revisit some compliance works, but software updates, especially for internet-connected devices, are encouraged.
Chapter 5 - EU CRA mapping to NIS 2, EU RED, NERC-CIP, NIST, ISA IEC 62443, and ISO 27001
Jeppe explains that NIS 2 and EU CRA complement each other very well because they come from the same place and are designed to cover the broad picture. The NIS 2 covers critical infrastructure but it has not been broadened in scope so the critical infrastructure is more than just utilities, websites and other infrastructure could be included.
The EU CRA also covers standalone software so apps on smartphones and such are also in scope. Essentially the EU CRA will cover almost every electronic product available for sale within the EU.
NIS 2 will cover the organizations that are important to maintain the operation of the nations within the EU. NIS2 is similar to NERC-CIP in the United States for protection of critical infrastructure. The NIST 2 and NERC-CIP try to cover critical infrastructure with the different toolings that they have available but they cover the same aspects. The interdependencies are complex though: ISO 27001.2 series can be a large part of compliance. To say NIST 2 compliance with ISO 27001 does not necessarily mean compliance with essential requirements in NIST 2. One of the things that ISA IEC 62443 can be used for under NIST 2 is the OEM supplier management. Essential and important entities need to impose security requirements for their suppliers and manufacturers applying for example to PLCs to an industrial solution if the OEM suppliers have ISA IEC 62443-certified products that can be one way to address some parts of the supplier or manufacturer requirements. This is actually a citation from some of the ENISA guidance on how an asset owner can handle suppliers under NIST 2.
Jeppe is involved in the standardization work for CRA and is looking at adopting ISO and IEC processes and standards for products. He advocates for the IEC 62443 as one of the most dominant security standards for industrial systems and is a good one to copy one to one for the EU CRA. The IEC 62443 has the advantage of being recognized worldwide. It is a case of using what has already been proven instead of inventing a new one in the European Union. A lot of the same tools are used in both the EU and the US to verify conformance and a lot of the same requirements are set so complementing each other, so there would be no sense in the two markets splitting in two different directions.
In conclusion
Jeppe believes that one of the most interesting aspects about the essential requirements for the EU CRA is that consumer IOT and industrial devices are treated the same fundamentally. “The functional requirements an OEM needs to have is a set of technical requirements that have to be in place and a set of processes that have to be in place, whether making a connected coffee machine for the home, or a control system for a nuclear power plant the risk analysis is the common denominator in EU CRA. That risk analysis will differ wildly for those two products. The EU CRA has a type of conformance assessment procedure that an OEM can use to verify and validate their solution. For 95% of the products in scope for the CRA, a self-assessment is more than sufficient. Then there are certain types of products and categories of products in military applications or high security applications defined in the CRA which the European Commission is allowed to alter requirements for change with the legal tools available to them. These applications could include operating systems, smart cards and crypto engines for ultra secure communication lines. These are use case scenarios where a high assurance is mandated that this device functions as intended and and has no faults that the OEM knows of.
Get in touch with Jeppe on LinkedIn or email him on: jpbj@forcetechnology.com.