Introduction
Manufacturers and importers that provide products with digital elements in the EU market will have to comply with the Cyber Resilience Act (CRA). This article contains some general practical advice on the implementation of requirements found in the CRA. Note that it is important for each company to make their own analysis and fulfillment of any regulation, including the CRA. This whitepaper is not a complete overview of the CRA and is not legal advice.
Affected products
The CRA applies to “products with digital elements whose intended, or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network.” [Article 2.1], which is most any product that contains software. There are exceptions for products that are already regulated through existing legislation, such as in automotive and medicine. Open source projects are also exempted from complying to the CRA, but importantly this exception does not extend to the use of open source components in commercial products (see section on SBOM and open source below).
The CRA differentiates between critical and non-critical products, where critical products include products such as routers, microcontrollers, operating systems and industrial automation and control systems. Critical products are expected to be certified by a third party while non-critical products will be self-certified by manufacturers or importers.
CRA requirements
The requirements in the CRA include (but are not limited to):
- Secure development: The product must have been developed with security in mind, e.g. using a secure software development lifecycle (SSDL).
- Security testing: Apply regular security testing and security reviews of the product.
- Vulnerability management, including vulnerability disclosure and reporting of incidents.
- Security patches must be provided free of charge for the lifetime of the product.
- A Software bill of material (SBOM) must be provided with the product. The manufacturer is responsible for the whole product, including third party components and open source components that they include in their product.
Secure development
Secure development means that cybersecurity is considered in all phases of product development. This can be contrasted to trying to fix cybersecurity after the product has been developed, which will never be as effective or efficient. Products that are developed according to a secure software development lifecycle (SSDL) are said to be secure by design.
- Start with risk assessment and threat modeling, not with testing. It is often tempting to just test a product for vulnerabilities and fix those, but this will not fix the root cause of the vulnerabilities. Risk assessment and threat modeling is the foundation of secure development.
- Include security activities in the regular work. Security should not be a separate activity, but rather a part of normal development activities.
- Everybody should be involved in security. It can be tempting to hire someone to take care of security in product development, but this is not a scalable solution. Security needs to be everybody’s responsibility.
- Start small, improve and be efficient. It is not productive to do too much security work.
- Make sure that secure development activities are easily traceable for internal follow up, standards compliance or future audits.
Security testing and review
Security testing complements secure development by providing feedback and information on the security status of the product. There are many different types of security testing, where the most common include vulnerability testing and penetration testing. Security review includes re-evaluating previous risk assessments when appropriate.
- Security testing should start with people that are involved in the development of the product, even if they do not have detailed knowledge of security. Knowing the product and having access to internal documents makes it easier to identify possible security issues. Security testing should be a part of the existing testing and quality activities for the product.
- Penetration testing done by security experts can be useful, but should preferably be done once secure development practices are in place and should be used to complement, not replace, internal testing.
- Vulnerability testing is a broad topic, but using vulnerability scanners during development is a good starting point. Keeping track of vulnerabilities in third party components, such as open source packages, is a minimum.
Vulnerability management
Vulnerability management means continuously evaluating and managing vulnerabilities as they are discovered.
- Vulnerabilities in third party components need to be managed. Vulnerability testing can inform about the existence of such vulnerabilities, but there also needs to be a plan on how and when to patch those vulnerabilities.
- Externally reported vulnerabilities on a product must be handled by the manufacturer. Having a clear policy on how to respond to such vulnerabilities is a minimum.
Security patches
An essential part of any cybersecurity work is fixing discovered vulnerabilities together with continuous improvement. The CRA makes it mandatory to provide security patches in a timely fashion and free of charge.
- Having a regular release schedule is much easier in the long term than ad hoc response to new vulnerabilities. This can be a challenge for embedded products, but is a challenge that needs to be tackled.
- For products with dependencies to other products, it is important to handle interoperability questions. A security patch that cannot be installed due to interoperability issues is useless.
SBOM and open source
A software bill of material (SBOM) is essentially a “list of ingredients” for software. The reason this is important to provide, is that it provides transparency to possible risks and vulnerability through third party components. It is important to note that a provider of a product is responsible for that product, including third party components and open source components. This means that manufacturers need to apply cybersecurity practices not only on their own work, but also do due diligence on their supply chain.
- SBOM should be provided in a standard, commonly used, computer readable format. There are tools available that help with this. It is important to note that customers can and will use the SBOM to scan for risks and vulnerabilities.
- In addition to doing due diligence on open source licenses, manufacturers must also do due diligence on open source from a cybersecurity point of view.
CRA and standards
There is no specific standard that exactly matches the requirements in the CRA. However, the European Union Agency for Cybersecurity (ENISA) and the Joint Research Centre of the European Commission have published a report mapping standards to the CRA. The report contains a more complete list of requirements from CRA than is covered in this whitepaper and matches these requirements to different existing cybersecurity standards.
Cyber Resilience Act Requirements Standards Mapping – Joint Research Centre & ENISA Joint Analysis
In summary, the standards ETSI EN 303 645, ISO 27001 and IEC 62443 all have some overlap with the CRA, with ETSI EN 303 645 being the closest match. It is important to note that CRA is outcome driven rather than prescriptive and this is also the proper way to tackle cybersecurity. It is more important to understand what we are trying to achieve, than to implement something for the sole reason of compliance. This is also a strength of ETSI EN 303 645: “The provisions are primarily outcome-focused, rather than prescriptive, giving organizations the flexibility to innovate and implement security solutions appropriate for their products.” (ETSI EN 303 645 V2.1.1 page 5). Even if a standard can provide assistance and guidance, it is always important to implement security that is appropriate for a product rather than blindly following a standard.
CRA and compliance
Companies that do not work with critical products will self-certify to the CRA. On one hand, there is a benefit of not having the cost of third party certification. On the other hand, the business risk of non-compliance still needs to be managed, as the fines are significant, up to EUR 15 000 000. Therefore it is reasonable to implement an internal audit and compliance control to manage the risk. However, traditional audits are often manual, which makes them costly, time consuming and only possible to execute occasionally. This is at odds with modern software development that emphasizes automation and agility when it comes to changes. A solution to this is to integrate the compliance controls into the development of the software, creating automatic controls of activities that are connected to CRA compliance. The human decisions of what solutions to implement for specific requirements are still needed, but the control that the implementation is still being followed can be automated and continuous, instantly detecting if some requirements are being violated. Compliance violations can happen e.g. if a certain test has not been executed, if an external web page has been moved or some feature is missing from the product. Continuous monitoring of compliance will make life easier both for business risk management as well as software development.
How we can help
Please contact us if you want help with understanding the CRA legislation, how it will affect your company and how you can integrate compliance into existing workflow. We provide workshops where your employees will get the chance to understand the challenges and provide solutions that work for your company and your products, as well as assistance and feedback on your journey towards CRA compliance.