Don't put the 'd' and second 'i' in IoT: How to secure devices in your biz – belt and braces
No concessions, no compromises – it's the only way
Comment The enterprise is filling up with devices. Gone are the days when the only IT kit our staff used was phones, printers, scanners, desktop PCs, and servers that were bought, configured, installed, and maintained by our IT team.
Now we have more different types of device than you can comfortably shake a stick at – which, of course, means we have a similar growth in the number of potential security threats.
Can we run a secure organisation with this vast variety of kit to fend with? Depends what you mean by “secure”. If you mean “so nobody can hack it”, then no: even with a minimal set of tightly configured, rigorously controlled systems, you can never guarantee absolute security. What we can do, though, is control the risk and keep it to a level that fits the organisation’s risk appetite.
I’ve spent a chunk of my life writing about how to secure your network to work with IoT and user-owned devices. For a change I’m going to look at the devices themselves. So do all the usual stuff, such as keeping user-owned devices outside the firewall, segregating IoT devices on their own subnets secured with access control lists, enabling the right access (and only the right access) for devices to be monitored, managed and upgraded, and implementing network access control.
Oh, and never, ever configure a device out of the box on the corporate network. Assume it’s an electronic sieve until you’ve configured it otherwise, and preferably give it a completely separate network with its own broadband internet link and no physical connection – not even through the world’s most hellish firewall – to the corporate LAN.
And then turn your attention to the equipment itself.
Name’s not on the list, you’re not coming in
I said earlier that your mission is to stay within the organisation’s risk appetite, and there will be times when you look at a gadget and simply say: no, this just can’t be secured sufficiently to be accepted into the organisation. Some risks you treat, by putting them behind firewalls, and monitoring like a hawk. And some you tolerate – the benefit makes it worth it. But some you terminate, by simply not using that device: it’s not often that there’s only one device on the market that can satisfy a requirement, so look for something more suitable.
If there’s a default admin username on the device and you can change it, do so and set a secure password. If you can’t change the admin ID, then you’re stuck with just changing the password. If there are any other accounts on the device and they’re required, set their passwords to something secure and different from the others; if they’re not required, blow them away. And turn off any guest logins.
Make sure, also, that the administrator passwords you choose are different for each device. Too much hard work? Not if you’re interested in staying secure.
Device firmware updates are your path to fixing bugs – including security-related ones – in the operating software. Update the firmware to the vendor’s latest version while you’re on the secure configuration network. If the device can update its own firmware on a schedule, then set it to do so. If it’s a user’s own device (a smartphone, for instance) then mandate that users keep the operating system software and applications up to date.
As someone who makes a living from security consulting, I’d go further than mandating that the user do something: I’d insist on using a mobile device management (MDM) package to enforce policy – on both company- and user-owned phones and tablets – so there’s no need to rely on the individual user. No MDM, no connection – and if the users don’t like it, tough.
All the MDM products on the planet have a ridiculous number of settings, so work methodically through them and ensure you enable only the features you need.
Configure them to be restrictive: turn features off by default, and only enable the ones you want. Use it to enforce the basics such as mandating a six-digit unlock code that has to be changed regularly, but consider all the more granular ones: whether you want to permit screenshots, whether users can use the device’s camera when they’re within your office (yes, you can really do geographical stuff like that), enabling the popup blocker on the onboard web browser, and so on.
Incidentally, you often find that MDM systems provide more control over some platforms than others (generally iOS support tends to be more in-depth than Android) so you might revisit the risk decision and permit only some types of tablet or smartphone.
Turn off the features you don’t need
Most devices will have a heap of features that you don’t need, so disable them all. There may be multiple ways to manage devices such as browser interfaces, SNMP, management applications, and so on, but stick with one and turn the rest off.
That also includes interfaces. If you’re connecting via Ethernet, turn off any radios. If you’re connecting via Wi-Fi then disable every other mechanism (not forgetting Bluetooth).
Know what it’s trying to leak
Some devices will, by design and in line with your requirements, deliver data to a cloud service. That’s fine, so long as it is secure, and you’re controlling what they can do and have thought about it in the risk assessment. But be sure what connections it’s trying to make: turn off the ones you don’t want, and whack a big brick firewall in the way just in case something gets turned on by mistake later.
Consider the physical security
If the device isn’t portable – say it’s a camera or motion sensor for a security system – you need to consider and protect the physical security. There’s no point going to the trouble of configuring its security to within an inch of its life if someone can take a bent paperclip and prod the "factory reset" button on the back panel.
Turn on the encryption features
Particularly with Wi-Fi-based IoT devices, traffic interception is a tangible problem. If someone compromises the wireless network key, they can sit nearby and watch the traffic fly past – so your best solution is to use whatever end-to-end encryption features the devices provide. If there’s a choice of how they connect to transfer data, pick the one that’s most heavily encrypted.
Make them shout at you
You’ll have dealt with monitoring when you did the networking configuration we’re not talking about, but on the device itself make the most of any proactive management features they have. Get them to send log events when anything significant happens that they’re able to tell you about – particularly the key activities such as admin logins, password changes, changes in settings, and so on. Even if a device is compromised and the attacker disables logging, you may still be able to smell a rat from an unscheduled admin login, for example.
A policy of electronic euthanasia
Kit becomes end of life. It’s just the way it is, and there’s nothing we can do about it. IoT equipment will generally become obsolete way more quickly than the more complex, expensive infrastructure equipment it’s sitting on – which means firmware updates will stop more quickly. No Microsoft-style extended support here, I’m afraid: some of these things make a mayfly look positively immortal.
Happily, if something’s got a short life it’s less likely that you’ll become attached to it, so there won’t be too many tears when you have to do a secure-wipe on its settings (which of course you’ll do, won’t you) and send it one-way to the IoT office in the sky.
No compromise, no concessions
The secret to IoT device security is having robust controls and sticking to them.
In a very small nutshell that simply comes down to admitting only the devices that pass the risk assessment. You must configure them robustly and check the configuration regularly during their lifetime. You use the data they give you to ensure they’re operating securely as they do their job. Finally, dispose of devices when you can no longer keep them secure – failure to do this is one of the most common vulnerabilities.
After that, everything is details. ®