Fears around security consistently come up as the main obstacle towards adoption of IoT solutions. This is absolutely a fair point. A lot of the device infrastructure, especially in consumer and home automation IoT, has proven to be rather poor in security features, and this deservedly gets a lot of press. The idea that we would connect such devices up to industrial control systems and systems-of-record sounds terrifying. However, industrial IoT is not the same as consumer IoT, and environments tend to be a whole lot more controlled, which gives us plenty of opportunity to apply existing best practices in security. In addition, the nature of the communication allows us to do some things that would be really difficult in a scenario with human users.
Since the middle of August last year, I have been part of a team looking into the security of industrial IoT infrastructure and solutions, and we worked through a number of scenarios about which we will soon be able to talk about much more. However, there are two themes that came out of our analysis that I thought would be interesting to share, and add three practical recommendations.
Let me be clear, though: the thinking below reflects a focus on manufacturing, heavy industry, big assets and machines, and so on - the sort of IoT SAP provides solutions for - with sensors and devices connected to a central location. Low powered devices, wearables, consumer IoT and other scenarios may well - or most likely will - require a different approach.
"Treat the edge as hostile until proven otherwise"
So, what is the way to approach the problem of potentially insecure device infrastructure connected up to core SAP systems and potentially industrial control systems? Don't trust it until you have confirmation that you can. The data ingestion of IoT solutions tends to be large, and include predictive models that need to be trained on this data. It's a lot easier to deal with missing data, then with data that was manipulated in some way and try to exclude that when you have no way to distinguish it from good data, so we simply reject anything that doesn't meet clear authentication and encryption standards we set, or is coming from a host we don't know about. That should prevent us training and executing predictive models based on manipulated data, and thus prevent corruption of the core system, or sending an inappropriate instruction to any control systems.
"M2M communication is fundamentally different in nature than H2M communication"
Human-to-machine (H2M) communication is largely unpredictable. With a user behind their PC, we have no idea what they might be doing next. They could go to any website, open any connection, unless somehow prohibited. This is typically not the case in machine-to-machine (M2M) communications in IoT, where in fact the behavior is highly predictable: it will typically send data on a certain frequency to the same end point, again and again, and again. Think for instance of a temperature or pressure reading every minute.
Bearing those two main themes in mind, we can now look at the problem a bit differently, opening up options that we may not have thought of before, used as we are to protecting landscapes that primarily serve human users.
The three recommendations are:
- Use PKI client certificates for authentication and device identity
- Apply a "whitelist" model for device security
- Monitor the network for unknown hosts and quarantine them
1. Use PKI client certificates for authentication and device identity
When humans access a protected resource (a website, say), there tend to be a number of interactions. You might get presented with a logon screen at first access, already over an HTTPS connection. You supply username and password or some other means of credentials, and you get access. The point is, there are multiple requests/interactions. We don't know when this might happen, so an attacker sniffing the network may have to wait a long time before their target visits the website they want them to access (for instance, their bank website). Moreover, it is not always obvious where the victim might be, so which section of the network to sniff is not that simple to determine.
When devices access a protected resource, all credentials tend to be in the same request. As mentioned before, this is likely to be on a regular frequency, and will tend to have a fixed physical location. And while a browser takes care of certificate verification (you will see significant error warnings if the browser detects problematic certificates), for such devices it is up to the developer to ensure this is done correctly. Unfortunately, failing to verify certificates is a very common mistake. While unverified certificates will work and provide encryption, man-in-the-middle attacks (MITM) are highly feasible.
Verified server certificates prove to the device it is indeed talking to the end point it believes it is, and client certificates give a means to the server to verify that the device is indeed the device it pretends to be. Client certificates are better than tokens and username/password combinations as those by themselves are enough to spoof a device message in case the connection is tapped, as the private key is never communicated. Therefore, only physical or admin access to the device, stealing the certificate, and using it in manipulated messages would endanger this approach.
2. Apply a "whitelist" model for device security
If we know exactly what the device should be able to do, we can disable everything else. We should know the end point of where our data needs to go. We likely will need to make a connection to a CA to validate server certificates. We probably need admin access in some way, for instance through SSH, as well as over-the-air firmware updates. Regardless, this is a limited list of legitimate end points. The device will never have to go to Google or Amazon. That gives us all kinds of options, from aggressive firewalling (explicitly allowing only known end points and drop everything else), to removing all root certificates from the device other than the ones from our end points (so verification even of legitimate server certificates signed by CA's other than ours would fail). I have even considered the idea of a edge infrastructure specific DNS server, that only translates a small list of end points, so that other server names won't even route.
3. Monitor the network for unknown hosts and quarantine them
Finally, all protection mechanisms can fail. Whether through a misconfiguration or otherwise, we need to do what we can to keep intruders out, but also detect and throw them out when we encounter them. We should know all the legitimate hosts in our environment, even if the number can be quite large. That means we should also be able to detect - in case of software defined networks (SDN) with network access controls (NAC) - when rogue and unknown devices join the network. This might be an attempt to start an MITM attack, so we should quarantine such rogue hosts the moment they are detected.
Now, all this relies on a certain amount of power and capabilities of the edge infrastructure itself. Not every edge device is capable, especially small sensors and devices operating on batteries. However, we have already seen through the past couple of months a move towards ARM7 as device platform, which is capable of running a full Linux operating system and can perform the complex math required for PKI encryption. Such infrastructure can provide end-to-end security from device to end point, without the use of IoT gateways. Less capable or powerful devices that require such an IoT gateway may leave you exposed exactly where you might be most vulnerable - between the device and the IoT gateway - if the protocol they are operating on and the communication itself is not protected.
We're just at the start of all this. We will learn quickly, as more IoT solutions become available and start to come online. We will continuously monitor how things progress, and will adjust our strategy if and when needed. I'd also be interested in your ideas, especially if you have a background in information security and have given IoT security some thought.
Nevertheless, even in these early days, I think it is important we realize we're not helpless, and there are techniques we can apply to keep such solutions more secure.
