Investigate, respond, and verify recovery

Investigation is a timeline, not a vibe

After S1 containment, Maya still has a case. She builds a timeline: 02:14 authentication, 02:16 export, 02:18 alert, 02:22 account disable and session revoke. She gathers TrackPort authorization reasons, MFA prompt metadata, and whether other Warehouse-Admins accounts exported overnight. SP 800-61 Revision 3 asks responders to handle evidence carefully and to aim at recovery, not at theater. Competing hypotheses remain on the board until evidence kills them.

Contradictory evidence is normal. The identity provider says the user-agent was FleetLink/4.2. EDR on a company laptop shows no FleetLink process. That contradiction raises a stolen-token or unofficial-phone hypothesis. Do not average the two records into a mush. Keep both, with provenance.

Scoped response with a human decision

Reconstruct the approved S1 containment decision before planning recovery; do not submit the same change merely because a new lesson began. A response action is not “lock down the warehouse.” It is a sentence: disable identity jordan.h in the identity provider; revoke sessions; require Maya’s approval under the scoped on-call response policy; let that approval expire after 60 minutes before execution; do not delete mailboxes or reimage yet. The executor should be a separately authorized admin or automation identity, not the chatbot that drafted the note and not the Slack message that discussed it. Executed containment remains in place until separately authorized recovery; approval expiry never automatically re-enables a compromised identity.

Preconditions matter. If Jordan is actually working a night shift, disabling the account may interrupt contracted dock work. The policy permits Maya to accept that scoped loss to stop address exports after checking dependencies; Priya supplies operational context when reached. Document the accepted loss. CSF Respond and Recover are different functions: stopping the export is not the same as restoring a trustworthy authorization state.

• Target: the exact account, group, host, or firewall rule.
• Parameters: disable versus delete, revoke versus rotate, duration.
• Preconditions: change window, owner approval, no conflicting restore job.
• Expiry and revocation: approvals die; they do not live in chat forever.

Verify the postcondition

A console that says “disabled” is a success response from an API. Verification is independent: a new login attempt is rejected; existing sessions die; a test export with a canary token fails authorization; TrackPort last-export timestamp does not move; YardOS still loads pallets. If the disable API timed out, Maya does not retry blindly. She reconciles: is the account already disabled, still enabled, or unknown? Blind retry of a write is how you double-close a ticket and miss a still-open session.

Compensation, if needed, should be reversible and supported: re-enable only after phishing-resistant re-enrollment, not “undo” by restoring a snapshot that also restores the rogue group membership. Close the case with the human correction captured: Priya explains the Warehouse-Admins shortcut, Devon files the least-privilege fix from F5, and the uncertainty that remains is written down. This is the last SOC lesson before you meet IRIS, which automates pieces of this loop without inheriting authority from a model prompt.