SecureConnect
Enterprises have requirements to encrypt in-transit data in many environments, particularly in PCI and other regulated environments. Encrypting in-transit data is straightforward for an enterprise when the data is moving between data centers. An enterprise can deploy dedicated security appliances (such as VPN concentrators) to implement IPsec-based communication across open, untrusted networks.
However, what if an enterprise needs to encrypt in-transit data within a VLAN, data center, or PCI environment, or from a cloud location to an enterprise data center? Deploying a dedicated security appliance to protect every workload is no longer feasible, especially in public cloud environments. Additionally, configuring and managing IPsec connections becomes more difficult as the number of hosts increases.
SecureConnect Overview
SecureConnect leverages the built-in IPsec subsystem of host operating systems. On Windows hosts, SecureConnect utilizes the Windows IPsec subsystem. On Linux hosts, SecureConnect utilizes StrongSwan and Linux kernel IPsec for traffic encryption.
With SecureConnect, Illumio delivers a feature that configures the Security Policy (SP) necessary to enable traffic encryption between workloads. Once authenticated, encryption and cryptography suites provide confidentiality and data integrity to network traffic between workloads.
The PCE centrally manages all Security Policies (SPs) for workloads, enabling them to be policy-driven. For example, a customer can require that all traffic between their web servers and database servers be encrypted. Selecting the SecureConnect option for these workloads enables the PCE to apply the requisite security policy to your organization, making that happen. SecureConnect simplifies the configuration of IPsec encryption and automatically scales according to your policy definitions.
SecureConnect Use Cases
Employing SecureConnect is especially beneficial in these common scenarios:
Facilitate PCI compliance by ensuring that confidential data is encrypted over the network.
Secure off-site backup and recovery of data across geographically distributed data centers.
Secure communications across applications and application tiers for regulatory compliance and tighter security.
Enable secure data migration across different public cloud providers.
SecureConnect Features and Enforcement
SecureConnect supports connections between Linux workloads, Windows workloads, and mixed Linux and Windows workloads.
Note
SecureConnect rules are only applied to workloads where the VEN is in a non-idle enforcement state.
However, unlike other rules, SecureConnect requires matching rules to be applied to workloads on BOTH sides of any connection. Therefore, SecureConnect traffic is not supported between two workloads where a VEN on either side is in the idle state.
SecureConnect Rules and Visibility-Only State
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.
SecureConnect Rules
Note
SecureConnect rules are only applied to workloads where the VEN is in a non-idle enforcement state.
However, unlike other rules, SecureCionnect requires matching rules to be applied to workloads on both sides of any connection. Therefore, SecureConnect traffic is not supported between two workloads where a VEN on either side is in an idle state.
For SecureConnect rules in visibility-only state, it is essential to keep in mind that these rules are:
Applicable only to workloads in an enforced state (Visibility-only, Selective, or Full Enforcement).
Matching rules are required on both source and destination workloads.
Unsupported for workloads in Idle state.
The visibility-only state offers no enforcement and represents continuous monitoring and reporting of network traffic. It is ideal for initial policy planning and traffic analysis. However, it may disrupt applications dependent on NAT or IP forwarding.
Blocked + Allowed Logging Mode
This mode provides detailed logging of:
Allowed traffic (explicitly permitted by rules).
Blocked traffic (explicitly denied or not explicitly permitted).
Unlocked traffic (permitted without explicit rules).
Visibility Options by Enforcement Mode
These options are available for the selective and full enforcement modes:
Selective Enforcement Mode
Selective enforcement provides:
Off—There is no logging. The VEN does not collect any information about traffic connections. This option provides no Illumination detail and demands the least amount of system resources from a workload.
Blocked—Logs only blocked traffic. The VEN collects only the blocked connection details (source IP, destination IP, protocol, and source port and destination port), including all dropped packets. This option provides less Illumination detail but demands fewer system resources from a workload than high detail.
Blocked + Allowed – Logs both allowed and blocked traffic. The VEN collects connection details (source IP, destination IP, protocol, source port, and destination port). This applies to both allowed and blocked connections. This option provides rich Illumination detail but requires some system resources from a workload.
Enhanced Data Collection – Detailed logs with traffic flow metadata.
Full Enforcement Mode
Full enforcement blocks all non-explicitly allowed traffic, providing the highest level of security.
Visibility options mirror Selective Enforcement:
Off
Blocked
Blocked + Allowed
Enhanced Data Collection
Full enforcement is recommended after successful testing and validation of the allowlist model.
Enhanced Data Collection
As of release 25.2.10, Enhanced Data Collection is enabled in all enforcement modes. Before February 25, 2010, it could be enabled only in Full Enforcement mode.
Enhanced Data Collection allows the VEN to log byte counts and connection details for Allowed, Blocked, and Potentially Blocked traffic.