Correlation Rules and Risk-Based Alerting (RBA) Guide

Single-event detection rules force a bad choice: make them sensitive and the SOC drowns, make them specific and quiet attackers walk past them. Correlation rules and risk-based alerting (RBA) remove that choice by treating most detections as observations about an entity and alerting only when the observations add up. This guide goes beyond the overview in the Alert Fatigue Reduction Guide and covers the design work: the correlation types Sigma standardises, how to build a scoring scheme, how to stop noisy rules from stacking scores, entity resolution, deduplication, how the main SIEM platforms implement the idea and how to migrate a rule set without losing coverage. It is written for detection engineers and SOC leads who own a SIEM rule set.

Key takeaways

Correlation and RBA solve different problems. A correlation rule encodes a known sequence or threshold; RBA accumulates many unrelated weak signals on an entity until the total justifies a human.
Risk rules are observations, not alerts. They should be narrow, ATT&CK-tagged and allowed to be noisy, because their output lands in a risk index rather than the analyst queue.
Scoring needs guard rails. Cap how much one rule can contribute, discount common threat objects and weight by asset and identity criticality, or one chatty rule will dominate every alert.
Entity resolution decides whether it works. If "jsmith", "JSMITH@corp" and "CORP\jsmith" are three risk objects, risk never accumulates.
Keep a short list of direct alerts. Tampering with security tools, log clearing and creation of new global administrators should never wait for a score.

Correlation rules versus risk-based alerting

Approach	How it fires	Strengths	Weaknesses
Threshold correlation	Count of events or distinct values per entity within a window	Simple, explainable, cheap to run	Fixed thresholds are easy to stay under (slow password spraying)
Sequence correlation	Rule A then rule B for the same entity within a window	High fidelity for known patterns, such as failed logons followed by success	Each pattern must be written and maintained; misses variations
Risk-based alerting	Sum of scored observations per entity crosses a threshold, or observations span several tactics or data sources	Catches slow, varied activity; analysts see the whole story at once	Needs entity resolution, score tuning and analyst training; harder to explain to auditors
Machine learning correlation	Model links anomalies and alerts into multistage incidents	Finds combinations nobody wrote a rule for	Opaque; limited tuning; tied to one vendor's engine

Most mature SOCs use all four: correlation for well-understood attack sequences, RBA for the long tail, platform machine learning where available, and a small set of direct alerts.

Correlation rule types: the Sigma model

The Sigma Correlation Rules Specification (version 2.1.0, released 2 August 2025) gives a vendor-neutral vocabulary for correlation. A correlation rule refers to one or more ordinary Sigma rules and adds group-by (the entity fields), timespan (for example 1h or 90m) and a condition.

Type	Fires when	Typical use
`event_count`	The number of matching events per group meets the condition	100 or more failed logons to one host in an hour
`value_count`	The number of distinct values of a field per group meets the condition	Failed logons against 100 or more different accounts from one source in a day (password spraying, T1110.003)
`temporal`	All referenced rules match for the same group within the timespan, in any order	Three reconnaissance commands by the same user on one system within five minutes
`temporal_ordered`	As temporal, but in the listed order	Many failed logons followed by a successful logon for the same account within one hour
`value_sum`	The sum of a numeric field per group meets the condition	Bytes sent to one website by one user above a limit in an hour
`value_avg`, `value_percentile`	Average or percentile of a numeric field meets the condition	Unusual transfer sizes or session lengths

Aliases: let one correlation group across differently named fields in different log sources, for example a user field in a VPN log and an account field in Windows logs.
Severity escalation: the specification lets single-event matches stay low or informational while the correlation raises the level, which is RBA thinking expressed in a correlation rule.
Generate: controls whether the referenced base rules are also emitted as stand-alone rules; by default only the correlation query is generated.
Window caveat: the specification warns that some backends only recognise static time boundaries, so a one-hour window may miss events that straddle the hour. Test how your SIEM implements windows before trusting a threshold.

See the Sigma Rules Guide for the base rule format.

How risk-based alerting works

Splunk's RBA community describes the method as aggregating low-fidelity security events as interesting observations tagged with security metadata, to create high-fidelity, low-volume alerts. The pattern is now common across SIEMs, though the names differ.

Risk rules run against raw events. Instead of raising an alert, each match writes a risk event containing the risk object (the user, host or service it is about), a risk score, a risk message, ATT&CK tactic and technique annotations, and one or more threat objects (the artefact involved, such as a process command line, file hash, domain or IP address).
The risk index stores these observations. They are searchable by analysts even when they never trigger an alert, which makes them valuable for hunting and investigation.
Risk modifiers adjust scores by context, typically raising them for privileged users, crown-jewel systems or watchlisted entities.
Risk incident rules watch the risk index and raise one alert per entity when the accumulated picture crosses a threshold: total score in a window, number of distinct ATT&CK tactics, number of distinct data sources, or a combination.
The analyst receives one alert with every contributing observation on a timeline, rather than ten separate tickets.

