Cortex XDR Rollout: Legacy Servers, Automation False Positives, and Ransomware Blocking Under Deadline

Why one policy fails: the server population is not homogeneous. A domain controller, a backup target, and an EOL 2008 R2 box have different supported capabilities, different performance headroom, and different blast radii. A single policy forces you to set protection to the lowest common denominator (weak everywhere) or to the highest (breaks the fragile hosts and gets the rollout stopped).

Policy structure - separate profiles per risk/role tier

1. Workstations - full protection: malware, exploit, behavior threat, blocking enforcement.
2. Standard supported servers - full protection, with scan scheduling constrained to a maintenance window and CPU throttling set conservatively.
3. File and backup servers - detection-first for behavior and ransomware, with block enabled only after role-specific acceptance testing. These are the hosts where a false positive is an outage, and where the backup job that just broke lives.
4. EOL and unsupported-kernel hosts - these are a coverage problem, not a policy problem. Confirm which modules the agent actually supports on those builds before promising enforcement. Typically you get partial capability plus compensating controls: network segmentation, restricted admin paths, and explicit risk acceptance with an owner and a remediation date. Do not claim parity you cannot deliver.
5. Legacy AV coexistence hosts - an interim profile with conservative settings to avoid two real-time engines fighting over file I/O, then a staged removal that is verified host by host rather than assumed.

Sequencing Ring deployment by population, not by calendar: lab, then ~1% of workstations, then a business unit, then broad. Servers move last and per role, with the storage team's two problem hosts instrumented with performance telemetry before and after.

Evidence to gather first: actual CPU samples from those two file servers with the agent installed in detect-only mode, so the 45% figure is measured rather than asserted. If the spike is scheduled scan I/O, the fix is scan scope and timing - not disabling protection.

Diagnosis: PsExec and scheduled tasks are dual-use. The rules are not wrong - the environment is producing the technique legitimately at high volume, and the current signal cannot distinguish the automation account behaving normally from an attacker using the same tooling.

Approach: narrow exceptions, not rule disables

1. Scope the exception on the full context tuple, not just the process name: automation service account, the specific parent process chain, the source hosts or jump box, and ideally the signed binary hash. An exception on "PsExec" alone is an open door; an exception on "PsExec launched by account X from host Y with parent Z" is a narrow corridor.
2. Create a separate low-severity detection for the excepted activity rather than silence. It stays visible in the dataset, is searchable during investigations, and can be trended. Exceptions that produce no record are indistinguishable from a gap.
3. Watch the exception for drift. Alert if the automation account is used from a host outside the known jump boxes, outside the automation window, or with an unusual child process. Attackers who learn the account name will try exactly this.
4. Fix the root cause where possible. If automation is using PsExec because there is no approved remote-execution path, that is an infrastructure finding. Get it into the risk register with an owner; the exception is a control, not a solution.
5. Review on a schedule. Exceptions expire. Set a review date and re-justify - automation exceptions accumulate and are rarely revisited.

What to avoid: suppressing by account alone, suppressing both rules wholesale, or tuning the rule to exclude the technique. Each reduces the 1,100 alerts but creates a permanent blind spot in the exact area an attacker would use to move laterally.

What to tell the CISO: the deadline is achievable as a policy state and not achievable as a risk reduction if enforced everywhere at once. The backup server outage is the evidence - the module worked as designed against a job that legitimately rewrites files at volume. Repeat that across 3,000 servers and the outage becomes the incident.

Plan

1. Days 1-5 - baseline in detect-only. Enable the module in detect mode on the whole server estate. You need to know which legitimate processes look like encryption before you block anything.
2. Days 5-15 - ring one, non-critical servers. Small population, block enabled, with an agreed rollback that any on-call engineer can execute without approval. Define in advance what "broken" looks like: job failures, latency, file lock errors.
3. Days 10-20 - role acceptance testing. For each server role (backup, database, file, application), run the role's own workload against a blocking host, including a controlled benign encryption test in an isolated environment to confirm the module detects real encryption behavior and that legitimate backup compression does not trip it. The backup team signs off, not security.
4. Days 20-30 - expand by role, with the highest-value and highest-risk roles staged last. Backup servers get a role-specific profile and a defined exclusion set agreed with the backup owner, documented and reviewed.
5. Throughout - a live canary per ring, alerting on any blocked event, and a standing rollback drill.

What good looks like at day 30: every server is in a blocking-capable policy, the roles that cannot tolerate it yet have a documented exception with a remediation date, and the exception list is short and owned. That is a defensible 30 days. Promising full enforcement on every host regardless of workload tolerance is not, and the outage will be attributed to security.