Skip to main content

Security Policy Guide 25.2.10

Policy Check and Rule Search

The Policy Check feature enables you to verify whether a rule allowing communication between workloads or between a workload and another IP address already exists. On the Policy Check page, you select two workloads or IP addresses to determine if a rule exists to allow communication between them. Policy checks can utilize a network profile to account for rules that affect outbound traffic to non-corporate interfaces on endpoints. Servers cannot have non-corporate interfaces.

Note

You can do a policy check between two workloads or a single workload and an IP address.

For example, you have created several rule sets for your workloads and applications, and you want to know whether your organization has an existing rule for that traffic before you start writing new rules that duplicate those existing rules.

Perform a Policy Check

  1. From the PCE web console menu, choose Troubleshoot > Policy Check.

  2. In the Source field, type or select a workload or IP address.

  3. In the Destination field, type or select a workload or IP address.

  4. In the Destination Port and Protocol field, enter a port and protocol when the connection runs over TCP or UDP, or just a protocol when it runs over GRE or IPIP.

  5. Choose Corporate, Non-Corporate Networks (Endpoints Only) , or Anyin the Network Profile field.

    If an IP address is specified in the Destination and Source fields, the Network Profile value must be set to Corporate, which means searching within the internal corporate network only.

  6. Click Check Rules.

    If a connection between the selected two workloads or IP addresses is allowed, the page will display at least one rule that allows the connection.

    When a rule does not exist, the page displays “No Rules exist to allow that connection.”

Rule Search

You can't easily search for rules across rule sets when you have many rules organized in rule sets. The segmentation rule search solves this issue by making it simple to search for specific rules.

For example, it is time-consuming to narrow down the search without using this feature when you want to determine the number of rules for SNMP (UDP 161) and have approximately 200,000 rules organized across 700 rule sets.

You can search for and analyze rules that allow communication over a specific port and protocol.

  • Segmentation Rule Search enables you to quickly find rules that apply to sources and destinations.

  • A workload, an IP address, or a set of labels can represent sources and destinations.

  • Using this feature helps you identify rules that are being applied to your workloads due to unnecessarily broad rule sets or human errors.

To search for rules

  1. From the PCE web console menu, select Policies.

  2. Choose the Rule Search tab.

  3. Search for Active or Draft rules.

    1. In release 25.2.10, an additional dropdown list was added to the Rule Search:

      All rules: This includes Override Deny Rules, Allow Rules, Deny Rules, and IP tables rules. All rule types are showing when no type category is selected.

      Subset of rules: Select which rules you want to search by deselecting the other rule types.

    2. Choose an Exact Match of the selected search filters displayed or a match to any of the selected filters (All Results).

    3. Perform a Basic search for all attributes or an Advanced search by destination, source, or both.

    4. Filter by Labels and Rule Attributes. Use these options to narrow your search results. You can search all categories or select only the ones you want to use such as labels and label groups, IP address, IP lists, Rule options, Port and/or Protocol, Port range, Process name, Windows services, Policy services, Provision status, and Status.

  4. Click Run.

  5. Click Export to export the search result in JSON format.

Rule Search by Port

The following guidelines and uses cases are provided to clarify how Rule Search works when you search for rules by the port(s) they specify.

General Guidelines

  • Single-port searches generally work as expected. See Row 1 in the Use Case table.

  • When searching for a port range, the port ranges in the search and in the rule must match exactly. See Row 3 in the Use Case table.

  • When searching for rules that specify multiple ports, only rules that specify all of the ports are found. See Row 5 in the Use Case table.

Use Cases: Search for Rules by Port

Row

Use case

Examples

(A) Search specifies port(s)

Examples

(B) Rule specifies port(s)

Is the rule found?

1

(A) Search for rules that specify only a single port

and

(B) There's a rule that specifies the same single port

80

80

Yes

2

(A) Search for rules that specify only a single port

and

(B) There's a rule that specifies a port range that encompasses the searched-for port

80

50-100

No

3

(A) Search for rules that specify a port range

and

(B) There's a rule that specifies the same port range

50-100

50-100

Yes

4

(A) Search for rules that specify a port range

and

(B) There's a rule that specifies only a single port within the searched-for range

50-100

80

No

5

(A) Search for rules that specify multiple ports

and

(B) There's a rule that specifies the same multiple ports

50, 100

50, 100

Yes

6

(A) Search for rules that specify only a single port

and

(B) There's a rule that specifies multiple ports, including the searched-for port

50

50, 100

Yes

7

(A) Search for rules that specify multiple ports

and

(B) There's a rule that specifies some, but not all, of the searched-for ports

50, 80

50, 100

No

Illumio Policy Enforcement Model

Illumio employs an allowlist security model. By default, workload-to-workload communication is blocked unless explicitly permitted by defined Illumio policy rules. Administrators create these explicit rules to allow only necessary traffic, significantly enhancing security.

