Last week we talked about the importance of doing third party security assessments when designing an IoT product. In this second post of the series we will talk about the first phase on these assessments: threat modelling.

IoT threat modelling is the activity of identifying and quantifying the security risks associated with an IoT product and its surrounding ecosystem. Ideally, threat modelling should be done during the product design phase in what experts call “security by design”. Although it might sound obvious, is very common to find companies that elaborate their risk assessments and threat modelling once the product is developed.

The output of threat modelling is the “Threat Model Chart” or “Threat Model Document”, which can be a quite dense document, but definitely a security belt towards future incidents, as well as a a great input for future phases such as developing and testing.

Simple Threat Model Chart Skeleton

How do we get there? The first step on threat modelling is to decompose the whole system in several pieces. When we talk about IoT, the number of pieces involved can be large and of different nature:

  • Hardware modules
  • Firmware/operating system of the IoT device
  • Software running on the IoT device
  • Networking interfaces and protocols
  • External applications for user interfacing with the IoT device, such as a mobile app
  • Cloud and third party APIs interacting with the devices

Once the pieces under analysis have been identified, second step is for each of the pieces do the actual threat identification.

Threat identification is basically the process of answering the question: “what could go wrong?”.

This can be achieved using traditional methodologies such as STRIDE. However, we prefer a more practical and less subjective approach based on the identification of IoT industry frameworks and checklists. There are a number of them, but two that we particularly like and support are:

  • OWASP: The Open Web Application Security Project is an industry worldwide not-for-profit charitable organization focused on improving the security of software. Since its creation in 2001 they have published several guidelines and tools which compound the bible for many web application security analysts. In 2014 OWASP created the IoT project that is focused on identyfing IoT attack surfaces and vulnerabilities.
  • GSMA: The GSM Association, a historical alliance of mobile carriers, has also put its eyes on IoT security. They have developed a quite comprehensive set of IoT security guidelines and its reading can definitely set up a good base to identify IoT threats

Matching both OWASP and GSMA identified threats against your IoT product design can be a good practical exercise to understand what could go wrong.

Now you have a good number of threats identified for each of the components, third step is the threat qualification. The qualification will help on prioritizing the resources dedicated to mitigate each of these risks. An easy methodology for this could be DREAD that gives a score (e.g. 1 to 3) to each threat on five specific categories:

  • Damage – how bad would an attack be?
  • Reproducibility – how easy is it to reproduce the attack?
  • Exploitability – how much work is it to launch the attack?
  • Affected users – how many people will be impacted?
  • Discoverability – how easy is it to discover the threat?

The sum of all scores will give the threat the actual qualification, being the highest ones those where more effort needs to be put.

And this takes us to the final fourth step on threat analysis, protection design. Now you need to decide how to be protected against each threat, and identify those methodologies and technologies that will reduce the possibility and impact of a given threat . There is no methodology for threat protection design other than having best of class engineers around you.

Next post we will talk about IoT equipment reverse engineering. See you there!