Network separation for IoT Security: leveraging heterogeneity

Network separation for IoT Security: As was described in detail in my 4-part blog series on threat modeling a heterogeneous IoT landscape, IoT environments tend to be varied, and use a variety of chip architectures and network connectivity. This series stressed primarily how this complexity increased the number of threats and in general broadened the attack surface, so was largely a negative element we had to control and mitigate.

However, since then I have started thinking about the benefits of such heterogeneity as well. And just like how machine-to-machine (M2M) communication allowed us to apply whitelisting as a principle – whereas that is often not feasible in more traditional IT security – we can use such heterogeneity to our benefit to enhance security of the overall solution.

When we come up with new and innovative things, we need to name them and describe them to others. This itself causes interesting mental prisons that can obscure important elements. In IoT that is the concept that everything is going to connect to everything. We all probably have heard variations of the following phrase:

Analysts estimate that 20 billion (or 30, or 50 billion)  “things” will be internet connected by 2020

Similarly, terms like “The Internet of Everything” may have set an expectation that many of these devices are going to be talking to each other. My argument in this blog is that that is impossible to secure, is not true currently, and is unlikely to be the case in the future. In fact, our main task in IoT security will be how to connect devices up to as few other devices as feasible, and isolate components from each other as much as possible.

Consider the following diagram, representing a situation where many devices connect to many others.

Even in this diagram, connections are only made to the nearest neighbors. But is this really how IoT networks operate? I don’t think so (and if they do, we should probably change that). An exception might be made for mesh networks, but that’s not what we’re talking about here, as even then we don’t talk about direct communication, but message relay.

I would argue that even today, IoT networks look much more like the following: mutually isolated networks that don’t talk to each other.

The easiest way to illustrate the point might be a consumer IoT example: Suppose we have a home automation situation, where a consumer brought in a number of IoT’ed things into the house: Smart lighting, a connected fridge, a TV, and a connected doorbell. Each of these comes from different vendors, and each ask the consumer to put them on their home wifi network so they have internet connectivity. Such things typically come with a smart phone app that makes a connection to a cloud environment for each of these products. So, what do we have? A home network where things share a wifi network, but don’t actually talk to each other. The only place where the various home automation components come together is in the smart phone of the home owner, but as separate apps! The apps connect to the cloud, and the thing connects to the same cloud. But each thing is its own network path. Any home automation bridge doesn’t really change this: it just replaces the smart phone in this model. At most, you’ll have a single hub and spoke model, which each thing connected to the bridge, but none of the things able to talk to each other.

And in this example, the network is still shared by all components. But even that doesn’t have to be the case.

This summer I heard a really interesting talk by someone from a large chemical manufacturer who were thinking of how to IoT-enable their plants. Security was a concern, and they didn’t want to open up the OT environment – that they were quite happy with – to new threats. So, instead of adding sensors to the OT environment, they added sensors communicating over an LPWAN network.This was only one slide in a larger presentation, but it caught my eye. OT networks are historically not built for security, and for that purpose isolated from IT systems and other networks through airgapping. LPWAN networks are by themselves not terribly secure, as the communication between the device and any gateway, or the device and the network provider is not protected by modern strong cryptography. By adding our encryption scheme for low-power devices, we could protect that communication, while at the same time allowing no communication of any kind with the OT network – even though both set of infrastructure shares the same physical location. It may even make the cloud an attractive option for those that otherwise would be concerned about data leaving the site altogether.

Let’s assume for the moment that the white circles are components in the OT environment: PLCs, machines, etc. running in their own network. In blue, then, we have our sensor infrastructure, operating over an LPWAN network. Since the two share no network at all, separation is complete. No sensor can communicate with any component in the OT environment and vice versa.

Data is extracted from the OT network and sent up to a central cloud environment. The sensors also send data (via the network provider) into this cloud. And then on-premise back end business systems like SAP ERP/ECC and MII, themselves push data into the cloud. Only in the cloud does this data get merged and analyzed, which may results in actions triggered in the business  systems, or commands sent back down into the OT environment.

This article is not the place to fully describe what such an IoT manufacturing landscape might look like, but the main point should be clear: three separate networks that are completely isolated from each other, apart from a central cloud point where applications analyze and process the data coming in from all three. Should an attacker gain control over one network, that is not good, but it won’t immediately affect the other two, and if we detect it as soon as it happens, we likely have time to react.

There is an additional element, and that is to do with how an attacker operates. An attack typically consists of an attacker providing carefully crafted malicious input to a system. The easiest way to figure out what that malicious input should be to create a desired result is if the attacker is on the machine itself, and attaching a debugger to the process under attack. That might work for desktop applications.

In attacks on web applications, as in cross-site scripting or SQL injections, the underlying system is bigger and the attacker is unlikely to know it fully, but the application itself provides feedback: error messages, or a table with results, and so on. In order to manipulate a particular outcome, the attacker needs to be able to 1) see the results of the command sent, and 2) whether the attack is happening at all and isn’t stopped elsewhere before it reaches the vulnerable component (for instance, through security checks in the application, input sanitation APIs, or use of stored procedures/prepared statements). .

Essentially, there is protection in the size of the “black box” of the entire solution. That black box doesn’t really exist when the attacker runs attacks against a desktop application on a machine he has access to, with a debugger attached. In web applications, that black box is a lot bigger, already, and can be made yet bigger by obscuring errors thrown by the environment into friendly messages, rather than large stack traces. That is, by reducing the amount of feedback the attacker can get back from the system.

In our OT, IT and sensor solution of three separate networks, this black box is enormous. Data from the OT environment and the sensor network is analyzed and used to train predictive models that describe behavior. New information gets run through those models to generate an outcome. Yes, an attacker might gain access to one of these networks, but the amount of manipulated data that needs to be generated to cause a particular effect and the lack of feedback from the system what is going on (even if an attacker can manipulate a device feed, can they see the outcome of the analysis? Can they see the effect in the OT environment? Highly unlikely).

So, we make it harder for the attacker to get feedback from the system. But the implication goes further: if it takes a lot of data manipulation to cause an effect, that means any attack is by definition very noisy, and therefore should be easy to detect. Once detected, we can react, before a nefarious outcome is achieved by the attacker.

None of this is water-tight, and it should be obvious we still need to do all we can to protect each individual network from compromise, as well as any integration points. But we shouldn’t assume our protections are 100% secure, either. We need to protect and detect, so we can react. If we can slow attackers down, and make any attack require a volume of manipulation that is hard to hide, we are making progress. Separating networks to completely isolate them from each other for a single IoT solution is not the silver bullet that will solve everything. But it is one powerful tool in a larger arsenal that will help us secure the Internet of Things.