Earlier this month, harmonized standards belonging to European Union Cybersecurity Resilience Act were published in form of final drafts. These harmonized standards serve as a guidance for manufacturers of Class I Important products, such as firewalls, bootloaders and operating systems on what measures to implement in what use cases in order to meet CRA essential requirements. Demonstrated compliance with harmonized standards may serve as self-assessment path of Important products, while non-compliance (or non-existence of harmonized standard for certain kind of important product type) requires external certification.
Standard of interest here is EN 304-626 (note: linked document is still a draft and ETSI has a habit of unpublishing drafts once they are outdated, so this link may become invalid) - Cybersecurity requirements for operating systems. In published draft version 1.0.1, it recognizes two major use-cases:
Vast majority of embedded systems will fall into category of restricted computing systems. This category has somewhat less strict requirements as the norm expects that restricted nature of system will close some potential attack vectors which do exist on general purpose systems, such as inability to install malicious or buggy application without the knowledge of system manufacturer and limited ways of interacting with the system.
This basic distinction is then extended by the assessment environment conditions the operating system is supposed to work in. These conditions further detail on expected use-cases of operating system such as support for networking, which increases risk of remote attacks or ability to modify, upgrade or install security-relevant components, etc. If an operating system is expected to support or be affected by given condition, then related risks are elevated.
Standard defines technical requirements - mitigation measures which increase cybersecurity resilience of operating systems. The list is quite long and by no means all operating systems need to implement all the mitigations. The mapping between use-cases and required technical requirements is established in security profiles section. There a list of requirements that have to be implemented is given for each of two use-cases. Then a list of requirements which apply on top of baseline requirements is given for each condition that applies.
As an example a baseline security profile for restricted embedded system does not require authentification nor authorization to be implemented, which makes sense because for many embedded systems a concept of user is not applicable. Once an embedded system gets connected to computer network, condition for “public network access” holds and technical requirement for implementing authorization must be implemented.
This way a list of technical requirements that a system must implement in order to be eligible for self-assessment of Class I Important product can be established based on range of use cases an operating system supports.
If we analyze baseline security profile for restricted system and security profiles for various conditions, the outcome is that an embedded system that fulfills condition for restriced system does not need to implement memory protection.
There’s a caveat here: At the bottom of chapter which lists requirements for conditioned mitigations, there is a note, which reads:
The mitigations ADEF, ISO-1, ISO-2, and ISO-7 listed in the SP-GEN baseline (clause 5.3.3) are also required for an SP-REST product when any high-exposure condition holds, namely any of C-NET, C-LOSS, C-MULTI, C-UNTR, C-FUNC, or C-PHYS. They are part of the SP-GEN baseline and so need not be repeated under those conditions for an SP-GEN product.
By this short note additional requirements are added to the mix when several specific conditions hold: public network access, risk of loss, multiple user accounts or concurrent users, sensitive functions or exposure to untrusted users. If any of these conditions are met, then even a restricted system has to implement following mitigations:
These are normally required for general-purpose systems but exposure to conditions which grealy increase risk of unauthorized access to system make them mandatory even for restricted systems.
The takeaway from this is that an operating system that is used in any of above-listed conditions must use memory protection, stack overflow protection and stack isolation, even if it is an real-time operating system for embedded systems.
For you as a user of such system, the case is two-fold:
Manufacturer should only provide CE marking if their operating system is either compliant with EN 304-626, or the system was externally certified by a notified body. The latter is rather problematic as of time of writing this article as there are no notified bodies providing certification for operating systems.
This is not just a matter for legal or compliance department. We see this version of EN 304-626 as a rather reasonable culmination of months-long effort and see requirements for hardware-based memory safety a change in the right direction. If a computing system is connected to public network then it is inevitable that potential attackers can write your RAM. Any network request that arrives is written in your device RAM. You can’t avoid it. Any single bug that allows the attacker to execute these data opens way for total compromise of your device.
Many real-time operating systems on the market provide both support for memory protection and stack overflow protection. In many of these operating systems both protections have to be explicitly enabled and at least in case of memory protection, it has to be configured manually. CMRX RTOS enables both protections by default and requires no manual configuration of memory protection.
CMRX is ready to meet EN 304-626 requirements today!