Why this matters beyond the homelab: Alert fatigue is the most common way a SIEM fails in production. Not by missing an event, but by burying it in fourteen thousand irrelevant ones nobody reads. Tuning noise out is not weakening detection, it is the work that makes detection usable, and it requires understanding what the noise actually is before you silence it.
The Number
Fifteen agents. Twenty-four hours. 16,090 alerts.
That is roughly eleven alerts a minute, continuously, in a homelab where nothing was wrong. Nobody reads eleven alerts a minute. I certainly was not, which means the SIEM had already stopped functioning as a detection system and become a log firehose with a nice UI.
The instinct here is to start raising severity thresholds until the noise stops. That is the wrong first move, because it silences things without understanding them and quietly discards real detections along with the junk.
The right first move is to look at the distribution.
Finding Where It Comes From
Alert volume is almost never evenly distributed. It concentrates, usually hard, and finding the concentration takes one query.
Grouping the 24-hour sample by agent and rule ID:
alliance-dc01 ..................... 13,947 (86.7%)
everything else (14 agents) ........ 2,143 (13.3%)
One host. Then within that host, by rule:
60106 Windows Logon Success ....... ~7,900
60137 Windows User Logoff ......... ~5,800
everything else on dc01 .............. 247
Two rules. Both level 3, meaning informational. Both firing correctly.
That is the whole picture in two queries. 89% of total alert volume traced to one host and two rules, and neither rule was malfunctioning. A domain controller logging successful logons and logoffs is a domain controller doing its job.
What the Noise Actually Was
This is the step worth being disciplined about. Before suppressing anything, identify what is generating it, because “high volume authentication events on a domain controller” is also an accurate description of a credential attack.
Two sources accounted for nearly all of it.
The Entra Connect sync account. The hybrid sync service account authenticates on a delta sync cycle every thirty minutes, every cycle producing logon and logoff events. I verified the cycle timing was consistent and matched the configured sync interval, which confirmed it was the sync service behaving normally rather than something impersonating it. Regular, predictable, healthy.
The domain controller’s own machine account. ALLIANCE-DC01$ authenticating to itself, constantly, as machine accounts do.
Both are unremarkable. Both are also exactly the kind of thing you should confirm rather than assume. An anomalous authentication pattern hiding inside expected authentication noise is a real technique, and the only reason I can say these were benign is that I checked the cadence and the source rather than pattern-matching on the account name.
A third contributor showed up across all agents: security configuration assessment results, rules 19008 and 19009, reporting checks that passed or were not applicable. Every agent, every scan, logging every non-finding. Useful data for a compliance report, meaningless as an alert.
Suppression as Detection Engineering
The fix went into local_rules.xml as a dedicated block of suppression rules, in the 100900-100924 range so they are visually separate from detection rules and obvious in a diff.
The approach, for each:
Suppress narrowly. Not “silence rule 60106,” which would blind me to all successful logons everywhere. Instead: silence 60106 for this specific service account on this specific host. The rule still fires for every other principal.
Match on the specific principal. For the sync account, on the account name. For machine accounts, on the trailing $ that all machine accounts carry. That second one is where I hit the type="pcre2" silent failure documented in a separate post, which cost more time than the rule itself.
Suppress the non-finding, keep the finding. For the configuration assessment noise, drop passed and not-applicable results, keep failures. The failures are the entire reason the scan exists.
Leave a comment on every suppression saying what it hides and why. A suppression rule with no explanation is indistinguishable from a blind spot six months later. This is the part that makes it engineering rather than muting.
Result: dc01 dropped from dominating the alert stream to being roughly comparable to everything else, and the remaining volume is readable by a human.
The Thing Worth Being Honest About
Every suppression rule is a deliberate blind spot. That is not a reason to avoid them, but it is a reason to be precise about them.
If someone compromises the Entra Connect sync account specifically, my suppression rule helps them hide. I accepted that trade knowingly, and it changes what other detection needs to exist: the sync account should be monitored for behavioral anomalies, meaning authentication outside its expected thirty-minute cadence, from an unexpected source, or performing operations outside its normal scope, rather than for the fact of authenticating at all.
That is the general form. Suppressing an expected pattern obligates you to detect deviation from that pattern. Volume-based alerting on a predictable service account is worthless. Cadence-based alerting on the same account is valuable. Silencing the first without building the second is where suppression turns into a real gap.
Takeaways
Look at the distribution before touching thresholds. Noise concentrates. Two queries usually find it.
Raising the global severity floor is the lazy fix. It discards real detections along with the noise and does not teach you anything about your environment.
Identify the source before suppressing it. “Authentication noise” and “credential attack” look identical in aggregate. Verify cadence and principal.
Suppress the principal, not the rule. Narrow scope keeps the detection alive everywhere else.
Comment every suppression. Undocumented silence becomes an unknown blind spot.
Every suppression creates an obligation. If you silence an expected pattern, build detection for deviation from it.
Related: Rules That Match Nothing | SIEM Automation Pipeline | Deploying Fleet-Wide SIEM Across a Proxmox Cluster