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:

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.

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 The Illumio Policy Model and The Illumio Policy Model.
  • 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.

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.

NOTE:

The order in which the rules are written or any possible overlap between rules does not affect the allowlist model, since each rule permits some traffic between workloads.

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

NOTE:

Illumio recommends creating no more than 500 rules per ruleset, or the PCE web console will not be able to display all of the rules. If you want to create a ruleset with more than 500 rules, Illumio recommends splitting the rules across multiple rulesets, or use the Illumio Illumio Core REST API, where there is no limit on the number of rules you can create per ruleset.

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.