CRA risk assessment
In this post we discuss CRA’s risk assessment requirement and provide a simple process for it. Related to this, CRA’s Annex I states “(1) Products with digital elements shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks” and further “(2) On the basis of the cybersecurity risk assessment referred to in Article 13(2) and where applicable, products with digital elements shall: [list of essential requirements]”. So, you must assess the risks related to your product and then use that information in the conformance evaluation of the CRA’s essential requirements.
First we present a simple approach for the risk assessment. If you are using some other risk assessment methodology, that is fine, as CRA does not dictate any specific process. Our risk assessment process has three steps:
Define risk assessment scope
Identify the assets the product protects
Enumerate the risks
In this post we assume you are going to verify your product against the CRA essential requirements listed in Annex I. If you are going to use some other security standards, then check first what it requires for risk assessment. However, the principles presented here should be fairly universal.
Test of Things’ 3-step process for risk assessment
Intended purpose of the product
The starting point of risk assessment is the intended purpose of the product, which we mentioned in the previous blog post. This tells us about the criticality of the product function and the types of risks expected during the product’s use. For example, a smart lock has a different reliability and risk profile compared to a smart lamp. For the smart lock, risks could include unauthorised physical access to premises, or safety risk if a person is locked in or out. For the smart lamp, risks are more limited. Both can be used as a beachhead to attack internal networks and possibly as nodes in denial-of-service attacks.
The risk assessment must also accommodate reasonable foreseeable use and misuse of the product, not just the intended use. You cannot “check away” risks by foreseeable use of the product by omitting them from intended use. For example, sharing an account with family members or installing a device to an open network are foreseeable events. This means that you must estimate how your product is going to be used and misused, perform risk assessment, and ensure that the security measures are sufficient.
Operating environment
The operating environment where the product will be deployed brings its own risks. This includes the exposed attack surface and the external services which your product uses and is dependent on, which we discussed in the previous blog post. Note that also remote data processing solutions, e.g. cloud servers, are considered part of your product if they are in your direct control and required for product operation. In this case, they also must meet the CRA essential requirements. However, remote systems which the product uses, but are not in your control, are dependencies which you still have to include in the risk assessment. In the risk assessment scoping, you can use the product boundaries and external dependencies we discussed in the previous blog post.
Support period
CRA explicitly mentions the intended product lifetime as one factor to risk assessment. CRA requires a support period matching the product's expected use time, with five years as the minimum floor. Considering the frequency of publicly reported software vulnerabilities, you must assume exploitable vulnerabilities are revealed during the product lifetime. Basically you need a mechanism to update software through its intended lifetime.
Assets
Once you have established the foreseeable use and misuse cases and identified the external environment, including dependencies, you should list the assets the product should protect. An asset here can be data or function. Some examples of assets you should consider:
User data (personal, behavioural, location, health, etc.)
Device functions (what the product does, including any physical effects)
Keys, tokens, and other secrets required for security controls
Logs for auditing and incident response
Risk enumeration
Now you have the required information to enumerate the risks. Risks are usually due external factors such as intrusions, data leaks, or incidents and failures in the dependencies. For each risk you should consider how it impacts the assets or environment. You may selectively include risks related to failures in your own product, e.g. key material is not properly protected, but avoid confusing risk assessment to essential requirement evaluation. Keep the process clear by first considering risks from external factors and then evaluating the product’s security posture.
A straightforward approach is to describe each risk by likelihood and impact. Likelihood is estimated frequency for the realization of the risk. Impact is the consequence of risk realizing for users, stakeholders, or more broadly for the environment and society. If you enumerate likelihood and impact by numbers 1-3 (low, medium, high) you get severity by multiplying likelihood and impact. This severity is a number between 1-9. This gives you a prioritized list of risks and concludes your risk assessment.
Risks give you the foundation for tasks that follow. In the next blog posts, we go through CRA’s essential features and check whether the product's design adequately addresses the identified risks. Not all essential requirements necessarily apply, if there are no relevant risks to mitigate. Risks that cannot be mitigated may require changes to the product's design, functionality, or even its defined intended purpose. Note that CRA does not permit residual cybersecurity risk to be accepted for reasons like development schedule or cost.
Finally, the risk assessment is not a one-time document. It must be kept updated throughout the product's support period as the threat landscape and product evolve.
