Understanding the EU Cyber Resilience act and achieve product cybersecurity compliance

BACKGROUND

NEW EUROPEAN CYBER RESILIENCE ACT (CRA) AIMS AT INCREASING SECURITY LEVEL AND TRANSPARENCY

On September 15th, 2022, the European Union Agency for Cybersecurity (ENISA) released the draft of the new Cyber Resilience Act (CRA)1 to be enforced by the European Parliament throughout the European Union, impacting manufacturers, importers, and distributors of products with digital elements. The CRA aims at increasing the level of security of all products with digital elements within the European Union by requiring manufacturers to implement and maintain a cybersecurity framework and to follow this framework throughout the product’s lifecycle. Additionally, enhanced transparency about security properties will enable consumers and businesses to take security-conscious decisions and use products with digital elements more securely.

LIMITED TIME TO ACT FOR PRODUCTS WITH DIGITAL ELEMENTS

This initiative by the ENISA follows increasing damage caused by cybercrime, which resulted in global costs of more than EUR 5.5 trillion in 2021 . Many of these cyberattacks are caused by vulnerabilities in products with digital elements and aggravated by lack of transparency by manufacturers about relevant security properties. While the CRA targets a broad scope of “products with digital elements”, ranging from operating systems, desktop and mobile applications to hardware devices and network equipment, this whitepaper will focus on connected devices and target manufacturers, distributors, and importers of such devices.

It is expected that the new CRA will be enacted as directive by the European Comission early 2024 without the need of the approval
by the European parliament. This will leave - even with a transition period - only short time to adopt necessary reporting requirements and to comply with the remaining essential requirements. Due to multi-year design & development cycles, all manufacturer need to act now. Only devices regulated by Regulation (EU) 2018/1139 (civil aviation), Regulation (EU) 2017/745 (medical devices), Regulation
(EU) 2017/746 (in vitro diagnostic medical devices), or devices certified in accordance with Regulation (EU) 2019/2144 (type-approval motor vehicles and their trailers, and systems, components and separate technical units intended for such vehicles...) are exempt
from the CRA. With the average multi-year timespan between design and production of connected devices this leaves little time
for adoption and applying necessary security changes.

OVERVIEW OF CRA REQUIREMENTS

While the CRA defines extended assurance obligations for fulfilling the essential security requirements such as third-party conformity
assessments for critical products (for both, class I and class II), the underlying requirements remain the same for all products. The new requirements imposed by the CRA can broadly be classified into the three categories governance, product development, and reporting:

REQUIREMENTS ON PRODUCT DEVELOPMENT

1. Requirements affecting the product itself define a minimum set of security properties to assure its resilience to cyber-attacks and elevate its level of security.

REQUIREMENTS ON GOVERNANCE

2. Requirements affecting manufacturer’s software development life cycle (SDLC) processes, such as concept & design, development, production & launch, and service & support, are designed to increase assurance of creating secure products and maintaining their level of security in a repeatable, transparent, and sustainable way and measurable with adequate security controls in place.

REQUIREMENTS ON REPORTING

3. Reporting and information requirements about exploited vulnerabilities and incidents involving the product to surveillance authorities and users of products assure that mitigating controls can be implemented in a timely manner. The goal here is to minimize the timeframe in which end users as well as critical infrastructure providers are exposed to cyber threats caused by critical vulnerabilities to elevate the overall level of security of Europe’s digital infrastructure by applying provided fixes or intermediate mitigations to reduce the impact of the vulnerability.

CRA REQUIREMENTS COVER SUPPLY-CHAIN VULNERABILITIES

The figure below provides an overview of key requirements and how they relate to respective phases of the product security lifecycle. Their purpose is to support and assure defense in depth and secure by design approaches with the goal to provide confidence that products meet elevated security expectations by the European market. One core requirement of the CRA is to manage supply-chain risk.

SUPPLY CHAIN RISKS

In modern applications, 80%-90% of the code base is made up of third-party software components – open source as well as proprietary.3 These range from crypto-libraries being used to secure sensitive information in transit to closed-source SDKs to control third-party hardware modules included in connected devices. As a majority of the code base is not under direct control of the manufacturer, a significant share of a connected device’s risk and exposure is inherited from third-party software components. Risks include:

THIRD-PARTY RISKS REMAIN HIDDEN

Lack of visibility: While direct dependencies and inclusions of third-party components are often known, the supply-chain rarely ends there. Third-party components commonly rely on further dependencies, which in turn have dependencies as well. Making the entire supply-chain transparent is even more challenging when the source code of affected components is not available, as is commonly the case for importers or distributors of connected devices.

THIRD-PARTY SOFTWARE MAY LOWER OVERALL SECURITY LEVEL

Lower security standards: Development practices as well as security level of vendors of third-party open source and commercial off-the-shelf (COTS) software components are rarely vetted. This results in scenarios where a significant part of the final product may not comply with the manufacturer’s security requirements, which lowers the security standard of the overall product.

