IM Engineer Study Notes
← Back to list
Security & Privacy
#UEBA#이상행위탐지#내부자위협#기준선#제로트러스트
Last updated · 2026-10-16

User and Entity Behavior Analytics (UEBA)

1. Overview

Definition: UEBA (User and Entity Behavior Analytics) is a security analytics technology that uses machine learning to learn the normal behavior of users and of entities such as devices, servers, and service accounts, establishes a behavioral baseline, and converts statistical deviations from that baseline into risk scores to detect insider threats and compromised accounts.

UEBA emerged from two currents: "the limits of rule-based detection" and "the collapse of the perimeter." Traditional SIEM/IDS detected only events matching predefined rules (signatures) such as "five or more failed logins" or "access outside business hours." But when an attacker steals a legitimate account's credentials and logs in with valid privileges, that act violates no rule at all. Likewise, when a privileged insider exfiltrates an unusual volume of data, rules do not catch it. In other words, the starting point of UEBA is the realization that we must watch not "who logged in (authentication)" but "whether that person is behaving differently from usual."

A second driver is the disappearance of the security perimeter. As cloud, remote work, and BYOD became ubiquitous, the assumption that "inside the internal network means trusted" collapsed, and identity became the new perimeter. As industry reports accumulated showing that a substantial share of data breaches originate not from external intrusion but from insiders or compromised internal accounts, the demand grew that blocking the outside of the firewall is not enough and that abnormal behavior occurring internally must be continuously observed. UEBA is the data-analytic answer to that demand.

This shift moves the burden of detection from "how well humans write rules" to "how well data represents normality." Where rule-based detection was an arms race to broaden the dictionary of known attacks, UEBA refines a model of normality and treats everything else as suspect. Thanks to this conceptual shift, UEBA can target areas that rules could never catch in principle, such as novel attacks without signatures or threats that abuse legitimate privileges. Yet the moment "normal" is defined by data, a new responsibility arises: that data's bias and incompleteness become the blind spots of detection.

The essential characteristics of UEBA can be summarized in four points. First, baselining — instead of humans writing rules in advance, normal patterns per individual, group, and entity are learned from data. Second, entity-centric — the analysis scope is widened beyond people to servers, IoT, and service accounts to capture anomalies of non-human subjects. Third, risk scoring — individual anomalies are converted not into a true/false dichotomy but into a cumulative risk score to set priorities. Fourth, contextualization — multiple weak signals are grouped by time and subject and reconstructed into a single threat narrative. These four characteristics show that UEBA is not merely the addition of detection rules but a shift in the detection paradigm.

2. Overall UEBA Architecture and Components

UEBA is composed of a layered analytics pipeline that collects data from diverse log sources, normalizes it, learns baselines, computes anomaly scores, and feeds them to the SOC/SOAR. The conceptual diagram below shows the overall structure from data collection to response integration.

flowchart TB
  subgraph SRC["Data source layer"]
    IDP["Auth logs(IAM/AD)"]
    EP["Endpoint(EDR)"]
    NW["Network flows(NetFlow)"]
    APP["Application/DB audit"]
    CL["Cloud activity logs"]
  end
  subgraph CORE["UEBA analytics core"]
    ING["Ingest/normalize/entity resolution"]
    BASE["Baseline model(ML training)"]
    DET["Anomaly detection engine"]
    RISK["Risk score aggregation(Risk Engine)"]
  end
  subgraph OUT["Response/operations layer"]
    ALERT["Prioritized alerts"]
    SOAR["SOAR automated response"]
    SOC["SOC analyst investigation"]
  end
  IDP --> ING
  EP --> ING
  NW --> ING
  APP --> ING
  CL --> ING
  ING --> BASE
  BASE --> DET
  DET --> RISK
  RISK --> ALERT
  ALERT --> SOAR
  ALERT --> SOC
  SOC -->|feedback| BASE

The data source layer supplies UEBA's raw material. Representative sources are authentication logs (login time, location, success/failure), endpoint process-execution records, network flows, application/DB access audits, and cloud API call logs. Since UEBA's detection quality is proportional to the breadth and consistency of input data, the wider the sources and the more accurately time and subject are identified, the more refined the baseline becomes. In particular, the core preprocessing step is resolving identifiers (account names, IPs, hostnames) scattered across logs into a single entity (Entity Resolution).

