The Illumio Policy Model

Illumio gives you the option to manage your security policies by using either adaptive or static policy. Choosing how to implement security policy is possible because of the Illumio policy model. 

About the Illumio Policy Model

The Illumio security policy for securing workloads differs from traditional network securities policies. Traditional security policies use network constructs, such as VLANs, zones, and IP addresses to tie security to the underlying network infrastructure.

In contrast, the Illumio security policy uses a multidimensional label system to sort and describe the function of workloads. By describing workload functionally, policy statements are clear and unambiguous. Illumio users assign four-dimensional labels to their workloads to identify their roles, applications, environments, and locations. Additionally, users specify labels in ruleset scopes and in the providers and consumers components of rules, which allows the workloads in their organization to communicate with each other.

Together, labeling workloads and creating the corresponding rulesets and rules define the security policies for workloads. The PCE converts these label-based security policies into the appropriate rules for the OS-level firewalls of the workloads.

See the following related topics:

• Labels and Label Groups for a description of each label type
• Workloads in the PCE for information about how workloads use labels and for the steps to assign labels to workloads
• Ruleset Scope and Rules for information about using labels in ruleset scopes and rules

Security Policy Guidelines

The following guidelines are recommendations on how to create your security policy in Illumio Core. Creating a security policy is an iterative process, so following these recommendations will provide a broad initial policy, which can then be incrementally improved until a sufficiently robust policy has been established.

When creating your security policy:

1. Create rules following the process below to prevent communication loss and optimize rule coverage.
2. Refine your initial policy to strengthen it by narrowing overly broad access.
3. Use the Test and Enforced policy states to verify and enact your policy.

Rule Creation Approach

For optimal configuration, Illumio recommends using the following approach when creating rules:

1. Core service policies: Core services are among the first services that are detected by the PCE and can include DNS, DHCP, backup traffic, and performance management. Use Illumination to explore your network environment and determine what unmanaged workloads are required. Because policy for core services tends to be very granular, rules for these services should be created before using Policy Generator. Wen core services are defined for a larger entity (like a datacenter or an environment), it is best to organize these “global” rules into a dedicated ruleset. This approach removes all the core services from the application-specific rules and helps keep the policy statements clear and easily understandable. Additionally, when RBAC is used for user segmentation, the core services are often managed by different users than the application-level rules, so separating them allows separate RBAC control.

   Since core infrastructure services, such as NFS are usually available to all workloads, use an IP list-based policy so that those servers accept connections from a CIDR block.

2. Application ringfencing: Unless your network has specific compliance or regulatory requirements it must follow, implementing application ringfencing is a good option for your initial policy, because it covers the majority of your traffic. It limits the risk of intrusion to a single application and provides the greatest impact for the least amount of work.

3. Environment-specific “Outbound Allow-All”: After creating rules for core services and for ringfencing applications, adding a rule to allow all outbound traffic within an environment (for example, Prod or Dev) usually provides rule coverage for most of the remaining traffic. This approach allows managed workloads to initiate communication with any traffic that is not currently managed by Illumio Core.

4. Use Policy Generator to build rules for App-to-App traffic: You can use Policy Generator to write application-specific rules. This approach establishs a base policy for initial enforcement that can be iteratively improved to be more granular, based on security needs.

5. Managing IP lists: As a default initial policy, Illumio recommends writing rules for traffic from applications to IP lists using an “All Services” rule. This approach permits traffic from the application group to that subnet on all services.

6. Managing internet traffic: In Illumination, any traffic not destined for a workload, unmanaged workload, or IP list is displayed as destined for the cloud icon above the application ("Internet"). Because most of this traffic will likely be destined for a single IP address, manage the traffic in the following ways:
   1. Create unmanaged workloads: Use the hostname to create an unmanaged workload for the destination IP address, then write a rule to block or allow traffic from the application to the unmanaged workload. When dynamic or high-order ports are used, use “All Services” in your rule.
   2. Use Illumination to write a workload-specific rule: Select the traffic flow in Illumination, then click Add a Rule and select All Services.
   3. Use Policy Generator to write a default “All Services” rule to each destination: This option quickly establishes a policy to turn traffic lines green in Illumination, but does not provide the visibility of having unmanaged workloads to represent each external destination.

Policy Refinement

