Behavioral analysis framework
Four working pieces
The framework breaks the work into four operating pieces. Each one is a different question the analyst is asking about the 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.
02📈 Baseline development
Build references at four scales: individual, group, system, application. Each catches a different class of deviation.
03⚠️ Anomaly detection
Surface deviations from the baseline. Five families, from temporal anomalies to communication shifts.
04🎯 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. Four patterns 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.
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.
Pattern recognition is dynamic
Patterns shift with the business. Mergers, reorganizations, seasonal cycles, and project phases all legitimately change behavior. A baseline that does not account for these will fire noise during every quarterly close, every promotion cycle, every product launch. Adaptation is what keeps pattern recognition useful.
Baseline development
A baseline is a reference. Four scales of reference matter, and each 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 for finding compromised infrastructure where the user-level signal is hidden by the system-level activity. 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.
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.
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.
What enrichment feeds the baseline?
HR data for role context. Business calendars for legitimate off-hours. Change management tickets for planned activity. A baseline without context generates noise that looks like anomaly but is just business.
When the baseline doesn't exist
Most SOCs 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, because a new or never-observed identity doing something sensitive is a different case from a known identity drifting. 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.
Anomaly detection
With baselines in place, anomaly detection is the systematic surfacing of deviations. Five 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. These signal account compromise or lateral movement and require fast correlation with other signals.
📤 Communication abnormalities
Unusual email recipients, unexpected attachment sizes, messaging volumes well outside baseline. These are often the earliest external signals of insider data movement and the latest signals of an external compromise that has reached the email environment.
Risk-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 data ( PCI Payment Card Industry data. Cardholder data subject to PCI DSS handling, retention, and audit requirements. , PII Personally Identifiable Information. Data that identifies an individual person, regulated under GDPR, CCPA, HIPAA where health-related, and similar regimes. , source code, secrets) automatically escalate severity. A clean methodology bakes both weights into the scoring 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 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 true positive on one identity and false-positive on another when the baselines say so. Subject-centric validation reduces false-positive rate without losing real signal.
Insider threat detection
Subtle behavioral deviations that match an identity’s known patterns of frustration, role change, or staging often surface here. Pattern-based alerts will miss this; entity-based comparison surfaces it.
Escalation support
The entity’s role and access drive escalation. Alerts on privileged or high-value identities escalate faster and 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 hours outside their normal window.
- This developer’s other recent activity includes account permission changes that look like preparation.
- The peer group (other developers on the same team) shows no parallel activity. This is one developer doing something unusual on their own.
Each individual signal is below the environment-wide threshold. The combination, in the context of this specific entity, is a high-confidence Subject-level anomaly. That is what Subject-centric triage adds.
Implementing behavioral analysis
This section changes altitude: everything above is what the analyst does during triage; the four practices below are what the SOC’s program builds 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. Marked false-positives recalibrate thresholds. New attack patterns become new baselines. 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.
Tooling vs. methodology
UEBA platforms ( Microsoft Sentinel Cloud-native SIEM/SOAR (formerly Azure Sentinel); AI-driven analytics across on-prem, cloud, and hybrid with rich connector library, plus a built-in UEBA module for user and entity behavior analytics. , Exabeam Next-gen SIEM with built-in UEBA; user-behavior timelines and automated investigation workflows. , Securonix and others) handle the framework’s mechanics out of the box. SIEMs can do it 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 are the four pieces that produce that second statement reliably.
Next up
Insider analysis
The fourth pillar. Risk vs. threat, the Insider Threat Matrix, and the patterns that come from the inside.
Read insider analysis