Entity-resolution quality is the foundation of all of UEBA. One person appears as many accounts, devices, and IPs, and a single IP may be shared by many people, so if scattered identifiers cannot be attributed to the correct subject, the baseline itself becomes contaminated. A mature UEBA therefore integrates with IAM, asset management (CMDB), and HR systems to continuously synchronize the relationships among account-person-role-device, and updates the entity mapping whenever an organizational change occurs.

The analytics core is UEBA's brain. In the ingest/normalize stage, heterogeneous logs are converted into a common schema and entities are resolved; then the baseline model learns each subject's normal range. The anomaly detection engine compares new events against the baseline to compute deviations, and the risk-score engine accumulates individual deviations by time and subject to produce an overall risk level. The important point is that it does not raise an alert on a single anomaly alone; rather, the structure is such that the score crosses a threshold only when multiple weak signals accumulate on the same subject. This is a design that suppresses false positives while still capturing stealthy attacks.

The response/operations layer turns analysis results into action. It presents high-risk subjects as prioritized alerts, and either performs automated responses in coordination with SOAR playbooks — such as disabling accounts, terminating sessions, or demanding step-up authentication — or forwards them to SOC analysts as investigation tasks. The analysts' verdicts (true/false positive) are fed back into the baseline model to incrementally improve detection accuracy.

The design principle running through the components can be summarized as "collect broadly, alert narrowly." Collection is as broad as possible across many sources, but alerts are issued narrowly, only when confidence is established by accumulating multiple signals. This asymmetric structure aims to maximize visibility while controlling analysts' cognitive load, revealing that the UEBA pipeline is not a mere list of detectors but an analytics system that optimizes the signal-to-noise ratio. Therefore, advancing only one layer yields limited effect; value emerges only when collection breadth, learning sophistication, score-aggregation logic, and response automation mature in balance.

3. Detection Mechanisms and Types

The heart of UEBA is a statistical/machine-learning pipeline that "learns the normal and measures the abnormal." The detailed process diagram below shows the flow in which a single event is compared against the baseline, converted into a risk score, and led to a response.

sequenceDiagram
  participant E as Event(log)
  participant N as Normalize/entity-resolve
  participant B as Baseline model
  participant S as Risk score engine
  participant R as Response(SOAR/SOC)
  E->>N: Collect raw logs
  N->>B: Generate per-entity feature vectors
  B->>B: Compute deviation vs baseline(stats/ML)
  B->>S: Pass individual anomaly signals
  S->>S: Accumulate score by time/subject
  alt Threshold exceeded
    S->>R: Issue high-risk alert
    R->>B: Analyst verdict feedback
  else Below threshold
    S->>S: Score decay(over time)
  end

Detection techniques fall broadly into three types, each with a different trade-off between detection coverage and false-positive rate. First, statistical anomaly detection measures deviation as "how many times vs usual" using statistics such as mean, standard deviation, and quantiles. For example, if a user who usually downloads 50MB a day suddenly downloads 5GB, it is immediately caught as a 100x deviation. It is simple to implement and highly explainable, but false positives can rise when the normal distribution exhibits seasonality.

Second, unsupervised ML finds rare patterns from unlabeled data via clustering, isolation level (Isolation Forest), autoencoder reconstruction error, and the like. It can capture unknown attacks even without prior labels, making it strong against "unknown departures from normal" such as insider threats, but explaining why something is anomalous is hard, so earning analysts' trust is a challenge. Third, peer group analysis captures relative anomalies — such as "accessing alone a system no one else on the same team accesses" — by comparing against the average behavior of groups with similar roles and departments. Unlike a self-baseline that looks only at an individual's past, it catches deviation relative to the group, which is complementary.

The three techniques are not mutually exclusive and are strongest when combined into an ensemble. In practice, statistical techniques quickly filter out obvious extremes, unsupervised ML complements subtle pattern deviations, and peer group analysis fills the blind spots of individual baselines, forming a layered defense. The deviations produced by each technique are normalized to a common scale and gathered into the risk-score engine, and here time weighting matters. By giving greater weight to more recent deviations and decaying older signals, the side effect of a past one-time anomaly permanently branding a subject as high-risk is prevented. Also, because the trend of a risk score matters more than its absolute value, the operational principle of prioritizing subjects whose scores spike within a short time window is widely used.

