Scope working example

Step 1. Regulatory check

The compromised user dlin has read access to a cloud finance platform that processes payment data. That does not by itself place the investigation inside a cardholder data environment, but it is the cue to flag possible PCI DSS exposure and engage compliance, who own that determination. The platform also stores personally identifiable information for vendors, including EU residents, which makes GDPR a candidate regime for the case — whether it attaches is an Article 3 determination that belongs to the DPO, and the analyst’s contribution is the tag and the timestamp.

Decisions: Document the possible PCI exposure now. Engage compliance early so any breach-notification clock can run in parallel with the technical investigation. Tag the case as both PCI and GDPR relevant.

Step 2. Time window

The alert is a phishing-driven intrusion that fired today. The Subject phase did not find slow-burn signals. The default window for this threat type is 24 to 72 hours of historical review, with a 4-week look at the primary entities to confirm no prior staging.

Decisions: Set primary window at 72 hours pre-alert through current time. Set extended check at 4 weeks for dlin’s account specifically. Note that endpoint telemetry has 90-day retention, identity telemetry has 1 year, both are sufficient.

Step 3. Entity boundaries

Subject’s entity map gets categorized:

• Primary: dlin (user), laptop-finance-09 (host), dlin’s cloud identity.
• Secondary: The machine account of laptop-finance-09. The two other finance users who opened the same email.
• Downstream: The cloud finance platform dlin’s identity federates into. Inside the boundary as the system the compromised identity can reach; it gets no entity profile of its own, but its authentication and API logs are pinned to the infrastructure check.
• Originating threat: The external sender. Tracked as the adversary side of the case rather than as an entity under investigation; its sending domain and infrastructure indicators feed Uncover’s threat-intelligence work.
• Out of scope (for now): The one finance team member who received but did not open the email. Their inbox still gets a baseline check, but no full investigation unless something new surfaces.

Decisions: Primary entities get full investigation depth. Secondary entities get baseline comparison and are upgraded only on a signal.

Step 4. Infrastructure check

What can the SOC see for this case?

• In scope: EDR on the laptop, cloud identity logs, firewall logs, proxy logs, mailbox audit.
• Limited: The cloud finance platform’s in-app activity is in the vendor’s logs; the SOC sees authentication and gross API calls only. A vendor request is needed for deeper investigation.
• Gaps: If the user worked from a personal phone via the cloud platform’s mobile app, that activity may not show up in corporate telemetry.

Decisions: Note the cloud-platform gap explicitly. If Uncover needs deeper data, request from the vendor now so it arrives in parallel.

Step 5. Hand off to Uncover

The Scope deliverable is a one-page boundary statement Uncover can pin above their query window:

• Threat type: phishing-driven intrusion.
• Time: 72 hours primary, 4 weeks extended for dlin.
• Primary entities: dlin, laptop-finance-09, cloud identity. Full depth.
• Secondary entities: machine account, 2 other finance users. Baseline depth. External sender tracked as the originating threat.
• Downstream: cloud finance platform inside the boundary for reachability; vendor logs requested.
• Regulatory: likely PCI and GDPR exposure; confirmation owned by compliance. Compliance engaged.
• Infrastructure gaps: mobile app activity on the cloud platform may be invisible; vendor request submitted.
• Open questions for Uncover: do the two other openers’ hosts show the same execution chain; were dlin’s cloud session tokens exposed or replayed; what do the vendor’s in-app logs show beyond the federated login?

Step 1. Time scope

The Cursor case has a narrower time horizon than the finance-team intrusion. Subject’s reads were all clean; there is no expanding pattern to chase. The boundary is sized to validate the benign-true-positive hypothesis, not to investigate a compromise.

• Primary window: alert minus 1 hour through alert plus 4 hours. Five-hour total, enough to capture the IDE session that produced the alert and any follow-on behavior.
• Comparison window: the same user’s prior 14 days of IDE activity, used only for behavioral baselining, not for incident reconstruction.
• Extension trigger: if Uncover surfaces any signal inconsistent with the benign read (new persistence, unexpected network destinations, credential access), the time window expands to 24 hours pre-alert and the case is escalated within Risk.

A short window is the correct call when Subject’s reads agree. Extending it preemptively would burn time investigating absence of compromise.

Step 2. Subject scope

Subject’s per-entity assessment is the input. Scope translates it into investigative boundaries that don’t expand the entity list.

• Primary subject: the developer’s laptop and the Cursor Helper (Plugin) binary. Full process telemetry, file activity, and network behavior for this host during the time window.
• User context: the named frontend engineer. Authentication and authorization checks for the period; no peer-group expansion required because Subject’s relationship-dimension read was clean.
• Excluded: other developer laptops, other engineers on the team, the vendor’s infrastructure beyond observable DNS and TLS. Subject’s read was conclusive on these surfaces; Scope does not re-open them.

What a less experienced analyst could miss: that over-scoping is the failure mode here. It would look like pulling every developer laptop running Cursor into the investigation, or expanding to investigate Anysphere as a vendor. Both are tempting because the binary is the focal artifact. The methodology says no: Subject already validated the binary and the trust chain. Re-opening that question is wasted work.

Step 3. Environment scope

The environment for a single managed developer workstation is genuinely narrow, and Scope keeps it that way.

• In scope: the laptop’s EDR telemetry, the corporate egress proxy logs for this device, the developer’s SSO authentication events, the MDM compliance record for the laptop.
• Conditionally in: internal source-control access logs for the user’s repositories during the window (read-only, no payload reconstruction).
• Out of scope: peer laptops, the vendor’s own infrastructure beyond DNS / TLS observability, any system the laptop did not actually reach during the window.

Step 4. Data sources and tooling

