We don't have a 24/7 SOC, so we're considering automatic isolation for servers and other high-value devices when Microsoft Defender for Endpoint triggers custom, high-confidence detections—for example, a shell launched from an unusual parent process. During business hours, someone could investigate quickly, 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 any false positives, and then enable automatic isolation only for the most precise rules. Has anyone implemented something similar? How often did false positives occur, and did the protection prevent a real incident or create operational problems?
5 Answers
Some organizations do allow automatic isolation of both workstations and servers, but it depends heavily on the environment. If you do not run systems such as payment platforms or an ERP system, and recovery is straightforward, the risk may be acceptable. Hospitals and other environments with continuous critical operations should be much more cautious.
A common policy is to isolate workstations for a high-severity alert or several medium-severity alerts. False positives still happen, but they tend to be uncommon once the rules are tuned. Running in audit mode first is a good idea, but also measure which assets would be affected and test how quickly you can restore access after an isolation.
Expect false positives eventually. Whether that is acceptable depends on how much downtime your business can tolerate and how quickly you can reverse an isolation. I’d start with user workstations because they are usually the most common entry point and generally have a lower operational impact than servers. You may decide never to auto-isolate servers, and that can still be a sensible policy.
Application controls such as WDAC or AppLocker can also make workstation protection much stronger, although they take effort to tune and maintain.
The strongest case for managed detection and response is overnight coverage. An MDR provider can validate alerts and contain a host while your internal team is unavailable. If you do automate this yourself, use narrow rules, keep exceptions temporary, preserve a break-glass access path, and make sure the isolation and rollback procedures work when normal network access is unavailable.
I’d avoid a blanket isolation rule for servers. For many systems, blocking suspicious egress or using network segmentation is safer unless the detection is unequivocal. Test the workflow with historical alerts and an after-hours tabletop exercise rather than relying only on a 45-day waiting period.
Be particularly careful with domain controllers and other infrastructure that many systems depend on. Automatic containment can create a larger outage, and some tools have had issues when isolating those systems. Also account for attackers pivoting through printers, cameras, unmanaged devices, or temporary virtual machines, since endpoint isolation alone may not stop lateral movement.
Useful detections to consider include ransomware behavior, credential theft tools, disabled security controls, unexpected remote-management utilities, file-transfer tools, network scanners, and unusual scripting or runtime activity. Each should be validated against legitimate administrative use before enabling automatic response.
Selective isolation can reduce the impact of a mistake. If the device stays connected to the tools people need, a late-night false positive may be an inconvenience rather than a full outage.