It's two in the morning and the SIEM queue has thrown four hundred alerts since your shift started. Three hundred and eighty of them are the same rule: scheduled task created. It fires every night at midnight because the backup agent on every server creates a task to kick off its job, and every night the SOC dismisses the same three hundred and eighty near-identical lines to get to the alerts that might actually be something.
You've felt this if you've ever worked a SOC shift. The rule that catches a real attacker persisting through schtasks is the exact same rule that fires on legitimate backup software, legitimate patch management, legitimate everything. So the team does the only thing that feels survivable: they stop reading that rule closely. It becomes background noise. And a scheduled task created for actual persistence looks, on the surface, exactly like the four hundred noise events before it. It sits in the queue until someone with fresh eyes reopens the ticket days later, if anyone does.
That is alert fatigue, and the fix everyone reaches for first is the wrong one: mute the rule, or push its severity down so it stops paging anyone. Both make the noise stop. Both also make the real event invisible, because you didn't remove the false positives, you removed the detection.
Tuning is not the same as muting
The difference between the two is whether you're narrowing the rule to the specific conditions that make an alert benign, or just turning the volume down on the whole thing.
A muted rule says "scheduled task creation isn't worth alerting on anymore." A tuned rule says "scheduled task creation from this specific parent process, running as this specific service account, creating a task with this specific naming pattern, matching what the backup agent does every night at this specific time window, is benign — everything else about scheduled task creation still pages someone."
The second version is more work to build. It's also the only version that keeps catching the thing the rule was written for in the first place.
A tuning pass that actually holds up
Pull the false positive population, not just the count. Before you touch the rule, pull every alert it fired in the last two to four weeks and actually read the field values: parent process, command line, user context, time of day, host role. You're looking for what the false positives have in common that a real attacker wouldn't reliably replicate.
Write the exclusion as narrowly as the evidence supports. If backup agents on this fleet always run as
svc-backupand always spawn from the same signed binary path, exclude on that combination, not on "any scheduled task creation from a service account." The narrower the exclusion, the smaller the blind spot you're opening.Time-box it and put it on a review date. An exclusion written today against this month's backup software version is not guaranteed to still be correct in six months when someone changes the deployment. Every tuning rule should carry an owner and a re-review date, or it quietly rots into a permanent blind spot nobody remembers approving.
Document the why, not just the what. "Excluded scheduled task creation matching svc-backup + signed binary path X, reviewed 2026-08-30, re-review by 2027-02-28, evidence: 380 alerts over 21 days, 100% matched this pattern, zero matched any known attacker TTP for T1053." That sentence is what lets the next analyst trust the exclusion instead of re-litigating it during an incident.
Measure the rule's false-positive rate over time, not just once. A rule that was 95% noise in January and is 95% noise again in June is a candidate for a real fix upstream (asking IT to change the backup deployment so it doesn't trip the same telemetry), not another round of tuning.
None of this is exotic. It's the unglamorous, iterative discipline that separates a SIEM that pages people for things that matter from one that everyone has quietly learned to ignore. The skill isn't writing detection rules once. It's tuning the ones you already have so the signal doesn't drown in the noise you created trying to be thorough.
That triage-to-tuning arc, reading what a rule is actually catching, deciding what genuinely belongs in an exclusion versus what belongs in a fix elsewhere, and writing the rule change so the next analyst can trust it, is the specific gap between knowing SIEM syntax and running a SOC that catches things. It's exactly what the SOC Analyst Book Bundle walks through across its L1 through L3 arc, from the first alert triage decision through the detection engineering that decides what should have paged someone in the first place.
