False Positives and Tuning
Summary
This note explains what false positives are, why they matter, and how tuning improves detection quality over time. The goal is to understand that good blue-team work is not only about creating alerts, but also about making them useful.
Why this matters
- too many noisy alerts make real triage harder
- weak tuning damages trust in detections and in the SIEM itself
- beginner blue-team work often improves most when alert quality improves, not when alert volume increases
Environment / Scope
| Item | Value |
|---|---|
| Topic | detection quality and tuning |
| Best use for this note | understanding alert noise and signal quality |
| Main focus | false positives, thresholds, exclusions, refinement |
| Safe to practise? | yes |
Key concepts
- False positive - an alert that fires even though the activity is benign or not actually relevant to the detection goal
- Tuning - improving the rule, threshold, exclusions, or supporting logic so alerts become more useful
- Signal-to-noise - how much useful value an alert provides compared to how much distraction it creates
- Threshold - a condition such as count, volume, or frequency that influences whether an alert fires
Mental model
An alert can be:
- technically correct
- but still operationally unhelpful
That usually means the detection is not wrong in a strict sense, but it is not tuned for the real environment.
Think about the flow like this:
telemetry -> detection rule -> alert -> triage outcome -> tuning decisionTuning uses the triage outcome to improve future alerts.
Everyday examples
| Situation | Likely tuning thought |
|---|---|
| admin script triggers PowerShell alert every day | add context or exclusions for known activity |
| many failed logons from a lab test host | adjust threshold or source-specific handling |
| one rule fires on many harmless background processes | narrow command-line or parent-process logic |
| alert has too little context to explain quickly | improve fields or enrichment rather than only changing severity |
Common misunderstandings
| Misunderstanding | Better explanation |
|---|---|
| ”A false positive means the rule is useless” | often it means the rule needs refinement, not deletion |
| ”More alerts means better security” | more low-quality alerts often make real detection worse |
| ”Tuning means lowering severity until the alert disappears” | tuning should improve relevance, not hide problems blindly |
| ”If one alert was noisy once, delete it” | first understand whether the rule, source, or threshold is the real issue |
Verification
| Check | Expected result |
|---|---|
| Alert logic is understood | you can explain why it fired |
| Benign pattern is identified | noisy cause is clear enough to tune safely |
| Rule change is tested | alert behaviour changes in the expected way |
| Signal improves | fewer noisy alerts without losing the useful ones |
Pitfalls / Troubleshooting
| Problem | Likely cause | What to check |
|---|---|---|
| Alert keeps firing on normal activity | rule too broad | thresholds, exclusions, source context |
| Tuning removes useful detections too aggressively | over-correction | test cases before and after tuning |
| Team no longer trusts the alert | long-term noise | recent triage outcomes, recurring benign patterns |
| Same issue keeps returning | tuning was local, not systemic | source quality, parsing, broader rule design |
Key takeaways
- false positives are normal, but they should lead to tuning rather than alert fatigue
- detection quality matters more than alert volume
- tuning is part of the detection lifecycle, not an optional extra