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