Introduction to Core Policy
This topic explains the components of Illumio Core security policy and how to visualize it in the PCE web console.
Visualizing Policy
Note
This section is provided for informational purposes only. Visualizing policy is outside the scope of the Common Criteria evaluation. Also outside the scope is the translation of rules by the VEN. The scope of this evaluation includes policy definition and transmission of policies from PCE to VEN.
The PCE Illumination feature enhances policy writing by allowing administrators to visualize flows before they write policy. While PCE Illumination can improve rule writing, it is purely an enhancement that can simplify policy creation. Note that policies can also be created without using Illumination by directly creating Rulesets with Rules.
Policies are identified using unique policy ID numbers. The policy ID identifies the policy and (if applicable) the version of the policy. For more information, see Policy Versioning.
The PCE Illumination feature provides the following different ways to create policy.
Illumination Map
The Illumination map visualizes the workloads that form logical groups (based on labels attached to workloads) and provides an understanding of the traffic flows between workloads. The Illumination Map visualizes all the workloads and traffic in an entire data center. Within the Illumination Map, administrators can expand workloads inside groups and see the traffic links for each connection. After the workloads are visible, users can write rules to allow the traffic between selected workloads (or roles) within or across groups by clicking on the traffic links and selecting the Add Rule link.
App Group Maps
App Group Maps are very similar to Illumination Maps but can be used to logically group workloads associated with a common application instance. App Groups are generated using a combination of Application and Environment labels or a combination of Application, Environment, and Location labels. Policies can be created by clicking on traffic flows between App Groups and by converting them into Rules using the Create Ruleset option.
Explorer
The Explorer feature can be used to query the PCE's traffic database to search for traffic flows between workloads or hosts, labeled workloads, or IP addresses. Also, Explorer searches can be restricted to specific port numbers and protocols. Explorer can also be used to add rules for traffic flows by selecting traffic flows and then allowing the selected connections.
Policy Generator
The Policy Generator simplifies the policy creation process by recommending the optimal security policy for App Groups. Policy Generator is used to accelerate security workflows and reduce the risk of human error by automatically creating security policies.
Components of Core Policy
The Common Criteria evaluation includes rule definition and provisioning. It does not include the translation of firewall rules by the VEN.
You can use rulesets to write policy so the workloads in your application can communicate with each other. A ruleset consists of rules and scopes:
Rules define which workloads are allowed to communicate.
Scopes define which workloads that the rules are applied to.
If workloads share the same labels as a ruleset, then those workloads will receive the rules described in the ruleset.
Rules are an integral component of the Illumio security policy. A set of rules, known as a ruleset, specify the allowed traffic in your network. Create the rules using labels that identify your workloads.
Rules are created to define the allowed communication for two or more workloads. The PCE uses an allow-list policy model. This means that you must specifically define what traffic is allowed; otherwise, it is blocked by default. For example, if you have two workloads that compose 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 and allows the required traffic between the workloads.
Because the PCE employs an allow-list policy model, it is not possible for contradictory rules to be created. Before any rules are written, all traffic is denied by default. As you add rules, each rule allows some subset of traffic to occur. The effects of rules can only be additive: more traffic is allowed by each rule. Traffic allowed by one rule can not negate or conflict with the traffic allowed by another rule.
Note
The order in which the rules are written or any possible overlap between rules does not affect the allow-list model, since each rule permits some traffic between workloads.
Access Control Policy Transmission
When the VEN starts up, the VEN requests policy from the PCE by using a REST API over a TLS connection. The API is authenticated and the PCE returns the policy for that particular VEN. Also, when a VEN is paired, it requests its policy from the PCE. During the time between the pairing and first policy application, the VEN is in Idle mode.
The VEN receives notifications about policy updates from the PCE in two ways:
The VEN sends a heartbeat message every 5 minutes to the PCE, and the PCE responds to the message with any updates for the VEN (for example, a new policy update is waiting for the VEN).
The VEN opens a persistent connection with the PCE (called Event Channel), and the PCE sends notifications over that channel.
When a VEN is configured from Idle to Enforcement or Visibility mode, the VEN uses whatever policy it receives from the PCE. It does not have any local policy. When a VEN is suspended, the VEN removes all its firewall rules. When a VEN is unpaired, it can be configured to set the new state of the firewall after the VEN is uninstalled. The VEN can be configured to leave the firewall open (no rules), closed (only allow ssh and other critical connections), or saved (remove VEN-specific firewall rules and do not modify firewall rules belonging to other entities).
Policy Unique ID
New policies provisioned to the VEN include a unique ID to support the Common Criteria for Information Technology Security re-certification. With this ID, you can confirm the new policy version applied to the VEN is the same as the one currently provisioned on the PCE. To view the policy generation on the VEN, enter the following command:
${persistent_data_root}/etc/firewall/debug/sec_policy.generationYou can also see the logged policy version in ${persistent_data_root}/log/platform.log.
Note
Persistent_data_root is used to express the location of the illumio data directory. By default, the data directory is C:/ProgramData/illumio.
Policy Versioning
An administrator can define policies in the PCE, but policies take effect only after they are provisioned in the PCE and applied by the VENs. The PCE assigns a unique version number to each provisioned policy. When a policy is provisioned, the PCE calculates a list of VENs to which the policy should be applied. All applicable VENs receive the provisioned policy. Each VEN gets the latest policy version that applies to that VEN.
Each time a policy is updated, the provisioned change gets a new version number. The PCE has one active version of the policy at one time. The older versions are considered historical versions. The PCE administrator can at any time restore a previous policy version by using the policy restore capability, which will provision the chosen policy version to the VENs. The administrator can also view a list of all historical policy versions and the incremental changes made by those policy versions.
Viewing the Policy Version
To view the policy version in the PCE Web Console:
Go to Troubleshooting > Events.
In the Select properties to filter view field, enter sec_policy.create and press Go.
Click on an event. Under Resource Change, see the Version number.