Transition to Subject
On this page
Alert ends with three deliverables and one decision: hand the case to Subject, close it at intake, or escalate it now. This page is the handoff contract: what to carry forward, what to leave behind, and how to know you are ready.
The handoff contract
One deliverable is finished work; the other two are honest lead lists. Alert does not classify assets, reconstruct the chain, or score impact, but no later phase should start from a cold read. The alert report template has a field for each item.
Finished: the validated alert
- Detection read: what fired, by what logic, with its trust prior.
- Parsed fields: each one traceable to its raw record.
- All four validation checks: every result, including the ones that disagree.
- Known gaps: named rather than skipped.
- Receipt, for a case no rule raised: channel, reporter or notifier, and the UTC time it reached the organization and the SOC (see Other intake).
Leads for Subject and Uncover
- Working hypothesis: the favored explanation, at least one competitor, and what would separate them.
- Named entities: primary, secondary or downstream, with privilege flagged.
- Temporal anchors and the leads worth chasing.
Flags for Scope, Risk, and the Escalation decision
- Regulated data in reach: a Scope flag, not an escalation.
- Control gaps and early severity signals. No impact score here.
- Escalation criteria: a criterion confirmed at High confidence fires the escalation tripwire now; one that only looks close is named, with what would confirm it.
Close path. Alert closes only at intake, and each close is an early Escalation decision recorded in the E fields: a Level 0 pattern close, a false positive (logic or data) with detection feedback, or a benign true positive with a pattern-entry proposal (the rule stays as written). Everything else goes to Subject.
What Subject asks. Who is involved? It needs the role behind each user, each system’s classification, and the trust relationships between them, over a stated window.
Depth. Record the level on the depth ladder and why. Any surprise moves it up; it never slides back down.
Leave behind unsupported tool or actor names, raw noise already summarized, and unlabeled speculation. An inference travels forward only labeled as one, with confidence per claim on the shared rubric.
You are ready if
- A peer could pick up the case tomorrow from your record alone.
- The escalation tripwire is checked: no criterion is confirmed, or the case has already escalated.
The full exit checklist closes the Alert working example.
Case C handoff, filled in
Validated alert (finished). SIEM correlation at 09:15 UTC: an IdP risk event (session S2 presented at 09:03:12 from 198.51.100.77, AS64502, new fingerprint, no authentication ceremony) joined on account and session to a new inbox rule at 09:06:55. All four validation checks agree. Parsed records: the 08:53:37 sign-in that minted S2 through 203.0.113.41 a minute after a gateway-recorded click on docs-share-portal[.]example, the inbox rule named ., and the 09:09:30 consent to “Mail Backup Sync” (Mail.Read, offline_access), all from S2. Known gaps: the gateway’s URL verdict is still pending; mail-access records for the consented app had not reached the SIEM at handoff.
Leads for Subject and Uncover. Working hypothesis: an adversary-in-the-middle proxy captured rvega’s 08:53 session, the attacker replayed it from a VPS, hid payment-themed mail, and granted consent to an OAuth app for persistent mailbox access. Alternatives ruled out by a 09:19 phone call (no VPN, no rule, no app approval). Open questions: who else received the link and reached the credential step, what the app has already read, and whether the attacker registered MFA methods or devices.
Flags for Scope, Risk, and the Escalation decision. Criterion 1, confirmed malicious activity not fully contained by a control: met at High confidence (IdP sign-in log and tenant audit, two independent sources). The escalation tripwire fired at 09:22: P1 by criterion, recorded as an early escalation decision, with the IR lead paged by pager and phone bridge rather than tenant email or chat. Regulated data: customer personal data in the mailbox, with delegate rights on the shared billing mailbox. Control gaps: push MFA rather than a phishing-resistant method, the IdP risk policy in report-only mode, and user consent allowed for unverified publishers. Depth: Level 2, because an attacker reading a mailbox of customer personal data makes access to regulated data plausible, not merely reachable.
Confidence. High on the replayed session; medium on the AiTM delivery mechanism, pending the gateway verdict.
Key takeaway
Alert ends with the validated alert and its gaps, leads led by the working hypothesis, and flags for Scope, Risk, and the Escalation decision. Subject builds on that work instead of re-deriving it.
Technical details verified . Product names, defaults and retention change; check your own tenant.