TTechclick ⚡ XP 0% All lessons
Splunk · SIEM · Correlation Searches & RBAInteractive · L1 / L2 / L3

Splunk ES Correlation Searches & Risk-Based Alerting — Detection Mastery

Most SIEM deployments drown analysts in per-rule alerts. Splunk Enterprise Security's Risk-Based Alerting (RBA) rewires the loop: correlation searches score entities instead of shouting, the risk index accumulates evidence, and a risk-incident rule fires one high-confidence notable only when combined risk crosses a threshold. This lesson maps every piece — search logic, risk annotations, the risk index, notable events, MITRE ATT&CK mapping, and adaptive response.

📅 2026-06-20 · ⏱ 17 min · 4 infographics · live detection demo · 🏷 10-Q assessment + AI Tutor inline

⚡ Quick Answer

Master Splunk Enterprise Security correlation searches and Risk-Based Alerting (RBA) in 2026: how risk rules score entities over time, the risk index, risk-incident rules, notable events, MITRE ATT&CK mapping, and adaptive response actions.

🎯 By the end you will be able to

Read as:

Pick where you want to start

1

Correlation searches

SPL, schedule, thresholds, notable vs risk.

 2

Risk index & RBA

Risk rules, entity scoring, risk-incident rules.

 3

MITRE ATT&CK in ES

Annotations, technique IDs, coverage maps.

 4

Adaptive response & tuning

Actions, containment, reducing alert noise.

🧠 Warm-up — 3 questions, no score

Just notice which ones make you pause. We answer all three inside the lesson.

1. What does a Splunk ES correlation search produce when it fires?

Answered in Correlation searches.

2. Where do risk events from RBA risk rules get stored?

Answered in Risk index & RBA.

3. What triggers a risk-incident rule to fire a notable?

Answered in Risk index & RBA.

Most engineers think…

Most people picture a SIEM as 'a rule fires, an alert appears'. That's the old model — and the reason SOC analysts spend half their shift closing false positives.

Splunk Enterprise Security's Risk-Based Alerting (RBA) inverts this. Correlation searches become risk rules that silently score users, hosts and IPs in a risk index rather than shouting immediately. Only when an entity's accumulated risk crosses a threshold does a risk-incident rule fire one high-confidence notable — and it arrives labelled with every MITRE ATT&CK technique that contributed. That context-rich, low-volume notable is what lets an analyst work quickly instead of playing alert whack-a-mole.

① Correlation searches — the detection engine of Splunk ES

A correlation search is the core detection primitive in Splunk Enterprise Security. It is an SPL query that runs on a schedule (commonly every five minutes), checks whether the result count meets a threshold, and fires one of two adaptive response actions: create a notable event (the traditional alert) or create a risk event (the RBA path).

The search logic itself is standard SPL — index=* sourcetype=... with stats, eval, where, and threshold clauses. What makes ES correlation searches special is the Content Management UI that wraps them: each search carries a title, description, severity, annotations (MITRE ATT&CK technique IDs, kill-chain phase, security domain), and one or more adaptive response actions.

In classic mode every match creates a notable in the Incident Review queue. In RBA mode the same search writes a risk event to the risk index instead — or in addition. The distinction matters: one fires per event, the other accumulates silently until the entity is truly suspicious.

Figure 1 — Correlation search to notable — the classic path
In classic ES mode a correlation search runs on schedule, checks the threshold, and creates a notable in Incident Review.Correlation search to notable — the classic pathSPL Searchscheduled query runsThresholdresult count checkedAction firesnotable or risk eventIncident Reviewanalyst triages alert
In classic ES mode a correlation search runs on schedule, checks the threshold, and creates a notable in Incident Review.
Threshold = result count, not event count

A correlation search fires when the SPL result set meets the threshold — for example 'results > 0' or 'count > 5'. The threshold is on the stats output, not on how many raw events were searched. Keep that distinction clear when explaining searches to an interviewer.

Quick check · Q1 of 10 · Remember

What are the two built-in adaptive response action types a correlation search can trigger?

Correct: b. A Splunk ES correlation search fires either a Notable Event (creates an alert in Incident Review immediately) or a Risk Event (writes a scored event to the risk index for RBA). Both are built-in adaptive response actions.
👉 So far: Correlation searches are scheduled SPL queries that fire either a Notable Event (immediate alert) or a Risk Event (silent score) via adaptive response actions. Annotations carry MITRE ATT&CK technique IDs.

② The risk index & Risk-Based Alerting — from scoring to the single notable

The risk index (index=risk) is where RBA lives. Every time a risk rule fires, it writes a risk event that includes the risk score, the risk object (a user, host or IP), the source search name, and the MITRE ATT&CK annotations. Nothing goes to Incident Review yet.

Risk-incident rules aggregate the evidence

