SIEM vs UEBA: Rules and Correlation vs Behavioural Baselines

Most SOCs now own a SIEM with a UEBA feature switched on, yet few can say which detections should be written as rules and which should be left to behavioural baselines, so they get duplicate alerts on the noisy cases and silence on valid-account abuse. SIEM correlation and UEBA are two different kinds of detection logic: one encodes what an analyst already knows is bad, the other learns what is normal for each entity and scores departures from it. This guide compares them as detection methods rather than products, including how to baseline service accounts and other non-human identities. It is for detection engineers, SOC leads and platform owners; the foundations are in the SIEM Guide and the UEBA Guide.

Key takeaways

• Rules encode knowledge, baselines encode normality. A SIEM correlation rule fires when events match a pattern you wrote; UEBA fires when an entity departs from its own history or its peers. Each catches what the other misses.
• UEBA is mostly a SIEM feature now. The major SIEM platforms ship UEBA or entity risk scoring inside the product, so the real decision is which use cases go to which logic, not which tool to buy.
• Non-human accounts suit rules better than most teams think. A well-run service account's behaviour is narrow enough to express as an explicit allow list (source, logon type, API set, schedule). Use baselines for the long tail you cannot enumerate.
• The two fail differently. Rules fail on the unknown and drift as environments change; baselines fail on poisoned or thin history and on noisy automation. Tune each with its own method.
• Data needs differ. Correlation needs the right fields from the right sources for each rule; UEBA needs weeks of consistent history, resolved identities and HR or ownership context. A source that is fine for rules can be useless for baselines.

The short answer

Write a SIEM rule when you can describe the bad behaviour precisely: a known technique, a policy violation, a sequence of events in a time window, or a forbidden action. Use UEBA when the behaviour is only suspicious relative to what the entity normally does: a user reading ten times their usual volume or a service principal calling a new API family. The joint living off the land guidance from CISA, NSA, FBI and partners recommends both in the same list: consider SIEM tools for log aggregation, establish and continuously maintain baselines, and leverage UEBA to correlate activity across data sources.

Detection logic compared

Rules and correlation

The threat model behind correlation is "we know what this attack looks like". An engineer translates a technique, an incident lesson or a policy into conditions on fields. Sigma, the open rule format, shows the range of logic now expected of a SIEM. Its correlation rules specification (version 2.1.0) defines event_count (for example ten failed logons for one account in five minutes), value_count (one source trying many distinct accounts, the shape of T1110.003 Password Spraying), temporal and temporal_ordered (events from several rules within a time span, in any order or a fixed order), and aggregations such as value_sum, value_avg and value_percentile. The specification itself warns that some backends cannot preserve event order or only match within fixed time boundaries, which can cause false positives and false negatives, so converted rules need testing on each platform.

Architecture, in words: parsed and normalised events land in the SIEM; scheduled or streaming queries evaluate each rule; matches create alerts with entities attached; the SOC triages. Every rule has an author, a test and an owner, which is why correlation is explainable and auditable. See the Detection Engineering Guide for the rule lifecycle.

Behavioural baselines

The threat model behind UEBA is "the attacker will look legitimate". Stolen credentials, insiders and living off the land techniques produce events that match no signature, so the platform learns normal behaviour and scores deviation. The platforms describe this in similar terms. Microsoft's Sentinel documentation says UEBA builds dynamic behavioural profiles and detects anomalies by comparing current activity to established baselines. Splunk's Enterprise Security documentation says its UEBA identifies anomalies by comparing current activity against learned baselines for users and assets. MITRE D3FEND catalogues the family as D3-UBA User Behavior Analysis, with children such as D3-ANET Authentication Event Thresholding, D3-RAPA Resource Access Pattern Analysis and D3-UDTA User Data Transfer Analysis.

Architecture, in words: features are extracted from events (logon count, bytes transferred, distinct hosts, first-seen country); per-entity and per-peer-group baselines are learned over a window; each new event or time bucket is scored against them; anomalies accumulate into an entity score with decay; high scores create alerts or enrich existing ones.

Where the two logics overlap

The boundary is blurred in practice. A Sigma value_percentile correlation or a hand-written query comparing today's volume with a 30-day average is a simple baseline built as a rule. Conversely, risk scoring in several platforms accumulates the output of ordinary rules per entity. The useful distinction is who defines normal: the engineer (rule) or the model (UEBA).

