Zero Trust - Network Security

“Know the enemy and know yourself”

Know the enemy and know yourself is perhaps the most well known quote from Art of War. In Cybersecurity a lot of focus is given to the former part of the quote, yet it is an incomplete tactic. It’s a folly to only care about external actors and their TTPs (Tactic, Techniques and Procedures) yet not know the internal actors. To “know yourself” the cybersecurity team must also understand what the typical network behavior looks like.

In a typical network segmentation security model systems are allowed to talk within a subnet while firewalls control inter-subnet traffic. If there are five systems within a subnet, then they would be allowed to communicate to each other freely. If a sixth one is added to the subnet, then the default rules would allow the new server to communicate with existing servers. This make sense since firewalls were meant to protect the boundary and not the nodes.

The traditional approach to defending the network lays emphasis on the boundary and understanding the attack vectors against that boundary. The network subnet represents a trust boundary and devices outside the boundary may be considered untrusted, but a new device placed inside the boundary gains trust implicitly. With Zero Trust or ZT, there is a paradigm shift to this approach since there is no implicit trust for the devices or their communications. Protecting the network then evolves to understanding the typical behavior of the network, creating logical segments and locking down atypical paths and protocols of communication between segments and nodes. The approach to achieve this is depicted below (links to Microsoft Azure documentation, but the principles can be adopted in any network deployment)

• Open/flat network -> Network segmentation with many ingress/egress micro-perimeters -> Fully distributed ingress/egress micro-perimeters and micro-segmentation
• Unencrypted internal traffic -> All User-App traffic is encrypted -> All internal traffic is encrypted
• Minimal network traffic monitoring -> Monitor and capture critical network traffic -> Replace IDS (Intrusion Detection Systems) with NDR (Network Detection and Response) based on machine-learning models

It should be noted that the shift to ML based cybersecurity tools is inevitable for most models that implement the ZT Architecture. With extensive monitoring requirements that are inherent to ZT architecture, the SOC needs the capability to focus only on high fidelity incidents and relegate the low/medium alerts to automated systems like SOAR. ML models take on the burden of security analysts at much larger scale to surface up only incidents that require a human touch. This whitepaper by Vectra gives a good example of how Machine Learning provides this capability.

There are several network security models that can be adopted to implement a ZT architecture. Azure documentation has several examples of this pattern and all cloud providers would have similar capabilities.

In conclusion, if your network is a battleground, then you must convert that flat open field to a battleground lined with trenches, trigger wires and a confusing maze of tunnels so that the attackers are forced to heed another one of Sun Tzu’s quotes:

On dispersive ground, therefore, fight not. On facile ground, halt not. On contentious ground, attack not. — Sun Tzu, The Art of War