CRA Risk Assessment: From Product Context to Threat Modeling
Table of contents
The previous post introduced the Product Context as the starting point of Risk Management for the Cyber Resilience Act (CRA). Let us remember that Risk Management is a continuous cycle that assesses, estimates, treats, communicates and monitors the cybersecurity risks of a product with digital elements (PDE). In this post, we will contrast Information Security with Product Cybersecurity and look into Risk Assessment for a PDE, beginning with Threat Modeling. Risk Assessment is arguably the most challenging and complex part of the Risk Management cycle. On the upside, it is a real chance to build better products and feel more calm about cybersecurity.
Information Security Vs. Product Cybersecurity
One of the main causes of confusion when talking about CRA Risk Assessment is the difference between Information Security and Product Cybersecurity. So let us clarify!
Information Security, or Enterprise IT Security, is concerned with an organisation’s digital infrastructure like laptops, mobiles, networks, cloud services, etc. Its primary concern is usually keeping business data confidential (integrity and availability are also a concern of course). This is mainly done using processes, e.g., how user accounts are created and managed, and policies, e.g., that you may not connect your private smartphone to the organisation’s internal networks. Processes and policies are established in a systematic way using an Information Security Management System (ISMS). What an ISMS should look like is well-established, and the field of Information Security is quite mature in general. In Europe and Asia, ISO/IEC 27001 is the primary standard for ISMS, it has been around since 2005 and revised two times since. On the legal side, Information Security is mainly regulated by the NIS2 directive within the EU (which I have written about previously).
Product Cybersecurity is concerned with software, firmware and hardware that is put on the market and sold to organisations as well as end-users. Its primary concern is to design, develop, deliver and maintain secure products, including support of products already sold. This is done using processes like “Secure by Design” and “Vulnerability Reporting”, but compared to Information Security, these processes are more about engineering of digital products than organisational management, and this is regularly confused. The processes and policies required to consistently build secure products become part of a product company’s product development process. What a product development process for secure products should look like is still quite immature. Safety critical domains like industrial automation and control systems, automotive, medical devices or maritime have been regulated in the recent years, and standards like IEC 62443-4-1 and ISO/SAE 21434 have been around since 2018 and 2021, respectively. Their establishment in the industry is still maturing, however, and when it comes to products that are not safety-critical, cybersecurity is still an immature field. This immature field is the target of CRA. For the first time, CRA makes processes like the mentioned “Secure by Design” a legal requirement for virtually any product with digital elements sold in the EU.
Risk-Based Cybersecurity
Both Information Security and Product Cybersecurity have moved from checklist-based cybersecurity (“Do we have a firewall?”, “Do we implement secure boot?”) to risk-based cybersecurity. Which means that both perform risk assessments to decide how to protect the organisation’s IT (Information Security) or the user of the product (Product Cybersecurity). Organisations perform different kinds of risk assessments, e.g., of financial, regulatory, environmental risks, and Information Security risk assessment usually integrates well into existing risk management frameworks. Product Cybersecurity risk assessment usually does not.
In companies that already produce safety-critical products, e.g., automotive, medical devices or mobile machinery, product cybersecurity processes can be integrated well with product safety processes, even if there is a considerable learning curve when coming from functional safety. Companies that produce non-safety-critical products, however, have considerable challenges to establish product cybersecurity processes, because they often lack structured product development processes that are regularly seen as too costly, slow and inflexible.
Risk Assessment for Product Cybersecurity
Now that we know the context of Product Cybersecurity, we can take a closer look at the different steps of Risk Assessment. According to prEN 40000-1-2, Risk Assessment includes the steps of identification of assets and cybersecurity objectives, identification of threats, estimation of risks as well as evaluation of risks. In the following, I will group identification of assets, cybersecurity objectives and threats into Threat Modeling, which is the focus of this blog post. In my opinion, this more clearly reflects how these steps are done in practice, and it aligns better with Adam Shostack’s Four Question Framework that I will get back to further below.
It is worth noting that prEN 40000-1-2 intentionally leaves the methodologies used for risk assessment open (Clause 6.4.1 Note 3, highlight mine):
This document does not specify methodologies for a risk analysis. As long as the risk estimation is based on the likelihood of occurrence or exploitability and the magnitude of loss or disruption after a successful attack. Thus, different approaches and models such as the fishbone model, event tree analysis, fault tree models, attack feasibility ratings or attack potential considerations can be used within the analysis of risks.
To be honest, the choice of mentioned approaches is questionable, largely because several of them are classical safety engineering tools that struggle to model cybersecurity attacks. Maybe it is changed in the latest version of the standard, but this topic will require a longer discussion in a follow-up blog post. For now, we will focus on Threat Modeling.
Threat Modeling
Threat Modeling is a structured approach to identify threats to the cybersecurity of the PDE under analysis. The input to Threat Modeling for CRA is the Product Context defined in the previous step of the Risk Management cycle. According to prEN 40000-1-2, the PDE’s assets are an input to threat identification. Assets are anything of value in the context of the PDE, it could be data, intellectual property like algorithms, functionality and control, or hardware that we want to protect. Anything that we would care about losing confidentiality, integrity, or availability (CIA), is a potential asset. From my experience, asset identification and threat identification are quite closely related. Asset identification happens first, but might be revised during threat identification. They are often also performed on the basis of the same tool, a data flow diagram.
Let us unpack this a little with the help of Adam Shostack’s Four Question Framework that I mentioned above. At this point, the aim of threat modeling following prEN 40000-1-2 is to answer the questions of “What are we working on?” and “What can go wrong?”1. The common language for answering “What are we working on?” is a data flow diagram, or short DFD. A simple example is shown below, where the system is modeled using external entities that are outside of the control of the PDE but they are sources or sinks of data (rectangles). The model also includes processes that transform data (circles), data stores that hold data (parallel lines), data flows that move data (arrows), and trust boundaries that separate different levels of trust or privilege (dashed red lines).
Core elements and trust boundary in a Data Flow Diagram (DFD)
Modeling a system as a DFD can take quite a bit of time but also generate new insights, including what the actual assets of the systems are. I have previously gotten the comment “We never had this kind of overview.” when doing threat modeling with a team, and going through this exercise is usually much appreciated by developers, product owners and managers. It gives the team an abstract, shared mental model of what the product is and what it is doing. Especially in times of agentic coding, a shared mental model is not always easy to maintain but threat modeling is a great way to do it.
Several DFDs can be created for different views of the system, e.g., default operation or maintenance. The DFDs are also extremely helpful to answer “What can go wrong?”, or in terms of prEN 40000-1-2, identify threats. This is where, e.g., the popular technique STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) comes in. There are different techniques that can be used, and even STRIDE can be used in different ways, but one possibility is to go through each of the data flows and think about each potential attack. Data flows that cross trust boundaries can be of special interest: looking at the communication between External Entity and Process, can the External Entity be subject to Spoofing? I.e., are we protected against someone pretending to be External Entity? Maybe we do not have adequate encryption on this link and Information disclosure is a possibility? When going through these kinds of questions, the team will usually gather a number of threats that will then be evaluated as part of the Risk Estimation, which is the next step of Risk Assessment.
This is of course a very short representation of threat modeling. The definite guide can be found in Adam’s book on this topic which is due for a second edition in early 2027. Apart from applying STRIDE and thinking hard about how the PDE could be attacked, relevant threat catalogs like MITRE EMB3D™ or the upcoming EN 40000-1-4 can be used to consider common threats to similar systems. In any case, the goal of this exercise is to obtain a list of threats to the identified assets of the PDE, which can be evaluated to identify risks for the end-user of the PDE.
Summary
In summary, product cybersecurity is an engineering challenge that cannot be solved by an IT policy. Many companies will face the challenge of establishing effective engineering practices that result in secure and compliant products. In any case, the way to compliance (and better products!) starts with a rigorous Risk Assessment under CRA.
We started to have an overview of Risk Assessment with looking at Threat Modeling. Data Flow Diagrams (DFDs) help teams to visualize the system, have a common mental model and shared understanding of what the system does. Frameworks like the popular STRIDE help to identify threats. Once a list of threats to the PDE’s assets has been identified, we can move to evaluating them as part of Risk Estimation, which is the topic of the next blog post.
Adam Shostack also includes “What are we going to do?” and “Did we do a good job?” during threat modeling but I mention them separately to more clearly map to the risk management of prEN 40000-1-2. ↩︎