Cutting SIEM alert noise

An analyst who has learned to close a particular alert without reading it has effectively deleted that detection. The rule still runs, still fires, still appears in the coverage report, and no longer detects anything. This is the real cost of alert noise, and it is worse than having no rule at all, because the coverage report says you are protected.

Tuning is the work of getting the alert volume down to what can genuinely be investigated. It is unglamorous, continuous, and it is the difference between a SIEM that works and one that is expensive furniture.

Start by measuring, not tuning

Before changing anything, get three numbers for the last month:

• Alerts by rule. Almost always a short head and a long tail. A handful of rules produce most of the volume.
• Outcome by rule. How many of each rule's alerts led to any action at all.
• Time spent by rule, even estimated.

The rules that produce high volume and no action are where the work is. Usually five to ten rules account for the majority of wasted effort, and fixing those changes the day-to-day experience more than any other intervention.

The four causes, and what each needs

Cause one: the rule describes normal behaviour

The most common. A rule fires on something that is genuinely suspicious in the abstract and completely routine in your environment. A service account authenticating from an unusual location because that is where your backup infrastructure runs. Administrative tooling that looks like the techniques it was built to imitate.

The fix is an exclusion, written precisely. Not "ignore this account" but "ignore this account performing this action from this source". A broad exclusion is how a rule quietly stops covering the thing it was for.

Every exclusion needs a comment saying why it exists and who approved it. Undocumented exclusions accumulate until nobody dares remove any of them.

Cause two: the threshold is wrong

Rules with a count-based trigger (failed logins, connection attempts, data volume) are often set to vendor defaults chosen for a hypothetical environment.

The fix is to look at your actual distribution and set the threshold above normal rather than at a round number. If your normal peak is forty and the threshold is ten, the rule fires constantly. If normal peak is four, a threshold of ten is reasonable.

Revisit these after any significant change to the estate, because normal moves.

Cause three: the same event arrives several times

One event generating alerts from the endpoint tool, the network sensor and the SIEM correlation rule is three tickets for one thing.

The fix is correlation and deduplication: grouping by entity and time window so that related signals become one case with several pieces of evidence. This is usually a configuration problem rather than a rule problem, and it produces a large reduction quickly.

Cause four: the rule should never have been enabled

Every SIEM ships with a large default rule set. Some of it covers technology you do not run. Some encodes assumptions about your architecture that are wrong.

The fix is to disable it. There is a reluctance here: disabling a security control feels like a step backwards. It is not. A rule that fires daily and is closed unread is already disabled; you are just paying for it and pretending otherwise.

A working method

Rather than a tuning project, run a weekly cycle.

1. Pick the top three noisy rules by volume with no resulting action.
2. For each, decide which of the four causes applies. This usually takes minutes once you look at a sample of the alerts.
3. Make the change, with a written reason.
4. Watch for a week. Confirm the volume dropped and that nothing that should have fired stopped firing.
5. Repeat.

Three rules a week is roughly 150 a year, which is more than most environments have. The cycle matters more than the pace.

Guarding against over-tuning

The obvious risk is tuning until nothing fires. A few habits prevent it.

Suppress rather than delete, where you can. A suppressed alert that is still recorded can be reviewed later. A deleted one leaves no trace that a decision was made.

Give exclusions an expiry. Exclusions added during an incident, or for a temporary system, should have a review date. Otherwise they outlive their reason by years.

Test the rules you care about. For the detections that matter most, generate the behaviour deliberately in a controlled way and confirm the alert still arrives. This is the only way to know whether tuning has gone too far, and it is worth doing quarterly for a small set of critical detections.

Track what you missed. Anything discovered by a user, a customer, or a third party rather than by your own detection is a coverage gap. Review each one and ask whether a rule existed, whether it fired, and whether it was closed without being read.

What good looks like

There is no correct alert volume, but there are signs of a healthy state:

• Every alert that reaches an analyst gets genuinely read.
• The false positive rate is falling over time rather than flat.
• Exclusions are documented, dated and reviewed.
• The team can name what they are not covering, which means the gaps are known rather than assumed away.

The last one is the most useful test. A team that cannot say what it does not detect has usually confused the volume of alerts with the quality of coverage.