Getting started with threat modelling and risk analysis

The CRA has quite a few concrete requirements, like automatic updates, secure-by-default systems, and so on. But what if you are developing a product where it seems clear some of the requirements don’t fit? For example, the CRA mandates automatically-installed updates by default, but what if the device you are developing doesn’t even have a network connection? Surely the CRA doesn’t force manufacturers to add internet connectivity to devices that otherwise wouldn’t need it, right?

No, it does not. The key concepts to understand whenever you are looking at CRA compliance are risk analysis and threat modeling. These are important practices for secure product development anyway, but doing a thorough threat model and risk analysis in the product design phase also reduces compliance costs, simplifies development, and makes post-release vulnerability monitoring much easier. If your device doesn’t have a network connection, you document this in your risk analysis/threat model, and then you simply do not have to consider attacks from a remote adversary.

What is threat modeling?

A threat model is a structured representation of all the entities, data flows, and boundaries that affect the security of a product. That is to say, it is a methodology for looking at your product and its environment from a cybersecurity point of view. For an introduction to threat modeling practices, there are a number of free and open resources that can help get you started.

• The OWASP Foundation’s Threat Modeling Project describes the process well, and links to more resources
• The Cloud Native Computing Foundation’s Security Technical Advisory Group has an excellent publication called Open and Secure - A Manual for Practicing Threat Modeling to Assess and Fortify Open Source Security
• OWASP Threat Dragon is a GUI tool for building threat models
• TARA (Threat Assessment and Remediation Analysis) is a risk analysis and threat modelling methodology common in automotive and industrial applications, and mandated by ISO/SAE 21434

How does the CRA mandate threat modeling?

The CRA specifically talks about threat modeling and risk assessment in Article 13, paragraph 2. The CRA’s preferred term is “risk assessment”; threat modeling is one type of risk assessment and a formal threat model should be sufficient to meet the CRA’s risk assessment mandates. The text on risk assessment is right at the beginning of the section listing the manufacturer’s obligations:

It’s also necessary for this analysis to take into account both intended uses of the product and “reasonably foreseeable” use, and should take into account risks across the entire product lifecycle:

Very importantly, paragraph 3 also tells us that a proper risk assessment allows the manufacturer to declare which of the specific product-related essential requirements are applicable to their product:

How does my threat model affect my obligations under the CRA?

All of your obligations under the CRA should relate to your threat model. If you are making a product that does not store or process personal information, for example, you may not require encryption at rest. Documenting that fact, i.e. that you have considered the requirement and determined that it is not applicable, is the measure you must take to avoid running afoul of an investigation by a regulator. If you do process personal data, your threat model should describe exactly how that data is encrypted, and why that addresses the reasonably foreseeable threats. You would likely choose to create an encrypted data partition, backed by the tamper-proof hardware-unique keys of your platform. Then, you can document how this is implemented (in the example linked above, by using Torizon’s built-in features), and why it prevents an attacker from gaining access to the data even if they physically de-solder the eMMC chip.

Choosing the most robust security options is not always necessary. If you do not need to consider physical access attacks in your threat model (for example, if the intended and reasonably foreseeable use of your product is always in a secure area with controlled access only for authorized personnel), you might not need to implement the strongest or best-in-class encryption for data at rest. You might be able to encrypt data on a per-user basis, using a key derivation function based on the user’s password. But as a rule, it’s better to choose the most secure baseline, even when you aren’t 100% sure you need it. If you choose less-secure solutions, you have more work to do in justifying why those choices are acceptable. So, if your hardware and software platform offer you strong security features, take advantage of them. And in general, it’s advisable to choose platforms with well-established hardware-backed security.

Conclusion and key takeaways

• Risk assessment and threat modeling are an absolutely necessary baseline for CRA compliance
• Threat modeling can begin before even one line of code has been written, but should be a continuous process throughout the product development cycle
• Risk assessment must be realistic: you can declare the intended use of your product, but you must also take into account “reasonably foreseeable” use. That means you can’t just declare that your product’s intended use is to be a doorstop and avoid all security obligations.
• Threat modeling helps reduce compliance costs, because you formally document what security measures are out of scope and don’t require development effort
• Choosing cheaper, less-secure options for hardware and software platforms can increase the cost of compliance; choosing platforms with robust security features from the start will accelerate development and avoid expensive redesigns or recalls down the road

If you would like to know more about the threat modeling and the risks, you can reach out to us. If you are using Toradex hardware and/or Torizon software and software updates, this becomes much easier, because we’ve done a large part of the work already.
Contact us to learn how!