Designing the scoring scheme

Scores are a design artefact. Write the scheme down, version it with the rules and review it quarterly. A simple matrix based on confidence and impact keeps it consistent:

Observation confidence	Standard entity	Privileged user or critical asset	Example
Weak (common in normal use)	10	15	Encoded PowerShell command line (T1059.001) on a developer workstation
Moderate (unusual, sometimes benign)	25	40	New inbox rule forwarding externally; RDP to a server not seen before (T1021.001)
Strong (rarely benign)	50	75	Access to LSASS memory by an unsigned process (T1003.001)
Direct alert (never benign)	Bypass RBA: alert immediately		Security tool disabled (T1685 Disable or Modify Tools); new global administrator

The values are illustrative; what matters is that a threshold of, say, 100 in 24 hours (the threshold used in several of the Splunk RBA community's example searches) means "roughly two strong or four moderate observations", and that the team agrees with that meaning.

Guard rails against score inflation

Cap per-rule contribution: the RBA community's "limit score stacking" searches cap what one source rule can add, for example to two or three times its highest single score, so a rule firing 200 times on a build server does not cross the threshold alone.
Discount common threat objects: the community's threat object prevalence approach classifies each threat object by how many users and hosts it appears on, then applies a multiplier (in their example 1 for rare, 0.5 for regular, 0.25 for multiple entities and 0 for many). Rare artefacts keep their score; ubiquitous ones fade.
Require diversity: alert on observations from several distinct rules, data sources or ATT&CK tactics rather than score alone. Three tactics on one host over seven days is a stronger signal than one tactic seen many times.
Dynamic scoring: scores can depend on prior behaviour. The community gives an example where a rule scores 50 the first time and only 5 for each additional user seen on the same machine.

Entity resolution, deduplication and chaining

Normalise the risk object: Splunk Enterprise Security added a normalized_risk_object field in version 7.1 that uses asset and identity data so that different spellings of a user or host resolve to one entity, and default risk incident rules throttle on it. Whatever platform you use, feed it a maintained identity and asset inventory, including service accounts and workload identities.
Deduplicate risk alerts: because risk incident rules look back over a rolling window, the same entity can keep re-alerting as events arrive and age out. The community pattern is a saved search every 5 to 30 minutes over about 30 days that compares each new alert with earlier ones for the entity and suppresses it unless something material has changed (a new source, tactic or threat object), recording an alert_reason.
Chain rules without losing observations: rather than one complex rule for "A then B", let A and B write risk independently and add a small extra risk when both occur for the same user within, for example, ten minutes. The individual observations stay available, and either can be tuned down without allowlisting.
Retain closed dispositions: feed analyst verdicts back so that an entity cleared yesterday does not re-alert on the same evidence today.

How the main platforms implement it

Platform	Mechanism	Notable details from vendor documentation
Splunk Enterprise Security	Risk rules, risk index and risk incident rules	Detections write risk events with risk and threat objects and ATT&CK annotations; the Splunk Threat Research Team's content library holds over 1,000 detections that can be used as risk rules
Elastic Security	Entity risk scoring	Scores hosts, users and services in the entity store from open or acknowledged alerts in the last 30 days (including building block alerts), up to 10,000 alerts per entity, on a 0 to 100 scale (Low from 20, Moderate from 40, High from 70, Critical above 90); asset criticality and privileged user status add weight; recalculated hourly
Microsoft Sentinel and Defender XDR	Fusion machine learning correlation, now the Defender XDR correlation engine	Fusion ("Advanced multistage attack detection") is disabled for workspaces onboarded to the Defender portal, where the Defender XDR correlation engine replaces it; Sentinel in the Azure portal is supported until 31 March 2027
Any SIEM via Sigma	Correlation rules	Sigma correlation types convert to backend queries where the backend supports them; check conversion output and window behaviour

Elastic's building block alerts are worth noting: they are alerts that feed scoring and correlation without appearing in the main alert queue, which is the same idea as a risk rule. For platform selection, see the SIEM Guide.

Migrating a rule set to RBA

Inventory and classify rules: sort every existing detection into direct alert, risk rule or retire, using its false positive rate and how often analysts close it as benign. See the Detection Engineering Guide.
Build entity resolution first: load asset and identity inventories, including non-human identities, and check that the top 100 risk objects resolve correctly.
Convert a pilot set: take 20 to 40 noisy but useful rules covering several ATT&CK tactics, convert them to risk rules with scores from the matrix and tactic annotations.
Run in parallel: keep the original alerts live while risk incident rules run in a non-alerting mode for two to four weeks. Compare: did RBA surface every true positive the old rules caught, and what else did it surface?
Tune thresholds and caps: adjust from evidence, not intuition. Review the entities that came closest to the threshold without crossing it.
Cut over by tactic: disable the old alerts one tactic group at a time once parallel results match.
Roll back cleanly: keep the old rules disabled rather than deleted for at least a quarter, so they can be re-enabled if coverage drops.
Purple team it: replay a known chain (for example spray, successful sign-in, mailbox rule, data access) and confirm a single risk alert fires. See the Purple Teaming Guide.

Small versus large SOCs

Small team: start with a handful of Sigma correlations for the highest-value sequences and the platform's built-in entity scoring. A full custom RBA scheme needs ongoing tuning time a two-person team rarely has.
Large or multi-tenant SOC: RBA pays off most, because volume is the main problem and there are enough analysts to own scoring, entity data and deduplication as a discipline.

Where identity fits

Identity is the natural risk object. Most attack chains that RBA catches are a user or service account doing several slightly odd things, and most RBA failures are identity resolution failures. Treat service principals, API keys and workload identities as risk objects in their own right, with higher weights when they hold privileged roles, since a compromised integration can do in one call what a user does in ten. Token-based activity (T1550.001 Application Access Token) and account manipulation (T1098) are good risk rule candidates because individually they are often legitimate. See the Detection Engineering for Non-Human Identities Guide and the UEBA Guide.

Detection and measurement

Alert reduction ratio: risk events written per risk alert raised; track it alongside true positive rate so reduction is not bought with misses.
True positive rate of risk alerts compared with the direct alerts they replaced.
Coverage retained: share of purple team or emulation scenarios that produced a risk alert after cut-over.
Entity resolution rate: percentage of risk events whose risk object matched an inventory record.
Top contributors: the five rules contributing most score each month; a single rule dominating is a tuning signal.
Time to triage per risk alert, which should fall as analysts see the full timeline at once.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev. 5	SI-4(16) Correlate Monitoring Information; SI-4(13) Analyze Traffic and Event Patterns	Correlation across monitoring tools and baselining event patterns
NIST SP 800-53 Rev. 5	AU-6(3) Correlate Audit Record Repositories; AU-6(5) Integrated Analysis of Audit Records	Joining logs across sources for analysis
NIST CSF 2.0	DE.AE-03, DE.AE-04, DE.AE-06, DE.AE-08, RS.MA-02	Correlating information, understanding impact, informing staff, declaring incidents, triage
ISO/IEC 27001:2022 Annex A	A.8.16 Monitoring activities	Monitoring for anomalous behaviour and evaluating events
CIS Controls v8.1	Control 8 Audit Log Management	Centralised, analysed logs
MITRE ATT&CK v20	Tactic annotations such as TA0006 Credential Access and TA0008 Lateral Movement	Tactic counts as risk incident rule criteria

Common failure patterns

Converting everything: moving high-fidelity detections into RBA delays response for no benefit. Keep tool tampering and log clearing as direct alerts.
Unresolved entities: risk scattered across spellings of the same account never accumulates, and the SOC concludes RBA "does not find anything".
No caps: one misbehaving scanner or build agent crosses the threshold daily, and analysts learn to ignore risk alerts too.
Thresholds attackers can stay under: a single count threshold invites low-and-slow activity. The Microsoft Midnight Blizzard breach began with a deliberately low-volume password spray against a test tenant account without MFA, then moved through OAuth applications to mailbox access: each step on its own looked minor, which is exactly the chain an entity-centred, multi-tactic risk rule is designed to join up.
Ignoring the risk index: observations that never alert are still evidence. Teams that never search the risk index lose half the value.
Silent retirement of rules: deleting old alerts before parallel running proves coverage leaves gaps nobody notices until an incident.

Practitioner checklist

Classify every detection as direct alert, risk rule or retire.
Publish a written scoring matrix and review it quarterly.
Load asset and identity inventories, including non-human identities, and measure resolution rate.
Cap per-rule score contribution and discount common threat objects.
Use tactic and data source diversity, not score alone, in risk incident rules.
Deduplicate risk alerts per entity and feed analyst dispositions back.
Express known sequences as Sigma correlation rules and test window behaviour on your backend.
Run RBA in parallel for two to four weeks before disabling old alerts.
Validate with emulated attack chains after every major tuning change.

Standards and references

Related NHI Mgmt Group resources: Alert Fatigue Reduction Guide · SIEM Guide · Detection Engineering Maturity Model · Threat Hunting Frameworks Guide

Correlation Rules and Risk Based Alerting Guide: Turning Weak Signals into Entity Risk Alerts