Convergence: UEBA inside the SIEM platform

Standalone UEBA products still exist, but the main SIEM platforms now ship behavioural analytics or entity risk scoring as part of the product. Platforms are listed alphabetically; each row uses the vendor's own feature names, and order is not a ranking.

Availability: licensing, edition and enablement steps for these features differ between all four platforms and change often, so check current terms in each vendor's documentation.

When a standalone UEBA product still makes sense: the SIEM holds only a subset of the data the models need (for example because of ingest cost), several SIEMs coexist after an acquisition, or insider risk is a separate programme with its own data handling rules. In each case, send the UEBA output back to the SIEM as enrichment so the SOC triages in one place. The wider platform trade-offs are in Next-Gen SIEM vs Traditional SIEM, and evaluation questions are in the User and Entity Behaviour Analytics (UEBA) buyer's guide.

Baselining non-human accounts: rule or model?

The LOTL guidance says automated tools and service accounts should be predictably bounded by time of day, source and destination hosts, and user accounts. If you can write those bounds down for a non-human identity, a rule beats a model, because it alerts on the first deviation with no learning period and no risk of learning the attacker as normal. Reserve UEBA for NHIs you cannot describe yet, or whose behaviour varies legitimately.

Two cautions specific to NHIs. First, a baseline learned while a credential is already compromised treats the attacker as normal; a rule written from the documented purpose does not. Second, UEBA peer groups are often built from HR data, which non-human accounts lack, so workloads need peer groups by application and environment or they get compared with people. The Okta Breach, where a support service account's credentials were saved in a personal browser profile and then used by an attacker, included a download of a full user report: a bulk-read action that account would rarely perform, and exactly the kind of bound a rule can state. Ownership and inventory come first: see the Service Account Security Guide.

Failure modes of each approach

The Snowflake Breach shows both sides. The intrusions used valid credentials with ordinary SQL, so no signature fired. The lessons on that page split cleanly: logins from commercial VPN ranges and new client tools are baseline questions for each account, while enforcing network allow lists and alerting on large copies to temporary stages can be written as explicit rules.

False-positive tuning, method by method

Tuning rules:

1. Record why each alert was closed (benign true positive, false positive, duplicate) so tuning is driven by data, not complaints.
2. Prefer narrowing conditions (specific process, parent, logon type) over adding broad exclusions such as a whole subnet.
3. Give every exclusion an owner, a reason and an expiry date, and review them quarterly.
4. Test each change against a replay of historical data before deploying, and keep the previous version to roll back.

Tuning UEBA:

1. Fix inputs first: resolve identities across systems, label automation and service accounts, and correct peer groups. Most UEBA noise is a data problem.
2. Weight anomalies by asset criticality and privilege, so rarity on a kiosk user scores lower than on a Tier 0 administrator, using the platform's asset or entity context where available.
3. Suppress known-benign patterns with time-bound exclusions; prefer time-bound over indefinite exclusions.
4. Set alert thresholds on accumulated entity scores, not single anomalies, and let scores decay.
5. Expect an anomaly surge after migrations or reorganisations; plan a reduced-alerting period with a named reviewer rather than turning the feature off.

Avoid tuning the same use case in both places. If a rule and a UEBA anomaly both fire for one pattern, decide which owns it and suppress the other, or merge them into one alert with the anomaly as enrichment.

Data requirements

Ingest cost is the common conflict: teams drop verbose sources to save money, which leaves rules working but starves UEBA of history. Decide per source which logic depends on it before changing collection or retention. The Log Management and Retention Guide covers tiering.

Decision criteria

• Write a rule when the behaviour is a known technique, a policy breach, an action an entity should never take, or an ordered sequence.
• Use UEBA when only the entity's own history or peers can say whether the behaviour is wrong: volumes, first-seen access, unusual times for variable roles, insider collection.
• Use both, merged for high-value identities: rules for hard bounds, UEBA scores as enrichment that raises priority.
• Small teams: turn on the UEBA built into your SIEM, connect identity sources first, use scores as triage enrichment, and spend engineering time on a short list of high-fidelity rules, including NHI bounds.
• Large teams: run detection-as-code for rules, give UEBA a named owner who tunes inputs and peer groups, and measure both with the same metrics.
• Insider risk programmes: UEBA output often feeds a separate insider risk process with HR and legal; agree data access and escalation rules before go-live. See Insider Risk vs Insider Threat.

