During a recent incident response simulation for a client, I was tasked with evaluating the efficacy of the Sophos XGS platform in performing rapid network isolation of a suspected compromised host. While the marketing materials often tout "one-click isolation," the practical reality involves a nuanced interplay between the firewall, Synchronized Security components, and a properly configured Network Access Control (NAC) posture. This post details the step-by-step forensic containment procedure I benchmarked, highlighting the critical configuration dependencies and latency observed between detection and complete network segmentation.
The scenario presupposes the Sophos XGS firewall is deployed as the network gateway, with Synchronized Security enabled and endpoints running the Sophos Endpoint agent. NAC is implemented using 802.1X with a Sophos Central RADIUS server, controlling access to both wired and wireless networks.
**Step 1: Identification and Trigger**
The process begins with an alert, typically generated from:
* Sophos Intercept X on the endpoint (local AI detection).
* XGS Intrusion Prevention System (IPS) signature match for command & control traffic.
* Central Sophos XDR alert correlating multiple weak indicators.
In my test, I used a controlled IPS signature trigger (`ET CNC ShadowPad Server Beaconing`) to initiate the event. The key metric here is the time for the alert to appear in the Sophos Central Event Log as a "Synchronized Security" incident. My benchmark averaged **47 seconds** from malicious packet egress to actionable Central alert.
**Step 2: Validating Synchronized Security Status**
Before isolation can be automated, you must verify the health of the Security Heartbeat. A broken heartbeat will cripple automated response. The following CLI command on the XGS is critical for diagnostics:
```
# ssh admin@xgs
XGS> show security-heartbeat status
```
The output must confirm a valid heartbeat from the suspect host's IP address. In my lab, a host with a malfunctioning agent showed a heartbeat age of over 3600 seconds, necessitating a fallback to manual NAC-based isolation.
**Step 3: Executing Isolation via Firewall Policy (Automated Path)**
With a valid heartbeat, the recommended automated action is to apply a "Host Isolation" policy from Sophos Central. This action:
1. Places the host into a pre-defined "Isolated" host group.
2. Dynamically updates a firewall rule, denying all traffic except that destined to essential remediation servers (WSUS, Sophos Central, internal patch repositories).
This policy update is not instantaneous. My measurements indicate a propagation delay of **90 to 120 seconds** for the updated firewall policy to be fully enforced on the XGS appliance, beginning from the click in Central. During this window, the host may still have partial network access.
**Step 4: The NAC Enforcement Layer (Critical Redundancy)**
Firewall rules alone are insufficient if the host can move to another port or VLAN. This is where NAC integration is non-negotiable. The XGS, via Central, should trigger a RADIUS CoA (Change of Authorization) to the switch, reassigning the host's port to a quarantined VLAN.
* **Pitfall:** This requires absolute correctness in your NAD (Network Access Device) configurations and RADIUS vendor-specific attributes. The CoA delay in my environment was sub-20 seconds, but only after extensive switch template tuning.
* **Fallback Procedure:** If automated NAC fails, you must manually revoke the host's certificate or 802.1X credential in Central RADIUS and/or update the host's dynamic address group membership to force re-authentication into a quarantined policy.
**Step 5: Verification and Logging**
Confirm isolation by checking:
* Live firewall connections on XGS for the host's IP: should show only allowed remediation flows.
* Central RADIUS audit log for successful CoA or session termination.
* Switch MAC address table to confirm VLAN change.
The overall timeline from detection to full multi-layer isolation (firewall + NAC) in a properly configured environment averaged **3.5 minutes**. The primary bottlenecks are consistently the Central-to-appliance policy synchronization and the health of the Security Heartbeat. Organizations relying on this workflow must treat the heartbeat as critical infrastructure and set realistic expectations for containment time, planning manual NAC operations as a necessary contingency.
That's a really solid walkthrough so far. The interplay between XGS, Synchronized Security, and a tight NAC setup is exactly what makes or breaks the isolation time. I've seen similar setups where the lag wasn't in the firewall rule push, but in the NAC layer re-authenticating the host.
In my experience, if the 802.1X supplicant on the endpoint is being quirky, the host can linger in a weird semi-authenticated state for a bit, still able to talk to a few things. Your point about the "nuanced interplay" hits the nail on the head. Looking forward to the next steps on your observed latency
ship it
Yeah, the alert source totally dictates your response timeline. I've seen the Intercept X local AI detections come in fast, but the action from Central can feel glacial if the endpoint's heartbeat is off by even a minute. The IPS signature trigger is quicker to act on the firewall side, but then you're reacting to outbound traffic, which is already later in the kill chain.
Your setup with Central RADIUS for NAC is the key piece everyone glosses over. If your RADIUS policy just assigns a VLAN, isolation fails. You need a dedicated "quarantine" network object and a corresponding Access Policy in Central that changes the host's role to that object upon alert. That policy push to the firewall and the RADIUS server is where we've measured the most variable delay, sometimes up to 90 seconds.
What was the actual latency you observed between the Central alert and the firewall logging a drop for the host's IP on your production VLAN? That's the number that matters, not the UI saying "isolated."
Automate everything. Twice.
That's a really good point about the 802.1X supplicant being flaky. I've only played with basic NAC setups in a lab, and I honestly didn't think about the re-auth step being the bottleneck. If the host is in that weird semi-authenticated state, what's the best way to actually spot that in the logs? Is there a specific error code or timeout on the RADIUS side that tells you it's the supplicant acting up, not just a slow firewall rule?
You're absolutely right that the UI status and the actual packet flow can be out of sync. In our last quarterly drill, we timed it from the Central alert to the first firewall drop logged for that host on the production network. We saw a range of 45 to 110 seconds, with the bulk of the delay being that policy distribution you mentioned.
The worst outliers were always when the endpoint's heartbeat to Central was due right as the alert fired. It added a full polling cycle before the process even started. It's a good reminder that isolation time isn't a single number, it's a distribution heavily dependent on those system timers.