The Zero Trust security model is conceptually simple, but fiendishly difficult to implement at scale. Zero Trust (ZT) simply means that we cannot trust the perimeter to keep the bad guys out, and therefore all internal network traffic must be considered malicious until proven otherwise. Given the plethora of successful attacks it’s clear that relying on the perimeter isn’t viable, and in any case the perimeter concept is falling apart as we move to hybrid multi-cloud architectures and remote and 3rd party workforces. The much bigger headache is figuring out what to do next.
The heterogeneous, dynamic nature of today’s IT environment makes Zero Trust implementations problematic. The original ZT research (by Forrester) called for internal segmentation with security gateways as the primary solution, but this approach doesn’t scale. There isn’t enough information about each endpoint to categorize them for segmentation placement, and the necessarily large number of gateways is expensive to acquire and operate. Perhaps worst of all, maintaining security policies that offer viable protection but never block production traffic is next to impossible, especially given the growth of encrypted and east-west data flows. Some segmentation technologies rely on endpoint agents, but good luck trying to install that software ubiquitously, and heaven help you if they cause an outage.
Another approach is to authenticate the endpoints. This works reasonably well for a subset of devices (e.g. company owned laptops), though it’s pretty obvious that just because a device is authenticated doesn’t mean it’s not compromised. In any case the fact is that devices are proliferating, and the IT staff is in no position to hinder innovations that have clear business value. So we see thousands of new devices coming onto the network, most of which can’t easily be authenticated. The extreme example is IoT devices, which are usually very limited in resources and ability to be customized. In many organizations you can’t even scan these devices for vulnerabilities, let alone put agents on them.
A better approach to Zero Trust is the use of deception technology. Deception is more pragmatic in the sense that it doesn’t presume that you’ll be able characterize all the endpoints and legitimate data flows. Instead, deception sets up a parallel virtual infrastructure and data sets with no business purpose at all. If an endpoint tries to access any of these assets, it is extremely likely that the endpoint is compromised, since there is no legitimate reason for such activity.
Enterprise-grade deception scale through automation: Decoys and lures are tuned automatically to blend in with the rest of the network and are deployed through deception orchestration. Deception is well-suited to IoT environments: It’s possible to deploy decoys that mimic IoT devices (to appear legitimate to attackers) but do not touch the production devices in any way. Hence they can be placed on the same segments as IoT devices and detect compromised IoT units if they try to touch the decoy. Lastly, unlike a number of behavioral based approaches, deception doesn’t require an Internet connection back to the vendor – a definite security risk few people are comfortable with.
Zero Trust is a great idea that’s hard to argue with. Implementing isn’t easy though, and we suggest that implementing deception in parallel with implementing whitelist internal controls is a winning combination.
Authors
