← Detection Engineering: From Telemetry to Tuned Detections
Foundations of Detection Engineering
What Is Detection Engineering? The Detection Engineering Lifecycle
Telemetry and Data Sources
Understanding Telemetry Sources Data Quality and Detection Blind Spots
Writing Detection Logic and Mapping Adversary Behavior
From Technique to Detection Logic MITRE ATT&CK Mapping for Detection Engineers
Testing, Tuning, and Reducing False Positives
Testing Detections with Adversary Emulation Tuning Detections and Reducing False Positives
Operating Detections in Production
Building a Sustainable Detection Program
Testing, Tuning, and Reducing False Positives

Tuning Detections and Reducing False Positives

Learn practical techniques for tuning thresholds, adding context, and creating exceptions to reduce noise without introducing dangerous blind spots.

In this lesson, you will learn to:

  • By the end of this lesson, learners will be able to tune detection thresholds and exceptions using baselines, and explain how to reduce false positives without creating false negatives.

Tuning Detections and Reducing False Positives

This lesson teaches students how to tune detections in production. They learn how to set thresholds using baselines, add context to improve alert quality, use exceptions carefully, and monitor the impact of tuning decisions over time.

Setting Thresholds from Baselines

Thresholds are the simplest tuning lever, but they are often set by guesswork. A threshold based on real data is far more reliable than one based on intuition.

What is a baseline?

A baseline is a measurement of normal behavior. It tells you how often an observable occurs in ordinary operations. For example, you might measure how many failed logins a typical user generates in an hour. That number is your baseline.

How to set a threshold from a baseline
  1. Query historical data for the observable you want to threshold.
  2. Calculate the normal rate or count over your chosen time window.
  3. Set the threshold above the normal range, leaving a small buffer.
  4. Observe the detection in production and adjust as needed.
A realistic example

Suppose you want to detect brute-force login attempts. You query your authentication logs and find that most users have fewer than five failed logins per hour. You set the threshold at ten failed logins in one hour. This threshold catches real brute-force attacks without alerting on every forgotten password.

Avoid one-size-fits-all thresholds

Normal behavior varies by user, role, and system. A service account might legitimately generate far more logins than a standard user. A threshold that works globally may produce many false positives for automated accounts. Where possible, segment your baselines by relevant groups and apply different thresholds.

Setting Thresholds from a BaselineA light-theme diagram showing a normal activity baseline with small bars and a threshold line above it, catching an anomalous high spike.Setting Thresholds from BaselinesMeasure normal behavior, then alert above itAnomalyThresholdNormal baseline is low and consistentThe threshold sits above normal, catching only the spike
Setting Thresholds from a Baseline — A light-theme diagram showing a normal activity baseline and a threshold set above it to catch anomalous behavior.

Exceptions and Suppressions

Exceptions and suppressions are powerful tuning tools, but they are also where many detection programs quietly create blind spots. Understanding the difference and using them carefully is essential.

What is an exception?

An exception is a rule that tells the detection to ignore certain events that are known to be benign. For example, if a specific automated tool always triggers a detection and the team has verified it is safe, you might add an exception for that tool’s behavior.

What is a suppression?

A suppression is similar, but it usually hides the alert rather than changing the detection logic. Suppressions are often temporary, used while a known issue is investigated. They can be dangerous if they become permanent without review.

The risk of broad exceptions

Every exception narrows the detection. If an exception is too broad, an attacker can hide inside it. For example, an exception that ignores all activity from a specific administrator account would create a serious blind spot if that account were compromised.

Guidelines for safe exceptions
  • Be specific. Exclude only the exact known-benign behavior, not the whole source or account.
  • Document why. Record the reason for every exception so future engineers understand the context.
  • Set an expiry. Review exceptions regularly. If the original reason no longer applies, remove the exception.
  • Prefer logic refinement over exceptions. Sometimes the better fix is to improve the detection logic so the false positive is not generated at all.

Used wisely, exceptions reduce noise. Used carelessly, they silently remove your protection. Treat every exception as a small hole in your coverage, and make sure each hole is justified.

Safe Exception GuidelinesA light-theme checklist showing four guidelines for safe detection exceptions: be specific, document why, set expiry, and prefer logic refinement over exceptions.Safe Exception GuidelinesEvery exception is a small hole in coverage, make it justified1Be specificExclude only the exact known-benign behavior, not a whole account or source2Document whyRecord the reason so future engineers understand the context3Set an expiryReview exceptions regularly and remove them when no longer needed4Prefer logic refinementFix the detection logic so the false positive is not generated at allUsed wisely, exceptions reduce noise; used carelessly, they remove protection
Safe Exception Guidelines — A light-theme checklist showing four guidelines for safe detection exceptions: be specific, document why, set expiry, and prefer logic refinement.

Monitoring the Impact of Tuning

Tuning is not a single action. It is a cycle. After you adjust a threshold or add an exception, you must monitor the impact to confirm you improved the detection without breaking it.

Metrics that matter

Track simple metrics for each detection:

  • Alert volume. How many alerts per day or week?
  • False positive rate. What portion of alerts turn out to be benign?
  • True positive count. Has the detection caught real activity?
  • Time to triage. How long do analysts spend on each alert?

These metrics give you a baseline for tuning decisions. If you change something and alert volume drops but true positives also disappear, you may have gone too far.

A tuning feedback loop

The tuning loop looks like this:

  1. Observe current performance.
  2. Make one small change.
  3. Let the detection run for a defined period.
  4. Compare new metrics against the previous baseline.
  5. Keep the change or revert and try again.

Avoid making multiple changes at once. If you change a threshold and add an exception simultaneously, you will not know which change caused the result.

Watch for silent failure

The worst outcome is a detection that quietly stops firing. This can happen if a tuning change is too aggressive or a data source breaks. Regular monitoring of detection volume can catch silent failures early. If a detection that used to fire weekly suddenly produces nothing for a month, investigate immediately.

Tuning is a skill that improves with practice. The more detections you tune and observe, the better your intuition becomes. But always let data guide your decisions, not just intuition.

← Previous: Testing Detections with Adversary Emulation Next: Building a Sustainable Detection Program →