We don't have a 24/7 SOC, so we're considering automatic isolation in Microsoft Defender for Endpoint for servers and selected high-value devices when specific, high-confidence custom detections fire—for example, a shell launched from an unusual parent process or suspicious event-log tampering. During business hours someone can respond, but after around 7 PM there usually isn't anyone actively monitoring. Our idea is to run the detections in audit-only mode for about 45 days, review false positives, and then enable isolation only for rules that prove reliable. Has anyone implemented something similar? Did false positives cause serious problems, or has it mostly been routine and worthwhile?
4 Answers
Managed detection and response can be valuable when nobody is available overnight. Providers using tools such as SentinelOne or Huntress can contain a host and investigate at the same time. Automatic isolation has stopped ransomware and lateral movement in some environments, but I would keep domain controllers and other core infrastructure behind stricter safeguards until the behavior and recovery process are thoroughly tested.
For servers, I’d be more conservative than for workstations. Consider network segmentation or restricting egress first, unless the detection is unmistakable—for example, confirmed ransomware behavior, credential theft tooling, or security controls being disabled. Make sure the automation creates a ticket or alert containing the hostname, user, detection, and recovery steps so someone can triage it first thing in the morning.
The right answer depends heavily on the business impact of losing a host. Some organizations can tolerate an isolated server, while hospitals, payment environments, and other operational settings may not be able to. Before enabling the action, measure false positives by detection and asset criticality, create time-limited exceptions, preserve a break-glass management path, and document how to reverse isolation. An after-hours tabletop and testing the rollback process are just as important as a 45-day observation period.
We automatically isolate workstations for a narrow set of high-confidence detections, and use a higher threshold such as a critical alert or several medium-severity alerts. False positives do happen, but they’ve been uncommon and usually involve a user doing something unusual rather than malicious. I’d start with user endpoints before servers: they’re a common entry point and generally have a lower outage impact. Selective isolation can also keep services such as email and collaboration tools working while the device is contained.
Application control through WDAC or AppLocker made a bigger difference for us on workstations than isolation alone. It takes effort to tune, but it blocks a lot of common unwanted execution.
We’ve allowed automatic isolation on servers because our environment can tolerate the occasional false positive. That may not be appropriate for systems where even a short interruption has major financial or operational consequences.