THIRD-PARTY SOFTWARE CAN BE VULNERABLE TOO

Vulnerable components: Each third-party manufacturer operates at different intervals to provide new releases for their software components. Additionally, upgrading such a dependency in a connected device would require rigorous testing to avoid unintended side effects and breaking of existing functionality – in particular, if the device has requirements to safety. In consequence, once-included third-party software components rarely get updated even if newer releases contained security fixes.

ATTACKERS INCREASINGLY FOCUSING ON THE SUPPLY-CHAIN

Supply chain attacks: Supply chains have moved into the focus of cyber criminals as a lucrative entry-point into their target’s infrastructure. Threat actors have started to actively plant backdoors in open-source components and to spread malware via open-source repositories.

COUNTERMEASURES TO SUPPLY CHAIN RISKS

SUPPLY-CHAIN REQUIREMENTS ON PRODUCT SECURITY

Supply-chain vulnerabilities play a major role in the CRA. The severity of supply chain risks justifies rigorous mitigation efforts. The CRA acknowledges these challenges and discusses supply-chain risk from different angles.

PRODUCT SECURITY

From a product-security perspective, the CRA is quite straight forward when it comes to section 1 of the essential security requirements touching on supply-chain risks: It requires the manufacturer to assure that the product is free of known exploitable vulnerabilities at the time of publication and that this level of security is maintained throughout the product’s life cycle. The obvious strategy to fulfill this requirement is to rely on latest versions of third-party dependencies only, which are free from known vulnerabilities (Common Vulnerabilities and Exposures / CVE4).

To avoid being affected by known vulnerabilities where it is not feasible to simply use the latest software version, the impact of known vulnerabilities must be assessed and either determined mitigated or not applicable, or – if they are exploitable indeed – mitigated on an individual level, by e.g., backporting security patches. Typically, the impact assessment to determine if known vulnerabilities require mitigation, is a manual process analyzing the CVE, related patches, and resources in combination with the target environment or source code.

To reduce efforts of manual impact assessments for each known vulnerability, binary software composition analysis (SCA) put into context with the target product’s configuration and setup can aid this process tremendously by automatically determining known vulnerabilities with a low likelihood of affecting the configuration of the target product and discarding them. That way, focus can be placed on remediating remaining known exploitable vulnerabilities. Binary SCA streamlines manual impact assessments by automatically ignoring low-risk vulnerabilities and focusing on exploitable ones in relation to the target product‘s design.

GOVERNANCE

The CRA defines numerous requirements, which also cover supply-chain related issues:

• Software components must be identified, and an software bill of materials (SBOM) must be maintained.
• Vulnerabilities must be remediated without delay and security updates need to be distributed to affected users.
• Products must be tested and vetted for their level of security regularly.
• Due diligence for all third-party components is required. It must be assured that such components do not jeopardize the overall security level of the product.

HOW TO COMPLY WITH SUPPLY-CHAIN GOVERNANCE?

Now, adoption of software composition analysis tools is key. Software composition analysis (SCA) describes the automated process of determining the software components (open source and COTS), which are included in a final product. The result of an SCA is an SBOM either derived from source code, meta-data such as package manager information, or from binary representation. As it typically cannot be assured that source code is available for all software components provided by third parties along the supply-chain, SCA can often only rely on compiled binary representations of a software component.
By including binary SCA as part of the process to identify and manage security risks associated with third-party components used within the product, the generation of the inventory of software components from third-party suppliers can be automated. This is achieved by deconstructing the binary firmware build to assure that all software components, which will eventually be delivered to the users of products, can be investigated.

The SBOM includes identified software components, associated versions, as well as included patch level. The same impact assessment on known vulnerabilities, which is applied for the initial release of the product, must be repeated for each newly published vulnerability affecting any part of the product. Based on the SBOM, known vulnerabilities affecting any part of the product can be identified. This process must be regularly repeated to maintain an up-to-date overview of vulnerabilities affecting the product.

SBOMS MUST INCLUDE BINARY CODE FROM SUPPLY-CHAIN

An automated „security quality gate“, with binary SCA as part of the build process, will assist the process of verifying that a product or product upgrade is not released until its security-related issues have been mitigated. By automatically failing release pipelines if exploitable vulnerabilities are identified, it can be assured that security-related issues originating from third-party software are addressed as early as possible.

The ONEKEY Product Security Platform enables manufacturer (distributer/ importer) to automate their product security in multiple steps throughout the entire product life-cycle:

