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

This post was originally published on this site

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:

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 informal 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.

view counter

David Holmes is an evangelist for F5 Networks‘ security solutions, with an emphasis on distributed denial of service attacks, cryptography and firewall technology. He has spoken at conferences such as RSA, InfoSec and Gartner Data Center. Holmes has authored white papers on security topics from the modern DDoS threat spectrum to new paradigms of firewall management. Since joining F5 in 2001, Holmes has helped design system and core security features of F5’s Traffic Management Operating System (TMOS). Prior to joining F5, Holmes served as Vice President of Engineering at Dvorak Development. With more than 20 years of experience in security and product engineering, Holmes has contributed to security-related open source software projects such as OpenSSL. Follow David Holmes on twitter @Dholmesf5.

Previous Columns by David Holmes: