Originally posted at https://tech.labs.oliverwyman.com/blog/2017/05/30/how-to-actually-secure-iot-devices/
Every day it feels like there’s some new Internet of Things (IoT) story, telling us how these new devices in our homes and offices are causing more and more havoc. On the other hand, we really like the new and shiny things doing funky things for us, and that doesn’t look like it’s slowing down any time soon. The question is, how can we balance having the newest (and lowest cost) devices, while also not having our networks wrecked? Well, there’s some well meaning things like Project Sopris, and although I appreciate efforts in making the devices themselves less awful, we’ve a) got all the existing devices b) unless there’s a legal framework in place, most manufacturers aren’t going to obey those rules if they make their devices even 1 penny more expensive and c) even if they do, manufacturers will go out of business and hacks will occur even in the face of best efforts.
So, is there an alternative? Can we have our cake and eat it? Well, yes. Probably. I’d like to propose here yet another device, that might actually solve the problems herein. I haven’t built such a thing, as it would take quite some time to do so properly, but if anyone wants a new startup, feel free to make it. Simply put, it’s an IoT Firewall, although that doesn’t really do it justice. Firewall is where it starts, but it does so much more than that. To begin with, it’s a WiFi access point. Probably using WPA2 (Personal, not Enterprise for support of a wider set of devices), although maybe with multiple APs for WEP as well for devices that don’t support it, and for slightly better isolation between devices. All of your IoT devices are told to connect to one of this set of APs, and nothing else is. The devices are isolated from each other as far as possible (fun with VLANs, multiple APs if you’ve got them, etc). WPA2-Enterprise would be great here, given the separate access keys, but the percentage of IoT devices that support that is low to none sadly.
A device begins life on this network with it’s DNS and routing tables all heading one way: to the AP. All DNS lookups return the AP’s IP. All other packets go to a rather specialised little set of networking tables that basically just records what packets were sent to it and where they wanted to go, and then promptly drops them. A user of this AP can then see what the device wanted to do (a lot like the Little Snitch firewall) and decide whether later attempts at similar requests should be permitted. As it’s a device, not a human, they’ll generally try again in a short while. Incoming requests are treated similarly – if they were aimed at a particular device, then we record the packets, drop them, and allow user decisions about whether repeated instances should be allowed later.
Of course, we can go further. If a request to a third party server is currently trusted, but we don’t know whether to trust it in the future, we can simply record the current response and pretend to be that other server (while routing packets to the AP), while checking for changed responses from the third party, and providing them to the user for choosing whether to update the response next time. This works much less well with things like HTTPS, but in that case, attempting with a self-signed certificate for the third party domain and seeing if the device just lets it through regardless is worth trying, given the usual state of IoT code. Notably, this replacement technique also works well if the third party goes offline (e.g. because the manufacturer goes out of business) and someone else has provided a replacement. We can simply redirect to the replacement, lying through our teeth to the device.
The end-user overhead of all these actions I’ve noted here is significant, and one area of interest to a potential startup would be providing a feed of “and here’s how to treat device X” with frequent updates, thus reducing the level of user input. Ideally, the AP would also provide the option of switching whose feed of updates it accepts, along with the option to switch who provides system-level updates for it, but that feels like the sort of thing that might be regarded as an unacceptable level of competition for the average startup. Of course, if we standardised the firewall design, then maybe this could provide a whole new market, and maybe get around the problem of this device falling into the same traps as the things it’s meant to protect us from.