Most engineers think…
Most security engineers assume SIEM correlation rules are enough to catch insider threats: 'just write a rule for unusual login hours.' That picture breaks down the moment an attacker moves slowly, blends into normal hours, or uses stolen valid credentials.
Splunk UBA adds a behavioural layer on top of your SIEM. It ingests the same data, builds unsupervised ML baselines for each user and entity, spots deviations as anomalies, then clusters those anomalies across kill-chain phases into high-confidence threats. The result: analysts see five high-fidelity threats instead of fifty thousand raw events — and each threat already shows which kill-chain stages were hit.
① What Splunk UBA actually is — behavioural baselines, not rules
Traditional SIEM rules fire when an event matches a known pattern: 'five failed logins in a minute.' Splunk UBA takes a different approach. It ingests events — authentication logs, VPN sessions, DLP alerts, HR data, cloud activity — and uses unsupervised machine learning to build a personal baseline for every user and every entity (device, account, application). No pre-written rule, no labelled training set.
When behaviour drifts from that baseline — a user downloading ten times more data than usual, logging in from a new country at 2 a.m., or accessing systems peers never touch — UBA raises an anomaly. Anomalies are scored, time-stamped, and attached to the user or entity that generated them. The power is that UBA distils millions of raw events down to a few hundred anomalies per day, and then further to a handful of actionable threats.
Why can Splunk UBA detect insider threats that rule-based SIEM correlation misses?
② ML models — streaming, batch and peer groups
UBA runs two model families. Streaming models process every event in real time — vital when sequence and timing matter, such as detecting a rapid privilege escalation or a burst of failed authentications followed immediately by a success. Batch models operate on aggregated events over a sliding window, re-training on recent history to re-score entity risk as behaviour shifts week to week.
Peer groups — the comparison engine
Both model families rely on peer groups. UBA builds four kinds: HR peer groups from Active Directory groups and management chains; Organisational Unit (OU) peer groups from AD OU structure; behavioural peer groups formed by clustering similar activity patterns; and device peer groups by network activity. A sales rep accessing source-code repositories is anomalous only if none of their behavioural peers ever do the same — peer groups make that judgement automatic.
Each entity accumulates an Entity Risk Score — the weighted sum of its active anomalies. Analysts use the risk score leaderboard to spot the highest-risk users before an alert even fires.
The weighted sum of all active anomalies for a user or device. The risk leaderboard surfaces the highest-risk entities — analysts prioritise from here before alerts even fire.
Streaming models score every event in real time (sequence-sensitive). Batch models re-train on aggregated data over a sliding window to track shifting baselines week to week.
HR, OU, behavioural and device peer groups. A behaviour is anomalous only if none of an entity's peers share it — peers make ML context-aware and stop role-typical actions from firing alerts.
UBA groups anomalies by entity and kill-chain phase. When multiple phases align for one user, it raises a named threat (e.g. Data Exfiltration by Compromised Account) with a full timeline of evidence.
Always distinguish streaming models (real-time, sequence-aware) from batch models (aggregated, sliding-window re-training) and explain that both depend on peer groups to make a behaviour anomalous relative to similar users — not just to the global population.
Which UBA model type is most important for detecting a burst of failed logins immediately followed by a success?
③ Kill-chain threats — correlating anomalies across attack phases
An anomaly is a data point; a threat is a story. UBA maps each anomaly to a kill-chain phase — Reconnaissance, Delivery, Exploitation, Lateral Movement, Command & Control, Data Exfiltration, Persistence — and then looks for a user or device that has anomalies across multiple phases in a short window.
When the pattern aligns, UBA raises a threat with a name like Data Exfiltration by Suspicious User or Compromised Account — Lateral Movement. The threat bundles all contributing anomalies, shows the timeline, and assigns a threat score based on the severity and number of phases covered. A single threat represents what might have been twenty separate low-priority alerts in a rule-based SIEM.
Threats are the unit of work for the SOC. An analyst opens one threat, reviews the timeline of anomalies, sees which data sources confirmed each, and decides to investigate or dismiss — no need to pivot through raw logs to reconstruct the story.
A single anomaly is a weak signal. Analysts who triage anomalies one-by-one burn out fast. The correct workflow is to let UBA correlate anomalies into kill-chain threats and work the threat queue. Tuning means adjusting peer groups and model weights — not suppressing individual anomaly types.
▶ Watch a compromised account get caught by kill-chain correlation
Step through how UBA moves from raw login events to a named kill-chain threat in ES. Press Play for the healthy detection path, then Break it to see the classic tuning failure.
A UBA threat 'Data Exfiltration by Suspicious User' has fired on an employee. What does this mean for the analyst?
④ Integration with Enterprise Security — bidirectional, not one-way
UBA and Splunk Enterprise Security connect bidirectionally. In the ES-to-UBA direction, notable events generated by ES correlation searches can be forwarded to UBA as additional signal — adding rule-based detections into the ML pipeline so UBA can factor them into anomaly and risk scoring. In the UBA-to-ES direction, UBA pushes threats (and optionally individual anomalies) to ES as notable events in the Incident Review queue.
Status synchronisation
When an analyst updates the status of a notable event in ES — Pending, In Progress, Resolved — that status is synchronised back to UBA, keeping both systems consistent without double-entry. The practical result: the SOC works entirely in ES while UBA acts as a silent behavioural enrichment layer, boosting the risk context of every alert it touches.
The interview line: UBA does not replace ES; it feeds it with pre-correlated, high-confidence threats that a rule alone could never produce. Tune UBA by adjusting anomaly model weights and peer-group composition — not by writing more SIEM rules.
Priya at a Mumbai fintech faces this
The SOC is flooded with hundreds of low-severity UBA anomalies every day but zero threats are firing, so analysts ignore the anomaly feed entirely.
Peer groups were never configured — UBA is comparing every user to the global population, inflating anomaly scores for legitimate role-specific behaviour (finance users accessing large data exports).
Check UBA peer group configuration. HR and OU peer groups are empty; behavioural clustering was disabled during deployment. Finance users are being compared to engineers and support staff.
UBA ▸ Configuration ▸ Peer Groups ▸ HR / OU / BehaviouralEnable HR peer groups using the Active Directory import, map OU peer groups to business units, and run behavioural clustering. Re-baseline over 2–4 weeks. Anomaly scores for role-typical behaviour drop; genuine outliers rise and form threats.
After re-baselining, the anomaly feed shrinks to dozens of high-confidence items per day and 2–3 kill-chain threats per week reach ES as notable events — analysts now work the threat queue instead of ignoring it.
After configuring UBA-to-ES integration, generate obvious off-hours access with a test account, confirm UBA raises an anomaly and threat, then verify the threat appears as a notable event in ES Incident Review. Status-sync it back to Resolved in ES and confirm UBA reflects the same status.
An analyst resolves a notable event in Splunk ES that was pushed by UBA. What happens in UBA?
🤖 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.
🧠 In your own words
Type one line: what is the difference between a UBA anomaly and a UBA threat? Then compare with the expert version.
🗣 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
- Anomaly (UBA)
- A scored deviation from an entity's ML-learned behavioural baseline. Multiple anomalies correlated across kill-chain phases form a threat.
- Threat (UBA)
- A named, timeline-backed incident created by correlating anomalies across two or more kill-chain phases for the same user or entity.
- Entity Risk Score
- The weighted sum of all active anomalies for a user or device. High scores surface the riskiest entities before alerts are even raised.
- Peer Group
- A set of similar users or devices UBA uses as a comparison baseline — HR, OU, behavioural, or device — preventing role-typical behaviour from looking anomalous.
- Streaming Model
- A UBA ML model that processes every event in real time, sensitive to event sequence and timing.
- Batch Model
- A UBA ML model that operates on aggregated events over a sliding time window, re-training to track shifting behavioural baselines.
- Kill-Chain Phases
- Attack lifecycle stages (Recon, Delivery, Exploitation, Lateral Movement, C&C, Exfiltration, Persistence) that UBA maps anomalies to for threat correlation.
- Bidirectional Sync
- The UBA–ES integration where notable events and status changes flow both ways between UBA and Enterprise Security automatically.
- Analytics Store
- UBA's dedicated aggregated event store that reduces raw event volume for efficient ML model processing and configurable data retention.
📚 Sources
- Splunk — About Splunk User Behavior Analytics (v5.4.4). help.splunk.com/en/security-offerings/splunk-user-behavior-analytics
- Splunk — Splunk UBA Models Overview (v5.4.5). help.splunk.com/en/security-offerings/splunk-user-behavior-analytics/use-splunk-user-behavior-analytics/5.4.5
- Splunk — User and Entity Behavior Analytics (UEBA) for Enterprise Security. splunk.com/en_us/products/user-and-entity-behavior-analytics.html
- Splunk Blog — Elevating Security Intelligence with Splunk UBA's Machine Learning Models. splunk.com/en_us/blog/security/elevating-security-intelligence-with-splunk-uba-s-machine-learning-models.html
- Splunk Lantern — Getting Started with UBA. lantern.splunk.com/Security/Getting_Started/Getting_started_with_UBA
- Splunk Blog — User and Entity Behavior Analytics (UEBA) For Enterprise Security. splunk.com/en_us/blog/learn/user-entity-behavior-analytics-ueba.html
What's next?
Got UBA covered? Next, go deep on Splunk Enterprise Security correlation searches, risk-based alerting, and how the Risk Framework turns every signal — including UBA threats — into a risk score that drives the SOC queue.