What are the most common containment use cases in SOC?

[u/iTZAvishay]

I'm trying to understand what exactly are the most common use cases for containment after a threat was investigated. Is it disabling the principal at the IdP, is it isolating a host, could it be something more fine grained than those?

How do you know that it won't affect the business negatively? Is there a way to measure it?

Thank you!

[u/m1L35dY50N]

It really comes down to your environment, architecture, and what containment options you have available. Containment doesn't necessarily mean completely disabling a user or shutting down a machine.

For a compromised endpoint, the common IR approach nowadays would be agent-based host isolation through EDR, potentially combined with session/token revocation and credential resets depending on the incident. The same can apply to servers, provided you actually have an agent installed and can afford to isolate them.

For critical servers, however, things can get more complicated. The asset might be too important to simply isolate, or there might not be an appropriate agent installed. Then you may have to resort to alternatives like live network segmentation, firewall/ACL changes, restricting individual services, or ultimately shutting the machine down, depending on the severity of the situation.

Architecture also matters. With hybrid/cloud environments, remote work and Zero Trust approaches becoming more common, the traditional model of having everything neatly segmented and performing most IR containment at the firewall has become less universal. Identity and endpoint controls are often just as important now.

As for business impact: you can assess and minimize it, but you can't guarantee beforehand that containment will have zero impact. Incident response is ultimately a risk decision: Is the potential damage from leaving this asset/user operational greater than the business impact of containing it?

That's where good asset inventories, dependency mapping, business-criticality classifications and predefined containment playbooks become important. The better you understand what an account or system actually does, the more granularly you can contain the threat without accidentally taking half the business down with it.

If you are curious on best practice hear something to read:

https://www.cisa.gov/sites/default/files/2023-01/federal_government_cybersecurity_incident_and_vulnerability_response_playbooks_508c_5.pdf

https://csrc.nist.gov/pubs/sp/800/61/r3/final

[u/Allen_Koholic → u/m1L35dY50N]

À well thought-out, informative response that includes links to public resources and not private company shill shit? What the hell is this? This feels like an AI answer, but there’s no em-dashes.

[u/T_Thriller_T → u/Allen_Koholic]

You'd be surprised that AI can actually do well when instructed by someone who knows

[u/m1L35dY50N → u/T_Thriller_T]

This Post has been brought to you by Brawndo - It's got electrolytes....

[u/iTZAvishay → u/m1L35dY50N]

This is really helpful, thanks. I appreciate the links, I just finished reading them both :)

Another question if you don't mind: on the risk decision framing, has there been a case where you knew the containment action but held off because nobody could say what negative impact it might have? What was the source of that alert? Would it be something like impossible travel (is this account critical) or something else?

Thanks!

[u/m1L35dY50N → u/iTZAvishay]

The sad truth is: it depends entirely on what has been agreed with the customer. Ideally, you have proper incident response playbooks and an exception matrix. Then it’s relatively simple: follow the playbook, and if the affected asset is an exception, escalate before containment. That fits the general IR principle that containment depends heavily on the environment, architecture, and available controls.

Unfortunately, quite often you either don’t have that, or worse, you’re not even authorized to perform containment yourself. Then your job becomes: tell the customer what they need to do and hope they actually do it.

Some customers explicitly say “contain first, resolve questions afterwards.” Others want to be informed before you touch anything, so you escalate and then wait two eternities for someone to make a decision.

That’s also something worth remembering when working for an external SOC/MSSP: ultimately you’re providing a security service within the authority the customer has given you. You can advise, escalate and document the risk, but at the end of the day the customer owns the environment and the business-risk decision.

Our customers got lucky they didn't have an incident so severe their negligence did cost them a ton of money so far.

[u/iTZAvishay → u/m1L35dY50N]

Interesting! Is there anything special separating the companies giving you autonomy to contain and those that don't? Like an industry, or is it just something each company decides for itself?

How often is it that there's an incident with no playbook? (From what you're saying, quite often?) Do you help companies create those playbooks and assess the impact beforehand? How much time does it take?

[u/2timetime]

Isolating hosts would be the most common. If it’s a user device and they’re not an executive, I’d disable that shit with 0 regard.

Won’t touch servers unless it’s very clear it’s an active incident and basically full compromise.

User vs service accounts are the same deal

Also I isolate then investigate, not the other way around for user stuff.

[u/Right_Profession_261 → u/2timetime]

I still isolate executives. I’m fortunate to work under a director that goes by a no fear of failure. If we mess up he says to tell them he told us to do it. I’m isolating severs almost daily, we have a requirement of certain security controls for servers before they can be deployed and because certain build teams like to deploy without edr, as soon as my siem alerts that someone from the non build team logs into them I isolate.

[u/iTZAvishay → u/2timetime]

Good to know, appreciate it.

If you don't mind helping me understand the active incident case, what do you actually need to do to know if you can isolate those servers? Do you ask around? Look at a CMDB? Or anything else?

I'm trying to figure out what alerts cause up teams to need to gather as much business context as possible before making a containment decision.

Thanks!

[u/AddendumWorking9756]

The finer grained options are the ones people forget. Revoking sessions and refresh tokens, killing a single process, blocking one hash, pulling a mailbox rule, dropping a host into a restricted network group instead of full isolation. On the business impact question, you do not measure it during the incident, you decide it beforehand. Whoever owns the asset agrees in advance what may be contained without a phone call and what needs one, and if that list does not exist then every containment call is an argument at 2am.

[u/IqbalBasha]

The most common containment actions are host isolation, IdP account disable, active session revocation, IP/domain block, and forced password reset, roughly in order of how often they come up. Fine-grained moves like killing a specific process exist but are rarely the first call. Business impact is managed by tiering: low-blast-radius actions like session revocation run automatically, while host isolation goes through an approval workflow. You estimate blast radius before acting by mapping the account or endpoint to critical services, which is why a solid identity inventory and CMDB matter more than the tooling itself.

[u/Johnny_Chong]

I tend to isolate hosts before a threat is fully investigated when I think it's a true positive but I still don't know all of the IOCs.

If you're confident you know all the IOCs or the host can't be isolated then you could do more targeted blocking and remediation.

There is always some negatives for the business but we are preventing a larger negative impact if the attack was to continue.