IoT Threat Modelling

We hope that you’re finding the topic of security interesting, as well as a bit of a reality check! We’ve looked at how to develop a threat model and in this step, you’re going to learn about device security.

IoT Security

As you’ve seen in previous steps, planning for security in an IoT solution is essential but it can get complicated very quickly. IoT solutions involve data-collecting devices and cloud services such as storage and analytics, and can involve a lot of personal or sensitive data. These can present soft targets for hackers or those with malicious intent so understanding how a solution can be vulnerable is an integral part of any IoT architecture.

Intel, in their IoT Platform Reference Architecture document refer to asecurity layer in their architecture.

They describe it this way: ‘Robust hardware and software-level protection are essential for ensuring world-class security, which is a foundational IoT principle. Security is more like a process than a product because it depends on evaluating the threat model for specific use cases and addressing each possible threat. A layered security approach is highly recommended since it establishes multiple defense mechanisms against hackers.’

Let’s look more specifically at how this layered approach to security works in an IoT architecture.

Threat Modelling

When designing a system, it’s important to understand the potential threats to that system, and add appropriate defenses accordingly. The objective of threat modelling is to understand how an attacker might be able to compromise a system and then make sure appropriate responses and repairs are in place.

The movie The Big Short includes a quote which states ‘It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so’. In the context of IoT security, this means that we can get in the most trouble when we confidently assert that something won’t (or will) happen. Part of threat modelling is planning for the things you can’t plan for or anticipate. This might be as radical as taking a server offline or sending technicians to collect devices from the field if there’s a breach. But it could include less dramatic measures to ensure that data is safe and hackers are thwarted.

You should threat model the solution as a whole, and also focus on the following areas:

• The security and privacy features
• The features whose failures are security relevant
• The features that touch a trust boundary.

There are three rules of thumb to keep in mind when building a threat model:

• Create a diagram out of reference architecture.
• Start breadth-first. Get an overview, and understand the system as a whole before deep-diving. This approach helps ensure that you deep-dive in the right places.
• Drive the process, don’t let the process drive you. If you find an issue in the modelling phase and want to explore it, go for it! Don’t feel you need to follow these steps slavishly.

Threat modelling and IoT architecture

Microsoft’s guidance on threat modelling includes four main areas of focus. Each of these will have specific needs and involve particular threat vectors (ways the area can be attacked).

They include:

• Devices and data sources
• Data transport
• Device and event processing
• Presentation.

The diagram below illustrates an IoT architecture with each of these areas designated. The blue arrows indicate paths the data can take through the system. Whilst this looks complex, it’s important in a threat model to understand where your data is coming from and every possible place it can go. Missing just one path can create a serious vulnerability.

Attack Vectors to Consider

Again, an attack vector is simply a particular way that a hacker or person with malicious intent could compromise your IoT system. Microsoft documentation lists many possible options and we’ll summarise a few of the most important here.

1. Spoofing: Device spoofing takes place when an analogous device or virtual device takes the place of an intended device without the system knowing a switch was made. Spoofing can happen with services, APIs and other parts of an IoT system. Certificates can help reduce spoofing, but an IoT architecture should have mechanisms in place to ensure that the devices and services deployed to the solution are the ones you intend to be there.

2. Denial of service: Denial of Service (DOS) attacks are something we hear about in the news every so often because they can negatively affect our ability to reach a web site or service provider. One type of DOS attack involves overwhelming a service or device with garbage data or requests so the service or device can’t operate normally. Generally, a DOS attack is any hack where the device or service designed to perform a particular function is rendered useless. These types of attacks can prevent critical data from reaching a destination or enable hackers to attack other parts of an IoT installation.

3. Elevation of privilege: This type of attack causes a device or service that has a set of capabilities that are limited by permissions or function to function beyond their imposed limitations. For example, an automobile accelerator that has a mechanism that prevents the car from exceeding a certain speed. You can imagine an API or device that has permission to collect or store impersonal data being tricked into collecting or storing personal data that could cause harm if it got into the wrong hands, for example, credit card information.

As mentioned above, there are many other attack vectors to consider and a threat model should include mitigations for as many as possible.

A Secure Ecosystem

As you think about the security of an IoT solution, it can help to break down each aspect of the problem into functional categories. In the threat model we considered above, we saw four areas of focus. We can abstract these further to help us build a threat model. In an article for Network World, author Dean Hamilton echos the guidance that we’ll be looking at in this module. He recommends that IoT architects focus on securing devices, the network, and data. We’ll talk about security in three primary areas: devices, connection and communication, and cloud services. We’ll call this our secure IoT Ecosystem.

In the next three steps, we’ll look at each of these categories in turn.