A risk-incident rule is a special correlation search that runs against the risk index. It groups risk events by risk object over a lookback window, sums the scores, and creates a risk notable only when the combined score exceeds a threshold. The result: one alert that references every detection that contributed — an insider-threat story built from ten small signals rather than ten separate alerts.

The key objects are the risk object (who or what is being scored), the risk score (a numeric weight per risk rule), and the threat object (the external indicator, e.g. malicious IP, that the risk event also captures). Understanding these three is the interview answer that separates people who have configured RBA from people who have only heard the acronym.

Figure 2 — RBA loop — risk rules to one high-confidence notable
RBA rewires the loop: risk rules score entities silently; a risk-incident rule fires one notable only when combined score crosses threshold.RBA loop — risk rules to one high-confidence notableRisk Rule fireswrites to risk indexRisk Indexscores accumulateIncident Rulethreshold checkRisk Notableone alert, full ATT&CK
RBA rewires the loop: risk rules score entities silently; a risk-incident rule fires one notable only when combined score crosses threshold.
🔍
Correlation Search
tap to flip

An SPL query that runs on a schedule in Splunk ES, checks a threshold, and fires an adaptive response action — either a notable event or a risk event.

📊
Risk Index
tap to flip

The special Splunk index (index=risk) where risk rules write scored events. Risk-incident rules aggregate these by entity to decide when to fire a single high-confidence notable.

🎯
Risk-Incident Rule
tap to flip

A correlation search that runs against the risk index, groups events by risk object, sums scores over a time window, and creates a risk notable when the total crosses the configured threshold.

⚡
Adaptive Response Action
tap to flip

The action a correlation search triggers on a match — Risk Analysis (score the entity), Notable Event (alert now), or an integration action such as block IP or disable account.

Quick check · Q2 of 10 · Understand

What does a risk-incident rule actually search against?

Correct: c. A risk-incident rule runs against index=risk, groups accumulated risk events by risk object (user, host, IP), sums their scores over a lookback window, and fires a risk notable when the total crosses the threshold — not against raw log indexes.
👉 So far: Risk rules write scored events to index=risk by entity (user/host/IP). Risk-incident rules aggregate those scores and fire one high-confidence risk notable only when the threshold is crossed — RBA's core promise.

③ MITRE ATT&CK in Splunk ES — annotations, coverage maps & technique IDs

Every correlation search (and every risk rule) in Splunk ES can carry MITRE ATT&CK annotations: a technique ID (e.g. T1078 Valid Accounts), a sub-technique, and a tactic. These are stored as metadata on the search in Content Management. When a risk event is written to the risk index it inherits those annotations, so the resulting risk notable knows which ATT&CK techniques were observed across all contributing detections.

The MITRE ATT&CK Content Pack and the ES Use Case Library surface these as a coverage heatmap: which techniques have at least one detection, which are producing alerts, and which have no coverage. This is the artefact an architect shows a CISO to prove detection breadth.

In an interview, three MITRE-in-ES facts stand out: annotations live on the search (not the index), the risk index preserves them per event, and the Incident Review notable aggregates all technique IDs — so a SOC analyst sees the full ATT&CK story in one view rather than hunting across ten separate alerts.

Figure 3 — MITRE ATT&CK in ES — annotations power every view
ATT&CK technique IDs set on each correlation search flow through the risk index into every analyst-facing ES view.MITRE ATT&CK in ES — annotations power every viewCorrelation SearchATT&CK annotationsRisk Index eventsRisk NotableIncident ReviewCoverage HeatmapThreat Intel lookup
ATT&CK technique IDs set on each correlation search flow through the risk index into every analyst-facing ES view.
'MITRE ATT&CK mapping is automatic' — it is not

Splunk ES does not auto-tag your detections with MITRE technique IDs. You must set annotations manually on each correlation search in Content Management, or use Analytic Stories from the Splunk Security Content library which come pre-annotated. An unmapped search produces notables with no ATT&CK context.

▶ Watch a credential-theft RBA story unfold

One entity accumulates risk from four detections before a single notable fires. Press Play for the healthy detection path, then Break it to see the classic misconfiguration.

① Risk Rules fireThree correlation searches (new country login, off-hours access, password spray) each write a risk event for user 'rdevika' to index=risk — no notable yet.
▼
② Risk Indexindex=risk now holds three events for rdevika. Scores: 20 + 30 + 40 = 90. The risk-incident rule threshold is 100 — still below the wire.
▼
③ Fourth signalA fourth risk rule (lateral movement via SMB) fires, adding 20 more points. Total = 110 — threshold crossed.
▼
④ Risk Notable firesThe risk-incident rule creates one notable in Incident Review listing all four ATT&CK techniques (T1078, T1110, T1021, T1550) and the full risk timeline for rdevika.
Press Play to step through the RBA detection story. Then press Break it.
Quick check · Q3 of 10 · Apply