The Cursor case has fewer data sources than the finance-team intrusion because the subject surface is genuinely smaller. Scope names them precisely so Uncover does not improvise.

• EDR (CrowdStrike on macOS). Primary. Process tree, file activity, network sockets, signing-status events.
• Corporate egress proxy. Outbound destinations, TLS metadata, byte counts. Used to corroborate that the network signal mapped to vendor inference endpoints, not staging infrastructure.
• Identity provider logs. Authentication events for this user during the window. No password reset, no MFA bypass, no anomalous geographies.
• MDM compliance record. Confirms the laptop is enrolled, encrypted, OS-current, and reporting normally.
• Threat intelligence. Passive only. Confirm the vendor and inference endpoints have no prior incident associations. No active hash pivots, no speculative attribution.

Step 5. Boundary statement

The Scope deliverable for the Cursor case is deliberately compact:

• Time: alert minus 1h through alert plus 4h. Comparison window: prior 14 days for behavioral baselining only.
• Subject: one laptop, one engineer, one binary, the vendor’s documented endpoints. No expansion.
• Environment: EDR, corporate egress proxy, identity provider, MDM. Source-control reads conditional.
• Data sources: as above. Threat intel passive only.
• Regulatory: none triggered. The source code on the laptop is sensitive but is not regulated data; no PCI/PII/PHI in scope.
• Infrastructure gaps: macOS full-packet capture not available; USB monitoring not deployed on this host class. Uncover will note these as bounded confidence reductions, not as expansion triggers.
• Escalation trigger: any Uncover finding inconsistent with the benign read expands the time window to 24 hours pre-alert and bumps the case to the Risk phase for re-evaluation.
• Open questions for Uncover: do the connections match the vendor’s documented endpoints exactly; does the binary hash match the vendor-signed release; is there any activity in the window the benign read does not explain?

Uncover starts inside narrow rails. The case is shaped to confirm or refute the benign read efficiently, not to manufacture a compromise narrative from absence of evidence.

Step 1. Regulatory check

The mailbox holds customer contract and billing correspondence: names, contacts, account details, some of it for EU residents, so GDPR is flagged and compliance engaged now, before anyone knows what the attacker read. The staging pattern points at payment-redirect fraud, which adds a financial-crime dimension: if a fraudulent payment instruction has already gone out, finance and legal need to know on a different clock than the technical investigation.

Decisions: tag the case GDPR-relevant, engage compliance, and put finance on notice that outbound payment instructions from the customer-success mailboxes need out-of-band verification until the case closes.

Step 2. Time window

The forward edge of the window is open because the compromise may be live. The backward edge is set by the artifacts: rvega clicked the lure at 08:52 today, but consent grants and rules can predate the alert that finally exposed them.

• Primary window: 08:00 UTC today through current time, held open until containment.
• Extended check: 14 days back across the tenant for consent grants to the same application and for inbox rules with the same shape, and 90 days of rvega’s sign-in history, the same baseline window Alert and Subject read, to confirm today was the first foreign presentation.
• Retention check: IdP sign-in logs and the tenant audit log both cover the windows. Noted: mailbox item-level read events exist only at the tenant’s current audit tier; if the tier had been lower, the “what did they read” question would be unanswerable.

Step 3. Entity boundaries

• Primary: rvega’s account, the hijacked session, the “Mail Backup Sync” OAuth application. Full depth.
• Secondary: the second click-through user, the shared billing mailbox, the inbox rule artifact, and the two remaining lure recipients who did not click. Baseline depth, upgraded on any signal.
• Tenant-wide sweep dimension: any session presented from the attacker ASN, and any consent grant to the same app ID, across all users. This is a bounded query set, not an open-ended hunt; it is written into the boundary so Uncover runs it once, deliberately.
• Downstream: the CRM rvega’s SSO reaches. Inside the boundary as reachable-from-the-session; its authentication logs are already in the infrastructure check, and it gets no deeper look unless the session touched it.
• Originating threat: the AiTM domain and VPS IP, feeding Uncover’s intelligence work.
• Out of scope: rvega’s laptop beyond the already-completed EDR check, and every SaaS tenant with no observed attacker activity, pending the sweep results.

Step 4. Infrastructure check

• In scope: IdP sign-in and risk logs, the tenant unified audit log, the email gateway’s click and delivery records, CRM authentication logs.
• Limited: the OAuth application’s actual read activity is visible only as aggregate sync events at the current audit tier; per-message detail may require a vendor request.
• Gaps: the AiTM proxy sits outside the environment entirely; what rvega saw on that page is reconstructable only from the gateway’s URL verdict and the phishing kit’s known behavior, not from logs.

Decisions: submit the vendor request for app-activity detail now so it runs in parallel, and record the proxy blind spot as a permanent evidence boundary for this case.

Step 5. Hand off to Uncover

• Threat type: AiTM session theft with BEC staging.
• Time: 08:00 today through containment; 14-day tenant lookback for grants and rules; 30-day sign-in history for rvega.
• Primary entities: the account, the session, the app. Full depth.
• Secondary entities: second click-through user, billing mailbox, inbox rule, two non-click recipients. Baseline depth.
• Tenant sweep: attacker-ASN sessions and same-app consents, all users, one pass.
• Regulatory: GDPR flagged, compliance engaged, finance warned on payment instructions.
• Infrastructure gaps: app read-detail pending vendor; AiTM proxy permanently invisible.
• Escalation posture: the session and app grant are live persistence. Any evidence of payment-thread access or outbound mail moves this case to Escalation immediately, mid-phase.
• Open questions for Uncover: what did the session and the OAuth app actually read; did the attacker reach payment threads or the CRM; do the tenant sweeps surface other sessions or grants?