What You Need for Zero Trust Policy Discovery

The fundamental truth about micro-segmentation is that it will never be more granular than our understanding of the traffic to be protected. We truly can’t segment what we can’t see.

Most segmentation vendors now deliver some form of an application map that puts an application in a “bubble” of sorts to show its possible isolation. While a vast improvement over the alternative (with no visualizations), in reality, this is not enough to write a solid Zero Trust policy. Necessary – but insufficient. What else do we need?

As discussed in the introduction to this series, Zero Trust micro-segmentation success is determined by the effectiveness of the policy management process. Writing segmentation rules isn’t one task – it is a variety of analytical and decision-making steps. Therefore, making segmentation better requires a deep level of understanding and must be reflected in the right visibility and workflow for each step; there is no possibility that a single simple visualization will work for all tasks and decision points.

Policy discovery is the set of tasks that an organization goes through to understand an application and its context well enough to write a Zero Trust policy. It includes service, host, and application-level information – but also many other things.

Complete application context

The complete context for an application goes beyond its internal operation. It may communicate with other applications, likely connects to 20-30 common core services, has users coming from corporate and VPN locations, and may interact with SaaS services or other remote address spaces. Simply dumping all this on a map without organization is a recipe for confusion that will slow progress to a crawl!

It is important to summarize external connectivity into the normal named address ranges that might be in the IP management system. In this way, it is easy to spot user subnets, DMZ traffic, etc. Especially in the early days of a micro-segmentation deployment, there are more “unprotected” systems than “protected” systems. How are these systems displayed, organized and categorized? When these systems are objects in the policy model and displayed as such on the map, complexity and rule-writing are simplified. Finally, most applications exist for users. How is that user context understood, displayed, and available for action?

Ultimately, policy discovery requires complete application context, and that involves more than simple application drawings with a hundred or more lines to external IP addresses or hostnames.

Micro vs. macro workflows

Data centers or cloud environments are complex places, with much more than applications to consider. Application dependency maps are critical for understanding applications, but what about being able to see larger constructs? How is it possible to know what traffic is passing between Dev and Prod? How can one see all the database traffic on port 3306 across the whole environment to make sure none is missed? What about seeing the “reach” of a core service like LDAP or RDP to understand current activity?

Illumio’s experience in securing multiple environments over 100,000 nodes is reflected in having visualizations and exploration tools for the macro environment in addition to the application context. Writing effective abstracted label-based policies also requires the ability to visualize and inspect communications at every level of abstraction offered by the policy model. Interestingly, the application bubbles so useful for application views are of little use in this context. The best policy discovery solutions will have clear ways to show communications at all levels of abstraction and not just database dumps of collected flow data.

Require a micro-segmentation solution that provides the macro-level views essential to quickly address large swathes of traffic through bulk or aggregated policy writing.

Different views for different stakeholders

The firewall team will not be the only ones to inspect flows and policies during policy discovery activities. As the segmentation boundary moves onto the application server or container host, the operations and application teams will take a keen interest in making sure that every service they need has been provisioned properly. For these co-workers, their questions are best answered by purpose-built views tailored to the need to quickly inspect a policy and validate functionality. Many of the policy development details are not necessary, and indeed, distract from the core concerns of the application and operations teams.

Look for a micro-segmentation product that has thoughtfully constructed visualizations and workflows for application and operations teams. They are part of the workflow for policy and should have tools that support their needs. An RBAC filtered view is essential, of course, but expect more – get application owner-specific visualizations to speed the policy discovery process.

In Summary

No one can write policy faster than they understand what is required! Policy discovery is the first part of any policy management workflow. The policy demands of a modern application or containerized collection of microservices require full application context – well beyond a simple application bubble. Representing IP ranges, unmanaged systems, core services and more are all essential to understanding an application service in context.

Any good policy model will offer to abstract the communications at several levels or “labels,” so it is also important to have visualizations that support these higher-order policy objectives. After all, bulk policy is fast policy, so having the right capabilities will radically accelerate policy development.

Finally, micro-segmentation involves multiple organizations. Policy discovery is a team sport – make sure everyone has tailored discovery views so that each team works as efficiently as possible.

Fast, efficient policy discovery leads to fast, efficient policy authoring. Join us next week as we discuss what is needed to accelerate policy authoring.