The Internet of Things (IoT) is an exciting and emerging area of technology allowing individuals and businesses to make radical changes to how they live their lives and conduct commerce. Millions of Internet-connected devices are being deployed to help individual users and enterprises make their lives easier and accomplish tasks quicker and easier than they
The challenge with this trend is that IoT devices are just computers with sensors running applications. These computers arrive with built-in security flaws in their operating systems and the applications running on the devices are likely to contain additional security flaws as well. Because IoT devices interact with our personal lives – think fitness trackers – the proliferation of these devices exposes an unprecedented amount of personal sensitive data to significant risk. In addition, IoT security is not only about the code running on the device. These IoT devices are connected to systems that include supporting web services as well as other client applications that allow for management and reporting. IoT devices are only one part of an ecosystem of devices, applications, and services and the security of these components interacting with one another reflects the true security of the system.
A critical step to understanding the security of any system is to build a threat model. This helps to enumerate the components of the system as well as the paths that data takes as it flows through the system. Combining this information with an understanding of trust boundaries helps provide system designers with critical information to mitigate systemic risks to the technology and architecture.
The architecture diagram and trust boundaries for an IoT system threat model presented below are not specific to one technology, but instead is intended to capture the most common patterns seen in threat models for IoT systems. It is not intended to be comprehensive, but can act as a starting point and a template when starting to examine IoT systems.
Figure 1 Example architecture diagram with trust boundaries for an IoT system
The architecture diagram lays out the basic components of an IoT system – starting with the IoT device itself which communicates out to the broader Internet either directly, or via a local gateway. There are 3rd party services that may provide some sort of support to the applications running on the IoT device. The IoT device will communicate back to services hosted by the provider of the IoT system to accomplish whatever sort of back-end work is needed for the IoT device to do valuable stuff – placing an order for milk, uploading exercise data for analysis or whatever it is that the system is doing. Finally, there may be mobile and web applications that are used to configure the behavior of the IoT system as well as to view the results of what the IoT device is doing.
This is the IoT device itself. It consists of hardware likely running some sort of stripped-down operating system as well as sensors, drivers, at least one function-specific application, and some sort of local storage. From a security standpoint, the IoT device is important, but it is also critical to know that the security of the system as a whole depends on much more than the custom code – or operating system – running on the device. It is only one facet of a system that is much more complex.
Local IoT Gateway
Some IoT systems might rely on a site-specific gateway to help coordinate the behavior of one or more local IoT devices on a given site and their communication with various support services. Much like the IoT devices themselves, the gateway probably runs a stripped down version of an operating system and has communication capabilities to talk both with local IoT devices as well as remote services. It will also have some sort of local storage.
IoT Support Services
The IoT support services are deployed by the IoT vendor to provide back end capabilities for the IoT system. This likely involves managing configuration information and providing data storage and analysis services. These represent a large and potentially valuable target – data is concentrated here and that makes them attractive targets for attackers because a vulnerability exploited at this point in the system can potentially provide access to tremendous amounts of data across the various users of the system. Also they often have not received “adversarial” traffic – IoT device application developers are the only ones who have ever created requests to these services and service developers do not expect to see malformed or unexpected requests, which could expose vulnerabilities.
3rd Party Web Services
These represent any services provided by a 3rd party that help support the operation of the IoT device. These would be services run by someone other than the IoT provider but whose outputs are used to provide some of the valuable capabilities of the IoT system. These services can contain vulnerabilities as well as have other potentially negative impacts on the privacy of users of the IoT system because the IoT vendor does not have direct control over how data sent to the 3rd party services is used.
Many IoT systems have mobile clients that allow users to check the status of IoT sensors as well as provide configuration and direction for the behavior of the system. These IoT-supporting mobile applications share a common threat model with other mobile applications and need to be examined as with the other parts of the system.
Many IoT systems also have web clients that allow users to check the status of IoT sensors as well as provide configuration and direction for the behavior of the system. These web applications share a common threat model with other enterprise web applications.
The security of IoT systems can be exceptionally complex because of the large number of components, potentially extensive attack surface, and the interactions between different parts of the system. Threat modeling is a great starting point to understand the risks associated with IoT systems and how those risks can be mitigated, and this architecture diagram can provide a template and a starting point for further modeling of risks associated with an IoT system.