The four dimensions of Subject analysis
How the dimensions work together
The four dimensions are independent questions about the same Entity A person, system, or organization that interacts with or affects a security incident. . Authentication asks how the entity got in. Authorization asks what the entity is allowed to do. Behavior asks what the entity is actually doing. Relationships ask what the entity is connected to.
When all four agree (authenticated normally, acted within its permissions, in line with its history, with relationships that match the role), the Subject assessment passes quickly. When even one disagrees, the disagreement is the lead.
🔐 Authentication
The first dimension evaluates how the entity proved who it was. The job is not to assume the Credential Whatever the system accepts as proof of identity: a password, an API key, an OAuth token, a Kerberos ticket, an NTLM hash. Credentials are the highest-value loot in most intrusions; their theft is usually the pivot point. was used legitimately. The job is to evaluate the credentials themselves and the context they were used in.
Detect anomalies
Compare login data, geolocation, and device fingerprints to historical norms. Impossible-travel patterns (a login from two cities 1000 miles apart within 30 minutes), brand-new devices, or sources from anonymizing services are first-pass signals.
Validate identity
Cross-reference the account against HR records, identity provider data, and role definitions. A login from an account that has not been provisioned (or that was supposed to be off-boarded last week) is its own story.
Investigate the session
Map the authentication path: source IP, intermediate identity providers, MFA Multi-factor authentication. A login that required something beyond a password, typically a one-time code, an authenticator app prompt, a security key, or a biometric. MFA materially raises the cost of credential theft, but it can be defeated by phishing, MFA fatigue, or token replay. outcome, session tokens issued. Anomalies in any of these reshape the verdict.
Eight investigative techniques
The dimension breaks down into eight techniques an analyst applies in roughly this order. Each one is a different question about the same authentication event.
Geolocation & device analysis
Evaluate logins for access from unfamiliar locations or devices not typically associated with the user. Outliers in geography or device history often signal credential misuse.
Login patterns review
Investigate spikes in failed logins or rapid successions of attempts, especially when followed by a successful login. These patterns often indicate brute force or password-spraying efforts.
Network source inspection
Identify logins from anonymizing services, Tor exit nodes, or known hostile infrastructure. Frequent source IP changes often point to evasion tactics or compromised hosts.
MITRE mapping
Align observed authentication behaviors with MITRE ATT&CK A public knowledge base of adversary tactics and techniques observed in real-world attacks. Each technique has a stable ID (e.g., T1110 for Brute Force) that gives analysts shared vocabulary. attack.mitre.org . Situating an anomaly within a known threat framework gives investigators vocabulary for what they are seeing.
Identity change correlation
Check recent changes to user roles or access levels when investigating anomalies. Unauthorized activity shortly after promotions, transfers, or off-boarding often reflects privilege misuse or insider risk.
Session behavior review
Look for unusually long sessions or token reuse across locations. These behaviors often indicate hijacked sessions or token abuse following credential compromise.
SSO movement detection
Monitor federated login flows for lateral movement. Unauthorized access to additional systems via SSO can reveal deeper compromise and privilege escalation across federated identities.
MFA event auditing
Review authentication prompts for signs of excessive challenges, fallback method use, or repeated failures. These anomalies may indicate phishing, MFA fatigue, or bypass attempts.
Cloud-identity patterns you’ll see in 2024+
Modern intrusions disproportionately route through identity-provider abuse rather than endpoint compromise. The four patterns below dominate Microsoft Entra ID, Okta, and Google Workspace incidents you’ll triage today:
🔑 OAuth consent-grant abuse
The attacker registers a malicious application and tricks a user into granting it OAuth permissions (often Mail.Read, Files.ReadWrite, offline_access). No password is stolen; the consent itself is the foothold. Detect via consent-grant audit events with unusual app publishers, broad scopes, or recent app-registration ages. Maps to T1528 Steal Application Access Token.
🎫 Token replay / forged tokens
An attacker presents a stolen or forged bearer/refresh token to bypass primary authentication and MFA. The token may be lifted from a compromised endpoint, stolen via AiTM phishing, or forged using a stolen signing key (the Storm-0558 pattern). Detect via token-binding anomalies, unusual aud claims, sign-ins with no associated interactive login, and refresh-token usage from new locations. Maps to T1550.001 Application Access Token.
🌍 Impossible travel
A sign-in from a geographic location the user could not have physically reached given the time since their previous sign-in. Provider-side risk detections (Entra ID Identity Protection, Okta ThreatInsight) score this directly. Treat as a strong but not conclusive signal, VPN, mobile-carrier routing, and travel-while-active can produce false-positives. Maps to T1078.004 Valid Accounts: Cloud Accounts.
📲 Device-code / phishing-resistant-MFA bypass
The OAuth 2.0 device-authorization flow is exploited by attackers prompting the user to “enter this code on your other device” while the attacker’s device receives the token. Adversary-in-the-middle (AiTM) toolkits (EvilProxy, Tycoon) sit between user and IdP, capturing session cookies after legitimate MFA. Detect via unusual device-code grants, new-device sign-ins right after MFA succeeds, and session-cookie use from IPs the user never authenticated from. Maps to T1621 MFA Request Generation and T1539 Steal Web Session Cookie.
🔓 Authorization
Authorization asks whether the action the entity took was permitted, and whether the permissions themselves are appropriate.
The dimension is easy to under-evaluate. An action that maps cleanly to the user’s role looks fine in a glance. The deeper question is whether the role grants too much, or whether the role was modified recently to permit this exact action.
Permission mapping
Define expected access via a centralized RBAC Role-Based Access Control. A model where permissions are granted to roles rather than to individual users, and users inherit permissions by being assigned roles. RBAC makes access reviewable at the role level rather than per-user. matrix. Periodic entitlement reviews confirm each role still matches its function.
Privilege management
During triage, evaluate whether the entity’s actions exceed its assigned privilege level. Look for elevation, excessive grants, or chained permissions that effectively make the role admin.
Toxic access pairings
Two permissions that are reasonable individually but dangerous together. The classic finance case: someone with both “approve invoice” and “modify vendor bank account.” Each is normal in a role; the combination is fraud risk.
Administrative oversight
Flag administrative activity that happens outside approved change windows. Investigate shared account use or service accounts performing interactive actions; both indicate a workflow that did not follow policy.
📊 Behavior
The behavior dimension compares current activity to the entity’s historical norm. Subject borrows the techniques covered in the Alert chapter’s validation strategies, but applies them with deeper context: not “is this unusual in the environment” but “is this unusual for this specific identity.”
Baseline comparison
What does this entity normally do? When? With whom? Sudden access to unfamiliar sensitive systems, operating outside normal hours, or repeating tasks at unusual cadence are all baseline deviations worth investigating.
Privilege misuse
Actions that suggest elevation or misuse of existing permissions. The entity is allowed to do this, but the way they are doing it (volume, target, timing) is inconsistent with the role’s intent.
Access scope drift
Gradual expansion into new systems, tools, or data categories outside the entity’s historical norm. Each step alone looks like onboarding. The trajectory is the signal.
Behavioral staging
Methodical but slow deviations: low-risk systems explored before high-value ones, file collection before exfiltration. Each step normalizes the next.
🌐 Relationships
The relationships dimension maps the connections between the entity and other identities, systems, and data. Compromise rarely lives in One Identity IGA with lifecycle, RBAC, privileged access governance; unifies AD, Azure AD, and cloud platform identity. . It lives in the graph the identity participates in.
Four steps of relationship mapping
Relationship Mapping The process of identifying and visualizing connections between entities like users, systems, or processes. is its own small methodology. Four steps, applied in order, turn raw connections into a triage-usable graph.
Analyze connections
Build a detailed map of relationships between users, systems, and data by linking identities and entities. This baseline captures normal communication and access patterns essential for spotting deviations later.
Identify deviations
Compare current interactions against peer groups and typical workflows to find unauthorized or unusual access attempts. Early detection of these anomalies prioritizes investigation and reduces overall risk.
Measure changes
Monitor changes in communication frequency and volume to identify subtle shifts in behavior. Sudden variations may indicate reconnaissance, insider activity, or preparation for an attack.
Analyze sequences
Study the timing and order of activities to uncover coordinated actions signaling lateral movement or staged attacks. Recognizing these temporal patterns helps connect isolated alerts into a wider incident.
Example: how relationships expose lateral movement
A finance team user authenticates from their laptop at 09:14. Normal. The laptop then authenticates against a Domain Controller A server that responds to security authentication requests in a Windows domain environment. at 09:16. Normal for a typical workday. The domain controller authentication is followed at 09:18 by a successful logon from the same host to a developer’s workstation. That is the signal. The finance user’s identity touched a workstation that the user has never interacted with before, and that workstation is in a different department.
Single-entity analysis would have closed this at the laptop. Relationship mapping is what extends the question into “what else does this identity now reach?”
Next up
Entity types
Every kind of identity has its own analysis pattern. Users, endpoints, applications, services, network identifiers.
Read entity types