This article is the second installment in a multi-part series. You can find part 1 here.
A prevailing idea that you’ll find in my writings and presentations about multi-domain architectures, is the rather bold statement that “real” or “true” Zero Trust cannot be achieved unless it is pervasive end to end throughout the whole of enterprise architecture. Successfully deploying a Zero Trust strategy across the whole of the enterprise becomes very unlikely when organizations try to retrofit their legacy architectures to reverse engineer their environments into Zero Trust compliance. There must be a common glue that seamlessly connects each domain together to seamlessly exchange policy information between domains. That is, top level policy engines feed security policy as well as operational policy down to software-defined controllers. Those controllers then interface with the infrastructure programmable fabrics that they manage and exchange context and intent, thus instantiating both macro-segmentation and micro-segmentation across the fabric.
In our first article, we defined common enterprise domains with vastly different types of endpoints, underlying infrastructure to support it, workloads, granular security requirements, and overall mission. This is the reason why these domains are commonly managed by different IT groups who operate independently from each other. Further, the authentication and authorization strategies seen in each of these domains are normally quite different, as are the protocols and traffic patterns commonly seen. Applying a consistent policy across these boundaries becomes extremely difficult. To achieve a global Zero Trust posture that is intrinsically woven throughout the environment regardless of the domain, it is necessary to start by defining a centralized point of truth from which each environment is fed. As previously described, this point of truth is known as a policy engine.
The policy engine is the core component of Zero Trust, making policy decisions for the entire enterprise, regardless of which domain the resources reside in. Given that everything is implicitly denied in a Zero Trust architecture, every flow ultimately must be authenticated and authorized before being fully established. But additionally, each domain becomes a large, orchestrated sensor gathering metadata and actionable telemetry for event monitoring, baselining of the overall environment, as well as consistently analyzing and baselining the traffic patterns and behaviors of users, endpoints, and the applications that they consume. Consider the policy engine as having a few distinct roles:
- Top-Level Management Hierarchy: Defines a site structure that demonstrates the hierarchy of the organization. In an agency, there may be subagencies. Those subagencies might support different programmatic efforts. Those programmatic efforts might exist in 20 different buildings and have 10 different functional groups that support the program. Each of those functional groups might have different domain roles that provide different levels of conditional access. An example of this type of hierarchy may look like this:
- Big Agency
- Sub-agency One
- Blue Program
- Building 100
- Floor 1
- Switching Room 101
- Floor 2
- Switching Closet 201
- Building 200
- Building 300
- Blue Program Data Center Environment
- DC Row 1
- Compute Resources 100
- Compute Resources 200
- DC Row 2
- DC Row 1
- Green Program
- Orange Program
- Floor 1
- Operational Role:
- Establish Visibility and Assurance: Collects actionable telemetry from each point of the network and each piece of managed infrastructure. Aggregates all of this telemetry and develops analytics to paint a full picture of the environment, provide visibility to events/alerting, baseline steady state traits of the environment’s traffic, monitor for abnormalities, and utilize AI/ML to run predictive analytics (detect problems before they become problems).
- Define Segmentation Characteristics: Based on the Top-Level Management Hierarchy, begins building a macro-segmentation structure to segment Virtual Networks. It does so based on policy and does so in a manner abstracted from the underlying hardware. Picture a normal VLAN between network switches that trunks several VLANs. Each VLAN is virtually trunked across to extend different virtual segments between switching appliances. When a new virtual network is added, a new VLAN would be added to the trunk.
- Define Traffic Handling Characteristics: Paints which endpoint groups and application groups are able to traverse the particular Virtual Network, and decides how each application is prioritized (think quality of service).
- Develop Configuration Template Characteristics: Develops configuration templates for each location in the hierarchy, thus enabling Day-0/Day-N provisioning templates for new infrastructure, configuration compliance templates, and things like Golden Image compliance (ensuring that we’re on the approved version of code for the particular platform in question).
- Security Role:
- Auth Parameters: Defines authentication and authorization chains necessary for auth characteristics required to permit/deny flows.
- Integrations: The Policy engine has existing back-end integrations with the sources of truth defined in auth chains such as IdM, PKI, RADIUS, and AAA.
- Auth Data Broker: It then brokers the request and goes out to request the appropriate intent data from that source of truth to determine whether the flow meets the auth criteria that the auth chains require.
- Policy Distribution and Enforcement: The policy engine then notifies the fabric that the ingress flow is either permitted or denied from the source->dest->port much like a firewall policy
- Building 100
- Blue Program
- Sub-agency One
- Big Agency
As we can see, the policy engine has key functions that not only deliver on Zero Trust principles, but simultaneously use that awareness of the whole of the environment to deliver granular operational control. It is the central figure and point of truth for all domains in the environment, as well as the foundational glue that bonds the controllers within each domain. In our next article, we’ll learn about what enables these policies to be seamlessly distributed down into each domain in order to deliver the security and mobility required for today’s hybrid workforce.