The implementation of the European Union’s (EU) Cyber Resilience Act (CRA) will require every manufacturer of connected embedded devices selling into the European market to follow cybersecurity best practices. One basic element of cybersecurity protection is the timely updating of the Linux® operating system and application code.
It is not only such regulations that are driving embedded device OEMs to adopt a more active security posture: the reputational and financial risks to manufacturers have mounted as cyber-criminals and state-backed cyber attackers have created a more threatening environment for connected devices. According to the European Commission, ransomware attacks are estimated to have cost the world around €20bn in 2021, with an attack occurring somewhere every 11 seconds.
The CRA will look to impose responsibility for securing a device on its manufacturer, not on retailers, network operators, or users. Many measures are required to achieve compliance, but among the most important is the provision of security updates, and the availability of patches to fix known vulnerabilities and exposures.
It is far easier to fix vulnerabilities if the device runs current rather than outdated Linux code. Old base code is also harder to maintain, because over time the code diverges further and further from the latest version that most devices are using, so approaches to fixing vulnerabilities that the open-source community develops for up-to-date code become less and less applicable.
Providing updates to a device’s Linux OS, and a means to deliver them to devices in the field, are now crucial features of new embedded devices.
This throws the spotlight on the developer’s choice of Linux operating system platform. Updating is better supported by some than by others. Here are Foundries.io’s key take-aways for developers who want to prepare their connected embedded device for efficient and timely Linux OS updates:
1. Select a Linux OS which is built for security update development
Part of the amazing value of the Linux platform is the ability it gives to customize the OS, typically using the framework of the Yocto Project for OS development.
A binary Linux distribution, in contrast, takes away the freedom of the OEM to customize the OS for their application. Even when the initial instance of a binary distribution is appropriate for an embedded product, there is a risk that the vendor’s updates over time make the distribution less and less compatible with the product’s use case and application requirements. This poses a dilemma for the device manufacturer: whether to implement updates which strengthen security, or retain outdated code that maintains higher performance or retains desired features. Binary distributions can also complicate OEMs’ license management, for instance by removing their freedom to exclude any software component that has a GPL v3 license.
Open Linux distributions maintain the manufacturer’s freedom to customize. Yet some militate against an OEM’s ability to maintain their product with timely updates. For instance, the Linux distributions supplied by SoC vendors with their BSPs tend to be maintained on a rigid schedule which does not reflect the OEM’s need, such as for urgent provisioning of fixes in response to emergent threats. Instead, BSP distributions typically bundle a set of updates into regular major releases. This slows the OEMs ability to respond to vulnerabilities and exposures, and to introduce valuable new features.
Use of an SoC vendor’s Linux distribution also risks locking the OEM into that vendor’s products.
Poky OS is another open Linux distribution: it is optimized for the development and testing of the OpenEmbedded build framework, but is not intended for use in a production environment. This forces manufacturers to make substantial modifications to their operating software environment before the distribution can be considered production-ready. And thereafter, it will be the manufacturer’s responsibility to maintain and update this Linux distribution, and to keep it secure.
By contrast, support for update delivery to production units is at the heart of the Linux microPlatform (LmP) distribution licensed by Foundries.io. The LmP is minimal, security-rich, updatable, and customizable. It facilitates Yocto Project update development by providing a base Linux OS and decoupling the vendor’s code. It also offers out-of-the-box integration with the FoundriesFactory™ DevSecOps platform. And the LmP Linux distribution is maintained by Foundries.io, so OEMs are relieved of the task of Linux maintenance.
Unlike SoC vendors’ distributions, LmP is a cross-architecture distribution, readily enabling migration from one SoC vendors’ products to another’s. This is a particularly useful benefit when an OEM wants to spin out different versions of an original product based on alternative hardware platforms, enabling it to keep the same Linux distribution. It also means that the OEM’s development effort sunk into systems based on LmP can support more than one product.
2. Make sure you can deploy your updates to devices in the field
Developing update code on a Linux distribution which the OEM controls is only half of the job of ensuring that a device runs current code: code updates also need to be deployed to production units in the field.
This calls for a robust update client. In Foundries.io’s case, we license LmP with aktualizr-lite, supported by The Update Framework (TUF) to provide for security-focused delivery of over-the-air (OTA) updates. TUF provides for multi-level key management, and multiple roles with separate responsibilities. The restricted responsibility of each role in the update process strengthens the protection of devices against attempts to exploit the update process, minimizing the impact on the entire system of a single compromised key.
LmP also implements rollback support to enable a return to a previous stable version in the event of a faulty update deployment. One of the many advantages of basing the development flow on the FoundriesFactory platform is that it supports multiple workflows/development environments, so updates can be tested before deployment to the field. This helps OEMs to manage the risk of problems occurring in devices after the roll-out of updated software.
3. Deploy technology that enables you to decouple OS updates from application code updates
Changes implemented in the Linux OS by an update can unexpectedly cause application code to fail or misbehave. In this event, the ability to isolate the element that caused the code impairment is crucial. If OS and application code are tied together, it becomes more difficult to find the cause of the problem.
For this reason, it is good practice to detach application code from the Linux OS. This is readily achievable through the use of containers for application code.
In the FoundriesFactory platform, containerization is supported through the Docker software tool. Since the platform also provides native support of CI/CD processes, it becomes natural to detach application code update development from Linux OS updates, allowing their separate update processes to follow separate schedules.
Adopting these three principles makes the development and deployment of update code easier. For users of the FoundriesFactory platform, all three principles are baked into their LmP OS and their development flow.
If you would like to discuss how the FoundriesFactory platform can help you with your embedded projects, contact us today.