Security Experts:

Connect with us

Hi, what are you looking for?



Threat Modeling the Internet of Things Part 2: Three Steps to Pizza

Part 1 of this series posited that the Internet of Things (IoT) needs a more rigorous security application than it currently has, lest we end up building another patchy, vulnerability-ridden system like the Internet we have now.

Part 1 of this series posited that the Internet of Things (IoT) needs a more rigorous security application than it currently has, lest we end up building another patchy, vulnerability-ridden system like the Internet we have now. And if one were to dismiss the Internet of Things as a consumer-only problem, remember that IoT isn’t just for consumers, it also spans enterprise, industrial, and government. 

One way to apply security to the development of any system is through the process of threat modeling. A threat model assessment (TMA) brings together system designers and security experts to:

1. Catalogue the assets in play

2. Identify potential threats

3. Score the threats vs. the assets

Sounds complex, right? It doesn’t really have to be, and when done with the right attitude and the right people, it can be inspiring and, gasp, even fun. Let’s have a look at the mechanics of threat modeling, and then drop some tips about how to initiate a new threat model program.

Step One: Catalogue the Assets at Play

For an Internet of Things project, the scope of the assets includes not just the device itself, but all the systems that the support that device.

A typical IoT project has an architecture that looks something like this: A group of “things,” some with read-only sensors and some with controls, communicate through a controller node. That node then publishes data through a local network or a public or private cloud. Within the cloud are data-collection nodes, processing and analytics, and maybe a web application to interface with the project. Lastly, sometimes there are tablets and tablet applications to interface with the web application or the controller. Like this:

IoT Architecture Design

An organization with a mature security process should already be doing threat modeling on their web applications and cloud stuff. In that case, a new threat model could be applied to just the device and the controller. But, many new IoT vendors and startups don’t have mature programs and should threat model the whole enchilada. One bite at a time, if necessary.

Now, you’re in luck, because other security pros have already taken a stab at this. The OWASP IoT Project page identifies many of the assets of an IoT system.

Device Threat Surface Ecosystem Threat Surface
Device Memory Ecosystem Access Control
Device Firmware Ecosystem Communications
Physical Interfaces Administrative Interface
Device Network Services Cloud Web Interface
Local Data Storage Vendor Backend APIs
Device Web Interface Third Party Backend APIs
Update Mechanism Mobile Application

Consider each of these threat surfaces and identify the assets within your project. List them as part of your threat model assessment.

Step Two: Identify Potential Threats

You’ve gotten lucky, again. Many potential threats are already known; you just have to apply them to your project. One of the early “models” in threat modeling is STRIDE threat classification. The STRIDE acronym is designed to help you remember to ask these questions:

• (S)poofing – can an attacker pretend to be someone he’s not?

• (T)ampering – can an attacker successfully inject tampered data into the system?

• (R)epudiation – can a user pretend that a transaction didn’t happen?

• (I)nformation Disclosure – is the application leaking data to outside parties?

• (D)enial of Service – how can the application be shut down maliciously?

• (E)scalation of Privilege – can users gain superuser powers?

Many commonly known attacks such as the Man-in-the-Middle attack or the Replay attack fall into these classifications. 

In step two, your threat model team (which can be a virtual team, of course) brainstorms as many of these threats as they can think of for each asset while a moderator writes everything down. Try to keep this step as a brainstorm-y as possible—keep the group thinking about threats and not mitigations. Don’t let value judgements appear here. If someone says, “That’s not likely to happen!” or “Hmm, we could fix that by…,” keep them on track by saying, “We’re just brainstorming here. The next step will be scoring, and the final step is mitigation.”

Step Three: Score the Threats versus the Assets

Once all of the threats have been brainstormed and recorded, it’s time to score them. Go back through the list and determine a risk assessment for each threat. Choose an ascending numbering system of 1-3, 1-5, or 1-10 where 1 is the least bad. Then use the DREAD acronym to give scores to each of these variables:

• (D)amage – how much damage could this threat cause?

• (R)eproducability – how reproducible is this threat?

• (E)xploitability – is this a boundary condition that is unlikely to be exploited?

• (A)ffected Users – are all users affected? Some? Or just a single user?

• (D)iscoverability – what is the likelihood that this threat would be discovered?

DREAD is an old scoring system; many modern practitioners always assume a maximum value for Reproducability and Discoverability. This is because the whole cottage industry of zero-day markets and, to a lesser extent, bug bounties, have taught researchers and attackers to invest time both discovering and “weaponizing” vulnerabilities. You should assume that if a vulnerability exists, someone will find it and figure out how to make it happen every time.

Threat Modeling the IoT—with Pizza

If you’re setting up a threat modeling system, here are some i
nformal tips.

• Remember that you’re analyzing threats and assets, not people. 

• Don’t use the second person (“you”) as in saying things like, “You’re doing it wrong.”

• Have a kickoff luncheon where you model something politically safe (like a doghouse or a competitor’s product), and bring pizza.

The next article in this series will take a real-world IoT project example and run it through the STRIDE and DREAD classifications to show you how you can threat model your own Internet of Things project.

Written By

Click to comment

Daily Briefing Newsletter

Subscribe to the SecurityWeek Email Briefing to stay informed on the latest threats, trends, and technology, along with insightful columns from industry experts.

Join this webinar to learn best practices that organizations can use to improve both their resilience to new threats and their response times to incidents.


Join this live webinar as we explore the potential security threats that can arise when third parties are granted access to a sensitive data or systems.


Expert Insights

Related Content

CISO Strategy

Cybersecurity-related risk is a top concern, so boards need to know they have the proper oversight in place. Even as first-timers, successful CISOs make...


The overall effect of current global geopolitical conditions is that nation states have a greater incentive to target the ICS/OT of critical industries, while...


Cybersecurity firm Forescout shows how various ICS vulnerabilities can be chained for an exploit that allows hackers to cause damage to a bridge.


Otorio has released a free tool that organizations can use to detect and address issues related to DCOM authentication.


More than 1,300 ICS vulnerabilities were discovered in 2022, including nearly 1,000 that have a high or critical severity rating.

Cybersecurity Funding

Internet of Things (IoT) and Industrial IoT security provider Shield-IoT this week announced that it has closed a $7.4 million Series A funding round,...


Siemens and Schneider Electric address nearly 100 vulnerabilities across several of their products with their February 2023 Patch Tuesday advisories.


Wago has patched critical vulnerabilities that can allow hackers to take complete control of its programmable logic controllers (PLCs).