Five steps to successful threat modeling

The Internet of Things (IoT) is changing the way we interact with the world around us. Over the next few years, billions more connected devices will enable us to drive efficiency, boost productivity, and enhance comfort and convenience in our personal and professional lives. And we’re not the only ones to see the potential of this market.

IoT devices are the target of increasingly sophisticated cyberattacks and innovators must protect their assets and their customers from these emerging threats. In a time- and cost-sensitive environment, security can be mistakenly added later as an afterthought. But that approach puts individuals, organizations, and vital infrastructure at risk.

Simplifying security
To meet the challenges of operating in this ever-changing and connected world, security can no longer be considered a separate component. It must be embedded in every element and process, starting with the product development phase. Arm’s Platform Security Architecture (PSA) framework simplifies this activity and makes it quicker and easier to build a secure device.

Arm PSA is divided into three stages: analyze, architect and implement. The first – analyze – is discussed in detail in this blog.

Identifying the right level of security for your device
To design-in security, Arm PSA recommends developers and manufacturers start by analyzing the operating environment and understanding and documenting the ways each device could be attacked. It is a process known as Threat Models and Security Analyses (TMSA), or an English Language Protection Profile, and it has been used in the mobile industry for some time but is rarely carried out in the IoT space.

The TMSA will highlight critical issues you need to address and challenge you to consider important questions, such as:

– What are your most valuable assets?
– What are the potential threats to your device?
– What type of attack do you need to protect against?
– How severe are the threats?
– What counter-measures could you implement?
– What are your security requirements?
– How does your device meet your security requirements?

This process will help you decide how robust your security needs to be and what, exactly, you need to do to protect your IoT product. Rather than slowing down development, it will help you determine the right level of security for your device, which means you will not be over-spending or exposing your device, your organization or your customers to unnecessary risk.

Who will benefit from Threat Models and Security Analyses (TMSA)?
You can apply the methodology to any device, from simple, low-cost or even disposable applications, through to the most advanced edge and gateway devices.

The TMSA documentation is intended to make threat modeling more accessible to all, so you can secure your device even if you do not have access to dedicated security knowledge or expertise.

5 steps to design security into your next IoT device

Now we will take you through the TMSA process step-by-step to help you determine your security requirements. We are using a smart speaker, such as one you may have in your home, as a basic example but more detailed analysis of common IoT use cases, including an asset tracker, water meter and network camera, can be downloaded from our website.

1. Analyze use case, define the external entities and the assets to protect

Analyze the use case, or target of evaluation

The first step in designing-in security is understanding the ecosystem your device operates within and identifying your use case – known as the target of evaluation (ToE) in the TMSA documentation. The use case is the product or the system that is the subject of the security evaluation.

In the example of the smart speaker, you can start with the device itself and the application that acts as the user interface. There will be cloud services that enable the device, plus a number of third parties who are creating content for you. If the speaker is being used in a home environment, there may be music, shopping, news, voice assistant or home automation applications. In a business or industrial setting, the applications may be targeted to provide information or services relevant to your sector.

Once you have an understanding of the use case, you can then develop a list of the main components of your device that need to be protected.

Assets
Attackers will be targeting the assets in your device in the same way as a thief who breaks into your home may be searching for jewelry or cash. So, you need to identify the assets or data that will be of most interest to them.

If we return to the smart speaker example, the assets we may need to protect include:

– Firmware
– Certificates and device-unique keys
– Log-in credentials (user or admin)
– System configurations (to ensure your IP cannot be compromised or control taken away)
– Event logs
– Voice recordings
– Network communication
– Device resources (for example: microphone array and speakers, computing power and battery, network bandwidth, debug interface, storage)

Your list of assets may not be exhaustive, but it will include the assets or data of most value to you and your customers.

External entities
To develop your understanding of the threats to your device you also need to identify users and external entities that would interact with the product. This may include legitimate users, for example, the owner of the device or the virtual system administrator, but it should also extend to potential attackers or adversaries looking to gain access or control of the device.

Step 1 checklist

✔️Analyze the use case, or the target of evaluation (ToE)
✔️Identify your most valuable assets
✔️Identify users and external entities

2. Identify potential adversaries, the attack surface and threats

Potential adversaries
It helps to know who may be working against you. A generic adversary model groups attackers in five categories and can be used to identify potential adversaries:

• Remote software attacker: Most attacks fall into this category.
• Network attacker: For example, a man-in-the-middle attack, where communication between two parties is intercepted by an attacker.
• Malicious insider attacker: This is often overlooked but has potentially serious consequences. It could be a disgruntled employee inside your organization, or part of an OEM, an ODM supply chain or a silicon vendor.
• Simple hardware attacker: This assumes the attacker has physical access to your device and can connect a USB dongle, debug port, voltage/current measurement, port scanner, etc.
• Advanced hardware attacker: Advanced hardware attackers have unlimited resources and require physical access to the device. They will often deploy very sophisticated attacks, using specialized equipment, including ion-beam lithography or microscopy probing.

The attack surface
By this stage in the process, you know what you need to protect and who has the potential to attack. Now, it is time to consider your vulnerabilities, which Arm split into four main categories: communication, lifecycle, software and physical (also known as hardware). These categories act as entry points to your device and offer a way-in for attackers. Potential vulnerabilities should be identified for each of the four main categories and will depend on the type of device you are designing or manufacturing.

