What You Need to Author a Zero Trust Segmentation Policy

Last week, we discussed the capabilities needed to discover the application and broader environmental context required to write a Zero Trust Segmentation policy. Once we know what is compulsory, we need to express that in policy statements. Any good micro-segmentation solution will move seamlessly from discovery to authoring and fully support all of the workflows required to write a fine-grained segmentation policy efficiently. Let’s discuss what accelerates and supports Zero Trust Segmentation policy.

Say what you want, not how to do it

Historically, writing access-control lists (ACLs) requires us to know what we want and how to do it. Large, complex tables of rules result. Zero Trust Segmentation works on a declarative policy model, by contrast, and creates a separation between “policy” and “rules.” Policy is the outcome we desire – such as separating DEV and PROD environments. The rules or ACLs required to make that policy true are an output of the policy engine, not human effort. This radically simplifies policy authoring.

If I write a rule permitting one device to talk to three others, I don’t need to write four rules. I just need to write one policy that says the one server can talk to the other three. The policy engine creates all the rules to make that policy true. When taken at the scale of an entire data center or cloud deployment, this simplification accelerates the development of a Zero Trust Segmentation policy.

Familiar names vs. IP addresses

Writing traditional firewall rules will always be slow due to the constant need to translate between IP addresses that the infrastructure understands and the names that we give servers in conversation. Eliminating this translation radically reduces the time to write a Zero Trust Segmentation policy.

The best situation is when the organization can reuse the names that already exist inside CMDBs, SIEMs, IP address management systems, host name conventions, server names, etc. When familiar names label every system in the visualization and provide the abstraction for policy writing, suddenly everyone can understand and write Zero Trust policy. There is no translation required, and the whole team can quickly reach consensus on that the written policy matches the need discovered through visualization.

Use inheritance to reduce policy burden

Once we have abstracted the Zero Trust Segmentation policy into names (or labels), we can take advantage of one of the best parts of a Zero Trust allowlist – policy inheritance. A pure allowlist does not require attention to rule ordering, unlike a traditional firewall.

In a firewall, the mix of allowlist and denylist rules means that the rules must be in a strict order to function as designed. In an allowlist, because things are only permitted, it makes no difference in what order they are permitted or if they are permitted more than once.

This means that Zero Trust Segmentation policy can be freely inherited. I can write a policy once and reuse it as many times as needed. A workload might derive part of its policy from the PROD environment policy, the data center level policy and the policy we have written for all databases. We can define policy for core services once and then have every workload in the environment assume that policy. Inheritance makes Zero Trust policy authoring much easier than traditional methods.

Distribute rule-writing to get scale

Firewall rule writing has long been centralized and managed by a network security team since the devices are effectively part of the network architecture. This has created awkward conversations where the firewall team needs the application team to describe in IP addresses how their systems work. And only then can the firewall team translate that into rules. But why bother with all that communication and translation?

With Zero Trust Segmentation and a robust role-based access control (RBAC) capability, rule-writing can be distributed. When the Zero Trust Segmentation solution has been designed to provide application specific views and capabilities, it is possible to have application owners write or validate policy for the internal operation of their application, and then for the centralized team to approve their work and add in the policies for core services, data center and internet access.

A strong Zero Trust Segmentation solution provides agency to the application and DevOps teams throughout the policy authoring process. The more your organization wants to automate, the more important this delegation becomes. When the whole team can work toward shared goals it builds trust, organizational cohesion, and speeds the delivery of a Zero Trust Segmentation policy.

In summary

Data centers and cloud environments are complex, and it would be natural to assume that writing a segmentation policy would share the same complexity. But the best Zero Trust Segmentation solutions replace the traditional firewall rule development process with simple, scalable and effective workflows. A declarative policy model means that you can say what you want, not how to do it.

Humans are good at saying what they want, and a smart policy engine can turn that into rules for the infrastructure. When the policy is based on familiar names and can be reused multiple times, it reduces the work for the entire team.

And best of all, when the whole team can collaborate, the inefficient walls between teams break down and the whole organization can work together to secure the critical assets. Zero Trust Segmentation improves every aspect of segmentation policy, simultaneously tightening segmentation while also reducing the burden on the organization.