What’s Important in a Policy Model for Microsegmentation?

Of all the features to discuss in a microsegmentation solution, most vendors wouldn’t start with the policy model. However, in terms of the potential outcome a given solution might create, the policy model determines what is possible. Therefore, thinking through what is necessary in a policy model is excellent preparation for making a high-quality, low regret purchasing decision. Let’s examine each of the important components of a desirable microsegmentation policy model.

Multi-dimensional labels

Microsegmentation policies use labels to abstract segmentation from underlying network addressing and devices. Ideally, these labels will be “usefully multi-dimensional.” A flat namespace of unlimited labels is not useful; it offers no summarization or structure to hang policy statements that affect many machines. If you label every system in a flat namespace, it is barely better than just using IP addresses to specify the policy. Interestingly, while no limits should be placed on the number of labels within a given policy dimension, constraining policy dimensions has proven useful in large-scale deployments.

We humans can easily visualize four dimensions: three physical dimensions plus time, for example. But, if the physicists are correct and we live in an 11-or 13-dimensional space, only math can capture those dimensions. They are impossible to visualize in our brains. This has practical consequences for microsegmentation. You can program a computer to understand and compute an 11-dimensional policy, but no human will be able to understand it. Humans need to be able to inspect, audit, and understand microsegmentation policies.

In our experience, four dimensions can effectively model even the largest networks on the planet for policy purposes, while still preserving our ability to understand the model. So, look for a policy model that has more than flat-tag or label space. The structure of a few dimensions works at the scale of hundreds of thousands of systems but remains easy to understand and work with. Check out this video to learn more about the power of labels.

Rich-object model

A quality policy language will have a sufficiently rich-object model. A hyperscale enterprise data center is a complex place. It is obvious that the model must accommodate everything that needs to be protected: servers, VMs, containers, cloud instances, etc. But these protected systems are not enough to abstract all the useful policy primitives. You need to have objects for service/port mappings and IP-address ranges. Within shared servers – perhaps a server with multiple database instances – you must be able to abstract these instances from each other as distinct virtual services. Containers and container hosts should be both “first-class citizens” who appear on all visualizations and a part of policy statements. Interestingly, it is also important to add unprotected systems to the object model – especially in the early phases of deployment when more things are unprotected than protected and these systems communicate with each other. Being able to represent all flows cleanly makes it much easier to specify the desired policy. The best solutions will even be able to build policies for the unmanaged objects should you wish to have it available for export and possible implementation.

Inheritance

Policy inheritance is the only way to scale microsegmentation policy to cover an existing data center. If about 80 percent of the traffic flows within the data center, that implies that the existing perimeter firewall rules only cover 20 percent of the traffic. That means that the potential for five times as many rules exists within the data center as currently exist in all the firewalls! The abstractions provided by the policy model and its useful dimensionality must combine with a pure allow-list policy model. Only in this way can policy be written once to apply in many instances. Inheritance and smart policy automation around common microsegmentation policies, like application ringfencing, combine to form the only proven way to segment tens of thousands of systems successfully.

Declarative vs. imperative

The only policy model to successfully microsegment over 100,000 workloads uses a declarative method to express segmentation desire. A declarative policy model only requires one to specify the desired outcome. An imperative policy model requires the solution to be specified exactly to create the outcome. A traditional firewall ruleset is imperative: every statement must be present in perfect order and with perfect accuracy for the desired protection to exist. This causes no end of difficulty and complexity. However, the ideal microsegmentation policy uses declarative language exclusively: “I want to ringfence the Ordering application inside my Production environment.” How that is accomplished is the business of the Policy Compute Engine behind the policy language. In this way, the policy is always easy to specify, easy to understand, and easy to develop. Given the scale of work to be done, anything else will result in failure.

Consistent application

When all the necessary primitives exist, the best microsegmentation solutions will use them consistently across every area of the product. Labels aren’t just for policy authoring, but must inform visibility, policy distribution, and policy enforcement. Role-based access control (RBAC) should follow the label structure exactly so that application owners, DevOps, and others can access everything they need, but not more. Securing automated deployments in particular demands this precise delegation capability. A useful, clear, and simple label structure creates a mental model when it is consistently applied. Almost immediately, administrators intuitively understand how the solution works and can anticipate outcomes. This intuition quickly turns to speed, speed to mastery, and mastery to finished projects. Simplicity, clarity, and consistency are the solution for complex data center environments.

Complete abstraction

I am fond of saying that automation eats metadata for breakfast. Automation can’t proceed any faster than it can be abstracted. A successful policy model needs to abstract away any vestiges of network addressing and the enforcement mechanism itself. The policy must deal only in what is desired. In this way, automation can easily state the outcome: “Web must talk to App.” The rules required to make that true will be ever-changing in a dynamic cloud or automated environment, and that complexity can’t be exposed to the automation framework if it is to scale. A policy that relies on IP addresses, no matter how well-meaning, will simply not scale. Similarly, the enforcement mechanism must be hidden. Once the desire has been stated, the microsegmentation policy engine should figure out the best way to implement that policy given the resources it knows about. In this way, as systems come and go, the number of enforcement points will flex, and so must the policy and rule base. Only a fully abstracted policy will give DevOps and cloud architects the capabilities they need to interface seamlessly with the microsegmentation solution.

Large-scale policy

Many years ago, megafauna dominated the Earth. Giant versions of plants and animals were on every continent, and they would tower over the species we have today. The best policy models include scale factors that tower over the simple descriptions of individual applications. The ability to group any labels across any policy dimensions allows for single policies to affect systems in multiple data centers, environments, or applications. When writing policy for the hyperscale enterprise, these “mega policies” move with astonishing reach, speed, and efficiency to cover the enterprise with microsegmentation policies.

A policy model might seem like an abstract and unimportant concept. But for a successful microsegmentation deployment, nothing could be further from the truth. The policy model determines what will and will not be possible to express and how easy or hard it will be to do so. A company can quickly change the color of their UI, but it will struggle to fix a broken or improperly designed policy model. The most proven microsegmentation policy model in the world provides full abstraction from network addressing and enforcement points though a “usefully dimensional” label model. This model is consistently carried through every function of the product. When full object models combine with inheritance and declarative models, it is possible to easily and quickly state the desire outcome and have it be true in the world. Microsegmentation succeeds at the scale of hundreds of thousands of workloads only through a mature, complete, and well-designed policy model.

Next up in this series on questions about microsegmentation you don't know to ask, we’ll discuss what it takes to automate microsegmentation policy.