Step-by-step: Isolating a compromised endpoint using the Intercept X console.

For the console steps, right-click the endpoint in the threat view and select Isolate. Or go to Endpoints, find the machine, and use the Actions menu.

Big difference: file containment just blocks that process/file. Full isolation blocks all network traffic except to your Sophos console. All existing connections are dropped, yes. The user gets a notification.

Test this on a non-critical machine first. Sometimes legacy apps break when their traffic gets cut.

That's a good point about legacy applications breaking. I've seen similar issues in manufacturing environments where an isolated machine can't talk to a local PLC or a legacy inventory scanner that uses a specific port. The network cutoff is absolute.

When you say "test this on a non-critical machine first," is the recommendation to actually trigger the isolation action in a controlled drill, or just to test the policy settings in a lab? I'm worried a drill might still disrupt a user even if we tell them it's coming.

Also, does the console let you set a pre-defined duration for the isolation, or does it stay isolated until an admin manually re-enables it?

Good question about the drill. We've done it both ways, but the full isolation trigger is what we test. Even with warning, it can freak out the user when their Teams call drops, so maybe do it during a maintenance window.

You can set a duration. I saw a timeout option in the policy, but I think it's for auto-release after, like, 12 hours? I'd have to double-check the console. Might depend on your version.

In our AWS setup, we have some on-prem gear talking to EC2 instances. That's my worry too, isolating a host that talks to a legacy service. Does the console log those blocked connections so you can make an exception list later?

Your point about legacy apps breaking is dead on, but I think you're understating the business impact. I've seen isolation trigger a cascade failure because a "non-critical" machine was quietly feeding data to a reporting server. The app didn't crash on the isolated host itself, but it blew up several downstream processes hours later.

The notification the user gets is basically useless in a panic situation. It's a generic system tray popup. If you haven't drilled the help desk on what it looks like and scripted a response, you'll have a terrified user force-rebooting the machine, which can bypass the isolation if your policies aren't ironclad.

Always test the full isolation action, not just the policy. You need to see the actual network logs to understand what that host talks to. The console will show blocked connection attempts, which is your golden ticket for building that exception list before a real incident.

Thanks for sharing that, it's a really important layer I hadn't considered. The downstream cascade failure is a terrifying scenario.

So the blocked connection logs are key for mapping dependencies before you even need to isolate. That makes perfect sense. Do you find those logs in the console are detailed enough, like do they show the destination IP and port for each blocked attempt? I'm wondering how you'd turn that into a reliable whitelist.

I totally get your concern about the drill disrupting a user. We schedule ours for lunch hours or right at EOD and tell the user to save everything and just close their laptop lid. It's still a bit stressful for them, but it's the only way to see the real network cut.

On duration, yes, you can set it! In the policy under isolation settings, there's a timer. Ours is set for 8 hours as a safety net. After that, it auto-releases. But honestly, I still check in manually way before that timer would hit. You don't want a host just popping back onto the network if you're still investigating.

Those legacy port connections are the real killer, though. Even with a drill, you might miss something that only talks at 2 AM. The logs from the isolation event are your best friend for finding those.

The auto-release timer is a critical but often misunderstood control. While an 8-hour safety net is sensible, I'd argue the greater risk is the assumption that investigation will be complete before auto-release. In a major incident, your team might be deep in forensic work and that timer becomes a looming, unwanted distraction.

You can somewhat mitigate this by aligning the timer with your operational rhythm. We set ours to 24 hours, which roughly matches a full business day plus a morning follow-up, and we treat it as a hard checkpoint for a manual review. It forces a conscious decision to extend or release.

Your point about missing 2 AM connections is the crux of the issue. The isolation logs are indeed valuable, but they only show attempted outbound connections *after* isolation. To truly map dependencies, you need historical netflow or endpoint traffic data *before* an incident. That's where integrating your EDR data with a broader observability platform pays dividends, letting you build a communication map proactively.

You're spot on about the auto-release timer becoming a distraction during a serious incident. That's why we disabled it entirely in our policy. The risk of an automatic reconnection during active threat hunting outweighed the safety benefit for us. We manage it strictly through a manual checklist now.

Your point about needing pre-incident data is the real gem here. Relying solely on post-isolation logs is reactive and, as you said, misses everything that wasn't actively trying to phone home at that moment. We built our dependency maps by pulling historical data from our network monitoring tool, not the EDR, and it flagged several critical batch job connections we never would have seen otherwise.

It turns the runbook from just "how to click isolate" into "here are the five servers this machine talks to, so call those teams before you hit the button." That's the operational step-change.

The console steps user1046 gave are spot on. But your runbook shouldn't just be the click path. You need a pre-isolation checklist, like checking those network dependency maps first. That's the gitops mindset - treat your response like code that needs review.

On the network drop, yes, it's immediate. That's why we drill it. The user notification is easy to miss, so our runbook includes a script for the help desk to call the user right after clicking isolate. Cuts down on the panic reboot.

Isolating the machine cuts all its network connections, period. Containing a file just quarantines that specific object. You isolate when you think the host itself is suspect, not just a single file.

The console steps are straightforward, but the runbook needs more. Go to the Endpoints view, find the host, right-click, and select "Isolate." Confirm the pop-up. The user's sessions die immediately.

The real work is what happens before that click. You need a mapped list of that machine's critical dependencies from your network monitoring logs. If it's a database server or talks to a legacy scanner, isolation will break things downstream. The Intercept X logs post-isolation won't show you those silent, established connections that just got severed.

You're right to be cautious about testing on a non-critical machine. We recommend a full, scheduled isolation drill on a real endpoint to see the actual impact. It's the only way to find those silent dependencies.

On the duration question, yes, there's a timer in the isolation policy. It can auto-release, but as others have pointed out, that introduces its own risk. We advise setting it as a long-stop safety net, like 24 hours, with the clear understanding that you'll manually review and release well before it expires. Treating it as an automatic re-connection is asking for trouble.

Scheduled drills on a real endpoint? That's a great way for management to suddenly decide the disruption isn't worth it and axe your testing program. The "non-critical" machine you pick will mysteriously become mission-critical the day before the drill.

The only reliable dependency map comes from historical netflow data, not from inducing a failure. You're betting that the one hour you pick for your drill happens to catch the weekly batch job or the midnight sync. That's a gamble, not a test.

The console process is simple, but that simplicity is deceptive. You right-click the endpoint and select "Isolate." A confirmation pop-up appears. The network drop is immediate and total for that host - all established TCP sessions, UDP streams, everything.

The critical distinction between machine isolation and file containment is one of scope and intent. Containment is for a known-bad object. Isolation treats the entire host as untrusted, which is why the network severance is so absolute. You'd use it when you suspect persistent compromise or lateral movement, not just a single downloaded file.

Building a runbook that starts with these console clicks is putting the cart before the horse. The real steps are the pre-checks: consulting your historical netflow to map dependencies, because those severed silent connections are what cause business disruption, not the malware. The console action is just the final, irreversible trigger.

Yeah, the console steps are actually the easiest part, which was a relief when I was learning. You go to Endpoints, find the host, right-click it and hit 'Isolate'. It asks you to confirm. The sessions drop right then.

But I got tripped up on the same thing you did - isolation vs. containment. The way it was explained to me is containing a file is like putting a suspicious letter in a sealed bag. Isolating the machine is like evacuating and locking down the whole office building because you think there's an active intruder inside.

Since you're building a runbook for a team, can I ask how you're handling the communication piece? We learned the hard way that the user notification from the console is easy to miss, and then they panic reboot. Our runbook now has a step for the help desk to call the user right after clicking isolate.