In the Illumio Core 21.2.0 release, Illumio introduces Enforcement Boundaries, a new feature to speed your journey toward Zero Trust.
The Journey Toward Zero Trust
The Illumio security policy model is based on the principle of Zero Trust. What is Zero Trust? Zero Trust security segments internal networks and prevents the lateral spread of ransom ware and cyber breaches. When implemented, it eliminates automatic access for any source – internal or external – and assumes that internal network traffic cannot be trusted without prior authorization.
Achieving Zero Trust security is possible with the Illumio Core because it bases security policy on an allowlist model. The allowlist model means that you must specifically define what traffic is allowed to communicate with your managed workloads; otherwise, it is blocked by default. It follows a trust-centric model that denies everything and only permits what you explicitly allow—a better choice in today’s data centers. The list of what you do want to connect in your data center is much smaller than what you do not want to connect.
From a security perspective, creating policy based on allowlists is the preferred method and has the advantage of specifying what you trust explicitly; However, creating security policy exclusively on the allowlist model has some disadvantages. To start enforcing policy using the allowlist model, you must have a clear and complete understanding of all network communication within your data center. It is important to account for all the connections that must be allowed between your hosts and applications or you risk business-critical applications breaking. Without this perfect knowledge, you either leave holes in your security, or you block necessary connections that break application functionality.
Approaches toward Reaching Zero Trust
It is much easier to implement allowlist security in a greenfield environment because your knowledge of application connection requirements are current and your application developers can define allowlist policy (segmentation rules) as part of the application deployment.
In a brownfield environment, applications are already deployed and running. A data center can have thousands of applications. How do you go about deploying an allowlist model into a brownfield environment? Often, Illumio Core customers implement allowlist security in a brownfield environment by creating security policy one application at a time. By default, the PCE sets the enforcement state to “visibility only” when you install a VEN on a host, thereby allowing you to assess what traffic is reaching the host. You can observe application behavior in reaction to potential security policy, and gradually move applications into full enforcement.
This approach can be very successful in achieving Zero Trust for your environment. However, it can lack the ability to accommodate unplanned security mandates, such as blocking a new security threat, or limiting traffic between corporate headquarters and a new business location.
So, how do you compensate between these two competing goals? Requiring a complete understanding of your data center versus being agile enough to tackle sudden security mandates? The solution is to introduce a new set of rules that determine where segmentation rules apply. These rules are referred to as Enforcement Boundaries in Illumio Core. Enforcement Boundaries can block traffic from communicating with workloads you specify, while still allowing you to progress toward a Zero Trust environment.
Enforcement Boundaries: How They Work
Enforcement Boundaries provide the following advantages:
- Unlike firewall policies, boundaries provide a simple policy model that does not depend on rule order.
- Boundaries facilitate a secure path to block traffic to achieve a Zero Trust model.
Enforcement boundaries are separate from allowlist rules. You can use multiple labels in a boundary or specify a label group. They are not limited by label types. Enforcement boundaries can be applied across a set of workloads, ports, and IP addresses.
You can create an Enforcement Boundary between workloads running different operating systems. When you use the existing Illumio Core RAEL labels to designate workloads by OS, creating an Enforcement Boundary by OS is possible.
You can combine Enforcement Boundaries with allowlist rules in your overall security policy. Allowlist rules always supersede Enforcement Boundaries. For example, you might have a server running a legacy NetBIOS file. This server is deployed in your development environment and must communicate with an application running in your production environment. You have already created an Enforcement Boundary blocking traffic between workloads in the development and production environments. You workaround this requirement by creating a specific rule allowing NetBOIS traffic to connect through the ports on the production server.
Summing It All Up
Enforcement Boundaries are…
-
Part of the Illumio declarative policy model.
You define the end state and Illumio Core creates the appropriate native firewall rules. You don't have to worry about rule order. In the traditional firewall, you do.
- Overridden by allowlist policy.
-
Directional; you can create Enforcement Boundaries that are provider-centric or consumer-centric.
For example, you want to block traffic from one location but only in one direction.
- Flexible; they are available for label groups and IP lists.
- Most often used for brown field deployments.
-
Intended to serve as a stepping stone towards a full traditional allowlist policy model.
Implementing Enforcement Boundaries allow you to start the path toward full enforcement without having full knowledge of your data center environment.
Use Cases for Enforcement Boundaries
Potential use cases for Enforcement Boundaries include:
-
Environmental or location separation and individual service enforcement.
For example, you want to reduce risk in your environment by blocking traffic between your development and production environments.
You want to control which locations or entities in your environment that can communicate. For example, you organization just acquired another entity and you want to block network traffic between the two locations.
- Blocking traffic from specific services from traversing your network; such as:
Unencrypted protocols like unencrypted HTTP traffic unless explicitly allowed to a host.
Ubiquitous services in your network; for example, you don't want to allow Telnet access anywhere in your network.
Examples: Ways to Deploy
The following examples illustrate some common ways to utilize Enforcement Boundaries.
Block Traffic Between Environments
In the following example, an IT organization receives a mandate to implement security policy between the workloads in the development and production environments on a fixed project time line. Approaching this with a Zero Trust model could push implementation past the deadline. Achieving this security goal by using an Enforcement Boundary is achievable. It requires primarily two tasks: deploy VENs on all the workloads and set the Environment label correctly.
In this example, the IT organization can effectively block traffic between these two environments without requiring a complete picture of all port and protocol requirements for all applications or hosts in the production environment. No applications are at risk of breaking in production because required traffic was inadvertently blocked between applications or hosts in production.
Allowed Traffic Supersedes Enforcement Boundary
In this example, you can still allow instances of services to communicate with the production environment. Any policy that you create (the allowlist model) that allows a service to reach applications or hosts running in production still works and the segmentation rule will override the Enforcement Boundary. You explicitly create a segmentation rule that allows the SSH and RDP services to reach the necessary workloads.
SSH and RDP traffic can reach workloads in production without breaking the boundary blocking traffic from development workloads to production.