ONEKEY’s unique & proprietary binary extraction technology enables a deeper & more precise analysis of the binary firmware image without the need for source code. ONEKEY automatically generates a detailed SBOM, including software dependencies at all levels of the firmware. Next, based on artificial intelligence and machine learning, ONEKEY uses a natural language processing (NLP) approach to determine whether there are publicly known vulnerabilities affecting this software version. In addition, ONEKEY’s AI/ML-based approach automatically analyses the preconditions for exploitability of the vulnerabilities. In an integrated, automated impact assessment, the target device is analyzed if the prerequisites for exploitability are met, filtering out non-relevant vulnerabilities. This unique approach shortens response times by significantly reducing manual impact assessment and allowing development & Product Security Incident Response Teams (PSIRT)

The ONEKEY Product Security Platform provides automated security processes and controls mandated by the EU Cyber Resilience Act:

ONEKEY can generate an SBOM simply from a binary firmware image. The SBOM can be exported both in machine readable (i.e., CycloneDX, SPDX) or human readable formats (CSV, EXCEL) to make them available to other systems, end users, and regulatory bodies. ONEKEY‘s firmware monitoring analyses the target product daily for new zero-day vulnerabilities or known vulnerabilities and performs automatic AI/ML-based impact assessments for all identified vulnerabilities. This enables manufacturers to react to new vulnerabilities in the shortest possible time and to create and distribute security patches. Analysis and monitoring for automated security due diligence of third-party components - simply set up ONEKEY as a quality gate for any third-party component or product.

CRA REPORTING REQUIREMENTS

SUPPLY-CHAIN REQUIREMENTS ON REPORTING

A central goal of the CRA is to foster exchange and collaboration between different stakeholders in digital eco-systems. As such, users and market surveillance authorities must be provided with relevant security-related information about products, and it is necessary to make CRA-specific documentation available.

• Manufacturers are required to share information about exploited vulnerabilities with market surveillance authorities and ENISA during the lifetime of the product. This includes vulnerabilities affecting third-party components included in a product.
• Users and authorities must be informed about mitigating actions that can be taken and when security patches are available.
• Additionally, manufacturers of third-party components and maintainers of open-source software must be informed if a vulnerability is affecting applications under their control.

EFFECTS ON DISTRIBUTORS
AND IMPORTERS

These requirements underline that security is not just a one-off effort. It is a process and requires continuous maintenance. Regularly assessing the SBOM of a firmware for newly published vulnerabilities. Pro-actively addresses this requirement and supports reviewing and assessing of security-related issues by validating applicability and determining impact to the product.

Distributors and importers often lack the technical capabilities and necessary insights into affected products to reliably determine compliance with the CRA. In order not to purely rely on manufacturer’s self-assessment, distributors and importers can apply the same techniques to generate the SBOM from the binary
firmware and to uncover any known exploitable vulnerabilities.

SUPPORT WITH CRA
COMPLIANCE?

Stringent security and reporting practices as required by the CRA add overhead to existing product development life cycles. Nevertheless, they are a necessity to address today’s elevated security requirements and the ever-increasing threat landscape. And to satisfy ENISA’s regulatory requirements and avoid penalties of up to 15 million euro or 2.5% of the global annual turnover of course.

There are various tools available to improve documentation, processes, and cybersecurity automation. To ease CRA adoption, automation support is readily available within ONEKEY‘s product security platform to support vulnerability management or supply-chain assessments processes and assist with reporting and documentation requirements. Additionally, ONEKEY provides expert-advice and offers consulting resources to support manufacturers, importers, and distributors in achieving compliance with the CRA.

AUTOMATION & SUPPORT TO ACHIEVE & MAINTAIN CRA SECURITY REQUIREMENTS & COMPLIANCE

ONEKEY’S SECURITY EXPERTS’ ADVICE & AUTOMATION

In addition to reducing manual efforts by adding automated controls to processes required by the CRA, ONEKEY aids manufacturers, importers, and distributors of products with digital elements in adopting processes required by the CRA with gap analyses and implementation support.

ONEKEY‘s automated firmware security analysis platform can automatically detect and report violations of essential cybersecurity requirements as defined in Section 1 of Annex I of the CRA. Expanding on ONEKEY’s automated capabilities, ONEKEY’s technical experts and security researchers are also available to identify gaps to a product’s adherence to the CRA and to conduct penetration tests and vulnerability assessments on affected connected devices.

KEY TAKE AWAYS

Manufacturers need to act now to ensure product compliance:

• With attacks on connected devices on the rise, ENISA has defined essential requirements to increase the level of security of connected devices and established a framework to foster cooperation and information sharing on new vulnerabilities and emerging threats.
• CRA provides the toolset to produce such cyber-resilient connected devices, especially from a supply-chain risk’s perspective.
• To meet elevated security and compliance requirements and to tackle supply-chain risks, implementation of automated security and compliance controls, i.e., holistic binary software analysis, are required. Automated initial software analysis and continuous monitoring will substantially reduce efforts for implementation and maintaining CRA compliance.

Interested in further discussion with our security experts on how to achieve and maintain your CRA product security compliance? Please contact our security experts at: experts@onekey.com