The Inversion for Security in the Internet of Things

By and large, there’s been a lot of talk about the Internet of Things. So far, however, most of the focus concerns what happens when attackers sets their sights upon a device. These stories derive from the notion that many of these devices are potentially vulnerable and essentially unpatchable. Many network-connected devices have vulnerabilities that cannot be fixed easily. This became glaringly obvious with the growing awareness on the vulnerabilities found in SCADA devices, which led to the development of better sets of best practices for network segmentation and isolation as well as threat prevention against the vulnerabilities of these systems.

In recent months, a new narrative has taken shape on the Internet of Things, which stems from an inversion of the hypothesis above. Instead of thinking about how to protect against an attack on a network connected device, what can we do about the network connected devices that are doing the attacking?

Fundamentally, devices do what they’re programmed to do, and we assume that they will do that. But that doesn’t mean that they cannot be programmed to do other things. For instance, I was showing my coworker a device that had modified programming that allowed it to conduct a number of activities it wasn’t supposed to be able to do. That's a simple example, but it creates an entirely different set of network security challenges, for the traditional attack lifecycle doesn’t start with baiting the user to exploit an endpoint, but rather the introduction of a compromised network-connected device to the network.

Compounding matters further, there are no “users” that are associated with network connected devices. Too often network devices are given too much access to the network and given free will to do whatever their programming allows.

I believe that as we explore the issues surrounding the Internet of Things, we are going to be adding yet another dimension to the principle of Zero Trust. Zero Trust has traditionally been thought of as a data center network segmentation model, namely the idea that "nothing gets access until we establish who it is."

But with the Internet of Things, Zero Trust must be applied at the access layer, namely no device should associate to the network at all unless it can be identified (and ideally, authenticated), and it should be given a minimal number of rights to perform a specific number of functions. This comes down to defining the applications that the device should be able to perform, and restricting the network zones in which it’s allowed to perform these jobs. Activities that are outside of the device’s scope should not be permitted, and organizations should be especially wary about network connected devices setting up shells or remote access tools to the Internet.

There's more that I'll cover on this topic in the near future, but for now, I'd like to briefly mention that device-identification is a capability that’s present with the integration between the Palo Alto Networks next-generation firewall and the Aruba Networks wireless infrastructure. This is a solution that implements very tight integration between the users and devices identified by the wireless network environment, and the content that they can access with the next-generation firewall. If you’re interested in learning more about this topic, take a look at our solution brief about this integration.