Early Comments Open on the Cyber Resilience Act

The Cyber Resilience Act (CRA) is probably the biggest legislative intervention ever made in the beleaguered field of computer security. In a unique regulatory move, the public now has access to the detailed standards under consideration. This article briefly describes the draft standards and offers suggestions to product manufacturers (including open source development teams) and security experts for reviewing the standards.

Background on the CRA

The Linux Professional Institute (LPI) has followed proposals concerning the CRA from a very early stage, and summarized the impacts of the law about a month ago. LPI had also convened an expert panel as the law was being hammered out, and recorded the comments of experts at that stage in 2024.

A high-level perspective might be this: The European Union often sees its mission to intervene legally—and in extraordinary detail—into matters that other places leave up to the market or to random historical forces. But if there are any issues of public concern that call for such legal treatment, cybersecurity ranks high. This is a world where cyberattacks can close hospitals, subject millions of people to identity theft, and cripple services in an entire country.

The EU’s modus operandi is to release a regulation (the General Data Protection Regulation being an example), which is directly applicable in all EU member states. The extensive CRA regulation defines security goals and sets up „market surveillance authorities“ (paragraph 109) who use „simultaneous coordinated control actions“ (paragraph 114) to ensure that companies comply.

The Draft Standard

As verbose as the CRA is, it merely sets up the framework for regulating security. Details, such as which tools or programming practices to use, remain to be defined.

The draft standards just released were created by the European Telecommunications Standards Institute, a non-profit body similar to the National Institute of Standards and Technology in the United States.

An interesting justification for releasing early drafts comes in the ETSI’s guide to commenting: „ETSI is piloting informal public consultations of the vertical standards in support of the Cyber Resilience Act at a much earlier stage than it is usual in the standardization world.“ Their justification is a claim to be „[e]xercising one of the principles of international standardization – Openness – and taking it to a different level.“

The computer field, in my opinion, should honor this outreach and make serious efforts to turn it into an opportunity.

The standards are incredibly long and comprehensive. For instance, Section 4 of each standard tries to lay out everything from „Main functionalities“ and „Architecture“ to „Use cases.“

To illustrate the level of micro-management in the standards, Section 4.7.2.2.2 of the PKI standard (one of the standards that is more fleshed out) defines three types of logging (each with examples): registration service events, certificate generation service events, and revocation management service events.

Some requirements are perplexingly vague. For instance, Section 4.5.5.3 of the Password Managers standard, using terminology standardized in the IETF’s RFC 2119, says, „Security measures SHALL balance protection with usability and system performance.“ How does one measure „balance“? How does one validate conformance to this requirement?

The core section of most standards, in my option, is Section 5, Requirements. Like many standards, these try to codify what is already widely accepted in the field. They mandate popular practices such as a software bill of materials (SBOM) and the appropriate use of encryption.

But the downside of early releases also stands out: long sections of most standards are empty or contain just the bracketed „[to be defined]“ phrase. I will suggest, later in this article, practical leverage that computer experts can have in this situation.

Implications for Free and Open Source Software

Because most of our readers work with free and open source software, I direct the reader again to LPI’s recent article for detailed coverage of the potential impacts of the CRA. Although software delivered under free and open source licenses is exempt from many requirements and penalties, parts of Articles explicitly apply to open source software (Article 24).

Luckily, the parts of Article 14 (and Article 15, voluntary compliance) that apply to open source software mostly document types of monitoring and reporting that are already considered best practices and are conducted by free software projects. (The law does impose a novel requirement to report vulnerabilities to a central government body.)

Another oddity that might be troublesome for free and open source software is a requirement to remove alpha and beta releases (paragraph 37) after the final release is made. This might be enforceable by proprietary companies, but open source releases can’t be magically suctioned up at an arbitrary date.

Some Observations on Product Descriptions

Earlier, we explored the astonishing detail in these standards. I see two reasons for going so deeply into each type of product:

• What defines the product? In other words, does a real-life product match what the standard says it contains?
• What needs protection? What attack vectors might target this detail?

The explosion of detail also indicates that evaluations and reports will be automated. The descriptions should be precise and should eliminate overlaps, so that automatic reporting works and is consistent across different products in a particular category.

The product descriptions also fall into hierarchies or ontologies. For instance, security information and event management (SIEM) systems are divided into two types (self-hosted systems and managed services), each of which is further subdivided. If systems out in the field don’t fall neatly into the categories, it could hinder the collection and evaluation of their cybersecurity characteristics.

Suggestions for Commenting

How do we, as a community and an industry, handle this mass (or mess) of documentation?

I will modestly offer a few approaches, some for people working on or managing computer products and some for security experts.

Both groups should take advantage of this early review process to comment on the structure and scope of the documents in general. (You could expect this advice from me as a professional editor.) Are the sections divided up in a useful manner? Is material generally placed where it should be? Are terms consistent with what actual developers use?

Developers and managers should then focus on their own product. First, check whether your product is covered by the definition in the standard. Undoubtedly, whatever you’re doing is covered by the CRA somehow, so see whether the product definition in the relevant standard describes your product accurately. As explained earlier, the components and functions of each product are listed in detail; you should scrutinize these. Some standards also place some kinds of products „out of scope“; you should see whether your product falls under one of the exclusions.

Security experts should focus on the Requirements section (usually Section 5) of each standard. Here you can point out whether a requirement is outdated or misses a possible response to some threat.

I am pessimistic whether the Operating Systems standard could ever adequately cover the threats and solutions to those types of software. Threats and solutions tend to be different for every operating system, and there is no end to them. Other people may be able to determine whether the task is more feasible for other computer products.

The Draft Standards are a Real-World Test of the CRA

Threats and mitigating factors are in constant evolution, so any regulation that goes into such detail as the draft cyber standards will need continual revisiting and revision. This early stage of review allows experts throughout the computer field to figure out what the CRA can accomplish and to help it reach its goals.