Traditional SIEMs fire one alert per rule match, which buries analysts in thousands of low-fidelity alerts. Risk-based alerting (RBA) flips the model: instead of alerting on every match, it accumulates risk against the entity involved and only raises a case when that risk crosses a threshold. The result is far fewer, far higher-confidence alerts. This guide explains how RBA works and what separates a good implementation from a noisy one.
The problem RBA solves: alert fatigue
A rule-per-alert SIEM treats every detection as independently alert-worthy. A single user doing something mildly unusual can trip a dozen rules, each firing its own alert — while a real, multi-stage intrusion looks the same size as the noise. Analysts drown, tune rules down to survive, and miss the signal that mattered. RBA exists to break that volume-equals-importance trap.
What is risk-based alerting?
Risk-based alerting is an approach where detections do not alert directly. Instead, each detection emits a risk event attributed to a risk object — an entity such as a user, host, or IP — and assigns it a risk contribution. Risk events accumulate on the entity over time. Only when an entity's total risk crosses a defined threshold is a single notable (an investigatable case) raised, carrying all the contributing context with it.
Each risk event is typically enriched — annotated against a MITRE ATT&CK technique, weighted by detection fidelity, and adjusted for how critical the asset or identity is. The unit of attention shifts from "which rule fired?" to "which entity is behaving like a threat?"
How risk-based alerting works
- Detections emit risk, not alerts. A rule match produces a risk event attributed to an entity, with a score and MITRE context.
- Risk accumulates on the entity. Multiple signals across time and data sources add up against the same user, host, or IP.
- Context is layered in. Threat-intel hits, behavioral anomalies (UEBA), and asset criticality adjust the contribution.
- A threshold promotes to a notable. When the entity's risk crosses the line, one case is raised — with the full trail of contributing events.
- Risk decays. As time passes without new activity, risk falls again, so old noise does not keep an entity permanently hot.
Why RBA reduces alert fatigue
Because alerts are raised per entity at a threshold rather than per rule match, RBA collapses a flood of low-fidelity alerts into a curated set of high-impact cases. Industry implementations report cutting low-fidelity alert volume by roughly 50–90%. Just as important, RBA surfaces the breadth of an attack: an entity that trips many weak signals across multiple attack stages rises above one that trips the same rule a thousand times.
The design detail that matters
A naive risk score that simply adds up every event lets sheer volume outrank a real intrusion. A good score applies diminishing returns so repeats of the same signal saturate, and an attack-breadth boost so activity spanning more MITRE tactics and techniques is weighted higher. Volume should never beat breadth.
RBA vs. traditional alerting
| Traditional alerting | Risk-based alerting | |
|---|---|---|
| Unit of alerting | One alert per rule match | Risk attributed to an entity |
| Typical volume | Thousands of alerts | A handful of high-confidence notables |
| Context | Each alert is isolated | Signals accumulate with MITRE + threat-intel context |
| Promotion | Every match fires | One threshold on one score |
| Noise handling | Repeats flood the queue | Repeats saturate; breadth is rewarded |
How LogPulse does risk-based alerting
In LogPulse, every signal — detections, behavioral analytics (UEBA), and threat intelligence — emits a risk event attributed to an entity. Every entity carries one bounded 0–100 effective risk score: the same number on the leaderboard, on the notable, and in the promotion decision. The score uses diminishing returns so repetitive noise saturates, an attack-breadth boost so activity across more MITRE stages weighs more, time decay, and an entity-criticality multiplier.
Promotion is one threshold on one score; there is one open notable per entity; and a raised notable auto-resolves once risk decays below a clear threshold. Scores map to five bands (Info, Low, Moderate, High, Critical), and the scoring is tunable per organisation. See Security Monitoring (SIEM) for the full picture, and what is an agentic SOC for how AI then triages those notables with a human in the loop.