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 of these assessments: threat modeling.
IoT threat modeling is the activity of identifying and quantifying the security risks associated with an IoT product and its surrounding ecosystem. Ideally, threat modeling 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 modeling once the product is developed.
The output of threat modeling is the “Threat Model Chart” or “Threat Model Document”, which can be quite a dense document, but definitely a security belt towards future incidents, as well as a great input for future phases such as developing and testing.
Simple Threat Model Chart Skeleton[/caption]
How do we get there? The first step of threat modeling is to decompose the whole system in several pieces. When we talk about IoT, the number of pieces involved can be large and of a 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, the second step is for each of the pieces to carry out the actual threat identification.
Threat identification is basically the process of answering the question: “what could go wrong?”.
This can be achieved by 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 non-profit charitable organization focused on improving software security. 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 identifying 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 quite a 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, the third step is the threat qualification. The qualification will help with prioritizing the resources dedicated to mitigating 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 there to launch the attack?
- Affected users – how many people will be affected?
- Discoverability – how easy is it to discover the threat?
The sum of all scores will give the threat its total qualification, the highest ones being those where more effort needs to be put in.
And this takes us to the final and 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 the best class of engineers around you.
Next post we will talk about IoT equipment reverse engineering. See you there!
Article written by David Purón, Founder and Chief Executive Officer at Barbara IoT.