Environmental Separation

The Environmental Separation add-on restricts traffic between environments. Typical examples are blocking communication between development and production, or isolating test, lab, and DMZ environments from critical production systems.

Non-production environments usually have weaker security controls, looser access, and less monitoring than production, which makes them a common entry point for attackers moving laterally. Separating environments is one of the fastest ways to reduce that risk. It gives large enterprises a meaningful east-west control without having to segment every application first.

Separation rules are simple to write, but applying them without analysis is risky. Traffic between environments is often legitimate: a shared service, a workload that was labeled incorrectly, or infrastructure sitting in the wrong data center or VLAN. Blocking it outright can disrupt production. For that reason, this add-on requires the core-services policy framework from Basic Policy – Core Services + Ransomware to be in place first, and it starts with a review of the traffic that actually crosses each boundary.

Illumio Professional Services analyzes that cross-boundary traffic, finds any legitimate or required communication, and builds a mitigation plan. The plan either allows the traffic, permanently or temporarily, or corrects the underlying issue. PS then develops the separation policy and prepares it for customer review and provisioning.

The outcome is restricted cross-environment traffic between two unique labeled environments that protects High-trust environments from lower-trust environments. Environmental Separation works alongside ransomware containment and application ringfencing as a complementary control. Used together, these three layers form a complete segmentation strategy: port-level containment, environment-level separation, and application-level ringfencing.

Package Dependencies

• Basic Policy – Core Services + Ransomware, or the Containment or Segmentation Bundle  
• Core-services policy is a mandatory prerequisite. Shared infrastructure services often legitimately cross environment boundaries, and separation rules applied before those services are represented in policy are very likely to block required traffic.  

Technical Readiness

• Operational Illumio platform with workloads paired and reporting
• Environment labels applied to in-scope workloads
• Core-services policy framework implemented
• Enough traffic history to analyze communication across the in-scope boundaries
• Required policy objects present, including IP Lists and Unmanaged Workloads
• Administrative access to the PCE for Illumio Professional Services  

Customer Readiness

• Project manager or primary point of contact assigned
• Environments and boundaries to be separated identified
• Infrastructure, network, and application owners available
• Change-management process documented

Boundary Definition

• Confirm the environments and the boundaries between them that are in scope, for example development to production, or test, lab, and DMZ to production.
• Confirm how each in-scope environment is represented in the label schema.
• Confirm the workloads and systems that belong to each environment.
• Agree the separation objective for each boundary with customer stakeholders.

Customer Outcome

The customer has an agreed, documented definition of which environments will be separated and which workloads belong to each.

Cross-Boundary Traffic Analysis

• Review observed traffic that crosses each in-scope boundary.
• Identify legitimate or required communication crossing the boundary.
• Identify workloads that appear to be labeled with the wrong environment.
• Identify infrastructure that appears to sit in the wrong environment, data center, or VLAN. Identify shared services that need to be reachable across environments.
• Review findings with infrastructure and application owners to confirm business purpose.

Customer Outcome

The customer knows exactly what traffic crosses its environment boundaries and which of it is legitimate, required, or caused by misclassification or misplacement.

Mitigation Planning

• Build a mitigation plan for each confirmed cross-boundary finding.
• Classify each finding as:
• Traffic to allow permanently
• Traffic to allow temporarily, pending remediation
• A label correction An infrastructure change needed, such as moving a system out of the wrong environment, data center, or VLAN Document the owner, rationale, and recommended action for each finding. Record temporary exceptions so they can be tracked and removed later. Agree the mitigation plan with customer stakeholders.

Customer Outcome

The customer has an agreed plan for every cross-boundary dependency, so separation can go ahead without blocking legitimate production traffic.

Separation Policy Development

• Develop environment separation policy for the agreed boundaries.
• Build approved permanent and temporary exceptions into the policy.
• Validate the policy against the existing core-services and ransomware containment framework.
• Organize the policy structure and related policy objects.
• Create the separation policy in draft so the customer can review it before provisioning.

Customer Outcome

The customer receives draft environment separation policy that restricts cross-environment traffic while preserving approved dependencies, ready for customer review and provisioning.

Documentation and Handoff

• Provide an as-built record of the separation policy, covering boundaries, rules, related objects, and approved exceptions.
• Provide the mitigation plan and a register of temporary exceptions.
• Document the recommended path from draft policy through provisioning, validation, and enforcement.
• Document how Environmental Separation works with ransomware containment and ringfencing policy.
• Document guidance for adding new boundaries and maintaining separation policy.
• Review the policy and documentation with customer stakeholders.

Customer Outcome

The customer has documented separation policy, a tracked plan for closing out temporary exceptions, and a clear path to provisioning and enforcement through its own change-management process.

The delivery schedule is set at project initiation based on:

• Purchased add-on size
• Number of environments and boundaries in scope
• Volume of cross-boundary traffic
• Number of findings requiring mitigation
• Stakeholder availability and review cycles.

Delays in confirming cross-boundary traffic, approving the mitigation plan, or completing label corrections may affect the schedule.

Talk to our Sales team to learn more about Services.

Explore our Professional Services at illumio.com/services/professional-services