The Internet of Things (IoT) is big news at the moment, being used as a title for just about everything that interacts with the internet, be it man or machine. In some areas the commentary is just starting to recognise that security and privacy are issues. And as you expect, various players are putting forward their solutions.
The challenge is that the IoT is too fragmented for there to be a one size fits all solution. It reminds me of the email market of 15-20 years ago. There was a clear need for email, there were emerging standards (X.400, RFC 822, SMTP, MIME…), and proprietary solutions (cc: Mail, Banyan…). Achieving interoperability alone was challenging, let alone attempting end-to-end security. The best that could be achieved was to exchange files in the email using an armour format like PGP (and hoping interoperability gateways would not corrupt the file).
I suggest that is where the IoT is right now – lots of competing standards for different purposes.
As time evolved, SMTP and MIME matured to the extent that interoperability issues largely went away. Then end-to-end security could be addressed with S/MIME. Is this where we are with IoT?
Interoperability
The report “The IoT: Technologies, Opportunities, and Solutions” looks at data sharing in the IoT, identifying at least 4 different standards:
- Advanced Message Queueing Protocol (AMQP)
- Constrained Application Protocol (CoAP)
- Data Distribution Service (DDS)
- Message Queueing Telemetry Transport (MQTT)
To add to this list is HyperCat, which is a specification that allows IoTs’ clients to discover what data an IoT server has available (See “HyperCat: Interoperability on the Internet of Things” for more details).
Interoperability is where the state-of-the-art is: “let’s see if we can make the IoT work”.
Segmentation
One of the reasons for the variety of protocols, is the IoT is pulling in many different directions.
The IoT: Technologies, Opportunities, and Solutions report segments the market into the Consumer IoT and the Industrial IoT. This is not unlike the early stages of email.
The Industrial IoT is further segmented into: Device to Device; Device to Cloud and Cloud to Cloud. Alongside this, the OFCOM report “Promoting investment and innovation in the Internet of Things” identifies 5 key vertical markets:
- Healthcare
- Transport
- Energy
- Asset Tracking
- Smart Cities
Each of these segments has its own drivers, each has its own technology challenges, each is at a different technology readiness level, so each is looking at solving its own problems – and on the journey setting some standards.
In time, convergence may come, as we saw with MIME, but I believe we are 5 years away at least from that. In the meantime we need to worry about security. The evolution of Email had a luxury in this respect – while hacks were theoretically known during the early days, it was a long time before it became a significant malware delivery tool. The IoT is different, it is being attacked now.
Security
So where is the IoT with security? The article “IoT / IoE: If It Has an IP Address, It Can Be Hacked” looks at the fundamental challenge the IoT faces from a security perspective.
While I agree that connectivity is great and adds a lot of value / interoperability / functionality features, there is an oftentimes underestimated risk in putting the whole world (well, the whole Internet) directly in front of any system or device and even connect to it by giving it a routable IP address.
As security professionals, we know how to assess these risks and we know how to mitigate these risks (and we are learning how to balance security controls with usability).
However, the report “Vulnerability Coordination for the Internet… of Everything” identifies another issue.
Code is code, and all code contains security vulnerabilities. This is true no matter if the code is running on a server, desktop, laptop, tablet, phablet, phone, industrial control system, car, insulin pump, fitness tracker, home temperature control system, or refrigerator.
The issue we’re seeing in these latter products is that vendors—who have never run code inside these devices before or haven’t previously exposed their code to the Internet—are often the same vendors manufacturing them.
In turn, they are making enough coding errors that many ‘low-hanging fruit’ are present in their code, like simple buffer overflow vulnerabilities or cross-site scripting errors.
To summarise – the people building the IoT are not security professionals, in many cases they are engineers. This is not a poke at engineers. Engineers build great things, they also know how to build safe things by using robust and mature process. But in general, Engineers are not trained in security matters, and the operations in their businesses have not evolved to build secure systems (they build safe systems).
As a consequence we are seeing a fundamental failing in security understanding in IoT – thinking security is a technical thing that can be easily solved some time later. Whereas as security professionals we recognise that technology is just one element of the people, process and technology triad, and security needs to be designed in. The good news is bodies like the Federal Trade Commission in the US also recognise this: “To mitigate security risks, the FTC recommends that IoT device manufacturers incorporate security into the design of connected products” (Security Is a Must for the Internet of Things)
The IoT is in its infancy – we are where email was 15-20 years ago – the security and interoperability standards (S/MIME) equivalents will emerge in time. But in the interim, we can and should work on the people and process elements, otherwise we’ll create a monster we’ll find hard to manage. With email the risk was largely about human conversations; with the IoT it is largely about machine to machine communications, some of which will make critical decisions – we have to get it right, as the risks are significantly higher.
Once Upon a Camayoc 