Threat Modeling for IoT Devices Explained

The Growing Importance of IoT Threat Modeling

The growth of the IoT, through both legacy products with added connectivity features and new products coming to market, is creating a new age of opportunity where the data from connected devices will drive new services and business efficiencies to transform whole industries. However, as we become ever-more reliant on the data provided by these devices, we have an increased need to trust this data and prevent hacks that can manipulate the device or data. This trust is built upon right-size security in every IoT device.

The yearly PSA Certified Security Report, consistently finds that threat modeling is being under used by businesses. The numbers in 2023 show that only 40% are carrying out a threat model for every new product they bring to market. These stats are staggering when you consider that it’s one of the most useful tools for identifying security vulnerabilities.

In this blog, we will explore what IoT threat modeling is, how and when it should be carried out and how companies can be equipped to overcome the barriers of cost and limited expertise to ensure their products are built with security best practices from the ground-up. We cover the step-by-step process of threat modeling so trust can be built into every device that will fuel digital transformation.

Easing Security Analysis and Design

With no ‘one-size-fits-all’ solution to IoT security, we need to bridge the gap between the current applications of security best practices and the growing knowledge that they can’t be ignored. Added to this is the stark reality that smaller companies are taking bigger risks when it comes to security, we need to address the challenges that prevent security best practices; two of which are cost limitations and expertise/resource constraints.

What is Threat Modeling?

Threat modeling of a specific device and its use cases is the systematic process of identifying the sensitive assets, threats to those assets, and vulnerabilities that make the threats a necessary concern. The aim is to define security requirements that mitigate the threats and in turn protect the assets. Threat modeling guides the development of the necessary device architecture to ensure right-size security requirements for a specific device and its use case.

A device should be designed, manufactured, tested, and certified based on the threat model used to architect and design the device, saving costs further down the development process and ensuring trust is built in from the ground up.

When Should Threat Modeling be Carried Out?

A threat model should be created at the beginning of the product design to guide the architecture and design of a product. This ensures that the right security measures are mapped out before product development.

We have covered threat modeling in our foundational training course to make threat modeling accessible to everyone. In this module we cover threat modeling terminology, what threat modeling is and the benefits of completing a threat model.

How to Carry Out Threat Modeling

While there are multiple methods of threat modeling, the analysis is typically carried out by considering the topics outlined below:

• System definition. This includes an overview of the system, how it achieves its purpose and fulfills its use cases. Consideration must be given to any market-specific security requirements and any constraints or assumptions about the system in the target market.
  
  1. Describe the lifecycle of the system. This is a black box description (with no design/architecture details) that covers aspects like how the system is produced, configured, deployed, and how it reaches end-of-life, along with the various actors/entities involved in each stage.
  2. Describe each of the components of the system.
  3. Describe the fundamental operations of the system, typically placed in blocks in a pictorial form, and indicate the information flows from one block to another.

• Identify the trust boundaries. Identify the security or trust boundarieswhere security inside an object of analysis can be analyzed (analyzing the whole ecosystem is generally not viable) and define the trust relationships between the objects. Identify the information flow across the trust boundaries. The analysis must consider the system as implemented in its wider context, even if as a black box.

• Identify the stakeholders. A stakeholder is a person, group, or organization that places value in the system based on the critical assets. Typically, the list of stakeholders can be derived from market security requirements and the lifecycle of the system.

• Identify the critical assets to be protected. Identify the assets that need to be protected and the business reason that justifies their protection. The attackers can compromise key properties of assets like confidentiality, integrity, or availability. A stakeholder may not be interested in all properties of all assets so the relationship between the stakeholders and the assets should be considered. Assets can be the direct target of the attackers to compromise the system. However, some assets, for example, encryption keys, could be stepping-stones to the system being compromised.

• Identify attack surfaces. An attack surface is the sum of the different points (the “attack vectors”) where an unauthorized user can interact with the system. Examples of attack surfaces are input and output ports, APIs, and the side effects of computing such as timing, power consumption, and emissions. The attack surface is thus closely related to the security boundary. The attack surface depends on the threats and on the adversarial resources that are in the focus of the analysis.

• Create an adversary model. The adversarial model represents the levels of skill, capabilities, and resources that could be employed by an adversary to compromise the assets in the system. These are derived from the use cases, market security requirements, attack surfaces, and the adversaries that are expected to attempt to exploit the system.

• Identify all potential threats. Analyze the information flows over trust boundaries identified in the system description and examine the attack surfaces. The Microsoft STRIDE model, for example, can be applied on the attack surfaces and the use of attack vectors as a means to compromise an asset. Knowledge of adversarial models is important in this analysis.
  
• Risk assessment of identified threats. The likelihood of the threat must be determined. Then the impact of exploiting each threat on the system and organization must be determined. These two measures are combined to obtain the overall risk of the attack. NIST SP 800-30 Rev 1 provides a useful guide on this topic.

• Define the security functional requirements to mitigate the identified threats.
  1. Mitigating actions: Determine for each threat what should be done based on the risk. For example, reducing the threat to an acceptable level is necessary or accepting that it is not a risk, remove the feature that gives rise to the threat, or transfer the threat to a more suitable party.
  2. Mitigation: Typically, mitigations are captured at two levels; Security Objectives are high level descriptive goals to mitigate threats. Security Functional Requirements are low level prescriptive features or design techniques that must be implemented to achieve the mitigation expressed in the security objectives. 
  3. Residual risks may remain, and it may be necessary to go through the steps again.

Threat modeling results in documentation of the assets, threats, and counter-measures known in PSA Certified as Threat Models and Security Analysis (TMSA) document.

In our foundational training course, we cover four key methodologies for threat modeling: NIST Cybersecurity Framework, STRIDE, DREAD and ENISA.

Getting Started

PSA Certified provides resources to enable the IoT ecosystem to collaborate and take steps today to protect society tomorrow.

We offer three editable TMSA documents that can be used as a guide for threat modeling and can be adapted for specific use cases.

With clear measurement of security robustness for your device, you can choose the right components to meet your security functional requirements. PSA Certified offers objective measurement, and certification of silicon in three levels of increasing robustness; PSA Certified Level 1 that offers security best practice, PSA Certified Level 2 offering protection against scalable remote software attacks, and PSA Certified Level 3 with protection against hardware attacks, without the complexities and costs, and can focus on the differentiating features of your product.

In summary, it is clear that security analysis should not be missed in the design of connected devices. Threat modeling provides a systematic way to analyze and define security requirements that, when implemented, will mitigate the costs of security inaction. PSA Certified provides the resources to get started with your threat modeling, lowering the barrier to best practice security.