Infrastructure boundaries
Four common boundary types
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. boundaries are guardrails, not obstacles. They prevent triage from expanding into irrelevant environments, reduce noise from unrelated Telemetry Collection and transmission of security-relevant data from remote sources for monitoring and analysis. , and preserve analyst focus on the systems most likely to yield actionable data.
🌐 Network segmentation
Subnets, VLANs, firewall zones, and DMZs define logical containment zones. If a host is restricted to a specific VLAN with no routing to external zones, adjacent systems can often be ruled out of scope unless evidence suggests segmentation failure.
🏛️ System domains
Active Directory forests, Entra ID (formerly Azure AD) tenants, LDAP hierarchies. These create structural separation in authentication and policy enforcement. Recognizing domain boundaries prevents premature attribution of behavior across unrelated trust zones.
☁️ Deployment environments
Cloud workloads, on-premises systems, SaaS platforms. Each operates under distinct access, tooling, and forensic constraints. Recognizing which segments belong to which infrastructure class tailors the scope to environments with proper visibility and operational control.
🌍 Geographic and sovereignty
Data residency rules can prevent moving log data across regions. An investigation may need to be conducted in-region or by a regional team. Multinational organizations often face conflicting jurisdictions in the same case.
Boundaries as guardrails
A clear boundary definition is foundational to investigative discipline. Network Segmentation The division of a network into smaller, isolated segments to improve security and reduce the attack surface. defines where the investigation should and should not extend. Identity boundaries prevent chasing misleading indicators across unrelated trust zones. Deployment environment recognition prevents wasted effort on platforms outside the SOC’s jurisdiction.
Access patterns
Access patterns define how identities interact with systems and resources across the environment. Within Scope, access patterns are not evaluated for anomalies. They are cataloged to understand the structural flow of authentication and authorization. This contextual map sets investigative boundaries, identifies choke points, and prevents drift into unrelated identity ecosystems.
Authentication frameworks
SSO platforms, federated identity brokers, Kerberos-based systems. These determine where authentication events originate and how access is validated. Scope identifies which authentication systems were active during the event window and what logging sources are available; without that mapping, investigations risk extending into environments sharing no credential surface with the subject.
Authorization structures
RBAC Role-Based Access Control. Permissions granted to roles rather than individual users; users inherit access through role assignment. The model makes access reviewable at the role level instead of per-user. , ABAC, MAC. These impose constraints on what authenticated identities can do and where. Scope accounts for these limitations so the investigation does not over-triage actions that policy would have denied. An authenticated account without write permissions can be excluded from write-only investigations.
Trust relationships
Domain trusts, delegated permissions, service principal access, token exchange. These bridge identity across boundaries. Documenting them distinguishes where access naturally extends from where escalation or impersonation would be required. Misinterpreting trust lines is the classic mis-scoping mistake.
An example of using access patterns to bound scope
An alert fires on an account in a Workday-federated SSO context. The implicated User The identity behind activity on a system: the account that authenticated, launched the process, or received the email. In triage the user field names an account, not necessarily a person; whether the legitimate owner was actually behind the activity is exactly the question stolen credentials raise. normally authenticates against the corporate AD via SSO.
Without access-pattern mapping, an analyst might investigate every system the user could theoretically reach via SSO including downstream SaaS apps. That can be hundreds of systems.
With access-pattern mapping, Scope confirms:
- The user’s SSO entitlements limit Federation Linking identity across independent systems or organizations so that a trusted identity provider authenticates users on behalf of services it does not operate, typically via SAML or OIDC. Matters in triage because every relying service delegates authentication to the identity provider: a compromise there, such as a stolen signing key used to forge assertions (Golden SAML), can mint access to any federated service. to four specific SaaS apps.
- Two of those apps had no activity in the relevant window per the IdP logs.
- The other two are in scope; the rest are out.
The investigation goes from “hundreds of possible targets” to “two confirmed accessed targets.” That precision is what access patterns buy.
Tools as boundaries
Tooling is part of the infrastructure picture. Before Parsing Breaking a raw alert, log line, or command string into its component fields so each can be examined on its own: the user, the host, the action, the time. In triage, parsing the alert is the first move; the details that decide a verdict live in the fields, not in the alert name. a single Log A timestamped record of an event emitted by a system, application, or security control. Logs are the raw evidence of triage: the alert points at a moment in time, and the surrounding log entries are how the analyst reconstructs what actually happened. or reviewing alerts, analysts must inventory their tooling landscape to establish visibility coverage, identify data gaps, and recognize the fixed investigative boundaries each platform imposes. Tools define the mechanisms, not the actions.
Scope does not need the tool-by-tool catalog; that lives in Uncover’s tooling page, fourteen families with what each brings and where each is blind, and Uncover selects from it once the visibility map is drawn. What Scope needs is the answer to three questions for the tools this case will actually touch.
Coverage: which entities does it see?
The EDR sees managed endpoints, not the OT segment or the unmanaged BYOD phone. Network sensors see what crosses their taps. CSPM sees the cloud accounts it is enrolled in. Any in-scope entity with no tool watching it is a named gap, not an assumption of quiet.
Retention: how far back can it answer?
SIEM retention is capacity-bounded, endpoint Telemetry Collection and transmission of security-relevant data from remote sources for monitoring and analysis. often keeps days to weeks, and SaaS audit history is gated by license tier. If the Scope time window extends past a tool’s retention, that stretch of the window is dark and the scope document says so.
Retrieval: can it be queried inside the triage clock?
Packet capture may exist but take hours to pull. Disk forensics is retrospective and resource-intensive. Vendor-side SaaS logs need a request channel measured in days. A source that cannot answer within the triage window is a boundary for this phase even if the data exists somewhere.
Tools as boundary, not as scope
A platform that does not collect session data from unmanaged devices marks a hard edge in scoping. No assumptions extend beyond it. The Scope output names the tools available, what each one sees, and where each one’s vision ends. Uncover then queries within those bounds rather than chasing questions the tooling cannot answer.
Naming what is invisible
A useful Scope output is an explicit list of what the SOC cannot see for this case.
📱 Off-network mobile devices
Activity that happens when the device is off-corporate-network may be invisible until the device reconnects. MAM telemetry helps, but not all activity reaches it.
💼 Personal devices in BYOD
Often only see authentication events, not deeper telemetry. App-level activity, file access, and clipboard behavior live outside corporate visibility.
🔌 Third-party SaaS without integrated logging
The SOC sees the authentication; the in-app activity is in the vendor’s logs. Deeper investigation requires a vendor request and (usually) a contractual or legal channel.
🚪 Air-gapped systems
May produce no telemetry that reaches the SIEM at all. Investigation requires direct system access, often with physical or operational constraints.
🔒 Encrypted traffic without decryption
TLS metadata (timing, volume, JA3 fingerprint) is visible; payload content is not. C2 channels riding on legitimate TLS look like other TLS unless inspection is positioned upstream.
🪨 Legacy systems without modern agents
Mainframes, OT/ICS, embedded systems often cannot host EDR. Coverage is via network position or via the system’s own audit features, which may be limited.
Listing gaps is not an apology
Naming what cannot be seen is a deliberate statement that frames the investigation realistically. It prevents the analyst from chasing impossible queries, and it signals to escalation when an investigation has reached the limit of what the available telemetry can prove.
Key Takeaway
Infrastructure boundaries are the honest map of the SOC’s vision. Naming them, network, identity, geography, tooling, and above all the gaps, is Scope’s last responsibility before Uncover takes the work forward, because Uncover can only query what the environment can actually answer.
Next up
Scope working example
A walkthrough of Scope applied to the same intrusion that ran through Alert and Subject.
See the example