Worked scenario: one support agent, two lenses

A financial services firm reviews the Coinbase Insider Breach, where bribed support agents used legitimate accounts to copy customer records. Its own support platform logs every record view with agent ID, customer ID and ticket ID.

1. SIEM rule: alert when an agent views a customer record with no open ticket for that customer. This is a policy breach that can be stated exactly, so it is a rule, tested by replaying a month of logs to measure noise.
2. UEBA baseline: score agents whose daily record views exceed their own history and their peer group (same team, same queue). Mass viewing within ticketed work is not a policy breach, so only a baseline can flag it.
3. Merging: both outputs land on the agent entity. A high UEBA score raises the priority of any ticketless-view alert for that agent; neither alone pages the on-call analyst at night.
4. Tuning: the first two weeks show anomalies for new joiners. The team fixes peer groups to use start date and queue, rather than suppressing new joiners.
5. Measurement: the team tracks ticketless-view alerts closed as true positive and the share of UEBA alerts that led to a case.

How to implement both without duplication

1. Inventory use cases: list current rules and UEBA detections, mapped to ATT&CK techniques, and mark overlaps.
2. Assign each use case one primary logic using the decision criteria; the other becomes enrichment.
3. Prepare data: onboard identity sources, resolve identities, tag service accounts and workloads with owner and purpose, and load HR context.
4. Write NHI bound rules for every service account with a documented purpose.
5. Enable UEBA in observe mode: let it learn and record scores without alerting, and review the top-scoring entities weekly.
6. Pilot alerting on one population (privileged users or one business unit), then expand.
7. Roll back by reverting thresholds to observe mode; keep rule versions in source control.

Detection and measurement

• True positive rate by logic: share of alerts closed as true positive, reported separately for rules and UEBA.
• Duplicate alert rate: incidents with both a rule and a UEBA alert for the same activity that were not merged.
• NHI bound coverage: share of service accounts with a documented purpose that have an explicit bound rule.
• UEBA input health: share of events attributed to a resolved entity, and share of service accounts labelled as automation.
• Exclusion hygiene: exclusions and suppressions past their expiry date.
• Detection time for valid-account misuse: from first malicious use of a credential to alert, measured in purple team tests; see the Security Operations Metrics Guide.

Framework mapping

Common failure patterns

• Baselining what could be a rule: leaving service accounts to UEBA when their purpose is documented, which delays the alert and risks learning the attacker as normal.
• UEBA switched on without identity data: enabling the feature before connecting identity sources and resolving entities, then judging it on the noise.
• Double alerting: rule and UEBA alerts for the same pattern triaged separately by different analysts.
• Permanent suppressions: exclusions with no expiry that silently remove whole populations from both logics.
• Cost-driven source cuts: dropping verbose logs to save ingest cost without checking which baselines depended on them.
• Scores treated as verdicts: closing or escalating on a risk number without reading the contributing anomalies.

Practitioner checklist

• Map every detection to one primary logic, rule or baseline, and record it.
• Write bound rules for every service account and workload with a documented purpose.
• Resolve identities across directory, identity provider, cloud and SaaS before relying on UEBA.
• Build workload peer groups by application and environment, never from HR data.
• Run UEBA in observe mode before alerting, and pilot on one population.
• Merge rule and UEBA outputs on the entity so analysts see one picture.
• Give every exclusion an owner, reason and expiry.
• Check which logic depends on a source before changing collection or retention.
• Report true positive rate separately for rules and UEBA each quarter.

Standards and references

• CISA, NSA, FBI and partners: Identifying and Mitigating Living Off the Land Techniques
• CISA and ASD's ACSC: Guidance for SIEM and SOAR Implementation
• MITRE D3FEND: User Behavior Analysis
• SigmaHQ: Sigma Correlation Rules Specification
• Elastic: Entity analytics overview
• Google Cloud: Risk Analytics overview, Google Security Operations
• Microsoft Learn: Identify threats with UEBA in Microsoft Sentinel
• Splunk: UEBA overview in Splunk Enterprise Security

Related NHI Mgmt Group resources: ITDR vs UEBA, ITDR vs SIEM, SOAR vs SIEM, Detection Engineering for Non-Human Identities Guide.