Creating rules using the guidelines above establishes a stable policy where most of the traffic lines in Illumination will be green. It can be adjusted as new traffic is observed, but the recommendations above provide an initial basic policy. This policy can and should be refined incrementally, as it might initially be overly broad. The following guidelines provide the greatest benefits when refining your policy:

1. Identify critical applications: Determine your network's top five or top ten applications and refine the rules for them. Repeat as needed to continuously improve the policy.
2. Investigate inter-application flows: In Illumination, inspect the traffic between applications to see how it can be improved. When the traffic is destined for a single port, find out if the port is fixed or dynamic. If it is fixed, update “All Services” to the specified port. If it is dynamic with known ranges, create a new service with that range to narrow the service definition in the rule.
3. Investigate traffic to IP lists: Inspect the top-volume flows to IP lists. Optimally, try to reduce IP lists by replacing them with unmanaged workloads, then reduce the service definition to only the required ports.
4. Identify high-volume unmanaged workloads or applications: When a single unmanaged workload has many connections to managed applications, it might be a database cluster or critical server. Ideally, you should try to reduce usage of “All Services” where possible to a more narrow definition.
5. Restrict access for scopes and services to unmanaged workloads: Unmanaged workloads do not have a an installed VEN, so access to these types of workloads should be restricted where possible. Determine if you can use scopes to restrict access to specific roles within applications and review access to services to determine if any use of “All Services” can be reduced to a more specific port range.

Policy States

After creating the ruleset, you can preview the effects in Illumination using the Draft View. This view shows you the changes that will be enacted by your policy when it is enforced.

• Test: After refining your initial policy, most of the traffic lines in Illumination should be green. At this point, you can move your workloads to the Test policy state. No traffic will be blocked and you can check your policy's accuracy. Any new traffic will be displayed as a red line, which can be addressed using the strategies discussed in Rule Creation Approach and Policy Refinement.
• Enforced: It is useful to move workloads to the Enforced policy state in stages. This action can be done by workload, by application, by environment, or by datacenter. Start with less critical applications or workloads, stabilize them, then move on to more sensitive systems. This approach minimizes issues to a smaller number of affected workloads.

Understanding Rulesets and Rules

Rules are an integral component of the Illumio security policy. A set of rules is known as a “ruleset” and it specifies the allowed traffic in your network. Create the Rules using Labels that identify your Workloads. See Labels and Label Groups for more information.

The Illumio Core 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. for security policy uses rules to define the allowed communication for two or more workloads. For example, if you have two workloads that comprise a simple application — a web server and a database server — to allow these two workloads to communicate, you must write a rule that describes this relationship.

For example, in the following diagram: 

The relationships between the tiers (or workloads, as they are known in Illumio Core) in this example are:

• The Web workload can initiate communications with the App workload (Web → App).
• The App workload can initiate communications with the Database workload (App → Database).

In Illumio Core, the relationship in the diagram above is expressed as two separate rules:

• The Web workload can initiate communications with the App workload.
• The App workload can initiate communications with the Database workload.

As a ruleset, this relationship would resemble the following example Ruleset detail page:

To build your network security policy, create a ruleset for each of your workloads. Use labels to identify your workloads and use scopes to apply rulesets to multiple workloads at once. For more information, see Labels and Label Groups and Rulesets

Overview of Policy Objects

The PCE contains the following policy objects that help you write your security policy:

• Segmentation Templates: Prepackaged, tested security policies that provide all the segmentation rules needed for common enterprise applications.
• Labels and Label Groups: Group similar labels together and use the label groups in rule writing.
• Services Allow you to define or discover existing services on your workloads. When a workload is paired with the PCE (has a VEN installed), it is scanned for any running processes, which are then displayed in the Services list.
• Virtual Services: Allow you to label processes or services on workloads. Virtual services can either be used directly in rules or the labels applied to virtual services can be used to write rules.
• IP Lists: Create IP lists (allowlists) so you can define IP addresses, IP ranges, and CIDR blocks that should be allowed access to your applications.
• Load Balancers and Virtual Servers: Add F5 Load Balancer configurations to the PCE so you can write policy for workloads whose traffic is managed by load balancers.
• Pairing Profiles: Configurations that allows you to apply certain properties to workloads as they pair with the PCE, such as applying labels and setting workload policy state.
• User Groups: You can import Active Directory User Groups to write user-based rules for Adaptive User Segmentation.