Behavioral analysis framework
On this page
The behavioral framework is the toolkit that turns a stream of events about an entity into a judgment on whether the entity is behaving normally. Pattern recognition, baselines, anomaly detection, and Subject-centric triage operating together.
How the framework fits together
The framework breaks the work into pattern recognition, baselines, anomaly detection, and Subject-centric triage. Each one is a different question the analyst is asking about the entity Entity Any discrete actor or object that evidence can attach to during an investigation: a user account, a host, a process, an IP address, a domain, a file. Triage decomposes an alert into its entities and asks what each one was doing; the same idea gives UEBA its E. .
Pattern recognition
Learn the shapes of normal for each entity type. Time, access, location, communication. The base layer of judgment.
Baseline development
Build references at the individual, group, system, and application scales. Each catches a different class of deviation.
Anomaly detection
Surface deviations from the baseline, from temporal anomalies to communication shifts.
Subject-centric triage
Apply the framework with the entity in the foreground. Not “is this unusual in the environment” but “is this unusual for this entity.”
Pattern recognition
Recognizing the shapes of normal is the base layer of every behavioral judgment that follows. These are the patterns that matter most in practice.
Time-based patterns
Users and systems follow predictable daily and weekly schedules. Executives log in during business hours. Backups and batch jobs run during defined maintenance windows. Recognizing temporal cadence is what makes off-hours activity a signal instead of noise.
Access patterns
Different roles touch systems in characteristic ways. HR pulls personnel data during review cycles. Developers commit code constantly. Administrators run privileged actions at predictable cadences tied to change windows. The shape of access reveals the role.
Location patterns
Most identities connect from a consistent set of geographic origins and network segments. Sales teams roam more than back-office staff. IT uses known VPN endpoints. The pattern is what makes a single login from an unusual place worth investigating. Read it with the confounders in mind: SASE or ZTNA egress, mobile carriers, and privacy relays move apparent location without the user moving, and residential proxies let an attacker appear to sign in from an ordinary home connection.
Communication patterns
Communication volume and channel vary by role. Executives engage broad external networks. Engineering teams use chat heavily during business hours. Sudden changes in who communicates with whom are early signals of insider activity or compromise.
Patterns shift with the business. Mergers, reorganizations, seasonal cycles, and project phases all legitimately change behavior, and a baseline that does not account for them fires noise during every quarterly close, every promotion cycle, every product launch. Adaptation is what keeps pattern recognition useful.
Baseline development
Alert’s baseline check used whatever baseline exists to test one signal. Here we look at how baselines are scoped (individual, peer, system, application), how they fail, and what to do when they disagree or don’t exist. A baseline is a reference, and each scale catches a different class of deviation. Strong Subject programs maintain all four.
Individual baselines
Per-identity history: login times, system access, communication patterns, command-line activity. Catches deviations from this entity’s norm. Most useful for high-impact identities (executives, admins, privileged service accounts).
Group baselines
Per-role or per-team expected behavior. Catches drift across an entire role, and contextualizes individual deviations by asking whether peers are doing the same thing. Distinguishes “one developer is acting strange” from “the whole team is in production for the launch.”
System baselines
Performance, usage, and network metrics for hosts and services. Critical where no human identity is in the loop: a cryptominer or implant on a server shows up as CPU, process, or network deviation long before any account looks odd. Sustained high CPU on a database during a quiet hour is worth a look.
Application baselines
Per-application interaction rates, API call volumes, response times, error patterns. Catches data exfiltration that hides as ordinary application traffic. The right baseline catches a 30% query-volume spike from one role even when total volume looks normal. AI agents get application baselines too: the tools and connectors they call, the MCP servers they reach, and the data sources they read.
Three questions of any baseline
What window is the baseline built over?
Too short and seasonal patterns get missed (finance close at end-of-month, holiday slowdowns). Too long and stale behavior dilutes the signal. Typical starting point: rolling 30 to 90 days, with explicit handling for seasonal events. Know your platform’s window and whether it rolls: a rolling window slowly absorbs whatever happens inside it.
How is the entity grouped?
An individual baseline catches deviations from this entity’s history. A peer-group baseline catches drift across the role. Both have value; both deserve their own thresholds. When the two disagree, the disagreement is the lead: it can mean a legitimately unusual job, or an individual baseline poisoned by compromise that predates the window.
What context feeds the baseline?
A baseline without context generates noise that looks like anomaly but is just business. The context sources are listed under Integrate contextual data below.
Baselines can be poisoned
Anything present before the window opened, or drifting slowly inside it, looks normal to an individual baseline. An attacker with long dwell time, or an insider who stages slowly (the behavioral staging signal on the four dimensions page), becomes part of the reference that is supposed to catch them, and living-off-the-land tradecraft aims to match baselines on purpose. Three habits counter it:
- Check the window. When did the baseline start learning, and does that overlap the suspected compromise? If it does, the intrusion may be the baseline.
- Always run the peer comparison too. When an entity matches its own history but not its peers, that disagreement is a lead, not a clearance.
- Corroborate a clearing “normal”. Before a baseline match closes a case, back it with one independent fact: a change ticket, an approved access request, or the owner’s confirmation.
Choosing peer groups
A peer comparison is only as good as the peers. Start from what the directory already knows (department, title, manager, team), and for machines from the host class or the pipeline that launched them. Prefer behavioral peers when the platform builds them: UEBA products cluster identities by what they actually access, which catches the engineer whose title says one thing and whose work says another. Three checks before trusting the comparison:
- Is the group big enough? A peer group of three is an anecdote. When the team is small, widen to the same role across teams.
- Is the entity typical of it? The on-call engineer, the team lead, or the one admin on a team of analysts is an outlier by design. Compare against the people who share the duty, not the org chart.
- Are the peers clean? If the same campaign reached the whole team, the peers agree with the attacker. A whole group drifting together is a lead of its own unless a business event explains it.
For non-human identities, peers are the other instances of the same thing: jobs from the same pipeline, pods from the same image, functions that run as the same role. The five things to baseline for automation are on the non-human identities page.
When the baseline doesn’t exist (cold start)
New hires, new hosts, newly created service accounts, a newly onboarded tenant, and a UEBA deployment still in its learning period all start with no usable history. Most SOCs also cannot query a per-entity baseline at triage speed, and the framework has to work anyway. Two rules apply.
First, the absence is itself a finding. “No historical data for this account” is worth writing down, and no history means unknown, not normal. A new or never-observed identity doing something sensitive is a different case from a known identity drifting. Cold start is an attacker’s window too: an account or service principal created during the intrusion has no history that could flag it, so a creation date inside the alert window is a lead (see creation and provisioning).
Second, fall back one scale. No individual baseline means compare against the peer group (“do other engineers on this team touch this system?”), and no peer group means compare against role expectations (“would this job ever plausibly need this?”). A rough answer from the right comparison beats a precise answer from no comparison at all. Record which scale the verdict rests on, because the Subject handoff asks for it.
Anomaly detection
With baselines in place, anomaly detection is the systematic surfacing of deviations. The same families show up over and over.
Temporal & geographic anomalies
Logins at unusual times or from unfamiliar locations. Rapid succession logins suggest automation. Impossible-travel patterns suggest credential theft. Cross-reference these with the entity’s role and historical pattern before scoring.
Pattern deviations
Uncharacteristic changes in access frequency or data transfer volume. Spikes or sudden silences without operational cause. Investigate inside the broader context of system health and known business cycles; many “anomalies” turn out to be planned activity.
Unauthorized resource use
Access to systems or data outside the role’s normal scope. Source code from an account that has never touched the repo. Customer records from a marketing tool. Even a single anomalous access into sensitive areas is worth investigation.
Credential-based anomalies
Excessive concurrent sessions. Geographically inconsistent logins from the same identity within minutes. Rapid credential resets, especially from unexpected locations, and new MFA methods or devices registered right after them. These signal account compromise or lateral movement and require fast correlation with other signals.
Communication abnormalities
Unusual recipients, attachment sizes, or messaging volume, plus new inbox rules that delete, move, or forward mail externally (T1564.008 Email Hiding Rules, T1114.003 Email Forwarding Rule). For an insider these are often the first sign of data leaving; for an external attacker in the mailbox (business email compromise), the rules are often the first persistence step.
Weight the anomaly
Two principles. First, weight anomalies by the actor’s risk profile: an unusual action from an admin account or service principal carries more weight than the same action from a standard user. Second, weight by the data at risk: anomalies that touch regulated or high-value data ( PCI PCI Payment Card Industry data. Cardholder data subject to PCI DSS handling, retention, and audit requirements. , PII PII Personally Identifiable Information. Data that identifies an individual person. US laws such as CCPA say “personal information”; GDPR regulates the broader category of “personal data”; health information held by HIPAA-covered entities is PHI. , health data, source code, secrets) raise the impact side of the rating, and regulated data plausibly accessed by the activity sends the case to Level 2 depth. A clean methodology carries both weights into the Risk phase’s impact rating instead of leaving them to ad-hoc judgment.
Subject-centric triage
The framework’s payoff. Subject-centric triage is the discipline of always evaluating an alert through the lens of the implicated entity rather than through general detection logic Detection Logic The rule, model, or heuristic that decides whether a given input fires an alert. The logic that produced the alert matters as much as the alert it produced; two engines can name the same alert for very different reasons. alone.
Alert validation
Correlate the alert against the entity’s baselines. The same alert is a malicious true positive on one identity and a benign true positive (correctly detected, authorized activity) on another when the baselines say so. Subject-centric validation can cut the false-positive rate and clears expected activity faster, provided the baseline itself is trustworthy.
Insider threat detection
Subtle deviations around context the insider-risk program has shared (a role change, a resignation notice) or staging behavior often surface here. Pattern-based alerts often miss this; entity-based comparison surfaces it. Analysts compare observable technical activity; HR-held context reaches the case only through the insider-risk route, never as analyst-collected notes.
Escalation support
The entity’s role and access shape the priority Risk assigns and the route the escalation decision takes. Privileged identities always fail the Level 0 eligibility gate and get Level 2 depth, and high-value identities escalate to different on-call roles. Subject-centric triage encodes that into the workflow rather than relying on individual judgment.
Response tailoring
The depth of follow-up is bounded by the entity’s behavioral risk profile. A clean baseline + a low-risk action gets less time. A clean baseline + a high-risk action gets more. The methodology spends investigator effort where it has the most return.
Event reconstruction
Behavioral timelines per entity become the spine of any post-incident write-up. Subject-centric triage produces those timelines as a byproduct of the work, which makes Documentation faster downstream.
A worked example of Subject-centric triage
An alert fires: a developer account ran a database export at 22:30. Generic anomaly detection (environment-wide) might tune this out: developers query the database routinely, late-evening work happens, the export volume is within thresholds.
Subject-centric triage zooms in:
- This developer’s baseline shows they have never queried this specific database before.
- This developer’s historical working hours are 09:00 to 18:00. The 22:30 timing is four and a half hours past the end of their normal window.
- This developer’s other recent activity: two days earlier, they requested and self-approved read access to the production replica.
- The peer group (other developers on the same team) shows no parallel activity. This is one developer doing something unusual on their own.
- Before treating it as malicious: no change ticket, no on-call page, no manager approval on file. The benign explanations were checked and failed (the cognitive traps page explains why this step is not optional).
Each individual signal is below the environment-wide threshold. The combination, in the context of this specific entity, is a strong Subject-level anomaly. That is what Subject-centric triage adds.
Implementing behavioral analysis
This section changes altitude. Pattern recognition, reading anomalies against a baseline, and Subject-centric triage are analyst work; building the baselines, setting the scoring weights, and the practices below are what the SOC’s program provides so that work is possible. They are here for two readers. The analyst should recognize which practices their environment actually has, because each missing one is a known limit on what a behavioral claim can prove. The team lead or program designer should treat them as the build list.
Capture broad telemetry
Authentication events, system access, application interactions, network flows. The more dimensions captured, the more deviations the framework can find. Gaps in coverage are gaps in detection.
Integrate contextual data
HR records for role context. Business calendars for legitimate off-hours. Project assignments and change tickets for planned activity. Without context, the framework fires noise during every legitimate organizational change.
Adapt continuously
Analyst feedback feeds the framework. Closes recorded as false positive (logic) or false positive (data) tune the detection. Confirmed-benign changes update the baseline; confirmed attack patterns become new detections, never new baseline. A behavioral system that is not learning is decaying.
Respect privacy
Per-entity behavior modeling has implications beyond security. Coordinate with legal, HR, and works councils where relevant. Data minimization, role-based access to the analytics, encryption at rest. The framework’s value depends on trust. See the guardrails below.
Privacy and legal guardrails for per-employee modeling
Analysts record observable technical activity. HR-held context reaches the case only through the insider-risk route, and never as analyst-collected notes. Before the program models individual employees:
- Run a data protection impact assessment. In the EU, systematic monitoring of employees generally needs a DPIA under GDPR Art. 35, and many jurisdictions require notice that monitoring takes place.
- Have legal classify the tooling before it is deployed. In the EU, AI that monitors or evaluates employee behavior can be a high-risk system under the AI Act (Annex III, point 4(b); profiling keeps it high-risk; obligations apply from December 2027 on the current timeline), and AI that infers employees’ emotions has been prohibited since February 2025 except for medical or safety reasons.
- Keep inference to behavior, not state of mind. The framework compares what an identity did against what it normally does. It does not guess at how a person feels.
Tooling versus methodology
UEBA capabilities ( Microsoft Sentinel Microsoft Sentinel Microsoft's cloud SIEM/SOAR (formerly Azure Sentinel), built on Log Analytics and queried with KQL; playbooks run on Azure Logic Apps. Built-in UEBA and an optional lower-cost data lake tier. Now runs in the unified Microsoft Defender portal; Azure portal support ends 31 March 2027. UEBA, Exabeam Exabeam SIEM and user and entity behavior analytics (UEBA) vendor: risk-scored user and entity timelines and automated investigation. Merged with LogRhythm in July 2024; sells the cloud New-Scale platform and the self-hosted LogRhythm SIEM. , Securonix, and UEBA in Splunk Enterprise Security Premier, which replaces the standalone Splunk UBA product) automate much of the framework’s mechanics once data sources are connected and baselines have had time to learn. Several now baseline AI agents as well as people. Identity threat detection and response (ITDR) tools such as Microsoft Entra ID Protection and Defender for Identity cover the identity slice directly, and attack-path tools such as BloodHound CE precompute what an identity can reach. SIEMs can do the same work with custom rules but at higher operational cost. The tool matters less than the discipline of capturing data, integrating context, and learning from feedback. A SOC with no UEBA product but strong baselines often outperforms a SOC with the tool but no methodology around it.
Key takeaway
The behavioral framework is the difference between “an alert fired” and “this specific entity is doing something this specific entity does not normally do.” The second is far more useful, and it is what Subject is designed to surface. Pattern recognition, baseline development, anomaly detection, and Subject-centric triage together produce that second statement reliably.
Next up
Insider analysis
The special case. Risk vs. threat, the Insider Threat Matrix, and the patterns that come from the inside.
Read insider analysisTechnical details verified . Product names, defaults and retention change; check your own tenant.