Response

Endpoint isolation and account containment

One playbook contains a compromised host or account whichever EDR or identity provider sits underneath: isolate, disable, revoke, verify, and undo when it was a false alarm.

The problem

Each EDR has its own API, its own vocabulary for isolation and its own failure modes. Teams that run more than one tool end up with several procedures, and the analyst on shift has to remember which console does what.

Stack

EDR: CrowdStrike FalconMicrosoft Defender for EndpointSentinelOneTrend MicroCybereason
Identity: Entra IDOkta
Orchestration: Cortex XSOARCortex XSIAMSplunk SOARn8n
Ticketing and alerts: ServiceNowJiraSlackMicrosoft TeamsPagerDuty

How it works

1
Trigger
A confirmed detection or an analyst decision calls the containment playbook with a host or a user as input.
2
Resolve
The playbook finds which EDR manages the host (CrowdStrike, Microsoft Defender, SentinelOne, Trend Micro or Cybereason) and checks how critical the host is.
3
Approve
Servers, executive devices and other critical assets require an approval. Ordinary endpoints can be isolated automatically under rules the SOC sets.
4
Act
The playbook isolates the host through the right API. For a user, it disables the account, revokes sessions and resets credentials in Entra ID or Okta.
5
Verify
It polls the EDR until the host reports as isolated and records the result. A timeout opens an escalation instead of failing silently.
6
Release
When the case closes, the same playbook lifts the isolation and re-enables the account, with the same checks.

Guardrails and failure handling

A maintained list of critical assets decides which actions need approval.
Running the playbook twice on the same host changes nothing the second time.
Isolation and release are both reversible and both recorded.
Every action keeps who requested it, who approved it, what was changed and when.