Consult Hyperion

About 15 years ago, we built a robot to automate the some of the testing we do in-house. We called the robot “Roger” and thought nothing more of it. The idea of people and robots being somehow interchangeable in the workplace has since developed from being science fiction to something of a reality. The enterprise, as we know it, is rapidly changing. All manner of devices are becoming digital and 5G promises to connect everything, generating vast amounts of data that enterprises (and suppliers to enterprises) will look to leverage.

The Internet-of-things (IoT) is set to change the world. This will bring huge challenges to enterprises. It was hard enough managing employees expecting to use their own mobile devices for work. IoT will be orders of magnitude more complex than BYOD.

The challenge will not just be one of scale. The security and operational requirements for IoT in the enterprise are very different to the requirements of traditional users using their own devices for work, leading to many new risks. For instance, IoT devices operating on the edge network suddenly become an attractive target for attackers. According to a recent NASA report an unauthorised IoT device (Raspberry Pi) was the cause of a JPL network security breach. The hackers targeted an employee’s unsecured Raspberry Pi which resulted in leakage of sensitive mission critical data.

Identity and access management of IoT devices (or IDIoT, as we like to refer to it) presents a particular challenge. The ownership and control of IoT devices is much more complex than BYOD. We are not just talking about a relatively static mapping of devices to users. Instead, devices could be mapped to users, organisations or other devices and these mappings could be dynamic in some cases changing on a daily or even hourly basis. With all this complexity, how do you avoid looking like an idiot?

Using our 3-domain identity model, we think IDIoT can be broken down into three distinct areas:

• Identification: First and most importantly enterprises will need to uniquely identify each distinct device. In BYOD, this is usually done using unique identifiers, such as the IMEI or MAC address present in mobile phones. But this is not enough as these identifiers are trivially spoofed, so device fingerprints (capturing numerous data points from devices) is also done. Given the highly fragmented nature of IoT, device fingerprinting may well be impractical. There are more advanced technologies to prove device uniqueness (e.g. Physically Unclonable Functions or “PUFs”) but no one is deploying them yet.

"Increasingly IoT devices will be autonomous, directly accessing other systems"

• Authentication: Increasingly IoT devices will be autonomous, directly accessing other systems (or other devices). Often these interactions will require the IoT device to be able to authenticate that it is entitled to access the system in question. This authentication process will likely use cryptographic keys stored on the IoT device but how will those keys be protected? The story of IoT to date is riddled with examples of devices containing gaping security holes, with sensitive information like keys being exposed. Again, the technology to protect cryptographic keys (e.g. Secure Elements) exists, and is present in many smart phones, but not widely deployed in IoT.

• Authorisation: Finally, who or what should be able to access the IoT device itself to, for example, read the data generated by its sensors or to instruct the device to perform some action? The conventional answer to this question would be to employ network controls around the device, e.g. creating zones and protecting the perimeter of each zone. Such an approach is likely to be too rigid and inflexible for IoT. Instead, devices need to be able to make their own authorisation decisions, according to business rules set by the enterprise. How can this be done robustly?

Today many IoT vendors either do not think about security or think about it as an after-thought. We all know that security is better when done by design. Securing IoT deployments today must of course include all the things you would do to secure any other part of your infrastructure: risk assessments, device hardening, firmware and patch management, device management and so on. The problem is that with such a diverse range of IoT devices this is far from being a straightforward exercise.

Ultimately IoT vendors will only employ better security in IoT devices when they are compelled to do so—by market forces or by regulation. Enterprises therefore need to start making hardware security a criterion in selecting IoT partners. When will hardware security be essential? Ultimately that needs to be determined by performing a risk assessment. However, examples could include devices relying on untrusted networks for connectivity, that process commercially sensitive data, that perform payments, or that perform some vital health function.

“Alexa, please secure the office”. What could possibly go wrong with that?