Last year, I posted three blogs about IoT security which proposed an initial approach and template for how to architect a reasonably secure IoT landscape, which you can find here. Time moves quickly in IoT, though, and it is time to share more recent research in this area.
The point of view presented in those blogs, and in the TechEd presentation you may have attended, was based on applying long established information security principles to IoT landscapes, and I still believe that main principle is still valid. But customer feedback and conversations with other security professionals made it clear that we have more work to do.
I will share a paraphrased quote from a customer that makes the point:
IoT is moving ahead regardless of what security experts say and do. While security is certainly considered up front in a way that we have rarely seen in more traditional IT, device and device platform selections are made based on a wide variety of criteria, including the nature of the use case, the physical aspects and constraints of the environment edge components are located in, the connectivity options and desired life time of the device and how easy or not it is to service it. The main feature, therefore, of IoT edge infrastructure is that it tends to be highly heterogeneous and varied, and often will include equipment from a wide variety of suppliers and capabilities.
This certainly complicates the effort in keeping such an environment secure.
To get a grip on this problem, it seemed appropriate to start by threat modeling such a landscape of various device classes. Threat modeling is an approach to analyze the application or landscape for potential threats, from an attacker's point of view and see where the weaknesses might be, and how an attacker might gain access, steal or manipulate the assets that are managed by the system. Threat modeling is a standard component now in SAP's Secure Software Development Lifecycle.
The threats that are considered are the following, whose initial letters make up the STRIDE mnemonic:
The repudiation threat, by the way, is an interesting one in IoT, since there isn't a human actor involved. I do think it is relevant in IoT, though, as an outcome of the use of predictive modeling. Since it is often hard to trace back the way a data feed trained a predictive model, an audit trail is still highly relevant. Admittedly, in many cases, though, this will be in combination of either spoofing or tampering threats.
We focus here on the edge infrastructure, and for that, I modeled five device classes. More are certainly possible, but as you will soon see, this already very quickly gets very complex:
The result can be seen in the diagram below:
For our purpose, the main application environment and platform is out of our scope of analysis. They are of course important, but not the primary focus here. The web front-end for human users is modeled (and is important) but is also not part of our considerations. The attention here is on the different edge device classes.
Threat models can be a bit difficult to read without context. You can see a bit more here about how to interpret threat models based on the Microsoft format. SAP uses TAM diagrams, but otherwise largely follows the Microsoft approach. Most importantly, dashed red boxes and lines denote trust zones, and each connection that crosses a trust zone potentially has one or multiple threats associated with it.
You can see the first four device classes on the left below each other. The OT environment is center bottom. We also see our solution-specific DNS and Device Certificate Authority, which we discussed before in earlier articles. All device classes communicate with the end point gateway where we ingest the data (and potentially send commands back to the edge).
When initially modeled in the Microsoft Threat Modeling Tool, this resulted in 237 identified threats... I wouldn't use this figure beyond getting a sense of scale of how complex this really is, but it illustrates that there is a lot going on in such a landscape.
Talking through a complex model like this is hard. Therefore, in subsequent blogs, we will dive into the details of this diagram by looking at the various device classes separately, first covering the 32-bit device classes, followed by microcontrollers, and finally the OT networks.
Part 2: general computing devices
Part 3: microcontrollers
Part 4: SCADA/ICS
The point of view presented in those blogs, and in the TechEd presentation you may have attended, was based on applying long established information security principles to IoT landscapes, and I still believe that main principle is still valid. But customer feedback and conversations with other security professionals made it clear that we have more work to do.
I will share a paraphrased quote from a customer that makes the point:
Jay, this is great, and if I had full control and could make all the decisions about device infrastructure, I could actually adopt your template. Unfortunately, that is not the reality I live in.
IoT is moving ahead regardless of what security experts say and do. While security is certainly considered up front in a way that we have rarely seen in more traditional IT, device and device platform selections are made based on a wide variety of criteria, including the nature of the use case, the physical aspects and constraints of the environment edge components are located in, the connectivity options and desired life time of the device and how easy or not it is to service it. The main feature, therefore, of IoT edge infrastructure is that it tends to be highly heterogeneous and varied, and often will include equipment from a wide variety of suppliers and capabilities.
This certainly complicates the effort in keeping such an environment secure.
To get a grip on this problem, it seemed appropriate to start by threat modeling such a landscape of various device classes. Threat modeling is an approach to analyze the application or landscape for potential threats, from an attacker's point of view and see where the weaknesses might be, and how an attacker might gain access, steal or manipulate the assets that are managed by the system. Threat modeling is a standard component now in SAP's Secure Software Development Lifecycle.
The threats that are considered are the following, whose initial letters make up the STRIDE mnemonic:
- Spoofing
- Tampering
- Repudiation
- Information disclosure
- Denial of Service
- Elevation of privilege
The repudiation threat, by the way, is an interesting one in IoT, since there isn't a human actor involved. I do think it is relevant in IoT, though, as an outcome of the use of predictive modeling. Since it is often hard to trace back the way a data feed trained a predictive model, an audit trail is still highly relevant. Admittedly, in many cases, though, this will be in combination of either spoofing or tampering threats.
We focus here on the edge infrastructure, and for that, I modeled five device classes. More are certainly possible, but as you will soon see, this already very quickly gets very complex:
- "Dumb" 32-bit+ device: these are full "general computers" that typically run Linux, but are primarily communicating in a single-direction: read a value, transmit the value to our end point
- Smart/Edge Processing 32-bit+ device: also still running Linux (or a gateway OS) most likely, but likely aggregating data from multiple devices, or batching readings after initial analysis, before sending on to our end point. This will require a writable file system and often requires bi-directional communication
- GSM/telephonic connected 32-bit+ device: any device as 1. or 2. but where the communication channel is through a mobile phone network
- Microcontrollers (typically < 32-bit) communicating over low-power networks
- SCADA/ICS, PLC systems, i.e. OT environments, industrial systems
The result can be seen in the diagram below:
For our purpose, the main application environment and platform is out of our scope of analysis. They are of course important, but not the primary focus here. The web front-end for human users is modeled (and is important) but is also not part of our considerations. The attention here is on the different edge device classes.
Threat models can be a bit difficult to read without context. You can see a bit more here about how to interpret threat models based on the Microsoft format. SAP uses TAM diagrams, but otherwise largely follows the Microsoft approach. Most importantly, dashed red boxes and lines denote trust zones, and each connection that crosses a trust zone potentially has one or multiple threats associated with it.
You can see the first four device classes on the left below each other. The OT environment is center bottom. We also see our solution-specific DNS and Device Certificate Authority, which we discussed before in earlier articles. All device classes communicate with the end point gateway where we ingest the data (and potentially send commands back to the edge).
When initially modeled in the Microsoft Threat Modeling Tool, this resulted in 237 identified threats... I wouldn't use this figure beyond getting a sense of scale of how complex this really is, but it illustrates that there is a lot going on in such a landscape.
Talking through a complex model like this is hard. Therefore, in subsequent blogs, we will dive into the details of this diagram by looking at the various device classes separately, first covering the 32-bit device classes, followed by microcontrollers, and finally the OT networks.
Part 2: general computing devices
Part 3: microcontrollers
Part 4: SCADA/ICS
- SAP Managed Tags:
