Entity boundaries
On this page
Subject produced a map of identities. Entity boundaries decide which of those identities are formally in the investigation, which are watched but not investigated, and which are out of scope until a new signal pulls them in.
Primary vs. secondary
Subject hands Scope a provisional classification of its 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. map. Scope’s first call is to confirm or revise it against the evidence and make it binding: who gets full depth, who gets baseline depth, who is placed but not investigated, and who is explicitly out. That split is what keeps investigation depth proportional to evidence instead of spending equal time on every identity in the graph.
Entities directly implicated by the alert. The user whose account activity triggered the alert. The host that produced the telemetry. The service account that authenticated the action. The cloud resource the action targeted. Other credentials of the same principal are primary too, even when the alert never names them: the user’s federated cloud identity, for example, because a compromise running as the user can carry over to it. Primary entities receive full investigation depth: every dimension, every available data source, the full historical window the threat type warrants.
Entities connected to the primary set but not directly named in the alert. Peer accounts that share a trust path. Systems the primary entities have access to. Parent services that issued credentials. Secondary entities receive baseline-comparison depth: are they behaving normally? They are investigated more thoroughly only if a primary investigation surfaces them.
Why this split matters
A SOC that treats every connected identity as primary spends six hours on one alert. A SOC that only investigates the named identity misses the lateral movement Lateral Movement Moving from the initial foothold to other hosts, identities or tenants to find sensitive data or reach higher-value targets (ATT&CK tactic TA0008). It usually rides legitimate remote-access protocols (RDP, SMB, WinRM, SSH) with stolen credentials, or replays a stolen session into a cloud or SaaS tenant, so the signal is an account authenticating where it does not normally go. Each hop widens the blast radius, and confirmed lateral movement is an escalation criterion. . The two-tier split is the methodology’s answer: deep on what the alert touched directly, baseline-only on what is connected, with explicit upgrade criteria.
Upgrade a secondary to primary when any of these holds, and record which criterion fired:
- It shows an anomaly in any of Subject’s four dimensions inside the window.
- An indicator from a primary entity (hash, domain, session, token) appears on it.
- It authenticated from a primary host or session.
- Its credentials or keys were reachable from a compromised primary (cached tickets, hardcoded secrets).
- It is a high-value entity with any contact from the primary set.
One identity rule overrides the depth split: any user who reached the credential step of a phishing kit is credential-exposed until the password is reset, sessions are revoked and MFA methods are reviewed. Treat that user as primary, whatever the alert named.
Subject’s map may also carry a third ring: downstream systems the compromised identities can reach but that show no activity yet. Downstream entities do not get an investigation tier of their own; they get placed. Write them into the boundary as reachable, pin their logs to the infrastructure check, and name the signal that would promote them to secondary or primary. Leaving them off the boundary statement is how a federated platform or a connected CRM silently falls out of the case.
The worked examples use a few more categories. The rings below show how they nest; the table after them is the same set in text form.
| Category | What qualifies | Depth | Promotion signal |
|---|---|---|---|
| Primary | Directly implicated by the alert or the evidence: the actor, the host, the credential, the target | Full: every dimension, every source, the full window | Not applicable |
| Secondary (immediate, mid, distal) | Connected to the primary set by management, trust or shared infrastructure | Baseline comparison; distal ones often watched only | Any upgrade criterion below |
| Downstream | Reachable by in-scope identities, no activity seen yet | Placed: named in the boundary, logs pinned | First sign of access from an in-scope identity |
| Originating threat | Adversary-side infrastructure: sender, domain, IP, C2 | Enrichment only; feeds threat intelligence | Not applicable (never investigated as an internal entity) |
| Sweep query | A bounded tenant-wide or fleet-wide question, such as “who else received this message?” | One query with a written stop condition | Each hit becomes a secondary or primary entity |
| Out of scope | Named and deliberately excluded | None | A written re-entry trigger |
Primary entities by type
Primary entities require immediate, rigorous scrutiny. They are the foundation for everything Uncover will do, and capturing volatile or early-stage evidence depends on getting their scoping right at this moment. Four common categories cover most cases.
User accounts
Often the initial access vector via credential theft or phishing. Once inside, attackers use the account to escalate and move laterally.
- Analyze authentication patterns: geolocation, time anomalies, login spikes.
- Review group membership changes, role escalations, MFA resets.
- Review sessions and tokens: reuse from new ASNs or devices, OAuth consent grants, new MFA methods, mailbox rules.
- Correlate access attempts with sensitive resource interactions.
Endpoints
Execution platforms for malware, persistence mechanisms, and attacker tooling. Often hold key forensic artifacts that reveal intrusion methods.
- Examine process trees and parent-child anomalies.
- Inspect persistence locations: Windows Run/RunOnce keys, Startup folder, services, scheduled tasks, WMI event subscriptions; macOS LaunchAgents/LaunchDaemons and login items; Linux cron, systemd units, shell profiles.
- Investigate use of remote execution tools (PowerShell remoting, PsExec).
- Check for unauthorized services, scheduled tasks, local admin creation.
- Analyze outbound traffic and DNS queries for C2 activity.
Cloud resources
Common target for privilege escalation, data access, and persistence via misconfigurations or stolen credentials. Abnormal API usage is often the first sign.
- Investigate IAM changes: user/role creation, key usage, permission escalation.
- Audit bucket and compute resource policies for unauthorized changes.
- Review AWS CloudTrail AWS CloudTrail Records API activity in an AWS account: the audit trail for security and forensic work. Management events are on by default (90 days in Event history); data events such as S3 object reads and Lambda invokes must be enabled on a trail or event data store. (management events by default; S3 object-level and Lambda data events only if enabled), the Azure Activity Log plus Entra ID sign-in and audit logs and the M365 unified audit log, and GCP Cloud Audit Logs (Data Access logs are off by default for most services). Record any log that was never enabled as a visibility gap.
- Monitor for exfiltration via storage, automation misuse, or unusual geographies.
Applications
Compromised via vulnerabilities, misconfigured APIs, or weak authentication. Often act as pivot points to backend systems and data.
- Examine logs for injection attempts, RCE indicators, auth bypasses.
- Audit admin interface activity and role/permission changes.
- Review session tokens and API key behavior.
- Correlate frontend activity with backend database or storage access.
High-value categories
Any entity in scope (primary, secondary or downstream) that falls into one of these categories gets elevated attention from the moment it appears: a high-value secondary is monitored in real time and upgraded on any anomaly. The three categories are kinds, not a ranking.
Identity and control-plane infrastructure
Domain controllers, cloud control planes (AWS Organizations management account), security vaults (HashiCorp Vault instances, Azure Key Vault). Compromise here has organization-wide blast radius Blast Radius The set of systems, identities, and data an incident can plausibly reach from its current foothold: everything the compromised entity can touch, authenticate to, or influence. Scope draws boundaries around it, lateral movement grows it, and containment exists to stop it growing. . Microsoft’s legacy AD tier model called this Tier 0 (now the control plane); it is not the same as Subject’s Restricted sensitivity class, which is about the data an asset holds.
Revenue and operations systems
Finance applications (SAP, payment gateways), HR platforms (Workday, ADP), healthcare systems (Epic EHR, PACS servers). Direct impact on business operations and regulated data.
Administrative identities
Enterprise and Domain Admins, Entra Global and Privileged Role Administrators, cloud roles with iam:* or equivalent, break-glass accounts Break-glass Account An emergency-access account kept outside normal sign-in controls (often excluded from MFA or Conditional Access, with its credentials sealed) for use when the normal admin path is broken. Because it bypasses controls, every sign-in should alert, and one that no declared emergency explains is treated as a privileged-identity compromise until shown otherwise. Not the escalation tripwire, which was formerly called the break-glass rule. , CI/CD deploy identities, and database sysadmin accounts (SQL Server sa). Any identity that can administer a control-plane system belongs to the control plane itself: treat its compromise as a compromise of every system it controls. Privileged identities always fail the Level 0 eligibility gate and route to Level 2 on the depth ladder.
Scope evolution: the decision tree
Entity scope is not a one-time decision. It evolves as evidence develops. The evolution should follow a structured, documented pattern.
Compromised workstation accessed shared file drive \\fileserver\finance\
Incorporate fileserver into scope. Pull access logs, file modification history, share-permission changes.
User authenticated to VPN inside the case window (from the first suspected activity onward)
Examine MFA logs and add VPN concentrators to scope. Validate session origin, device fingerprint, and concurrent-session behavior.
PowerShell remoting was used to or from the endpoint (wsmprovhost.exe on the target, WinRM/Operational connection events, 4624 type 3 logons from the source host)
Include WinRM configuration, the WinRM/Operational log, and PowerShell script-block and module logging (4104/4103: Microsoft-Windows-PowerShell/Operational for Windows PowerShell 5.1, PowerShellCore/Operational for PowerShell 7) alongside 4688 process-creation events. Look for cross-host script invocation. Confirm script-block logging and 4688 command-line capture were actually enabled (see command-line parsing); if not, record an infrastructure gap.
Service account assumed a cloud role during the relevant window
Add the cloud role and all resources it can touch to scope. Review STS AssumeRole call patterns against the role’s normal usage.
Document each scope addition
Every entity added to scope after the initial decision should carry three lines of documentation:
- The evidence linking it in. e.g., “PowerShell script executed at 2024-03-14T15:32:27Z connecting to internal Jenkins server 10.45.67.89.”
- The risk assessment. e.g., “Jenkins server has pipeline access to production Kubernetes clusters; supply-chain compromise risk.”
- The required actions. e.g., “(1) Flag for volatile-evidence capture (AVML or LiME on Linux, WinPmem on Windows, analyzed later in Volatility 3) per the acquisition playbook, before any containment that would reboot the host; (2) review RBAC permissions; (3) validate build-artifact SHA-256 checksums.”
This documentation is what makes the scope expansion defensible later.
Re-scoping both ways
Expansion follows the decision tree. Contraction follows evidence too: when an entity’s four-dimension read and the indicator sweep come back clean, demote it to watched or out of scope with one line of justification. Re-scope whenever Uncover or Risk surfaces a new entity, a new window, or a new regulated data class. Version the boundary statement (v1, v2…) so the record shows what was in scope when each conclusion was drawn.
Secondary entities: three modeling techniques
Secondary entities are not in the alert. They get into scope through analysis of the operational topology and identity fabric. Three techniques surface them in a structured way.
Relationship mapping
Document technical trust relationships: Active Directory two-way trusts, privileged service accounts with elevated access, AWS cross-account roles, Kubernetes service-account tokens. These reveal potential compromise paths the alert did not directly name.
Access modeling
Identify every identity with access to the compromised resources during the relevant timeframe: contractors with SSO access, DevOps engineers with privileged cloud roles, recently terminated employees with lingering credentials. The access model is the immediate-blast-radius estimate.
Dependency tracing
Analyze data flows and credential pathways: automated synchronization jobs, cached authentication tickets, cross-account access mechanisms, hardcoded API credentials. Dependencies turn a single compromised identity into a network of potentially affected systems.
Prioritizing secondary entities during triage
Not every secondary entity deserves equal attention. Assess each one against proximity and likely adversary goals:
- Immediate-priority secondaries. Direct management, authentication, or automation ties to a compromised entity. (A service account that authenticates against the same identity provider Identity Provider (IdP) The service that authenticates users and issues the tokens or assertions other applications trust: Microsoft Entra ID, Okta, Google Workspace, Ping. Its sign-in and audit logs are first-class evidence in identity, SaaS and cloud cases, and an IdP compromise reaches every federated app. See Federation and Single Sign-On (SSO). . A peer in the same AD security group.)
- Mid-priority secondaries. Trust relationships that bridge to higher-value systems. (Cross-account IAM roles. Federated SAML trusts. Shared service principals.)
- Distal secondaries. Shared infrastructure Infrastructure The systems, networks, and services that computing runs on. In triage the word points two directions: the organization's infrastructure is what alerts fire on, and attacker infrastructure is the set of C2 servers, domains, and staging hosts an adversary operates, which pivoting on indicators is meant to map. nodes or vendor-managed services. Assess based on exposure level, credential 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. reuse, and control boundaries. Often watched, not investigated, unless a closer signal pulls them in.
Documenting this tiering keeps Uncover from spreading effort evenly across a long list and instead drives focused work where the methodology says the risk lives.
Containment and the entity scope
Scope does not decide containment. Authority comes from the written list of pre-authorized actions (containment authority), and evidence comes first (preserve before you contain). Scope answers one question for whoever acts: what breaks if this entity is cut off? Record the answer in the scope note so the Escalation decision weighs business collateral alongside the threat. Weigh three risks, not one: business collateral, evidence loss, and tipping off an active adversary (run the tip-off check).
Host isolation
List what the host serves: scheduled jobs, shared services, real-time workloads. Isolating it stops the compromise and every one of those.
Account disable
List what authenticates as the account: automation pipelines, sync jobs, production deployments. Name the owner who can say what a disable would break. For identities, order matters: run the identity-persistence sweep before the reset, so grants, rules and registered methods are on record before anyone removes them. Revoke sessions and refresh tokens as well, because a password reset alone does not end a stolen session; the reset itself needs IR or owner approval.
Credential rotation and network blocks are usually IR’s call; the scope note only needs to say which consumers share the key or which legitimate services share the indicator.
Key takeaway
Entity scope is the difference between “investigate the user” and “investigate the user, the three accounts that authenticate as them, the four systems those credentials access, and the two cloud roles those systems can assume.” The second is far more useful, and Scope is the phase that draws the lines, tiers them, and documents the evidence that justifies each addition.
Next up
Asset and user criticality
Which entities matter most if the activity is real: asset tiers, privileged and dormant identities, and how the weighting orders the work.
Read criticalityTechnical details verified . Product names, defaults and retention change; check your own tenant.