An analyst opens a risk notable and sees technique IDs T1078 and T1003. Where did those IDs originally come from?

Correct: a. MITRE ATT&CK technique IDs are set as annotations on each correlation search (or risk rule) in Content Management. When a risk event is written to the risk index it inherits those annotations, which then surface in the risk notable.
👉 So far: MITRE ATT&CK technique IDs are set manually as annotations on each correlation search. They flow into the risk index and surface in the risk notable, giving analysts the full ATT&CK story in one view.

④ Adaptive response actions — containment, enrichment & tuning for low noise

Adaptive response actions are what a correlation search does when it fires. The two built-in actions are: Risk Analysis (write a scored risk event to the risk index — the RBA path) and Notable Event (create an alert in Incident Review). Additional actions — from SOAR integrations, ES Premium Content, or custom scripts — can block an IP at the firewall, disable an Active Directory account, or enrich the event with threat intelligence lookups, all triggered from the same correlation search threshold.

Tuning for low noise without losing coverage

The failure mode in every ES deployment is the same: too many notable events, analysts stop triaging, real attacks hide in the noise. The RBA fix is: convert noisy, low-confidence searches to risk rules with a low score; keep high-confidence searches as direct notables; set the risk-incident rule threshold so it fires only on genuinely suspicious accumulated behaviour. Tune by reviewing the risk notable's contributing events — if most are false positives, raise the score threshold or tighten the search logic, not both at once.

Figure 4 — Classic notable vs RBA risk notable — analyst workload
RBA trades many low-context alerts for fewer, richer notables that already tell the full detection story.Classic notable vs RBA risk notable — analyst workloadClassic NotableOne alert per rule matchNo cross-rule contextAnalyst correlates manuallyHigh volume, low confidenceAlert fatigue builds fastRBA Risk NotableOne notable per entity storyAll ATT&CK techniques listedRisk index pre-correlatesLow volume, high confidenceAnalyst investigates once
RBA trades many low-context alerts for fewer, richer notables that already tell the full detection story.

Arjun at a Mumbai fintech firm faces this

The SOC receives over 400 notables per day from Splunk ES. Analysts are triaging less than 20% of them; a real credential-theft campaign runs undetected for three days buried in the noise.

Likely cause

All 60 correlation searches are configured with the Notable Event action. Each match — including broad, low-confidence detections like 'user logged in from a new country' — fires directly into Incident Review.

Diagnosis

Pull the Incident Review dashboard: the top 10 searches account for 380 of the 400 daily notables, all low-severity. The searches have no risk annotations and no MITRE ATT&CK tags.

ES Content Management ▸ Correlation Searches ▸ Edit ▸ Adaptive Response
Fix

Convert the 10 high-volume low-confidence searches to risk rules (add Risk Analysis action, assign a low score of 10–20, annotate with ATT&CK technique IDs). Create one risk-incident rule that fires a notable when any user or host accumulates more than 100 risk points in 24 hours. Keep 5 high-confidence searches (brute-force success, known-bad IP, etc.) as direct notables.

Verify

After 48 hours: daily notable count drops below 30. The risk notable for the compromised account shows five contributing detections across T1078, T1110 and T1021, giving analysts the full story in one click.

Validate RBA with the Risk Analysis dashboard

After converting searches to risk rules, open ES ▸ Security Intelligence ▸ Risk Analysis. You should see risk events accumulating per entity in the risk index before any notable fires. If the dashboard is empty, the risk rules are not writing events — check the Adaptive Response action configuration and the risk object field mapping.

Quick check · Q4 of 10 · Analyze

Your ES deployment fires 500 notables per day and analysts ignore most of them. The best first step?

Correct: c. Alert fatigue is fixed by RBA: move noisy, low-confidence detections to the risk-scoring path so they accumulate silently, and reserve the direct notable action for truly high-confidence matches. This reduces volume without losing true-positive coverage.
👉 So far: Adaptive response actions: Risk Analysis scores silently; Notable fires immediately; SOAR integrations contain threats. Tune by moving noisy searches to the risk path — never start with broad direct notables.

🤖 Ask the AI Tutor

Tap any question — instant, scoped to this lesson. No login, no waiting.

Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.

📝 Wrap-up assessment — six more

You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.

Q5 · Remember

Which Splunk index stores risk events written by RBA risk rules?

Correct: c. Risk rules write scored events to index=risk (the risk index). The risk-incident rule then searches this index to aggregate entity scores and decide when to fire a notable. The main and summary indexes store raw and summarised log data, not risk scores.
Q6 · Understand

A correlation search is set to 'Risk Analysis' adaptive response only. What happens when it matches?

