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 A person, system, or organization that interacts with or affects a security incident. .
🔍 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.
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.
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.
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
Strong behavioral analysis is not a tool. It is four practices the methodology asks of the SOC.
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.
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