Lukas Beierlieb · 4 min read
Isolating Open-Source Software with Virtualization to Comply with the CRA
Are you trying to wrap your head around the Cyber Resilience Act (CRA)? The CRA forces vendors to ensure their digital products have a high level of cybersecurity throughout their life cycle, including open source components. Read on to learn more about the details and how Cyberus can help to reduce your security maintenance burden.
The Cyber Resilience Act (CRA) is an EU regulation with the goal of improving cybersecurity. The regulation targets all products with digital elements. It entered force in January 2024, and vendors have to ensure their products comply from January 2027. Open-source software (OSS) is excluded from the CRA. However, when a vendor decides to incorporate OSS in its commercial product, the vendor has to take over the responsibility of ensuring security.
In this blog post, we provide an example scenario, with which we explain why a vendor wishes to use OSS components, why the CRA requires significant work to realize this wish, and how Cyberus and the Cyberus Hypervisor can help.
The Example Product: Smart Heating System
Let’s consider an embedded device that controls the heating of a house. In controls and monitors the central heating unit—a critical task because incorrect control can destroy the expensive heating unit. Further, the device can monitor and adjust the temperature of radiators throughout the house. The device runs a web server, which provides information about the status of the central heating unit and about the room temperatures, as well as access to room temperature controls.
The web server implementation builds upon popular OSS: the web framework express.js node.js running on top of the JavaScript runtime node.js, supported by additional open-source NPM packages. express.js is marketed as a minimal web framework, yet requires another 65 open-source packages. So, a significant number of OSS packages have to run on the embedded device to offer a monitoring and control interface to the house owner.
The Problem: Open-Source Software in a Critical Environment
If the web server runs directly on the embedded device, the security implications of vulnerabilities and supply chain attacks can be disastrous. If the web server is responsible for validating user inputs and can arbitrarily modify the central heating configuration, an attacker that takes control of the web server has no other obstacles to overcome to destroy the heating unit!
What do the CRA regulations require in such a scenario? The vendor is responsible to ensure a high level of cybersecurity in their product. This responsibility includes tasks such as monitoring software components for vulnerabilities and providing fixes for such issues in a timely manner. If the vendor develops its own heating configuration application, the responsibility stays at the vendor. If the vendor buys a commercially supported web framework, the framework vendor already bears the responsibility for that component. Open-source software is exempt from the CRA—until a company offers commercial support or includes the software in its commercial product; then, that company has to ensure CRA compliance. In our example, the vendor of the heating control device is responsible for the cybersecurity of node.js and a number of NPM packages.
The device vendor can avoid the complex and expensive task of ensuring security of the web server, if they can argue that the component is not security-critical. As a first security mitigation, the vendor can split the heating control. The web server with all its dependencies still controls the heating, but a small security component validates any commands, preventing unsafe central heating configurations. Now, attackers with control of the web server cannot wreak havoc directly; however, the available attack surface for privilege escalation attacks is vast.
A Solution: Risk Mitigation with Virtualization
Hypervisors are great tools to sandbox components. Software running in a virtual machine (VM) can interact only with the interfaces of the hypervisor, such as virtual-device emulation code. The hypervisor vendor is responsible for CRA compliance of the hypervisor components. Because of the critical role in isolating potentially dangerous software, the CRA categorizes hypervisors as especially important products.
However, further risk consideration is necessary when the hypervisor connects the VM to the outside, e.g., by providing a virtual network device. Without network connection, the web server of the heating control will be super secure as well as completely useless. With network connection, the vendor could utilize a firewall on the host system to restrict the VM’s connectivity, such that the VM can only respond to web server requests.
Build Your Systems Securely With Cyberus
Do you utilize open-source components in your products? Do you struggle with CRA compliance of your software? We offer the Cyberus Hypervisor and CtrlOS, which is a CRA-compliant operating system for embedded systems, offering auditable firewall configuration and many more hardening features helping your device’s security. Schedule a session with us or send us a message to get started on the solution you need!