Gating the IoT

Your car. My toaster. Our lights. The neighbor’s thermostat.

With an average of 7.8 connected devices per home, according to recent surveys, there are twice as many “things” in the house as the average 3.14 people per household in the US in 2015.

And all of them are “talking”. Not all talk to each other, yet, though the foundation for that is clearly laid out. But all of them talk to apps which talk to them over the Internet.

When you or I interact with that app, we do so via HTTP (hopefully secured). Whether it’s via a native mobile app that uses APIs or a modern web app is irrelevant; it is safe to say that both do so via HTTP.

But when things report in, it’s not so clear that they do so using HTTP. Oh, some do, certainly. But as the form factor for these things decreases it becomes increasingly difficult to manage power and compute in a way that’s supportive of heavier frameworks and protocols, like HTTP. That’s why IoT specific protocols have emerged. Protocols like MQTT (MQ Telemetry Transport) and AMQP (Advanced Message Queuing Protocol) that eliminate reliance on HTTP (but remain TCP/IP based) and even those like CoAP (Constrained Application Protocol – RFC 7252), which seek to minimize the impact of HTTP by optimizing a subset specifically for machine-to-machine (M2M) communications.

Publish/subscribe (usually simplified to pub/sub for brevity) models are nothing new in the world of applications. Message queuing is one of the ways that applications have always shared data, long before the days of the Internet became popular. Back then we implemented using C/C++. Then Java took the world (and the Internet) by storm and we learned how to use JMS (Java Message Service).

All pub/sub based protocols can be distilled down to a single, underlying concept: messages are “routed” based on “topics”.

This should sound familiar to those of you who have to “route” URIs. Page routing, app routing, content switching. We call it many different things but ultimately, it’s the same concept. Given a unique identifier in the application layer, requests are routed to the designated endpoint. With pub/sub protocols that is a message broker. For URIs, it’s generally an app or API hosted on a web server.

The difference with IoT protocols is that they are not HTTP-based, for the most part. They ride atop TCP/IP but are purposefully designed to be lightweight. This means that the (growing) data originating from the 7.8 devices in your home is being transported via something other than HTTP.

The thing is that the receiver (the message broker) needs to be scaled and secured, too. One of the complications, as it were, is that “things” like to have persistent connections. That’s because communication is bidirectional and asynchronous. Setting up connections via TCP is well-understood, and it’s a laborious chore that consumes CPU cycles that introduce latency into the equation. Latency that today’s consumers don’t tolerate. A persistent connection enables things to constantly communicate if necessary, and to receive updates with the immediacy that is not only desirable to some consumers, but necessary for others (industrial IoT relies on immediacy). This puts pressure on brokers in terms of capacity, because every connection counts against their total capacity to handle things. That generally means some sort of load balancing-capable proxy in front of the brokers to ensure messages are delivered to their destination. Devices generate a lot of data, after all, and they’re expected to work 24/7.

That, in turn, puts pressure on security ops to ensure that every connection counts. You don’t want to waste resources on a connection to a thing that isn’t valid. You don’t want to use up CPU cycle processing messages that aren’t valid.

While most attacks today have focused on harnessing the power of millions (literally millions) of compromised devices around the Internet, like any public-facing service, the IoT message brokers in the data center (cloud or on-prem) are vulnerable to attack, and in particular, to DoS attacks. That’s because they rely on the concept of topics as a core processing trigger. Topics might include “house/temperature” or “/house/temperature/alerts” or simply “house/#”. Those topics inform the message broker what to do and how to handle the data.

But what happens if it receives a topic it doesn’t understand? And what if that happens a lot. Like, more than the broker can handle?

Exactly. Resources are needlessly consumed and the broker might become overwhelmed and unable to process legitimate messages. It’s the same old story – exhaust the endpoint and deny service.

So like most web-based, public-facing services, an IoT broker – whether speaking MQTT or CoAP or some other pub/sub protocol – needs some level of protection against malicious attempts to confuse and confound it. Hence, you’re going to need to gate the IoT.

This is where I note that this will be an emerging market. Like XML and SOA and APIs before it, there will be IoT gateways. They will be built with the premise of protecting and scaling message brokers, and they will speak the language of the IoT. To do that, however, the gateway will need to speak “secure” protocols, too, like TLS. Inbound data might be malicious, but it’s hard to tell under all those encryption. Gateways, then, will need to the visibility to peer inside messages and inspect topics to ensure validity before passing them on to message brokers.

We might not call them IoT gateways. We might call them IoT proxies, or tack on a specific protocol and call them MQTT proxies or gateways. But at the end of the day they will operate on the same principles that have long defended and scaled the protocols that enable communication over the Internet. Whatever they are called, these solutions will need to be able to “speak” the language of IoT, namely protocols like MQTT, CoAP, and AMQP. That’s because they must be able to understand how to identify topics and execute logic to determine the validity of those topics, to prevent brokers from needlessly wasting precious resources on processing and dealing with those that are not legitimate, and may in fact be malicious.

If we’ve learned anything from the application and messaging protocols of the past, it’s that they can and will be manipulated and exploited for nefarious purposes. Whether it’s to exfiltrate data or to cause a denial of service, attackers will be targeting the systems on which this rapidly growing market of IoT is dependent. An ounce of prevention is still worth a pound of cure.

Stay safe out there.