← Security Alert Triage: Evidence, Scope, and Handoff
1. Turn the Alert into a Testable Claim
An Alert Is a Claim, Not an Incident Verify Telemetry Before You Trust Presence or Absence
2. Scope and Test Explanations
Scope Entities and Time with Stop Rules Test Competing Hypotheses and Counter-Evidence
3. Decide, Hand Off, and Improve
Set Disposition, Severity, and Containment Authority Write the Handoff and Close the Feedback Loop
2. Scope and Test Explanations

Scope Entities and Time with Stop Rules

Move from an anchor alert to affected accounts, devices, processes, destinations, and resources while recording why every pivot belongs.

In this lesson, you will learn to:

  • Build an entity-time scope from one anchor event.
  • Define and apply stop rules that prevent weak relationships from inflating the case.

Scope Entities and Time with Stop Rules

Teaches anchor selection, relationship strength, time windows, stable identifiers, pivot ledgers, blast-radius rings, and controlled expansion.

Expand through explicit relationships

Choose the most specific anchor: event ID, process GUID, message ID, cloud request ID, session ID, file hash, or precise account-host-time tuple. Begin with a narrow window that covers the alert logic. Create an entity ledger for account, device, process, IP, domain, resource, mailbox, cloud role, application, and control. For each pivot, record the relationship, source, time, confidence, query, and returned count.

Prefer direct relationships. A process GUID links endpoint events from one process. A logon ID links a local session on one host. A request ID links one cloud action. A shared IP or common domain can be weak because of NAT, proxies, content delivery, and multi-tenant hosting. Resolve dynamic addresses at event time and distinguish user, device, workload, and account. Expand backward for origin and forward for effect only as the scenario predicts. Search relevant peer entities when the detection scenario includes propagation, reuse, or campaign behavior.

Alert scope grows through evidence-linked ringsAnchor, direct entities, confirmed effects, related peers, and organizational exposure remain different levels of confidence.FIELD GUIDEAlert scope grows through evidence-linked ringsAnchor eventDirect entitiesConfirmed effectsRelated peer activityOrganization searchWORKFLOWAnchor eventOrganization searchBLAST RINGS
Alert scope grows through evidence-linked rings — Anchor, direct entities, confirmed effects, related peers, and organizational exposure remain different levels of confidence.

Stop when the evidence relationship becomes too weak

Define stop rules before broad pivots: a maximum time based on credential or token lifetime, one execution chain, one set of recipients, one administrative session, or one infrastructure cluster supported by direct evidence. Stop when a relationship depends only on shared commodity infrastructure, the result set becomes dominated by unrelated peers, or the next pivot cannot change action. Record excluded results so later evidence can reopen the boundary.

Scope has layers. The alert entity is the center. Directly related sessions, processes, or deliveries form the next ring. Confirmed effects and connected resources form another. Peer or organization-wide searches test spread but do not automatically make every match part of the incident. Label entities as alerted, observed, affected, compromised, contained, or cleared according to evidence. “Affected” should require a defined impact or unauthorized state, not merely appearing in a query result. A bounded scope supports faster action and a more credible handoff.

A pivot network records why each entity belongsAccount, device, process, destination, resource, and control are connected by time-stamped relationships rather than shared appearance.FIELD GUIDEA pivot network records why each entity belongsAnchor alertAccount or userDevice or workloadProcess or sessionDestinationResource andcontrolCHECKPOINTS1Anchor alert2Account or user3Device orworkloadPIVOT NETWORK
A pivot network records why each entity belongs — Account, device, process, destination, resource, and control are connected by time-stamped relationships rather than shared appearance.

Resources

  • CISA Federal Incident Response Playbook — Use the standardized detection, analysis, containment, eradication, recovery, coordination, and tracking practices as a practical response reference.
← Previous: Verify Telemetry Before You Trust Presence or Absence Next: Test Competing Hypotheses and Counter-Evidence →