Transcript
You have remote access, cloud, data center, the campus, and even IoT and OT environments. But what if you had one policy to rule them all? Would it bring peace and security to your kingdom? Or have you running from Mordor? Welcome to Forefront. I'm Nixon Kada, an engineer at Forescout. In this episode, we'll unpack what unified policy really means in UZTNA and outline a practical approach which any organization can take. Let's do it. First, let's go over what UZTNA, or Universal Zero Trust Network Access, actually means. We already have zero trust. So what makes this universal version any different? In truth, not much. It's really more of a steering correction. When NIST released the Zero Trust Framework in late 2020, the world was being turned upside down by the COVID pandemic. And with it came all the challenges of handling the surge in remote workers, where zero trust concepts were rapidly adopted. So UZTNA can be seen as an effort to shift attention back to the core domains of campus, data center, and operational technology environments. Now, you won't find any official frameworks for UZTNA because it's almost entirely grounded in the original Zero Trust publication. So let's quickly review that model. You've got your control plane, where the policy decision point, or PDP, sits. It's constantly being fed context from a bunch of other sources, such as threat intelligence, identity, compliance, and more. In order to make an informed decision on whether a user or device should have access to a resource, and if so, to what extent. That decision is relayed to the policy enforcement point, or PEP, in the data plane, which actually controls access. So it's clear that the PDP plays a central role in this idea of unified policy in UZTNA. But now let's get practical. What would that actually look like in the real world? Let's break it down into three stages. We'll start where most organizations naturally begin their UZTNA journey, by aligning the multiple policy systems across the environment towards a common goal. This is key because it establishes a consistent foundation of standards to build on later. In this stage, you have coordinated policy domains, where the individual policy systems across the enterprise all follow the least privileged access principles of zero trust. What's really being coordinated here is policy intent, not the actual enforcement logic or rule syntax. This means there's no shared control plane, and alignment is the result of your team's manual efforts in configuring each system to meet a common governance model, as outlined in NIST 800-207. And that's largely unavoidable. These technologies were each born to handle their specialized domains, and as a result, they all bring their own unique policy constructs and logic. Okay, so what's the strategy for rolling out coordinated policy domains? Well, to no surprise, more important than the technology are the people and processes. Get those cross-functional teams ready to handle shared policy governance and review. Which might be a new concept for some organizations, as owners of these different domains will need to elevate their level of cooperation and planning. Part of that effort will be in establishing an identity and classification model that will remain consistent across the domains. This is important because nearly all controls ultimately map back to the role of the device and user. This will aid in the next step of writing policy intent in plain human language before translating it into local rules. For example, only compliant corporate workstations may access HR applications. From there, it's up to each domain's administrators to understand how to apply that intent when crafting local policies. This is where careful consideration of each system's capabilities really matters. Can it enforce Network Layer 2, 3, 4, or 7 controls? Which zones, devices, or users can it apply to? For example, an on-prem campus system rule might be, if corporate and compliant, then move to trusted VLAN, else leave in quarantine. But for a data center rule, that might look like, source corporate trusted, destination HR app servers, service 443 SSL, allow. In the end, you might have a multi-layered approach, touching multiple PDPs, each applying the same intent, but with different levels of granularity. The good news is your policies are now aligned, but every domain is still making decisions in isolation. We move towards centralizing that decision process in our next stage, Federated Policy Orchestration. Here, while each PEP still maintains its own independently managed policy set, the decision of who those policies apply to and under which conditions is now determined primarily by a central PDP. This is necessary because while the previous stage gave us aligned policies, every domain was operating in isolation. This means it simply cannot scale or adapt fast enough to changing risk. Federated Policy Orchestration is an important leap from manually aligned static policies to centrally driven, real-time decision making. This maps to the Zero Trust Framework and provides not only centrally driven policy behavior, but also unified visibility across the domains. So how do we make that jump? It all starts with the brain of the operation, the central PDP. In order to make those dynamic policy decisions, it needs to collect data from two key categories, identity and security context. For identity, the central PDP ingests information on users and devices from systems it integrates with. This is in addition to any native discovery capabilities it has. From there, it normalizes and enhances the data to build a consistent identity model that can be applied across all domains. This is key because it makes sure the right policies get applied to the right users and devices. Security context can include a wide range of sources, such as vulnerability scanners, data detections, activity logs, EDR, MDR solutions, and much more. All of which can either plug directly into policies to initiate responses or get factored into the PDP's risk algorithm to produce a score that represents the overall security posture of a user or device. Since the PDP is now making event-driven decisions based on identity and security context, it can respond in real time. This offers a clear advantage over the Coordinated Policy Domains model. This requires a policy engine with logical constructs from all domains and response actions tailored to each PDP's native policy model. Those actions are typically carried out via object tagging, group membership or risk scoring, which qualify users and devices for pre-existing rules inside each PDP's policy system. For example, we have a rule in our cloud domain that only users with risk scores less than 5 working from compliant devices can update the HR web system. That risk score can be dynamically updated by the central PDP, which also adds or removes the identifier for the workstation in use from the compliant devices group. This is why the previous stage is important because while we now have a big advantage with Federated Policy Orchestration's centralized decision making, the enforcement rules which follow your Zero Trust strategy still need to be present in each domain. And there's a silver lining to that. If your PDPs ever lose contact with the central PDP, they still have a valid rule set to fall back on. Now at this stage, you have in place a system of continuous assessment and response that is essential to use ETNA, and the tenets of Zero Trust have been met. So what if we took it further? What would the idea of one policy for everything really look like in practice? The idea of unified policy governance is an appealing one. Even with Federated Orchestration in place, having to maintain multiple policy sets across each domain is time consuming and has operational complexity. If there were truly one place to manage policy across all domains, then both the controls and logic could be more easily understood and implemented. Of course, being able to discover, identify, and continuously assess all subjects across every domain in addition to having the relevant access controls for those devices and users is a very tall order. Now there are two possible ways this can play out. One is that a single supplier becomes responsible for your entire enforcement stack, offering centralized policy management and enforcement capabilities. The other is having a neutral solution serving as the central PDP that can directly manage policies on third-party PDPs either through a standardized API or direct integration. Let's look at the single vendor design first. Here, each domain's policy decision points become collapsed with a single point for policy administration. However, each PDP will likely still maintain its own policy engine. Similar to the Federated model, data for identity and security context will still be centralized at this PDP. The key difference with unified governance is that the policies themselves are authored at the central PDP and pushed directly to the PEPs across each domain. In practice, that means that the policy model now has to include constructs that span every enforcement domain, which brings about some challenges. Different domains support very different control semantics. So even within a single vendor ecosystem, policies would often need to be shaped based on the domain's capabilities. For example, Layer 2 controls are built around very different subjects and concepts that you would find at Layers 4 or 7. The advantage of a single supplier model is that in theory, the translation process from policy intent to enforcement semantics should have fewer obstacles because the PDP and PEPs are designed to work within the same ecosystem. Now the neutral PDP model has similar goals, where identity and security context are still consolidated. The difference here is that being neutral, the PDP needs to find a way to interface directly with the various enforcement systems. In this model, unified policy is expressed through a vendor-agnostic control plane and then delivered to each PEP through integrations capable of translating central policy intent into the native enforcement rules of the PEPs. Because each enforcement domain has differing control capabilities, the unified policy model must remain both domain-aware and capability-aware, shaping how the policy is interpreted and applied. In theory, this approach preserves vendor independence while still pursuing centralized governance, with the core challenge shifting from enforcement ownership to policy abstraction and translation. So, is unified policy achievable? The unified policy governance stage simplifies what policy is managed, but it doesn't eliminate the need to understand how each domain enforces it. Strides are being made under the single-vendor model, but it's still lacking a solution for all domains. Even if possible, there are real risks of vendor lock-in in addition to the reality that no single vendor can excel in each domain. Real compromises would need to be made for the goal of unified policy management. The idea of a neutral central PDP remains highly ambitious. Even if the technical challenges are overcome in translating policy intent into the native enforcement language of each PEP, it would still require strong, sustained participation from vendors from all domains to support this level of shared operation. In SB 800-207, NIST makes it clear that Zero Trust is not a single architecture but a set of guiding principles for workflow, system design, and operations. In other words, Zero Trust was never meant to prescribe one universal control model or a single way to express policy across every domain. It defines the outcomes we're trying to achieve, continuous verification, and least privileged access, not a single mandatory design. And that wraps up our episode on designing a practical UZTNA policy framework. We covered the initial stage of coordinated policy domains, where manual efforts are made to align the multiple enforcement points and their respective policies to the ideals of Zero Trust. We then advanced to the federated policy orchestration model, where a central PDP takes on the role of making real-time, context-driven access decisions based on identity and security posture, while calling upon each domain's native controls when needed. And lastly, we explored unified policy governance, where policy authoring itself would become centralized, either with a single supplier owning the entire enforcement stack or through a neutral PDP. We hope you found this practical approach to UZTNA policy useful. Thank you. If you'd like to learn more about Forescout's solution for UZTNA, please check out the link in the comments below.