In terms of target scenarios, UEBA covers four axes — compromised accounts (abnormal login geography/time), insider threats (privilege abuse/mass exfiltration), privilege escalation (Lateral Movement), and data exfiltration (abnormal data access). The table below is a supplementary comparison of each type.

Detection technique Core principle Strength Limitation
Statistical anomaly Mean/std-dev deviation Easy to explain, lightweight Vulnerable to seasonality/trends
Unsupervised ML Clustering/isolation/reconstruction error Captures unknown attacks Low explainability
Peer group analysis Deviation vs group average Captures relative anomalies Depends on group-definition quality

Elaborating the four detection scenarios a little more makes each one's characteristics sharper.

  • A. Compromised Account: A case where login uses legitimate credentials but the access geography, time, device, and speed differ from usual. For example, Impossible Travel — the same account accessing from the opposite side of the globe 10 minutes after a login from Seoul — is a representative signal. Because authentication succeeded, rule-based detection struggles, and it is caught only as a contextual deviation from the baseline.
  • B. Insider Threat: A case where an employee who legitimately holds privileges views and exfiltrates data beyond the usual range. It includes not only malicious insiders but also unintentional leakage due to mistakes or policy ignorance. It is captured effectively only by combining individual baselines with peer group analysis.
  • C. Privilege Escalation/Lateral Movement: The stage where an attacker who succeeded in intrusion moves internally to higher privileges and more important assets. The key signal is a chained access pattern to hosts/services not usually accessed, and graph-based analysis shows particular strength here.
  • D. Data Exfiltration: The final stage of exfiltrating sensitive data externally. Abnormal large transfers, uploads to external storage, and mass downloads during off-business hours are measured as deviations from the baseline.

4. SIEM vs UEBA Comparison and Application Cases

UEBA is often confused with SIEM, but their orientations differ. SIEM is strong at collecting and retaining broad logs and detecting known threats via rules and correlation analysis, and is optimized for compliance evidence. By contrast, UEBA focuses on deviation from a learned baseline to target unknown/internal threats that are hard to express as rules. The two are complementary rather than competitive, and in fact many commercial SIEMs have absorbed UEBA modules, trending toward integration as "next-generation SIEM." The fundamental reason for the difference lies in the source of detection knowledge — SIEM relies on human-written rules (explicit knowledge), while UEBA relies on baselines induced from data (tacit knowledge). Therefore SIEM is strong against threats where "we know what to look for," and UEBA against threats where "we do not know what to look for."

This difference is also reflected in the operating model. A SIEM-centric SOC's core competency is proactive knowledge management — "maintaining rules and adding rules for new threats" — whereas a UEBA-centric SOC's core becomes a data-science competency of "interpreting and verifying model-produced anomalies and feeding those verdicts back into the model." Therefore, when an organization adopts UEBA, it must bring in not only the tool but also the analyst competency to investigate and adjudicate anomaly signals together with a feedback process. Without this competency, UEBA alerts degrade into yet another uninterpretable noise.

As a concrete case, consider an incident where, at a financial institution, a particular service account threw hundreds of queries during early-morning hours outside business hours at a customer DB it did not usually access. Each individual query was within the privilege scope and so did not trip SIEM rules, but UEBA accumulated the fact that "that service account's time-of-day, target, and frequency" simultaneously deviated from the baseline and raised a high-risk alert; investigation revealed a case where credentials embedded in an automation script had been stolen. As another case, when an employee about to leave the company increased document downloads from around 10 to roughly 400 in a day, it was caught as a deviation of more than 40x versus the peer group average, and a data-exfiltration attempt was reportedly blocked in advance. Thus the value of UEBA lies in proving "different from usual, even without a rule" numerically.

As a third case, consider an incident in a manufacturing OT (operational technology) environment where a particular engineering workstation, unlike usual, sent configuration-change commands to many PLCs (control devices) at night. It was caught as a deviation from the behavioral baseline of the entity (workstation) rather than a person, and an infected device was reportedly blocked at the early stage of attempting lateral movement into the control network. This case shows that when UEBA's analysis scope extends beyond people to non-human entities, it remains valid even in environments such as OT/IoT where the concept of a user account is thin.

5. Deep Dive — Recent Trends and ITDR/Zero Trust Integration