Why Use Selective Enforcement?

Deploying the allowlist model universally and simultaneously can be challenging or disruptive. Illumio addresses this by providing selective enforcement, an intermediate enforcement state that allows a gradual security rollout.

Selective Enforcement provides:

  • Gradual Security Implementation: Smooth transition from open ("Idle" or "Visibility-only") states to full enforcement ("Full Enforcement").

  • Targeted Visibility: Enforcement focused on selected services and ports via labels or groups, while other services remain in visibility mode.

  • Rapid Threat Response: Immediate enforcement on vulnerable or critical ports and services without impacting entire workloads.

Applying Selective Enforcement

The Selective Enforcement mode is configured per workload using labels or groups of labels.

When Selective Enforcement is activated:

  • Enforced Ports and Services: Active enforcement of security rules; explicitly permitted inbound traffic only.

  • Visibility-Only Ports and Services: No active blocking, but communication is monitored and logged.

The Workload Behavior under Selective Enforcement:

  • Enforced Ports: Permits only explicitly allowed inbound traffic according to defined policy rules; all other traffic is blocked.

  • Visibility-Only Ports: Traffic remains unblocked but is actively monitored and logged

How Selective Enforcement Works

Selective enforcement is applied individually per workload through labels or label groups.

When enabled:

  • Enforced Ports/Services: Security rules are actively enforced; only explicitly permitted traffic passes.

  • Other Ports/Services: Remain in visibility-only mode; traffic is monitored but not blocked.

Workload Behavior under Selective Enforcement:

  • Selective Enforcement (Enforced Ports): Only explicitly permitted inbound traffic is allowed. All other inbound traffic to these ports is blocked.

  • Visibility-only (Other Ports): Traffic continues normally but is monitored and logged.

Enforcement Progression Model

Selective Enforcement is a crucial step in Illumio's structured enforcement progression:

Idle (Visibility-only) → Selective Enforcement → Full Enforcement

where

  • Idle: Visibility and monitoring are in place, but there is no enforcement.

  • Selective Enforcement: Partial enforcement on chosen ports/services.

  • Full Enforcement: Complete allowlist enforcement on all ports and services.

This structured approach simplifies the implementation of secure policies, offering flexibility in managing risk and operational complexity.

Use Cases and Limitations

Basic use cases for Selective enforcement are:

  • Incremental Policy Rollout: Enables the gradual introduction of policies, reducing risks to critical systems.

  • Rapid Security Response: Quickly enforce specific, critical, or vulnerable port and service policies.

Selective enforcement only applies to inbound (source-side/ingress) traffic, controlling incoming requests to protected workloads. It does not control outbound traffic from workloads.

Selective Enforcement Mode Limitations

Limitations of Selective Enforcement are grouped as follows:

  • Directional Enforcement, where Selective enforcement operates only on inbound traffic.

    • Inbound Policy (Destination-centric): Manages incoming traffic to workloads.

    • Outbound Policy (Source-centric): Manages outgoing traffic from workloads.

  • Support for Managed Workloads is available only because selective enforcement is available for workloads managed directly by Illumio.

    • Managed workloads are supported.

    • Unmanaged workloads or workloads managed via Network Enforcement Nodes (NEN) cannot utilize selective enforcement.

  • Impact on Virtual Services: Selective enforcement does not apply directly to virtual services as a single entity.

    Instead, policies must target individual workloads within virtual services. Enforcement is applied at the workload level within virtual services.

    Virtual services themselves are not directly enforced.

Workload Enforcement States

Workload policy modes determine how Illumio rules impact workload network communications. Illumio provides four policy modes.

The enforcement state displayed in the Policy Compute Engine (PCE) indicates the desired state for the next policy update. Failure to apply this state successfully will result in a Policy Sync error.

Idle Enforcement State

This state is typically used during initial VEN installation or activation. Its characteristics are:

  • No firewall rule enforcement.

  • Collects and reports network traffic data every 10 minutes.

  • Report OS compatibility every four hours.

  • Immediately reports network interface configuration changes.

Policy Exclusions

In Illumio Core 22.2.0 and later releases, the PCE supports including policy exclusions incpolicy scopes and rules. This topic explains what they are, how they are supported in Illumio Core, and how to add them to your security policy.

Policy Exclusions Overview

Using policy exclusions in your Illumio Core policy can significantly simplify the rule-writing process. Specifically, using a policy exclusion in a scope or rules allows you to replace the inclusion of a large number of required labels with the exclusion of a small number of unwanted labels. Security policies written with exclusions can be easier to read and maintain.

Using policy exclusions allows you to state in your security policy that you want a policy or rule to apply to “all except X,” where X can be both labels and label groups. To state this another way, “all except X” means ”All labeled workloads except X” or “All label group objects of a dimension except X.”

