In our first article, we covered the objectives of the Cyber Resilience Act, identified which organisations will be affected and the expected timeline for compliance. In case you have not had the chance you can read the article Approaching the EU Cyber Resilience Act
In this follow-up article, we dig deeper into the actual requirements of the act, focusing on the essential cybersecurity requirements. The act aims to enforce core security tenets such as confidentiality, integrity, and availability, combined with secure by design and secure by default principles. However, the requirements are not straightforward in terms of implementation and might require certain trade-offs by manufacturers.
While the regulation does account for occasional exceptions, this article primarily addresses the most common scenarios. It is not intended to be an exhaustive or universally applicable guide, but rather a general overview of the act’s technical cybersecurity requirements.
Essential Cybersecurity Requirements of the Cyber Resilience Act
The regulation starts off with the overall expectation that “products shall be designed, developed, and produced in a way that ensures an appropriate level of cybersecurity based on the risks”.
This naturally implies that the risks are comprehensively understood and effectively mitigated throughout the product’s lifecycle. From this end-to-end perspective, we can identify the need to conduct thorough threat assessments and risk analyses during the design phase. We can then identify and implement suitable technical controls to mitigate identified risks and ensure that the level of security can be sustained over time while the product is in operation at a customer’s location.
This overall requirement is made more concrete, and the act states that products must:
“Be made available on the market without known exploitable vulnerabilities”
Having no known exploitable vulnerabilities, while seeming straightforward, warrants a nuanced interpretation.
By definition, a vulnerability is a weakness that can be exploited under certain conditions. However, not all vulnerabilities can be, or are, exploited in practice. If we interpret the act literally, we could claim that every vulnerability, regardless of its exploitability, the availability of a patch, or even whether the vulnerable code path is reached in the product, must be addressed.
Engineering teams operate within constraints, there is never an unlimited amount of time or resources. As a result, vulnerabilities are usually prioritized for remediation based on factors such as the severity, likelihood or known exploitation of the issue. Furthermore, fixes for some vulnerabilities might only be available in newer versions of a dependency, which could lead to breaking changes. In such cases, teams may need to backport the fixes to the current version in use or integrate an upgraded version of the dependency.
The prevalence of unsupported dependencies is quite significant, and addressing issues with them requires an important amount of effort. Meeting this requirement will need a substantial shift in engineering culture to manage dependencies effectively and monitor them for security updates. For products with a longer lifespan, this will create the challenge of active product maintenance over longer periods of time.
“Be made available on the market with a security by default configuration, unless otherwise agreed between manufacturer and business user in relation to a tailor-made product with digital elements, including the possibility to reset the product to its original state”
The definition of a ‘secure by default’ configuration will vary depending on the product and the security controls it supports. This requirement marks a shift from current practices, which often prioritize interoperability, ease of integration and maintenance, and minimize the risk of breakage due to misconfigurations. As a result, many security controls that previously needed explicit opt-in may now need to be enabled by default.
The provision to reset a product to its original state presents a trade-off and requires careful interpretation of what ‘original’ really means. Resetting to the initial state could mean the product reverts to a version of its firmware which could then be exploited through a known vulnerability present in that earlier version. Many products today are designed to explicitly prevent firmware rollback for this very reason, and a product security assessment would typically identify the ability to roll back to a previous firmware as a weakness unless mitigations are in place to prevent rollback to vulnerable versions.
Therefore, it would be prudent to interpret the ‘original state’ as a ‘factory firmware reset’, but with the factory firmware being a recent version that is free of known exploitable vulnerabilities, or requiring all security updates to be installed before the product can be taken into use. This approach balances the need for product security while aligning with the spirit of the Cyber Resilience Act, as explained in the next requirement.
“Ensure that vulnerabilities can be addressed through security updates, including, where applicable, through automatic security updates that are installed within an appropriate timeframe enabled as a default setting, with a clear and easy-to-use opt-out mechanism, through the notification of available updates to users, and the option to temporarily postpone them”
The act requires a key security mechanism for all products: the ability to receive security updates during their expected lifecycle.
The regulation expects the availability of security updates to be notified to a user and, by default, automatically installed within an appropriate timeframe. However, the act also acknowledges the need for an opt-out or postponement possibility.
The implementation of this requirement will vary, depending on the product type. For instance, a connected consumer device may have automated firmware updates downloaded from the internet, and automatically applied without any delay. In contrast, an update to an Industrial Control System, which could disrupt production, may need to be deferred to the next maintenance window and installed manually.
While the language implies remote software updates, the actual mechanism of updating is not prescribed. Of course, many companies have already been moving to remote updates for the additional advantage of reducing the cost of maintenance due to not needing a maintenance engineer to make a visit.
It’s crucial to remember that introducing automated, remote software and firmware update capabilities can increase the product’s attack surface. Therefore, these capabilities must be implemented with care to avoid creating more security issues. In our experience, few engineering teams get this exactly right on their first attempt, and it is one of the areas where seeking expert help for design and security testing might be wise to consider.
“Ensure protection from unauthorised access by appropriate control mechanisms, including but not limited to authentication, identity or access management systems, and report on possible unauthorised access”
This requirement may seem familiar to many as it aligns with established best practices in cybersecurity. If device access is possible in any way, it should be secured through robust access control mechanisms, clear access control policies, and comprehensive logging.
The era when ‘admin’ was considered an acceptable password, or everyone is using the same shared user, is long gone. Such weak security practices do however persist in some products to this day. The act aims to eliminate these vulnerabilities by enforcing strong authentication measures.
Further emphasis is placed on the importance of logging and monitoring. Detailed logs can help detect any unauthorized access attempts and supply valuable information during incident response and forensic analysis.
“Protect the confidentiality of stored, transmitted or otherwise processed data, personal or other, such as by encrypting relevant data at rest or in transit by state of the art mechanisms, and by using other technical means”
To protect data at rest, encryption should be applied to data storage on the device. This approach ensures that the data stays secure even when the device is not in use. It has become very common, and very cheap, for security researchers and malicious actors to desolder the memory chip and dump its contents as one of the first steps in investigating a product.
For data in transit, mechanisms such as Transport Layer Security (TLS) or similar protocols should be employed. These protocols enable secure communications and are designed to prevent eavesdropping, tampering, and message forgery.
The act calls for the use of state-of-the-art mechanisms, requiring the selection of modern, strong and resilient encryption and hashing algorithms. For example, the use of MD5, SHA1 or RSA algorithms are no longer considered robust choices.
“Protect the integrity of stored, transmitted or otherwise processed data, personal or other, commands, programs and configuration against any manipulation or modification not authorised by the user, and report on corruptions”
The integrity of stored and transmitted data can be ensured through encryption. However, the integrity of commands and programs can become a bit of a rabbit hole, and while it implies that the software should be resilient to security vulnerabilities that could allow an attacker to execute arbitrary code, it might even extend to runtime protections in certain scenarios.
Depending on the technology stack and build environment, various code protection mechanisms such as stack canaries can be employed to prevent attacks at runtime. Stack canaries, for instance, are used to detect a stack buffer overflow before execution of malicious code can occur. For new products, it might be useful to consider development languages that are memory safe.
In addition, the act calls for robust configuration management to prevent unauthorized modifications. This could involve practices, such as least privilege access and a clear isolation of roles.
Lastly, the act emphasizes the need for effective incident response mechanisms. In case of data corruption or a security breach, timely detection, reporting, and remediation are crucial. This could involve keeping detailed logs, setting up real-time alerts, and having a well-defined incident response plan.
“Process only data, personal or other, that are adequate, relevant and limited to what is necessary in relation to the intended purpose of the product with digital elements (minimisation of data)”
Here we see an encouragement of manufacturers to adopt a privacy-conscious approach to data collection, possibly moving away from the current ‘collect everything by default’ mindset. While the term ‘necessary’ is expected to be broadly interpreted in the industry, it’s important to remember that the most effective way to prevent data loss is to limit data collection in the first place.
“Protect the availability of essential and basic functions, also after an incident, including through resilience and mitigation measures against denial-of-service attacks”
The determination of what constitutes an ‘essential’ or ‘basic’ function should be made on a case-by-case basis during the product’s design phase. The requirement wants to ensure the availability of the product and its functions, a critical aspect of security that complements the previously discussed requirements of confidentiality, integrity, and privacy.
Stress testing and penetration testing can help identify potential vulnerabilities and ensure the product can handle high loads or attack scenarios without compromising its essential functions.
“Minimise the negative impact by the products themselves or connected devices on the availability of services provided by other devices or networks”
Measures must be taken to prevent your product from being exploited as part of a botnet operation or used in other ways for malicious activities. While specifics are not explicitly outlined in the requirement, it suggests a direction where the compromise of an individual unit should not lead to the compromise of other similar units or backend systems.
To protect against such situations, a careful separation of roles at architectural, hardware and software levels in the product design is essential. This could involve implementing robust isolation mechanisms between different components or services, ensuring that a compromise in one area does not affect others.
Furthermore, it will be crucial to have robust security measures in place to prevent the device from being used as a launchpad for attacks on other devices or networks. This could include measures like rate limiting, or anomaly detection.
“Be designed, developed and produced to limit attack surfaces, including external interfaces;”
In practice, this requirement means adopting a ‘security by design’ approach where security considerations are integrated into every stage of the product lifecycle, from first design to development, production, and extends to the decommissioning of the product. This includes minimizing the number of external interfaces and services, while ensuring that those which are necessary are secured effectively.
Apart from security testing, threat modelling and design reviews are a key part of this process. It involves identifying potential threats and vulnerabilities in the early stages of design and development, allowing for proactive mitigation strategies, and verifying that the design introduces technical controls that adequately mitigate these identified threats.
“Be designed, developed and produced to reduce the impact of an incident using appropriate exploitation mitigation mechanisms and techniques”
Reducing the impact of an incident requires a comprehensive approach that includes both proper role isolation and technical exploitation mitigation controls.
When it comes to role isolation, it’s crucial to establish clear privilege separation for hardware, users, and applications. This means ensuring that each of these has only the minimum necessary privileges to perform its function, thereby limiting the potential damage if a component is compromised.
In addition, any operating system used should be appropriately hardened, introducing secure configurations, and limiting the attack surface of the system to make it more resistant to exploits.
“Provide security related information by recording and monitoring relevant internal activity, including the access to or modification of data, services or functions, with an opt-out mechanism for the user”
In practice, this requires the deployment of telemetry and monitoring systems capable of tracking and logging internal activity. These systems can offer invaluable insights into the operational aspects of the product and aid in the early detection of potential security issues.
However, it’s paramount that these systems are designed and implemented with a strong emphasis on user privacy, as specified in a prior requirement.
This means ensuring data collected is minimal, anonymized where possible, securely stored, used solely for the intended purpose of enhancing product security and removed when no longer necessary.
Furthermore, users should be clearly informed about the data collection practices and given an easy and straightforward way to opt out if they choose, as these requirements will bump into other EU legislation such as the GDPR.
“Provide the possibility for users to securely and easily remove on a permanent basis all data and settings and, where such data can be transferred to other products or systems, ensure that this is done in a secure manner”
There comes a day where the product is removed, sold, or simply discarded, and your customers will want to ensure their data cannot be recovered in the future. It’s therefore important to remember that deleting data does not necessarily remove data.
It is however not necessarily difficult to achieve this, ensure data is encrypted, throw away the encryption keys and reset the unit to a factory default state.
The Future of Cyber Resilience
The Cyber Resilience Act introduces many requirements which might require large changes to the technical design and processes for how products are developed. The high-level picture is a sensible one from a security point of view, though time will tell us how effective this act will turn out to be.
If we are to summarize the requirements of the Cyber Resilience Act, we can state that products must be secure by design, secure by default, and without known vulnerabilities. It’s necessary to protect the confidentiality and integrity of your products and its data, and not become part of a botnet. Prevent data loss and ensure it is possible to detect when something goes wrong through logging and telemetry, while remaining privacy conscious. And if, despite all good intentions, a vulnerability is identified, ensure they can be rectified by applying updates in a timely manner.
Achieving these requirements for all products on the European market will be a major step forward from where we are today. But to get there, there is an important chunk of work ahead of us that needs to be done.
If you want to learn how the Cyber Resilience Act affects your unique circumstances, reach out for a friendly chat to see how we can help. Amanita Consulting has ample experience addressing these questions for clients, from both the process and technical perspective, and we can help you get on top of this challenge.