Detection tuning is the work of adjusting detection rules after they are written so they fit the environment they run in. A rule straight from a vendor pack or a Sigma repository often fires on normal activity, misses variations of the attack, or both. Tuning narrows the noise, closes the gaps, and confirms with real data that the rule still catches what it was built to catch.
Why Detections Need Tuning
Every environment has its own tools, admin habits and software. A rule that flags rundll32.exe loading a DLL from a user folder may be quiet in one company and fire constantly in another where a legitimate application does exactly that. Rules also age: new software arrives, field names change after an agent upgrade, and log sources get added or dropped.
Untuned rules lead to two problems. Noisy rules cause alert fatigue and get muted. Rules that are too narrow miss small variations, such as a renamed binary or a different command-line flag.
How Detection Tuning Works
1. Measure the current rule
Run the rule against past telemetry, often 30 to 90 days, and look at every match. Note which matches were benign and why, and whether any known incidents or tests were caught.
2. Adjust the logic
Add narrow exclusions for known-good activity, such as a specific signed binary, service account or parent process. Broaden the logic where it is brittle, for example by matching on behavior or command-line arguments rather than a file name.
3. Test the change against the same history
Rerun the tuned rule over the same window. The benign matches should drop, and any true positives from before should still match.
4. Confirm with a simulation
Past data may not contain the attack at all. Running a safe simulation of the technique shows whether the tuned rule fires on the behavior today.
5. Deploy and watch
After deployment, track the alert volume and outcomes for a while, and revisit exclusions periodically.
Detection Tuning vs Detection Engineering
Detection engineering covers the full life of a detection: choosing what to detect, writing the rule, testing, deploying and maintaining it. Tuning is the maintenance part of that cycle, applied to rules that already exist. In practice, most of a detection engineer's time goes to tuning.
Example
A rule for "LSASS memory access" produces dozens of alerts a week. Replaying it over 60 days of EDR data shows almost all matches come from the endpoint backup agent and a vulnerability scanner. The engineer excludes those two signed binaries by full path and signer rather than by name, reruns the rule, and sees matches drop to three, all from a red team exercise. A simulation of credential dumping with a different tool then confirms the rule still fires.
FourCore HUNT supports this kind of tuning by testing detection changes against past telemetry in the team's own SIEM and EDR before they go live.
Frequently Asked Questions
What is detection tuning?
It is the process of adjusting existing detection rules to reduce false positives and close gaps, then confirming the changes against past data and simulated attacks. The goal is rules that fire on attacks and stay quiet otherwise.
How often should detections be tuned?
Noisy rules should be tuned as soon as the pattern is clear. Beyond that, review each rule's volume and outcomes on a regular schedule and after major changes such as new software or agent upgrades.
What is the risk of over-tuning a detection?
Exclusions that are too broad, such as a whole folder or host, can hide real attacks and give attackers a place to work unseen. Keep exclusions specific and confirm the rule still catches the technique with a simulation.