One Defend policy for 5,000 heterogeneous endpoints

One policy across 5,000 heterogeneous hosts guarantees you pay the worst-case cost everywhere.

• Windows workstations (4,800): start with detection-only event capture and measure which hunts break. Malware, ransomware and memory protection all on - that is where commodity malware lands.
• Production servers (all OS): keep all events, especially process events, because servers are the high-value target and the volume is small relative to workstations.
• Linux fleet (150): all process events, but consider dropping network events, which usually dominate volume and are the least useful on a server with no user browsing.
• macOS (50): prevention on; volume is negligible either way.

Quantify before acting: aggregate data_stream.dataset by host.os.type over 7 days. logs-endpoint.events.network is typically more than half of endpoint volume. If that holds, changing workstation network capture is the largest single win and the least damaging, because workstation network traffic is rarely the pivot point for a hunt that process and file events cannot answer.

Trade-off to state explicitly: network events feed network-behaviour rules and connection-based hunts (C2 beaconing, unusual outbound ports). Do not disable network capture on any host class covered by those rules. The correct order is split policies, measure, reduce capture on the noisiest low-value class, and only then touch ILM or retention.

Treat the policy as intent and the agent as observed state. Check in this order:

1. Fleet agent status. An agent whose output is blocked (wrong Fleet URL after a proxy change, expired enrollment token, full disk on the host) keeps its last configuration and simply stops shipping.
2. Policy revision. Agents still on an older policy revision may retain the previous capture mode. Sort the agent list by policy revision and look for stragglers.
3. Agent logs on the affected host. Messages about a full event queue or output backpressure mean the agent cannot keep up. That is usually caused by total event volume, not by process capture being off - the process events are the ones being dropped under pressure.
4. Endpoint status. Confirm the running policy from the endpoint's own status output, not only from the Fleet UI, since per-policy overrides can differ from what the UI summary implies.

Do not fix a full event queue by raising memory alone; it just moves the failure. Reduce total volume (previous step) or reduce the rule and hunt load reading it, then confirm with a targeted query such as event.dataset: endpoint.events.process and host.name: <host> over a 15-minute window rather than trusting the policy page. Correlate the affected host list against the Windows build versions - older builds with poor file-system notification behaviour are a recurring cause of partial process visibility.

Prevention on Linux is more conditional than on Windows. Verify:

• Support and kernel. Prevention depends on kernel-level file-system hooks. On unsupported kernels or hardened configurations the endpoint can run in detection-only mode while still producing alerts. Check the endpoint's own reported capabilities, not just the policy value.
• Applied policy. Confirm malware.protection is set to prevent in the policy actually assigned to that host, and that the host is in the policy's assignment (tags or explicit agent policy) rather than inheriting a stale one.
• Scan trigger. A binary executed from an excluded path, or one that never generates a monitored file event, is never scanned. Check exclusions and trusted applications for /tmp, the application directory, or a broad mount point.
• Coverage differences. The Windows protection matrix does not carry over unchanged. Ransomware and memory protection behave differently per OS; do not assume parity.

Diagnostic signal: a malware-detected alert with no corresponding prevention action recorded strongly suggests detect-only execution.

Fallback if prevention is genuinely unavailable for that fleet: compensating detection plus response. A behaviour rule on C2-like process lineage with automatic case creation and a manual isolation step, plus restricting execution from writable paths (noexec on /tmp, mount options) at the OS level. Then decide whether the real fix is a kernel or policy change, because for some Linux fleets prevention will never be available and detection-with-response has to be the documented control rather than an unstated assumption.