You can include policy exclusions in policy scopes and rules, specifically in the destination and source actors.

Use Cases

The following examples demonstrate a few common use cases for using policy exclusions:

  • All environments except Production should be able to pull updates directly from Red Hat.

  • The standard jump boxes should be able to connect to all environments except PCI.

  • All applications, except Quarantine, should be able to connect to Core Services.

Policy Exclusions Support

Policy exclusions are supported by Illumio Core features and in the PCE web console in the following ways:

Illumio Core Feature

Details

Policy scopes and rules

In policies and rules, excluding a label creates an “all-but” rule or boundary that applies to all workloads that don't have that excluded label but do have another label of the same label type as the excluded label.

For example, your data center supports Production, QA, and Development environments.

Adding an exclusion for “All environments except Production” means that the rules apply to all workloads with Environment labels, except those labeled as Production. It does not translate to “All workloads except those with the Production label,” which would include workloads that don't have an Environment label. When you create a rule that applies to “All environments but Production," this rule achieves the same effect as creating one that applies to the QA and Development environments only.

Labels

Fully supports except for the restrictions below. See Requirements and Restrictions.

Label Groups

Label groups are supported for policy exclusions in the same way as labels. For example, you want to create a boundary between Finance and all other applications. You create a label group named “Finance Apps” and use it as a policy exclusion.

Individual workloads, virtual services, virtual servers, “All Workloads,” the “Uses virtual service only” option, the “Uses virtual service and workloads” option, and container hosts do not support label group exclusions.

Additionally, you cannot specify exclusions out of label groups. For example, you have created a label group for the environment “Non-production.” You want to use the label group, except you don’t want it to apply to the “Development” environment. You want to create a policy exclusion for the “Development” environment label from the “Non-production” label group. This action is not supported. Selecting to exclude a label group excludes all labels within that group.

Rule Search and filters

You cannot search by policy exclusions; however, any rules that contain policy exclusions appear in the results of your rule search.

In label filters and rule searches, entering a label name displays both included and excluded labels with that name.

App Groups

In the App Groups > App Group List, select the Rules tab.

Rules with policy exclusions appear in the Rules tab.

Policy Check

Rules with policy exclusions are displayed on the Policy Check page.

Policy Generator

The PCE does not propose policy exclusions when using Policy Generator to create policy.

When using Policy Generator to calculate V-E scores for vulnerabilities (you have the Vulnerability maps feature enabled), Policy Generator won’t work for rules that contain policy exclusions because they are not supported in Policy Generator.

Access Management

Access management (Role-Based Access Control, or RBAC) detects policy exclusions when determining user access in the Policy Control Engine (PCE). However, you cannot exclude a policy exclusion from an RBAC role.

Policy exclusions are only supported in policies and rules. If a scope includes a policy exclusion based on labels outside the scopes you have permission for, you cannot view or manage those policies and rules.

For example, suppose a policy includes an exclusion of “All environments except Production,” and you have permission for the Production environment but not for the Staging environment. In that case, you will be unable to view or manage that policy.

Explorer

When writing rules using Explorer, you can select policies that contain policy exclusions. You can edit the rules in the policy that have exclusions. You can add new proposed rules, taking the exclusion scopes into account.

However, you cannot add a new policy exclusion to an existing proposed rule or an exclusion to a new one.

PCE web console maps

Policy exclusions apply to rules; they are not properties of the traffic links (the lines between the workloads) in the Illumio maps (Illumination Map, App Group Map, and Vulnerability Map).

When you click View Rule for any traffic link, you can view the policy exclusions in the panel.

Enforcement Boundaries

Policy exclusions are not supported in Enforcement Boundaries.

However, you can view policy exclusion rules in the Rules tab of an Enforcement Boundary details page.

Requirements and Restrictions

Requirements

When specifying a policy exclusion, it must be the same label type as the group it's being excluded from; the following examples are allowed:

  • All Locations except the New Jersey location

  • All Applications except Billing

However, this example is not allowed because it specifies different label types – Location vs Environment:

  • All Locations except those with Development systems

Restrictions

  • You can specify an included or excluded label for each dimension, but not both. The following examples show valid combinations:

    App: Swift

    App: All but Swift

    Env: Prod, App: All but Swift

    Loc: EU, Env: All but Prod

  • You cannot specify both included and excluded labels within the same label type. The following examples are invalid combinations:

    Env: Prod, Env: Dev, Env: All but UAT

    Env: Prod, App: HRM, App: CRM, App: All but Swift

    App: HRM + App: CRM - App:Swift

    Loc: EU - Loc: Switzerland

  • You cannot use policy exclusions with the following objects in the PCE:

    • Individual (named) workloads

    • Virtual servers

    • Virtual services

    • Container hosts