What you’ll be able to do
- Produce a triage note with observations, hypotheses, missing evidence, and a scoped, authorized next action with recovery limits.
- Request the next useful records instead of every possible log in the company.
- Avoid attributing a human’s guilt from an account name in an alert.
- Choose containment that matches the F1 loss without destroying evidence.
Triage is a time-boxed decision under uncertainty
Maya is on call for Riverstone’s synthetic SOC. At 02:18 an identity alert fires: “New country plus MFA-approved login for jordan.h, followed by a privileged API.” SP 800-61 Revision 3 frames this as incident handling: declare what you know, protect evidence, contain harm, and communicate. You will not have a complete case in the first ten minutes. You still have to decide whether the account should keep exporting addresses. Riverstone’s documented on-call playbook authorizes Maya to contain one identity when credible export abuse is suspected, after checking operational dependencies and recording the business impact. Broader changes require a separate approval.
A good triage note is boring. It quotes the identity-provider events, quotes any application events already present, lists hypotheses that could still be true, and names the smallest next records that would kill those hypotheses. It does not paste the alert title into an email to human resources.
Worked case: Jordan Hale, 02:14 to 02:16
Known: identity-provider success for jordan.h at 02:14 from 203.0.113.40, ASN in a country Jordan has not used this year, FleetLink user-agent, MFA push approved in two seconds. Known: TrackPort GET /exports/addresses for trailer 44 at 02:16, HTTP 200, 1.2 MB, authorization decision “allow” because the account is still in Warehouse-Admins from last quarter’s shortcut. Known: trailer 44 is assigned to driver Kim Park, not Jordan. Unknown: whether Jordan’s phone is missing; whether 203.0.113.40 is a VPN egress; whether other exports succeeded during the forwarder delay.
Hypotheses worth keeping in parallel: (1) stolen account with a tired or social-engineered MFA approval; (2) Jordan on travel using a new roaming path; (3) a family member using the phone; (4) a poisoned device sending the export. Hypothesis 2 is weakened by the unassigned trailer export. It is not dead until Jordan is contacted through a channel that is not the possibly stolen phone.
- Containment candidate under that authority: disable this account and revoke its sessions. A disable can be reversed after recovery checks; revocation requires fresh authentication and cannot restore the old sessions.
- Evidence candidate: full TrackPort authz log, EDR process tree if the laptop exists, assignment table, MFA prompt details.
- People candidate: Priya via known voice number, not the FleetLink push.
- Do not wipe the laptop; that is not triage.
Ask for the next useful evidence
The next useful evidence is the smallest record that changes the decision. Maya needs the authorization reason code more than she needs three months of printer logs. She needs MFA prompt location and number of prior denials more than a full packet capture of the warehouse. NIST SP 800-63-4 reminds you that authenticator events are identity evidence, not proof of a named human. Write the request so a tired admin can fulfill it: system, time window, account, fields.
If leadership asks “was it Jordan?” the honest answer is “the account jordan.h did this; human attribution is not yet supported.” That sentence is how you stay employed as an analyst rather than as a rumor mill.
CHECK YOUR JUDGMENT
The 02:18 alert is on Maya’s screen. Warehouse-Admins still includes jordan.h. TrackPort application logs after 02:16 are delayed. Priya is asleep. Which action and note are appropriate in the next five minutes?
NEXT FIELD LESSON