Recently, UEBA has evolved away from being a standalone product into an analytics engine embedded in XDR/SIEM/ITDR (Identity Threat Detection and Response). In particular, as identity became the key target of attacks, UEBA has taken its place at the heart of ITDR, which intensively analyzes behavior at the identity layer. Whereas legacy EDR/NDR looked at devices and networks, ITDR detects abnormal use of "accounts, tokens, and sessions" with UEBA techniques to block compromise and privilege escalation early.

UEBA is also re-examined as a core input of Zero Trust architecture. Zero Trust's principle of "continuously verify" requires not ending with a single authentication but re-evaluating trust throughout a session, and UEBA's real-time risk score becomes precisely that re-evaluation signal. For example, if post-login behavior departs from the baseline, the risk score rises, and the policy engine receiving it demands step-up authentication via adaptive access or isolates the session. In other words, UEBA provides the basis for dynamically adjusting "how much trust to grant to whom right now."

On the technical evolution axis, graph-based analysis and real-time streaming processing stand out. Whereas traditional UEBA looked at the time series of individual subjects, graph UEBA models access relationships among user-device-resource as a graph to structurally detect lateral-movement paths where "nodes not usually connected chain together within a short time." Also, as the center of gravity shifts from batch learning to streaming inference, risk scores are updated within seconds of a log occurring, enabling real-time adaptive response. This is directly linked to the SOC's fundamental goal of shortening mean time to detect/respond (MTTD/MTTR).

The rise of generative AI also acts on UEBA in two ways. On the defensive side, LLMs summarize and explain complex anomaly narratives in natural language, shortening analysts' investigation time and complementing the explainability weakness of unsupervised ML. On the offensive side, AI attempts to evade the baseline by mimicking normal behavior more elaborately, so UEBA must also design adversarial robustness and baseline-retraining cycles together. Furthermore, as non-human identities (NHI, Non-Human Identity) such as service accounts, bots, and AI agents proliferate, it is a clear trend that UEBA, once human-centric, is shifting its center of gravity toward machine-entity behavior analytics.

6. Considerations and Implications

From a professional engineer's perspective, adopting UEBA should be approached not as a simple solution purchase but as a strategic task spanning data, organization, privacy, and operations.

  • Data quality and baseline-stabilization strategy: UEBA's success hinges on the breadth and consistency of input data and the quality of entity resolution. During the initial 2–8-week warm-up period, false positives are many, so a phased rollout roadmap premised on gradual source expansion and baseline maturity is needed. Because frequent reorganizations and job changes shake the baseline, retraining cycles and drift monitoring must run in parallel.

  • False positives/alert fatigue and operational trade-off: Raising sensitivity reduces misses but explodes false positives and paralyzes the SOC; lowering it does the reverse. An operating system that tunes risk-score thresholds, score decay, and peer-group definitions to the organizational context and continuously corrects them via an analyst feedback loop decides success. One must recognize that UEBA is an "operated" solution, not an "installed" one.

  • Privacy/worker-surveillance risk and governance: Because it continuously analyzes employee behavior, it can conflict with privacy law and worker-surveillance regulation. One must apply the principles of collection minimization, pseudonymization, purpose limitation, and access control, and institutionally guarantee through labor-management agreement and transparent notice that the purpose is security, not surveillance. UEBA without governance invites legal and ethical backlash.

  • Explainability and securing analyst trust: Unsupervised-ML-based UEBA struggles to explain "why it is anomalous," so if analysts cannot trust the alerts, it will be shunned in the field no matter how accurate it is. Therefore, equipping it with an explainability function that traces back and presents the signals contributing to a risk score, together with generative-AI-based natural-language summaries to raise analysts' investigative trust, is a hidden condition of adoption success. Technology must be evaluated not only by accuracy but by adoption.

  • Architecture integration and outlook: UEBA has limited value on its own; a closed-loop response is completed only when it is integrated with SIEM, SOAR, EDR, ITDR, and IAM. Going forward, its role is expected to expand as the real-time trust-evaluation engine of Zero Trust and the center of non-human entity management. Therefore, when designing a security architecture, it is advisable to position UEBA as a common analytics layer rather than a standalone product and to select it on the premise of standard log schemas (such as OCSF) and API integration.

References

In one line: UEBA is a behavior-based security analytics technology that converts deviation from a machine-learned baseline of users' and entities' normal behavior into a risk score to detect compromised accounts and insider threats that rules cannot catch, and it is evolving into the core analytics engine of Zero Trust and ITDR.