Edge Computing and IoT: Security Through Zero Trust
Originally published by CXO REvolutionaries here.
Written by Bryan Green, Chief Information Security Officer, Zscaler.
Though they're often used interchangeably, internet of things (IoT) and operational technology (OT) refer to adjacent but fundamentally different technologies. Both share common characteristics, such as being purpose-built hardware – a sensor, pump, or refrigerator, for instance – lacking a traditional user interface, and are typically headless.
Security challenges are another common thread running through IoT and OT. IoT and OT devices are susceptible to the same bugs, vulnerabilities, and misconfigurations we’re accustomed to with traditional endpoints and infrastructure.
They can be compromised, and once compromised, become a persistent foothold through which subsequent, more problematic attacks become possible, escalating the business impact they create. Threat actors sometimes target IoT/OT devices specifically because they're often overlooked from a security standpoint, flying below the radar. The manufacturers of elevator control systems, security cameras, alarms, and other "smart" devices often prioritize features and functionality over cybersecurity, while also having constraints related to code freezes and manufacturing timelines.
What’s the best defense? Ideally, security leaders modernized networks to a Zero Trust Architecture (ZTA) to reduce the attack surface. ZTA, as defined by NIST 800-207, provides a means to securely connect IoT/OT infrastructure while mitigating network security related risks. At a high level, ZTA is about removing the implicit trust of legacy networks. Simply, clients and servers should not co-exist on the same network subnet and do not have direct east-west IP connectivity. Instead, that connectivity should be brokered by a Security Service Edge (SSE) to inspect for malicious content and enforce security policy. (See diagram below.)
Generally, IoT and OT devices are not high-performance computing platforms. In most cases, they’re running stripped-down, outdated operating systems with custom IP stacks and hardware to save production costs and/or conserve power for battery-operated devices. The endpoints lack the technical resources to implement secure computing principles and yet at the same time they’re exposed to corporate networks, or often the public internet, and all the potential risks that implies.
The size and scope of IoT portfolio are also growing swiftly. Beyond thermostats and smart televisions, new IoT devices like augmented reality headsets and autonomous vehicles are projected to become increasingly popular and broadly deployed in both the consumer and business spaces, requiring substantially better security than they have today.
Further complicating IoT and OT architectures is the increasing deployment of the edge layer – an intermediate layer of computational technology that processes large volumes of data generated by IoT and OT devices. The edge compute infrastructure serves to process, consolidate, and then offload it along to higher-level fog or cloud services for analysis, correlation, or additional processing. Edge compute (just as the IoT devices that feed them data and the clouds they serve) should be incorporated into the ZTA, yet organizations today are typically only beginning to come to grips with the complexities involved.
Adding these devices securely to a ZTA will often require a new approach implemented at both a technological level and a business process level. Let’s walk through a couple of possibilities, ranging from the most speculative and long-term to the most practical and short-term.
ML-based policy recommendations
One approach to securing IoT devices lies in leveraging innovative technologies such as machine learning (ML) to build zero trust policy recommendations. Today, zero trust exchanges can observe many characteristics of IoT devices, such as their currently network access and usage patterns. Using large datasets and multi-dimensional observation, ML can predict which IoT devices might need access in the future and which types of access are potentially anomalous. These characteristics may include parameters such as hostname similarities, IP groupings, device fingerprinting, traffic patterns, packet payloads, or other observable traits.
In theory, it is also possible to create an ML model sufficiently optimized to run in such a resource-constrained environment while also sufficiently advanced to recognize a security breach underway and shut down or logically quarantine the device to prevent escalation.
Security service edge capabilities implemented via a trusted partner
The most plausible option is directly routing or tunneling traffic to a Security Service Edge using IPSec, Generic Routing Encapsulation (GRE) tunnels, or Proxy PAC files. Where possible, implementations via a lightweight agent on the IoT device provide improved outcomes.
With these options, the service edge will apply authentication and authorization while also enforcing business and security policies. The same approach applies to connections to edge computing infrastructure, meaning that all devices, irrespective of the local network, are secured and managed similarly.
While this approach is available today, it will still be essential for interested parties to select the right SSE service provider – meaning, to a significant extent, one that provides optimum performance. That is, because IoT and edge devices must be in continuous communication, the SSE platform must be both performant and fault tolerant, such that overall throughput and availability aren’t degraded.
The key will be to collaborate with a trusted partner that offers not only high-performance ZTA and SSE capabilities but also numerous data centers to scale and load balance the organization’s network traffic so as not to incur a performance penalty. This way, the organization can secure critical infrastructure using ZTA without compromising throughput or creating unacceptable latency for business services.
Sign up to receive CSA's latest blogs
This list receives 1-2 emails a month.