Threats
Now, you can apply your threat model, and in this case, we have used the STRIDE model against each entry point to determine your security threats. STRIDE stands for:

– Spoofing identity
– Tampering with data
– Repudiation
– Information disclosure
– Denial of service
– Elevation of privilege

It helps you identify and classify the threats to your device.

You can apply the STRIDE model to each entry point.

The above diagram shows potential attack surfaces for a smart speaker. If we take the user interface as an example of an entry point, potential communication attacks via voice commands could include:

– Spoofing, that is, an unauthorized person masquerading as the legitimate user to access the device.
– Escalation of privileges, or an attacker who is trying to breach the voice ID authentication to be identified as legitimate user to place an online shopping order.

However, in the example of network connecting with cloud server, the threats we may consider include:

– Spoofing, again, that is illegally accessing the device to use the victim’s authentication information.
– Tampering with the data, for example, intercepting it as it leaves the device.
– Information discloser, whereby information, such as user credentials are released that should remain confidential.
– Denial of service to valid users. This can threaten availability and reliability or temporarily disable a device.
– Escalation of privileges, or an attacker who is trying to log in as an administrator to gain access or control of the device.

You can apply STRIDE to all entry points to help you identify the threats to your device – including threats from hardware attacks, for example exploiting debug interface or tampering of local storage, as well as software and lifecycle attacks, as illustrated in the attack surfaces diagram above.

Now you have identified your vulnerabilities and your threats, you can then consider how the threats directly affect each of your assets identified earlier in the process, using the STRIDE threat model as your reference. An example, based on a smart speaker, is included below.

But how does this affect you and your customers? And how do you design the right level of security into your device?

The severity of an attack
Assessing the severity of the attack will enable you to allocate your resources appropriately. We suggest using the common vulnerability scoring system, CVSS, to consider the impact of the threats you have just identified. CVSS uses scores of between zero and 10 to help you understand how an attack would affect your device and your customers.

For example, a CVSS score of 9.0-10 should be where you focus your attention and resources because the impact of an attack would be severe.

This will help you to ensure your device has the right level of security built into it.

Step 2 checklist

✔️Identify your adversaries
✔️Understand the attack surface
✔️Identify potential threats
✔️Determine the severity of the threats

3. Identify high-level security objectives to address threats

In this section we are looking to set security objectives that seek to maintain six security elements:

– Confidentiality
– Integrity
– Availability
– Authenticity
– Secure lifecycle
– Non-repudiation

The risk to each element will depend on the type of attack launched. To explain further, using the STRIDE threat model, you can determine that a spoofing attack may affect authenticity, while a tampering attack may impact the integrity of the device.

Using this information, and the knowledge you have developed about the severity of a potential attack, you can now determine what you need to do to address the threats, and the counter-measure that you will employ.

Returning to the smart speaker example, the high-level security objectives may include:

• Secure identity
• Secure boot and firmware upgrade
• Secure audit
• Secure storage and binding
• Defense in depth
• Secure lifecycle management

The below diagram further illustrates how the STRIDE threat model is mapped to specific counter-measures. For example, secure identity is a major counter-measure for spoofing (S) threat to protect ToE’s authenticity.

Step 3 checklist

✔️Determine the impact of an attack on each security element
✔️Identify counter-measures
✔️Identify high-level security objectives

4. Define security requirements for each security objective

As a silicon partner or OEM you need more information. You need to know what to implement, so the high-level objectives you identified should be analyzed further to create specific security requirements that will directly target your threats.

For example, from a high-level objective of ‘secure identity’ you can determine that you need to maintain roles and authorization and trusted communication channels, secure remote management and set failure threshold limits.

Step 4 checklist

✔️Breakdown high-level objectives into more specific security requirements
✔️Determine what you need to do to meet your security requirements

5. Consolidate all information into a threats summary table

All of the information you have gathered so far can now be consolidated into a threats summary table. You should create a separate summary table for each of the assets you identified earlier. The following example covers just one.

The table will help you clearly see the potential impact of an attack and how you can address each threat.

Now work through the TMSA documentation to identify potential threats to your own device and determine your security requirements. Here are more examples to help you get started.

Step 5 checklist

✔️Create a threats summary table by consolidating all of the information gathered so far
✔️Translate into primitives

Additional resources
Earlier this year, we developed three detailed examples that analyze common IoT devices (a smart water meter, a network camera and an asset tracker) and guide you through the entire TMSA process.

The TMSA documents are freely available and accompanied by a summary of the Arm TrustZone and CryptoIsland technology that can be used to meet your security requirements. As well as providing advice on specific devices, the documents can also be used as a reference tool, so you can carry out your own security analysis on a different product.

Continuing the security journey
The Threat Model and Security Analysis (TMSA) is just the first of three stages in Arm’s Platform Security Architecture (PSA). Arm PSA has been designed to be a common foundation, which is easy to follow, and to demystify security designs and concepts. It draws and builds upon best practice from across the industry and is aimed at different entities throughout the supply chain, from chip designers and device developers to cloud and network infrastructure providers and software vendors.

After you have completed your TMSA documentation and established your security requirements, the next step is to put them into action.

Stage 2: Architect
This stage of the PSA includes architecture specifications for firmware and hardware.

Stage 3: Implement
This gives you access to high quality reference code and documents.