The Number That Breaks Your SOC
Pick a number: how many alerts does your EDR generate per day? For a 600-endpoint environment running CrowdStrike Falcon or SentinelOne at default sensitivity, the answer is usually somewhere between 400 and 1,200, depending on the software estate and how many developers are running build tooling that looks like malicious activity to a behavioral engine. For a 1,500-endpoint environment, you can double or triple that.
Now compare that to analyst capacity. A competent Tier-1 analyst triaging alerts thoughtfully — opening the process tree, checking the parent chain, looking at the machine's recent history — spends three to eight minutes per alert on the ones that require any investigation at all. At 90 seconds average (optimistically, for the ones that are obviously benign), a single analyst can review 240 alerts in a six-hour shift. A two-analyst SOC running 12-hour shifts handles roughly 480 alerts per day at that rate. If your EDR is generating 800, you are running a structural deficit from day one.
This playbook covers the four reduction layers — applied sequentially — that take that 800 down to a manageable number without creating detection blind spots.
Layer 1: Policy Tuning — The Free Win You Are Probably Leaving on the Table
Every EDR platform ships with a detection policy configuration that is tuned to be broadly sensitive — appropriate for a threat-hunting deployment or an environment with high tolerance for false positives, but not appropriate as the default operational posture for a Tier-1 queue.
In CrowdStrike Falcon, the prevention policy controls at the sensor level determine which process behaviors trigger detections. The "sensor visibility exclusions" and "machine learning sensitivity" settings have enormous impact on alert volume. Developer machines running Python build environments, endpoint protection management tools, and backup agents all generate high-frequency process patterns that look like suspicious behavior to a default-configured behavioral engine. Scoping these to exclusions — documented, reviewed annually, and scoped to specific groups rather than environment-wide — can eliminate 20–30% of daily alert volume without changing coverage for the actual threat patterns you care about.
SentinelOne's detection policy structure similarly distinguishes between "suspicious" and "malicious" thresholds, with separate configurations for prevention vs. detection mode. Operating in detection mode with conservative thresholds on developer endpoints and prevention mode on standard business workstations is a configuration pattern that reduces noise dramatically on the developer cohort while maintaining strong coverage on the higher-risk corporate device population.
The important discipline here: document every exclusion in a detection exception register, map each exception to the MITRE ATT&CK technique it affects, and review quarterly. Exclusions that are not reviewed become permanent blind spots. A deployment that has 200 undocumented process exclusions accumulated over two years of "just suppress that" responses has unknown detection gaps that policy tuning was never designed to create.
Layer 2: Entity Behavioral Baselines — The Difference Between "Anomalous" and "Malicious"
The second layer operates above the raw EDR policy level. Behavioral baselines per entity — per host, per user account, per service account — allow you to distinguish between a detection that is technically anomalous (this process type does not normally run on this host) and one that is truly indicative of compromise.
Consider a detection for PowerShell network connection (T1059.001 + T1071.001). On a developer's workstation that runs Ansible playbooks regularly, that detection fires dozens of times per week and is almost never malicious. On a finance team member's laptop with no prior PowerShell network activity in 90 days of observed behavior, the same detection is a high-priority escalation candidate.
Building entity behavioral baselines requires 30 to 90 days of observation data per entity before the baseline is reliable. During the baseline period, all detections should be logged and reviewed, but the analyst queue should be managed with the understanding that the baselines are not yet calibrated. After the baseline period, detections can be scored against the per-entity baseline: high deviation from baseline increases escalation priority, low deviation routes to suppressed queue for periodic review.
Carbon Black's process and network analysis capabilities are particularly well-suited to this baseline approach — the platform's reputation service and per-hash analysis provide a useful starting point for establishing what "normal" process execution looks like on a given machine type. Layering per-entity baselines on top of that gives you a two-dimensional scoring system: known-bad process hash + deviation from entity baseline, rather than a single-axis "is this process suspicious?"
Layer 3: Known-Benign Process Chain Suppression
Even with policy tuning and entity baselines applied, there will be a category of alerts that are neither tunable at the policy level nor suppressable based on entity deviation — because they are behaviors that are legitimately anomalous for the entity but consistently benign in your environment due to specific software or operational patterns.
Common examples: endpoint management agents (PDQ Deploy, Tanium, BigFix) that execute code on remote hosts via scheduled tasks (T1053.005 technique pattern), backup agents that read process memory for application-consistent snapshots (T1003 pattern), vulnerability scanners that spawn child processes performing network enumeration (T1046 pattern). These are tool behaviors that are indistinguishable from malicious technique usage from the EDR's perspective, but are completely expected in your environment given your operational tooling.
The suppression approach for this category: create named process chain suppressions scoped to the specific initiating process hash, the specific parent process identity, and the specific child process pattern. Do not suppress by process name alone — process names are trivially spoofed. Suppress by the combination of the three attributes, which makes the suppression resistant to an attacker abusing the same process name to bypass detection.
The discipline is the same as Layer 1: document each suppression, map it to its technique equivalent, and review quarterly. An undocumented suppression list is an exploitable detection gap waiting to be discovered.
Layer 4: Cross-Source Correlation Gating
The first three layers — policy tuning, entity baselines, and process chain suppression — will typically reduce raw EDR alert volume by 60–75% in a well-tuned deployment. The remaining 25–40% are genuine behavioral anomalies that warrant evaluation. Cross-source correlation gating is the layer that determines which of those genuine anomalies get escalated to the analyst queue and which get routed to a pending review queue for retrospective examination.
The logic is straightforward: a behavioral detection that is corroborated by a concurrent event from a second source (identity log, CloudTrail, or a second EDR event on a different host in the same entity cluster) gets escalated. A behavioral detection with no corroborating signal from any other source within the detection window gets logged and routed to pending review.
The detection window for correlation gating in the EDR context is typically shorter than for cross-source kill-chain detection — 5 to 15 minutes is appropriate for same-session activity, since most credential theft and immediate lateral movement sequences execute within minutes of each other. For persistence mechanisms (T1053, T1547), a longer window is appropriate because attackers may establish persistence and then go dormant before the next kill-chain stage.
A worked example at scale: a mid-market media company, approximately 900 endpoints, CrowdStrike Falcon plus Okta plus AWS CloudTrail. Raw daily Falcon alert volume: approximately 680. After policy tuning (Layer 1): 440. After entity baseline scoring (Layer 2): 280 in the active queue, 160 in low-deviation monitoring. After process chain suppression (Layer 3): 195 in active queue. After cross-source correlation gating (Layer 4): 18 corroborated escalations requiring analyst action, 177 pending review for retrospective investigation. That is a 97% reduction in the active analyst queue — from 680 to 18 — while preserving full visibility into the suppressed events for retrospective review.
The MITRE ATT&CK Coverage Preservation Test
Every noise reduction change should be accompanied by a coverage preservation check. The practical method: take your current detection policy configuration and run it against a library of known technique emulation outputs — process traces, network patterns, registry modifications — that represent each ATT&CK technique you care about. After each reduction layer is applied, re-run the emulation set and verify that the detection layer still fires on the known-bad patterns.
This does not require a formal purple team exercise for every change. A minimal coverage preservation test can be run using Atomic Red Team test cases mapped to the specific techniques your environment is most exposed to. The goal is not comprehensive ATT&CK matrix coverage — that is an enterprise ambition. The goal is verifying that the reduction changes did not accidentally suppress the five to ten technique detections that matter most for your threat model.
This is not to say that noise reduction is riskless. Any suppression or exclusion introduces the theoretical possibility that an attacker exploits the suppressed pattern to evade detection. The discipline of documentation, quarterly review, and coverage testing is what keeps that theoretical risk from becoming an actual blind spot. Noise reduction without governance is a different problem — and a worse one than the alert volume you started with.
The Sustainable Triage Model
The endpoint of this playbook is a triage model that is sustainable for a small team. Eighteen corroborated escalations per day — each with three-source context pre-assembled, entity behavioral deviation scores attached, and kill-chain stage classification applied — is a workload that two analysts can handle with time remaining for proactive threat hunting.
The 177 events in pending review are not ignored. They are available for retrospective investigation, they feed back into the behavioral baseline calibration, and they are searchable if a corroborating event surfaces later that makes one of them relevant. Retrospective investigation is a different cognitive mode from real-time triage — it is pattern analysis work that benefits from accumulated context, and it is the kind of work that develops analyst skill rather than depleting it.
Sustainable triage is a detection architecture goal, not a staffing goal. The four layers in this playbook are engineering decisions that change the cost function of detection without changing the coverage surface. That is the math that needs to change in the mid-market SOC.