In this series, we have discussed Policy Discovery and Policy Authoring so far. Once you have a policy to implement, you need to get it calculated, turned into rules and distributed to enforcement points. After all, the Zero Trust policy can only operate in the places it reaches! Let’s make sure we can instrument that policy in as many places and as effectively as possible.
Automate policy into rules
The first step in turning a human-readable policy (that is based on labels or metadata) into an enforced Zero Trust Segmentation policy is to translate it into rules that the infrastructure can understand. We have discussed how important it is for humans to specify policy without using IP addresses, but all the enforcement points require them! The policy computation function has a critical role to play.
Basing the Zero Trust Segmentation policy on labels means that the same automation driving application instances can drive the segmentation policy. Without needing to know the IP addresses, or even the number of similar application services, application automation can obtain the correct policy just by “stating its name.” When the human readable policy can be automatically turned into enforceable rules, segmentation becomes a service – just like the application components themselves.
Make it dynamic and continuous
Policy calculation must be dynamic and continuous. In a modern data center or cloud deployment, automation adjusts the applications constantly. This means that IP addresses change, instances spawn, do their work, and are removed. SaaS service controllers seamlessly shift load to a new IP address in a cluster of unknown size. This means that the IP addresses used in any ruleset must be updated as the infrastructure evolves. Policy computation and distribution must be continuous and near instantaneous to keep the defined policy accurate in all of the enforcement points.
Use existing enforcement points
A Zero Trust Segmentation policy is only as good as the number of places it operates. Luckily, you already own all the enforcement points you will ever need! Every modern operating system has a perfectly useful stateful firewall built in. This is IP-Tables or NetFilter if it is a Linux-based machine or the Windows Filtering Platform if a Windows-based instance. Similar OS-based firewalls exist for AIX, Solaris, and even an IBM System Z mainframe! Network switches from Cisco and Arista take ACLs, as do load-balancers from F5 Networks. It is not a stretch to say that almost every network attached device has the ability to take segmentation instructions.
So, any good micro-segmentation solution should use as many of these enforcement points as possible. After all, why rely on a vendor agent to do enforcement when the kernel firewall is some of the most stable and performant code available? Look for a solution capable of programming existing network and cloud network and firewall instances. Embedded systems and OT devices don’t have an in-built firewall and won’t take a vendor agent, so you’ll want a solution that uses all your available enforcement points.
Performance and scale considerations
Performance and scale must be considered when evaluating Zero Trust Segmentation solutions. Architectural choices matter, just as with any hardware forwarding device like a switch or router. Calculating a single policy during a proof-of-concept is hardly challenging.
But what happens if you have a fully automated datacenter where 40,000 compute instances are removed and replaced over a 15-minute interval in a wave that sweeps across a global data center complex? All of a sudden, the calculation time matters.
The only way to maintain correct policy in an automated application environment is to keep up with the automation. But even once calculation is complete, the policy must be distributed and then enforced. This convergence event is not unlike hardware routers converging their routing tables.
How effective is the policy distribution architecture of the solutions you are considering? If you have half of a data center fail, kicking off a large disaster-recovery re-route of traffic, the timely distribution of policy updates will suddenly become critically important to maintain application availability.
Leading vendors have experience converging full Zero Trust policies across as many as 500,000 objects. Ensure that the vendors you are considering can substantiate claims of multiple location failover and simultaneous policy convergence.
Getting a defined policy calculated and then distributed places the biggest performance burden on the micro-segmentation solution. Any solution can work in a simple evaluation environment. But only enterprise-scale solutions have the ability to withstand network partition events, failover and disaster recovery scenarios, to say nothing of demanding application automation reconfigurations.
To have an effective policy distribution capability, you will want to fully understand how a vendor solution automates human readable policy into rules. The policy should be distributed to as many of your existing enforcement points and possible, with mature, stable kernel firewalls preferred to any proprietary vendor solution. When you have continuous and dynamic policy calculation and distribution deployed, Zero Trust Segmentation becomes an available application service and can be fully automated by existing application automation.
Join us next week in our final installment as we consider what is required to enforce a Zero Trust Segmentation policy.