Tim Nyland-Jones, Information Security Manager at Northgate Vehicle Hire, investigates why IoT software and interoperability are still a long way from being standardised.
The ‘make it work, make it right, make it fast’ mantra is an oft-quoted one in the world of software development:
- Make it work: do the minimum necessary to create a product that meets functional requirements
- Make it right: do the important work to make sure that the main risks are addressed around legality, compliance, etc., that it passes all tests, and conforms to our best practices
- Make it fast: now that the product does all the things we need it to, and does them properly, the code needs to be made as lean and efficient as it can possibly be.
Are there standards we can make use of?
While international standards for an organisational approach to information security such as ISO27001 have been around for a good number of years now, a similar software-level standard has been more difficult to get in place. ISO 27034 (application security) may go some way to meeting this need but is currently incomplete. Looking specifically at IoT devices, there are numerous frameworks and platforms to assist with interoperability – Apple’s HomeKit is probably the most well-known but this is targeted at the consumer market rather than business; all the usual players like Amazon, Google, IBM and Microsoft provide IoT integration frameworks; there are also many open source options. In short, the complexity of software development and the immaturity of the IoT sector together mean that IoT software and interoperability are still a long way from being standardised.So how can we be responsible users?
In the meantime, some common-sense questions based on the UK Government’s Cyber Essentials programme may begin to provide a practical framework for using IoT devices in the enterprise. These are:- Usernames and passwords – Many recent problems with IoT devices have come about because of default credentials either being unable to be changed, or with credentials being entirely embedded in the software code. To provide assurance, all accounts should be documented and there should be a mechanism for changing them.
- Encryption – All user data on any IoT device must be encrypted, and responsible users would expect to see documentation of what algorithms are used. IT departments need to know vendors aren’t rolling their own encryption. So, we should ask what encryption is used – the only reason vendors would have to keep the encryption algorithm secret is if (a) it’s no longer regarded as secure (MD5, SHA-1) or (b) there isn’t actually any encryption…
- Patching – Nothing we ever install is fully secure; this is even more true in the cast of IoT devices. If we’re managing devices on our network, we expect that they will be patched regularly. Therefore, we should ask how often, and for how long, we can expect to get security updates for it. Because once our device is end-of-life, we’ll need to replace it. Also, we’ll need to know where the updates will come from; it would be great if they came as automatic notifications, but if not, a web page to visit regularly would work too.
- Vulnerabilities – How do they get reported? Hopefully not by Sky News or the BBC! All users of the device should have a method of reporting any vulnerabilities back to the vendor; that way we all find out about problems and get them fixed quicker. Of course, we need to be sure that the vendor acts on them, too.
- Testing – Can you provide evidence you’ve tested the device already for vulnerabilities? What was found? Have you put an action plan in place, or is there a roadmap for further developments and fixes?
What else?
Maybe we didn’t get the chance to ask all the questions we wanted to before the devices arrived. However, there are still plenty of things we can do to mitigate – on the basis that the devices will be inherently insecure:- Segregate – Any IoT devices should be kept well away from the main corporate network. You probably already have mature patching and security management practices for your main network – don’t compromise them by allowing devices with the potential for basic security holes in there.
- Test – If the vendor can’t provide their own testing results for the devices, and you don’t have the skills within your own IT department to test the devices, there are plenty of companies out there who will be happy to test them for you and report back.
- Patch often – Once IoT devices are in, it’s easy to forget they need patching – but if the vendor’s not able to provide an easy way to flag when patching is required, it’s up to us to remember. A once-a-week check is appropriate. And more often if the headlines dictate!
Managing the risks
Many of us in IT won’t come near to the internal workings of IoT devices. But we’ve all got a duty to ensure we manage the risks facing our businesses, and make sure we, the manufacturers and vendors, don’t just ‘make it work’, we all ‘make it secure’.Further reading
- Two articles on standardisation options: Standardising IoT Standards and Groups and IoT Cloud Platform Landscape
- The full Cyber Essentials questionnaire