How to further improve the Proposal of the EU Cyber Resilience Act

Jochen Michels, Head of Public Affairs Europe, Kaspersky

Igor Kumagin, Cybersecurity Expert, Kaspersky

The European Commission invited interested stakeholders to provide feedback on the “Proposal for the Regulation of the European Parliament and of the Council on horizontal cybersecurity requirements for products with digital elements and amending Regulation (EU) 2019/1020” (short Proposal for the Cyber Resilience Act, or CRA).

Kaspersky, as a global cybersecurity company with more than 25 years of experience in successfully designing and delivering cybersecurity solutions to protect users from cyberthreats, welcomes and fully supports the continuous efforts of the European Commission to strengthen cybersecurity in the EU and, particularly, to introduce horizonal legislation to improve the security of products with digital elements and thus enable businesses and consumers to use such products securely.

It is an important aim of the CRA to define minimum requirements for the development of secure products with digital elements ensuring that hardware and software products are placed on the market with fewer vulnerabilities. In this regard, Kaspersky welcomes the approach to ensure that manufacturers improve the security of products with digital elements from the design and development phase and throughout the whole life cycle. This also applies to the second main goal of the CRA – to create conditions allowing users to take cybersecurity into account when selecting and using products with digital elements. And we strongly advocate the approach to develop “objective-oriented and technology-neutral requirements”.

In this blog post, we have compiled some important points that should be discussed and considered in the further course of the legislative process. The full submission of our feedback to the Proposal is available here.

#1 For clarity, legal and operational security, Kaspersky calls for more detailed definitions and more comprehensive specifications on the terms and concepts introduced by the Proposal.

For instance, if there is an intention to introduce an overarching term to cover multiple tasks of manufacturers regarding the discovery, management, handling, and coordinated disclosure of security vulnerabilities in products, we would rather advocate for using the term “vulnerability treatment” instead of “vulnerability handling processes” to thus ensure consistency with other adopted intergovernmental frameworks, such as the OECD Recommendations on the Treatment of Digital Security Vulnerabilities, and to avoid misunderstandings in the IT security community where the concept of “vulnerability handling processes” has a long-established and specific meaning. What is more, the obligation for manufacturers to perform a due diligence when integrating components sourced from third parties needs to be explained more in detail. In addition to that and to ensure that resources of both ENISA and the manufacturers are allocated and used wisely, “actively exploited vulnerability” should be defined as a “vulnerability for which there is reliable evidence that execution of malicious code was performed by a malicious actor on a system without the permission of the system owner”.

#2 “Expected product lifetime” should be defined.

Problems surrounding the existing end-of-life (EOL) gap are well known and are also addressed in the CRA, as we initially requested. However, the concept of “expected product lifetime” is not clearly defined (and it is equally not clear who defines such timeframes – manufacturers or the authorities). This may lead to uncertainties and disproportionate additional burdens for manufacturers; i.e., a commitment to product updates for an indefinite period of time. Therefore, we recommend that the “expected product lifetime” be determined by manufacturers – who have the right to establish the minimum length of time for which a product will be provided with security updates. This right should go together with the obligations for manufacturers to make sure that transparent policies in this regard are available to users and authorities.

#3 Proposed process and obligations for reporting vulnerabilities require further improvements.

The Proposal takes a holistic approach and addresses the issue of vulnerabilities by introducing obligations for both manufacturers and importers to report vulnerabilities. Nevertheless, the draft raises a number of questions in this regard that need to be clarified. For example, a distinction should be made between vulnerabilities found in manufacturers' code components and those found in third-party components. Otherwise, this remains both an unrealistic and undesired course of action for manufacturers. We also recommend introducing vulnerability sharing safeguards to bring more transparency and accountability to this process, as well as improving coordination between national market surveillance authorities and ENISA – with regard to vulnerability reporting.

#4 Using SBOMs is an important industry practice to enhance software transparency, which should be available to users upon request only; however, it should not be in the “minimum” list, as a large percentage of B2C and B2B users still do not possess sufficient skills to process SBOMs.

Kaspersky was among the first cybersecurity vendors to introduce SBOMs and to provide them to its users further to requests via our Kaspersky Transparency Centers. We therefore firmly support the further development of this important emerging industry practice to enhance software transparency. Nevertheless, the inclusion of requirement (6) in Annex II in the list of “minimum” information to accompany the products does not seem to be very purposeful in terms of the average product user and in relation to the enormous effort required on the part of manufacturers. To avoid unnecessary burdens, we therefore recommend amending requirement (6) in Annex II (“Information and instructions to the user”) and changing it to: “in cases following particular requests from the user where the software bill of material can be accessed”.

#5 Requirement No. 2 in Annex I (Essential cybersecurity requirements), Paragraph 1, that “products with digital elements shall be delivered without any known exploitable vulnerabilities”, is not feasible for manufacturers, and should be amended to narrow the scope of such vulnerabilities.

Not all vulnerabilities are alike, and not all of them require the same treatment. It is not feasible to expect that manufacturers should mitigate all known vulnerabilities since, in many cases, existing vulnerabilities (especially minor ones) do not create any further impact. In addition, not all vulnerabilities are publicly known. Therefore, we recommend clarifying which vulnerabilities are meant (publicly known vulnerabilities or those known to the manufacturer) as well as adjusting the regulation:

There are a great many applications that can require high bandwidth, and, in this regard, it is not clear if such applications seriously pose a security concern. Furthermore, the way how this requirement is drafted raises questions as to what specifically manufacturers are expected to achieve, and thus which concrete steps should be taken. Overall, we believe that this requirement does not have a high security priority, and should be lowered and removed from the list of “essential” requirements.

This very broadly formulated requirement raises several questions and inaccuracies that are difficult to answer. We therefore suggest grouping this requirement with Requirement No. 1, which would provide more specifics on what is expected from manufacturers. Within Requirement No. 1, we also suggest, with regard to our Cyber Immunity' Concept, adding that “products should be designed in such a way that security is not an isolated property of a product but its core part”.

#8 The transition period should be clarified to allow organizations of different scale and sizes to get ready for compliance with the future regulation.

The very broad scope of the Cyber Resilience Act has far-reaching implications for its implementation. For many stakeholders, e.g., for start-ups and SMEs, a period of 12 to 24 months is too short to implement the key requirements across all products and industries while at the same time ensuring a level playing field. A transition period of 36 months would be more appropriate so that both public authorities and business could sufficiently prepare for compliance.