Using Cloudflare One to Secure IoT devices

There is probably an insecure device with an exploitable vulnerability sitting in your house. And your office. And probably even your child’s school. Cameras, printers, speakers, access control readers, thermostats, even heart monitors... all of these devices are, or can be, Internet of Things (IoT) devices. These IoT devices are seamlessly integrated into our modern lives to improve efficiency and control of our environments — yet they are notoriously insecure. This is due to the constrained nature of device hardware and their limited computational capacity, which often lead to minimize access controls, hard-coded passwords, and an inability to patch remotely.

The reality of this threat can play out dramatically. Take, for example, the 2016 Mirai botnet attack, in which hackers exploited millions of IoT devices to become a large-scale botnet network capable of launching DDoS attacks that took down major portions of the Internet, including Twitter, the Guardian, and CNN. These types of attacks are hardly an infrequent occurrence. Cloudflare experienced this reality firsthand in March 2021, when one of our potential vendors for physical security cameras, Verkada, was compromised. The incident allowed a hacker to access Verkada's internal support tools to manage the cameras remotely, enabling them to attempt to move laterally to other devices in the network. Thankfully, our use of a Zero Trust model at Cloudflare prevented the hackers from moving laterally; the incident affected the cameras and nothing else.

But even if we're unaffected, we view security incidents as a challenge to take our security products one step further. So we asked ourselves: can we use our own products to secure IoT devices themselves — even on the same network as production systems - thus ensuring any compromise of these notoriously insecure devices is isolated? Using Cloudflare One, the answer is yes.

Zero Trust Model

As aforementioned, Cloudflare was not impacted by an IoT compromise because we use a Zero Trust model. If the environmental considerations are suitable, such as in Cloudflare's corporate offices, the enterprise network can be ring-fenced with a Zero Trust model. Lateral movement is prevented because hitting any other part of the network requires authentication for access. Given that the IoT device itself is not isolated, careful attention must be paid to put all other network points of entry behind zero trust access.

However, not all environments can be so diligently controlled. Take, for example, data centers. The presence of other vendors, complexity of old production networks, and prevalence of machine-to-machine connections means we can't provide the same zero trust guarantees upon installing an IoT device (such as an access reader or a camera) as we can in our corporate offices. As the complexity of the environment grows, successfully deploying a Zero Trust model to prevent successful lateral movement from IoT devices only becomes more difficult.

VLAN

Many enterprises deploy their IoT devices on a completely separate network from production, utilizing an out-of-band network or VLAN. While VLANs create isolation at Layer 2, they require access lists at their upstream routed interface to restrict Layer 3 traffic. And many network administrators want additional configurations for more stringent guarantees, such as access lists for both ingress and egress traffic and logging for both successful and denied connections. The management of these access lists can quickly grow in complexity: each new network is another landscape to protect, patch, and detect.

If not properly configured, the security guarantees of VLANs can be easily undermined. Take a network with two separate VLANs; if the access lists are not consistently applied to the two respective switches, a hacked device from one VLAN could easily pivot to a device under the other VLAN. A network administrator could use private VLANs on a per switch basis but, again, this adds additional complexity.

Consistent configurations and architectural choices, from the access list rules to the type of gear used at each site, are required to successfully deploy VLANs to prevent lateral movement. As the number of sites increases and an environment's footprint expands, this only becomes more challenging.

We use our own products to isolate devices without deploying on a separate network. This provides security guarantees without requiring additional hardware. It's a severless, infrastructure-less solution to isolating a network.

How is this done? The hardware device (for our proof of concept, a Verkada camera) is connected to a Power over Ethernet switch, which is configured to tunnel its traffic via Anycast GRE to the Cloudflare Global network. There, we can configure rules from the Cloudflare dash to write egress rules, ensuring that outbound traffic only goes where it is supposed to. Thus, lateral movement is prevented.

This architecture allows a network administrator to control traffic from Layer 3 and up from a single dashboard by applying policies to ingress and egress traffic instantly. This architecture provides a simple set-it-and-forget-it solution that can adapt to a changing environment: protection is vendor agnostic, uses common standards, and log collection is automatic. Compared to other methods of lateral movement protection, Cloudflare provides superior ease, adaptability, and security guarantees necessary to securely manage any environment with IoT devices.

In Q4 2021, we hired a trusted pen test partner, to test this setup by replicating a rogue device attempting to pivot to production networks from behind the Cloudflare One architecture. They were unable to move laterally — as in, this architecture works.

Given that this architecture has been tested, we will begin to formalize the rollout of Cloudflare One internally at our data center sites as part of a Physical Security initiative to keep our most trusted assets secure.

For more information on using Cloudflare One at your enterprise, please reach out to our Sales team.