Illumio Associate cheat sheet

Core components: the PCE (Policy Compute Engine) is the central brain storing policy and labels; VENs are lightweight agents on workloads; CNEs (Containerized VENs) protect Kubernetes pods; the NEN enforces policy at the network layer without host agents.

Label model has three dimensions: Role (what the workload does, e.g., web, db), Application (the app or business service it belongs to), and Environment (e.g., prod, dev, staging). Location is an optional fourth dimension.

Policy is expressed as rules between label sets, not IP addresses. A rule such as 'Role=web in App=Payments in Env=prod may connect to Role=db on port 5432' scales because it follows workloads as they move.

The PCE computes a per-workload policy (the 'policy blob') and pushes it to each VEN. Enforcement happens locally on the host, so traffic is filtered even if the PCE is unreachable.

Enforcement modes per workload: Visibility Only (illuminated, no blocking), Selective Enforcement (only allowlisted rules enforced), and Full Enforcement (default-deny plus allowlist).

Breach containment goal: limit lateral movement. Once an attacker compromises a workload, full enforcement on that workload and its peers prevents east-west spread to unrelated applications.

Illumio can be deployed agent-based (VEN on hosts/VMs), agentless (network-level enforcement via NEN and integrations with firewalls/load balancers), or container-based (CNE), and modes can be mixed.

The PCE is typically deployed as a cluster of nodes for high availability; VENs pair to the PCE using a pairing profile and key. Losing PCE connectivity does not stop existing enforcement on VENs.

Traffic flow data is collected by VENs and flows through the PCE to build the Illumination map; this observed traffic is the basis for drafting and tightening policy.

Policy build sequence: label workloads, observe traffic in Visibility mode, draft rules from observed flows, review the 'policy coverage' and impact analysis, then move to Selective and finally Full Enforcement.

Rule anatomy: providers (source label sets) -> consumers (destination label sets), plus a port/protocol or port range, and optionally a scope (e.g., restrict a rule to one application). Rules are allow-only; there are no explicit deny rules.

Default behavior under Full Enforcement is deny all traffic not explicitly allowed, including intra-application traffic unless a rule permits it. This is the core of least-privilege segmentation.

A rule with no scope applies globally; scoping a rule to an Application limits it so it only matches traffic where both provider and consumer share that scope, reducing unintended allowances.

IP lists and virtual services can be used as providers/consumers for external or unmanaged endpoints that cannot carry labels.

Policy coverage is the percentage of observed flows that are allowed by current rules. Uncovered flows under Full Enforcement will be blocked, so raise coverage before enforcing.

The policy change workflow includes draft, provision (compute), and active states. Changes must be provisioned to the PCE before VENs receive them; use impact analysis to preview which flows a change will allow or block.

Enforcement can be set per workload, per label group, or via policy; a common rollout is to enforce on high-value assets first, then expand ring by ring.

Rules can be tested with the policy test/trace tooling to simulate whether a given provider-to-consumer flow would be allowed before enforcement is applied.

Illumination (the map) shows observed layer-3/layer-4 traffic between workloads, grouped by labels, revealing which applications talk to each other and on which ports.

Traffic analysis views distinguish allowed, blocked, and potentially blocked flows; 'potentially blocked' means the flow would be blocked if the workload were in full enforcement.

Insights detects anomalies such as a workload suddenly talking to many new destinations, unusual ports, or unexpected cross-environment traffic (e.g., dev to prod), which can indicate compromise or lateral movement.

Explorer and flow search let you query historical flows by label, IP, port, or time window to investigate incidents and validate segmentation.

Detection value depends on labeling quality: unlabeled or mislabeled workloads produce noisy maps and unreliable policy recommendations.

Insights can surface risky ports and protocols in use (e.g., SMB, RDP) so teams can prioritize tightening rules around high-risk services.

Flow data retention and export: flows can be exported to SIEM or other tools for correlation with endpoint and network telemetry.

Visibility-only mode is the prerequisite phase: you cannot safely enforce policy on traffic you have not first observed and understood.

Zero Trust principle: never trust implicitly based on network location; verify every request. Identity and context (labels, not IP subnets) drive access decisions.

Microsegmentation applies fine-grained policy down to individual workloads or small groups, rather than coarse perimeter firewalls or VLAN-based segmentation.

East-west traffic (workload-to-workload inside the data center) is the primary lateral-movement path for ransomware; microsegmentation targets it directly.

Ransomware containment strategy: segment by application and environment so an infected host cannot reach backup servers, domain controllers, or other applications' databases.

Least privilege in segmentation means allow only required ports and peers; block broad 'any-to-any' rules and legacy flat-network allowances.

Defense in depth: microsegmentation complements EDR, patching, MFA, and backups; it limits blast radius but does not replace endpoint detection.

Default-deny with allowlists enforces Zero Trust at layer 3/4; identity-aware proxies and application-layer controls extend it to layer 7.

Blast radius reduction is measurable: count how many workloads a compromised host could reach under current policy versus full enforcement to quantify risk reduction.

VEN is a kernel-level agent; it intercepts traffic locally and enforces the policy blob, so enforcement survives PCE outage.

CNE protects Kubernetes pods and can enforce at pod level using namespace and pod labels as scope.

NEN provides agentless enforcement at the network fabric, useful for appliances and unmanaged devices.

Pairing profiles define which labels a newly paired VEN receives and which PCE it connects to.

Labels are the only addressing scheme for policy; IP-based rules are the exception, not the norm.

Supercluster links multiple PCEs for global policy across regions.

Illumination requires VENs in visibility mode; without agents or NEN, traffic is invisible.

Full enforcement = default deny; Selective enforcement = only listed rules enforced, rest allowed.

Rules are allow-only; there is no explicit deny rule, so deny is achieved by omission under Full Enforcement.

Scope restricts a rule to an application; unscoped rules apply globally and can create unintended allowances.

Policy coverage = allowed observed flows / total observed flows; aim for high coverage before Full Enforcement.

Draft -> provision -> active is the policy lifecycle; unprovisioned changes do not reach VENs.

Impact analysis previews which flows a policy change will allow or block before you commit.

IP lists and virtual services handle unmanaged endpoints that cannot carry labels.

Ring-based rollout: enforce on high-value assets first, then expand to lower-risk groups.

Policy test/trace simulates a provider-to-consumer flow to confirm allow/block before enforcement.

Illumination map shows L3/L4 traffic between labeled workloads, revealing application dependencies.

Potentially blocked flows are those that would be blocked if the workload were in Full Enforcement.

Insights flags anomalies: many new destinations, unusual ports, cross-environment traffic (dev to prod).

Explorer and flow search query historical flows by label, IP, port, or time window.

Labeling quality drives detection quality; unlabeled workloads create noisy maps.

Risky ports (SMB, RDP) surfaced in Insights guide rule tightening priorities.

Flows can be exported to SIEM for correlation with endpoint and network telemetry.

Visibility-only mode is the prerequisite for safe enforcement.

Zero Trust: verify every request; do not trust based on network location.

Microsegmentation = fine-grained policy per workload or small group, not coarse VLANs or perimeter firewalls.

East-west traffic is the main ransomware lateral-movement path; segment it directly.

Segment by application and environment so infected hosts cannot reach backups, domain controllers, or other databases.

Least privilege = allow only required ports and peers; avoid any-to-any rules.

Microsegmentation complements EDR, patching, MFA, and backups; it limits blast radius but does not replace endpoint detection.

Default-deny with allowlists enforces Zero Trust at L3/L4; L7 controls extend it further.

Blast radius = number of workloads a compromised host could reach under current policy versus Full Enforcement.