The detection my whole team wanted silenced was a domain reconnaissance rule in my last fintech SOC: net.exe and nltest commands enumerating privileged groups. It threw about sixty alerts a day, and nearly all of them were information technology (IT) administrators doing routine work. The night-shift lead asked me twice in one week to just disable it.
I responded by pulling six months of its alert history and found exactly one true positive: the early recon phase of a red team engagement we had paid for. Disabling the rule would have deleted the only working coverage we had for that behavior.
My operating assumption is that exclusions and suppression rules remove pieces of coverage whenever they make alerts disappear, and disabling a detection removes its coverage too. The honest work is deciding, exclusion by exclusion, which pieces the program can afford to lose. Tooling can speed that decision up; the detection team still owns the coverage decision.
In brief:
- Vendor-provided rules are often a major source of false positives, which makes the default rule library the first tuning target, ahead of custom detections.
- Broad exclusions can create blind spots that attackers may exploit.
- Safe tuning starts by diagnosing why a rule fires and adding context to the logic itself. Before shipping, count the historical true positives an exclusion would have suppressed.
- A false positive rate near zero can signal a detection narrowed until it misses real attack variants.
False positives require detection engineering, not just triage
Much of the noise originates in detection engineering tools, especially vendor-provided rules, and the default rule library is a practical place to begin tuning for exactly that reason. Tracking a false positive rate isn't the same as prioritizing its reduction, and treating the two as equivalent is a governance failure that no procurement cycle closes on its own.
A triage layer on top speeds disposition after an alert fires while leaving the underlying signal unchanged, but the root cause remains upstream of anything you can buy. Reducing false positives at the source requires detection engineering; faster disposition only addresses analyst workload after the noise has already been created.
Why cutting false positives quietly cuts coverage
A detector can achieve zero false positives by never alerting, and it would also miss every attack. I treat every tuning action as movement along that same axis, and chasing extremely low rates can cause overfitting, where detections are scoped so narrowly they miss adversarial variants of the behavior they were built for.
Every exclusion is a small blind spot
Attackers can treat exclusion lists as a map. Documented ransomware incidents show attackers using exclusions to bypass antivirus (AV) defenses, adding paths or processes to exclusion lists so malicious payloads and credential-harvesting tools run with less scrutiny.
I treat blind spots defenders create voluntarily the same way. Vendor-recommended exclusions meant to avoid false positives leave directories or processes unscanned, and gaps form wherever malicious code can occupy that space. Palantir's ADS framework makes that cost visible, requiring detections to document blind spots and failure conditions, so coverage given up gets written down before it's given up.
How I actually tune a noisy detection
Diagnose every noisy rule before changing its logic, and change the logic before adding exclusions. Measure coverage loss before anything ships.
Start from why it fires, not how often
Alert count tells me which rule to look at, not what to do with it. I first check for broken logic, like a bad regex or field mapping. If the logic works, I assess whether it's calibrated for the environment, as with PowerShell detections in a Windows admin shop. Rules catching real violations may just need operational handling once volume exceeds capacity. Applying the wrong fix is how coverage dies.
The diagnosis is cheapest before deployment. A pre-operational data study lets engineers triage their own analytic results and identify what context separates benign from malicious instances. The governing principle is that a behavior being common in your environment doesn't necessarily make it a bad detection opportunity.
Tighten on context
When a rule is noisy, teams often exclude a process, host, or subnet. Add conditions describing why the traffic is benign instead: user history and working hours cut daily volume while preserving a high true positive rate. Impossible-travel detections improve when suppression logic accounts for VPN use and suspicious-IP profiles. Renamed-utility detections follow the same pattern: scope exclusions to known tools, never the whole class.
That's how I rebuilt the recon rule from my opening. I preserved net.exe and admin subnet coverage by adding conditions for account type and time of day. The rule also checked whether the source host had touched a domain controller in the prior thirty days. Volume dropped by roughly 90%, and the rule would still have caught the red team, because their activity failed every one of those conditions. A subnet exclusion would have waved them straight through.
Measure the true positives you'd lose before you cut
Before any exclusion merges, run it against history. Detection-as-code pipelines can replay historical logs to confirm a rule fires without over-firing, and tuning metadata can track true_positives, tuned_after_creation, and threshold_changed to keep drift visible. My bar is simpler: pull every confirmed true positive the rule has produced and run the proposed exclusion against each one. If it would have suppressed any of them, it doesn't ship.
A blocking continuous integration (CI) gate that counts suppressed historical true positives and fails the merge above a threshold remains rare in most environments, so this count is usually a manual review step. A reasonable program-level target while doing the manual version is to tune the highest-volume rules with documented exclusions, materially cut alert volume, and avoid disabling any rule that has ever produced a true positive.
The false positives worth keeping
Some of what your metrics call false positives are detections working as designed. True positive benign is a useful category: the logic correctly flagged threat-shaped behavior, and investigation found a legitimate cause, the way Microsoft Defender for Identity treats a pen test. These alerts prove the rule works; tune the volume, keep the rule. A noisy rule on a high-priority adversary can be worth its cost when it preserves visibility on a high-risk vector.
Demote rules that can't earn direct attention instead of disabling them. Splunk risk-based alerting routes noisy detections to a risk index that accumulates into higher-fidelity notables, and Sentinel's Fusion engine correlates low-fidelity alerts into incidents the same way. Scheduled threat-hunting queries are another release valve, since hard suppression removes the signal entirely.
How tools affect detection noise, and where they don't
Detection engineering tools intervene at different pipeline stages, and the stage determines whether they fix noise or relocate it.
Enrichment that reaches the detection logic helps; enrichment bolted on downstream doesn't
Tools help where they touch the detection logic itself, since changing the rule improves the underlying signal rather than just filtering its output. Teams that trace alert fatigue back to atomic detections lacking asset and identity context, then move that context into the detection layer, get a real fix. Platforms that feed triage decisions back into detection logic can shrink volume over time; faster triage alone just processes the existing noise.
In my experience, enrichment and AI triage bolted on downstream mostly relocates noise: auto-closing a false positive leaves the detection untouched, and debt accrues if nobody reviews it. A high closure rate isn't enough if the system also makes errors. AI SOC agents remain early enough that I'd verify vendor claims first; the category includes Prophet Security, Dropzone AI, Exaforce, and 7AI, and their tradeoffs differ enough that the label alone tells you little.
Run this test before your next tuning cycle
This week, pull the alert history on your noisiest rule and find its last true positive. If there is one, that alert is the exact price of the exclusion you were about to write. The recon rule my team wanted dead still runs today, at two alerts a week, and it caught the next red team too.
Frequently asked questions about tuning detections
How do you reduce false positives without losing coverage?
Fix broken logic first. For environmental noise, add context conditions, using a user's history and working hours to explain expected behavior, and account for asset criticality when deciding whether the activity merits an alert. Demote noisy true positives to risk scoring or hunt rotations, then replay any exclusion against the rule's true positive history. If it would have suppressed a real incident, narrow it until it wouldn't.
Do detection engineering tools actually reduce false positives?
Only at the layer where the noise is created. Detection-as-code pipelines with unit testing and historical replay, and platforms that feed triage outcomes back into rule logic, reduce false positives at the source. AI triage and enrichment layers that only filter or auto-close alerts reduce what analysts see without fixing what fires. Because vendor default rules are often a major noise source, that library stays a high-value tuning target regardless of tooling.
What is a good false positive rate?
There's no universal benchmark, since tolerance depends on daily alert volume and analyst capacity. Mature teams set targets by each rule's severity and threat priority, then calibrate them to available investigation capacity. Zero is a warning sign: a detection that never false-positives may have been narrowed until it also misses attack variants.
When should you keep a noisy detection?
Keep it when it maps to a high-priority technique or threat actor. Also keep alerts that are true positive benign, where the logic works and the causes are legitimate, and keep signals with correlation value alongside other weak signals. In those cases, demote the signal into a risk index or a building block rule instead of disabling it. A scheduled hunt can also keep the signal available without hitting the analyst queue.