Correct: b. The Risk Analysis action writes a scored risk event to the risk index but does NOT create a notable in Incident Review. Notables only appear when the risk-incident rule decides the entity's accumulated score has crossed the threshold.
Q7 · Apply

You want a Splunk ES detection to fire immediately for every instance of a known-bad C2 IP beacon, regardless of risk scores. Which action do you use?

Correct: b. The Notable Event adaptive response action fires a direct alert in Incident Review for every match — no accumulation required. This is correct for high-confidence, high-severity detections like known-bad C2 beacons where you need immediate triage, not gradual scoring.
Q8 · Analyze

Two risk rules fire for the same user: one scores 30 (new country login) and one scores 50 (off-hours admin access). The risk-incident threshold is 100. What happens?

Correct: c. The risk-incident rule sums scores per entity over a time window. 30 + 50 = 80, which is below the 100-point threshold, so no notable fires yet. The scores remain in the risk index waiting for the next contributing event to push the total over the threshold.
Q9 · Evaluate

An interviewer asks how you would prove MITRE ATT&CK coverage to a CISO. Best answer?

Correct: d. The MITRE ATT&CK coverage heatmap in Splunk ES visualises which technique cells have at least one active, annotated correlation search and how many alerts they produce. This is the artefact a CISO understands — coloured matrix showing breadth and gaps — not a count of searches or raw SPL.
Q10 · Evaluate

After enabling RBA, analysts report the risk-incident rule never fires even though risk rules are matching. Most likely cause?

Correct: b. If the risk object field (e.g. 'user' or 'src_ip') is mapped incorrectly, each risk event scores a different entity and no single entity ever accumulates enough score to cross the threshold. This is the most common RBA misconfiguration — check Content Management ▸ Adaptive Response ▸ Risk Analysis ▸ Risk Object settings.
Lesson complete — saved to your profile.
Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again".

🧠 In your own words

Type one line: explain in your own words why RBA fires fewer, better alerts than classic notable events. Then compare with the expert version.

Expert version: Classic ES fires one notable per correlation search match — 60 searches, 60 possible alerts per cycle. RBA flips this: risk rules score entities silently in the risk index, and the risk-incident rule fires only when an entity's cumulative score crosses a threshold. That one notable arrives labelled with every contributing MITRE ATT&CK technique, so the analyst gets the full detection story in one triage session instead of correlating dozens of separate alerts by hand.

🗣 Teach a friend

Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.

📖 Glossary

Correlation Search
A scheduled SPL query in Splunk ES that fires an adaptive response action (notable or risk event) when its result meets a configured threshold.
Notable Event
An alert record created in the Incident Review queue by the Notable Event adaptive response action — the immediate, classic alert path.
Risk Index
The special Splunk index (index=risk) where risk rules write scored risk events for RBA accumulation and aggregation.
Risk Rule
A correlation search configured to write a risk event to the risk index instead of (or in addition to) firing a direct notable, enabling entity-based score accumulation.
Risk-Incident Rule
A correlation search that runs against the risk index, groups events by risk object, sums scores over a lookback window, and fires a risk notable when the threshold is crossed.
Risk Object
The entity (user, host, or IP) being scored by risk rules in the risk index — the key field the risk-incident rule groups on.
Adaptive Response Action
An action attached to a Splunk ES correlation search: Risk Analysis (score entity), Notable Event (alert now), or an integration action such as block IP or disable account.
MITRE ATT&CK Annotation
A technique ID, tactic, and sub-technique set on a correlation search in Content Management that flows into risk events and notables for ATT&CK-mapped alerting.

📚 Sources

  1. Splunk Docs — How risk-based alerting works in Splunk Enterprise Security. help.splunk.com/en/splunk-enterprise-security-7/risk-based-alerting
  2. Splunk Docs — Analyze risk with risk-based alerting in Splunk Enterprise Security 8.5. help.splunk.com/en/splunk-enterprise-security-8
  3. Splunk Lantern — Risk-based alerting (RBA) — guided insights and implementation. lantern.splunk.com/Security/UCE/Guided_Insights/Risk-based_alerting
  4. Splunk Lantern — Implementing risk-based alerting — security use cases. lantern.splunk.com/Security_Use_Cases/Threat_Investigation
  5. Splunk Community — Risk-Based Alerting FAQs. community.splunk.com/t5/Splunk-Enterprise-Security/Risk-Based-Alerting-FAQs
  6. Somerford Associates — Optimising Risk-Based Alerting with Splunk Enterprise Security. somerfordassociates.com/blog/optimising-risk-based-alerting

What's next?

Got correlation searches and RBA mapped? Next, go deep on Splunk ES content management — how to clone, tune, and create detection searches from scratch using the Content Management UI and Analytic Stories — so you own the full detection pipeline end to end.

Next · All interview lessons → Practice on exam.techclick.in →