CRA Risk Management Starts With the Product Context
Table of contents
The previous post introduced Risk Management for the Cyber Resilience Act (CRA) as a continuous cycle that assesses, estimates, treats, communicates and monitors the cybersecurity risks of a product with digital elements (PDE). To be able to enter this cycle, the PDE’s purpose, functionality and interaction with its operational environment need to be understood and clearly defined. This is the purpose of the Product Context.
Significance of the Product Context
Some teams might be inclined to jump into the risk assessment, e.g., by drawing up data flow diagrams directly. The problem is that when the PDE is not clearly defined, you will not know what the important parts are and where to focus. In the end, it is easy to waste time when not preparing your Risk Management with a documented Product Context.
The Product Context does not need to be an elaborate document and it does not need to be in a complete and final state for beginning the risk assessment, either. From my experience, the team should, however, agree on the intended purpose, reasonably foreseeable use as well as system boundary and operational environment before proceeding. In the following, I will go through each element of the Product Context according to prEN 40000-1-2.
Intended Purpose and Reasonably Foreseeable Use
“Intended purpose and reasonably foreseeable use” is a complicated way of saying: it is not sufficient to analyze the functionality and use cases of your product that you advertise, but you need to consider realistic human behavior. Your users might be tired, or stressed, or both, and they might use the product in unintended ways. This could mean that a setup wizard is skipped and, e.g., this should not result in an unchanged default password. Another example would be a smart lock that is only intended for personal use, but the apartment that it protects is sometimes rented out and used to give guests access.
The concept of reasonably foreseeable use does not mean that you need to consider science-fiction-like scenarios, but neither is it sufficient to only analyze an ideal world described in brochures or manuals (the intended purpose). It is worth noting that this is not a CRA-specific concept but, e.g., also described in the “Blue Guide” which is a fundamental EU documents which describes how products in the EU are regulated (see Section 2.8):
Manufacturers have to match a level of protection corresponding to the use they prescribe to the product under the conditions of use which can be reasonably foreseen.
Therefore, the intended purpose and reasonably foreseeable use need to be documented as part of the product context. It establishes the scope and context for the risk assessment.
Product Functions
Compared to the previous section, describing the product functions as part of the product context might be more straightforward. The functions are what development teams regularly discuss anyway, and they should be documented to support the further analysis.
An important note is that this includes Remote Data Processing Solutions (RDPS) that the PDE depends on to provide its functions. Under CRA, any RDPS that is designed and developed, or otherwise under the responsibility of the manufacturer, is directly in scope. This covers situations where, e.g., a cloud service developed by the manufacturer is attacked, enabling subsequent attacks on the PDE. Consequently, the RDPS and how it supports the PDE’s functions need to be described in the product context. This also falls within the scope of risk management under the CRA.
Product Operational Environment
The environment in which the product will be operated, can greatly influence the cybersecurity risks. If the PDE is located in a restricted area, e.g., the production floor of a factory, certain attacks might become less likely compared to a PDE that is located in a public area. The restricted area might have physical protections in place that let you control and identify who can access the PDE physically. Furthermore, network access could be limited, or less and less commonly, nonexistent. On the other hand, the impact of a successful attack could be higher in a restricted area and give access to a protected network.
These considerations should be documented in the Product Operational Environment of the Product Context, and they should include potential RDPS as described above. Where the RDPS operates, e.g., which cloud service provider, geographical location, network, shared resources with other services, etc., can influence the PDE’s functions that depend on it.
There are products, where the operational environment is largely unknown to the manufacturer, e.g., network routers or virtualization containers can be used in very different environments. It will not be sufficient, however, to simply state the operational environment as “unknown”. Fortunately, there are standards for network routers (ETSI EN 304 627) and virtualization containers (ETSI EN 304 635), among other PDEs (ETSI EN 304 6XX series), that can be taken as inspiration. These describe use cases for the most common scenarios, e.g., non-professional or professional use, and use as part of critical infrastructure. Even when the specific operational environment is unknown to the manufacturer, the answers to the questions “Will your product foreseeably be used in critical infrastructure?” or “Is your product intended for professional use?” usually are known.
Product Architecture Overview
The Product Architecture Overview shall give a visual high-level overview of the PDE’s components including RDPS, if applicable. For more complex PDEs, this can mean that components are physically distributed and communicate via a network or an RDPS. It should become clear which components are under the manufacturer’s control and whether a potential RDPS is operated by the manufacturer or a third party.
A natural representation of the product architecture is a data-flow diagram (DFD), which can then be extended and detailed as part of the threat modeling process. Other, custom or more product-specific representations can be chosen, however.
Product User Description
Finally, the product context shall describe the product’s end users. Will these be ordinary or trained persons? They might even be specialists? Any knowledge about the end users will influence the product’s risks.
This description shall not only include end users as the persons who use the installed product but any person who interacts with it, e.g., during installation, maintenance, and decommissioning. If the product is a component to be used as part of other products, e.g., hardware component or software library, there might be expectations placed on the integrator that need to be considered.
To broaden the scope a bit further, the product might be used by vulnerable groups of users which can include people with disabilities or temporary conditions, e.g., illness, stress or other distractions. It is therefore important to design the PDE not only for the ideal user, but to take these use cases into account to cover not only the intended purpose but also the reasonably foreseeable use mentioned above. Concerning accessibility, specific standards like EN 301 549 should be considered early in the development of a PDE, as they might introduce requirements or features that need to be considered in the risk assessment.
Summary
To summarize, the product context is the foundation for the risk management cycle under CRA. The team responsible for the product needs to agree and document the intended purpose and reasonably foreseeable use, the product’s functions, the operational environment, the product’s high-level architecture as well as end users of the product. Importantly, Remote Data Processing Solutions (RDPS) like cloud services are in scope of the product context.
Once the product context is documented, risk assessment can be performed. As this is a bigger undertaking, I will explain it in several upcoming blogposts.