IoT Challenges — The Internet of Insecure Things

Three pointers on bringing the Internet of Things into your workplace without inviting chaos too

Image credit: Dustin O’Donnell

The “Internet of Things” is about tiny, cheap, ubiquitous devices that inhabit (some would say “infest”) your workplace and/or home, and quietly provide or display information.

To help imagine how IoT will change our lives, I use the “coffee rule”. Think about something that wastes your time in the physical world. Would you spend the cost of a cup of coffee to fix it? Is the meeting room down the hall occupied right now? Did I close the front door when I left home this morning? Has the mail been delivered yet? Is it business hours in the Dubai office? Is there a truck in the loading dock?

Small, single-purpose physical computing devices are going to be everywhere. Their supply and installation cost is already almost zero. The real cost is going to be management and maintenance; and particularly the effort of managing security risks.

A company of 100 staff will probably have around the same number of PCs which need to be maintained, and kept secure. Add another 500 smart devices (think every light switch, environment and occupancy sensors in every room, and every appliance) and there are a suddenly a lot of (tiny) computers that need some degree of looking after.

Some people have said that this very security and maintenance cost of IoT devices makes them too expensive at any (hardware) price, even if the unit installation cost approaches zero. I don’t believe this needs to be the case.

Here are my recommendations on practical ways to minimise the cost and risk associated with a connected workplace.

One — Use a “sandboxed” network for IoT devices

The movie-plot threat of the IoT world is “hackers compromise office network via the smart thermostat”. It’s not out of the question that this could happen given a sufficiently determined attacker. The way to mitigate this risk is to remove the gain; place devices on a network that has very limited access to the outside world (what security folks call a “sand box”). If theworst happens and a device is compromised, then the attacker only gains access to the sandbox, not your whole corporate network.

If you have professional-quality WiFi network routers you probably already have a sandboxed guest network for visitors that provides Internet access, but connects outside your firewall. Even mid-range home routers now offer this guest feature. I recommend that you use a similar sequestered network for your IoT devices. Don’t allow them access to your corporate services at all. (Prefer a dedicated network if possible; if you do share your actual visitor WiFi network with IoT devices, some of the recommendations later in this article won’t work without affecting your visitors).

If you segregate your IoT devices to their own network, then instead of connecting directly to your corporate network, your IoT devices should talk to message servers hosted in the cloud. Publish-subscribe messaging services (such as MQTT) allow you much tighter control than traditional web protocols, and they solve the problem of devices talking to each other; all communication is mediated via a single message broker. First you can disallow all incoming traffic to your IoT network; devices that need to talk to each other or to other business systems will do so via the message server. Second (presuming your IoT devices are not sharing a guest network with visitors’ personal devices) you can restrict the destination of outbound traffic to only your message server, which means that any compromised device can’t “leapfrog” to other systems, nor be repurposed to send spam email, nor conduct denial-of-service attacks.

Enforcing a policy of “don’t talk to strangers” for your IoT devices greatly reduces the number of avenues for attack, and also eliminates the risk to your internal network from any devices that arrive pre-infected with malware.

Note, I’m not recommending that you rely on cloud message services provided directly by device manufacturers (see my next point).

Two — Prefer open source devices and bring your own cloud

The flip side of “so cheap it’s almost free” is that manufacturers have no margin or motiviation to provide much ongoing support. The very cheapest devices are often undocumented and may not even identify the manufacturer. It is best to select devices that are open to third party developers; if a problem in the original software becomes known, and the manufacturer is unable to help, then the open source community may provide alternative software for the devices. Also, any device that is open to developers will be more scrutinised than completely closed platforms, and any security risks inherent in an open platform are likely to be discovered and rectified.

You should select IoT devices that can be configured to talk to your own messaging servers using standard protocols, i.e. devices that do not lock you in to the manufacturer’s proprietary services. In combination with restricting outbound network access to only your own servers, this will greatly simplify your confidence that devices are not leaking information to third parties.

Open source developer and renowned reverse-engineer Matthew Garrett has made an amusing hobby out of auditing low-cost IoT devices and found that the manufacturer’s software on some of them is hilariously insecure. When selecting devices, look for a platform that is known in the open source community so that you can have some degree of confidence that any glaringly insecure behaviours have been spotted. Confirm that devices are using standard encrypted communications (SSL/TLS). It’s a good rule of thumb that if the manufacturer invented their own proprietary security protocol, it is probably insecure. Smart developers know that they are not smart enough to compete with professional cryptographers.

Where devices support “over the air” updates for security patching, you should determine whether this capability requires you to open up your network or can be tightly filtered. Self-updating devices should only be permitted if you are able to make informed decisions about the safety of the update mechanism.

Three — Keep a device registry

If you have followed recommendations one and two, then you have a population of devices which are firewalled from your corporate network, and which should only be talking to a single message broker that you control. The final major risk is that these segregated and firewalled devices occasionally (or when compromised) communicate with something else that you didn’t expect.

The defense here is to keep good records — device type, device location, ethernet MAC address (which is a unique identifier of the WiFi interface)— of what devices you have, to allow locating devices that need updates, and also tracking down of rogue devices. In combination with firewall block logs or more advanced Intrusion Detection Systems (IDS) you should do a follow-up audit on newly installed devices to confirm whether they are attempting anything unexpected.

Your device registry should support you to, for example, locate all the Acme ThermoSens 6000 devices in your facility, should they require intervention. If a vulnerability is reported with a particular kind of device, knowing the MAC address of each will let you firewall these devices quickly until they can be repaired, without necessarily needing to run around and rip them off the walls.

You should also be able to track a particular single MAC address back to the responsible device. If a device goes rogue you can block it at the network edge while you arrange physical removal. Remember many of these devices can change their MAC address under software control, so you should use a “white list” on your network to prevent rogue devices from switching to an unregistered address (but again, this tactic won’t work if you’re sharing a WiFi network with visitors).

Is it really that scary?

If you are letting staff bring their mobile devices to work you should probably have most of these WiFi management strategies in place already. The key strategy is to separate traffic by way of a separate WiFi network that is outside your main firewall; if you can only do one thing, do that.

If you want to dip your toe into the IoT world to see what can be done at no infrastructure cost, start off by using your guest network.