Documentation working example

Step 1. Capture the record

The nine-section event report (see Standards) is assembled from the case record written throughout the investigation. The investigative entries were locked at handoff, so Documentation adds the closure sections as timestamped, attributed addenda, under the amendment rule. The handoff packet maps in per the crosswalk: summary, timeline, entities, evidence chain, verdict, and containment fill the decision header and sections 01-04; artifacts split between indicators (06) and appendices (09); the regulatory notification informs business impact (05); open questions carry into recommendations (08) rather than being dropped; the communication record lands verbatim in 09. The report covers triage’s work up to the handoff and links IR’s post-incident report rather than absorbing it. What only becomes clear at the end, chiefly lessons learned (07) and the detection-engineering recommendations (08), Documentation writes now.

What a less experienced analyst could miss: the temptation to smooth the timeline in hindsight. This case’s escalation tripwire was met at 09:24 and the P1 was set and IR engaged at 14:00, and the honest record keeps that gap visible. Rewriting the narrative so the escalation looks prompt would read better in review, and it would destroy the record’s two real uses: the audit trail stops matching the system-of-record timestamps, and the team loses the exact lesson (criteria as tripwires, not end-of-phase checklists) this case exists to teach.

Step 2. Sanitize for sharing

The record needs to be usable by the broader team without exposing sensitive data. PII is masked, regulated content is referenced rather than reproduced, sensitive infrastructure detail is generalized where possible. The version stored in the case-management system stays detailed; the version shared in training stays useful but safe. Here that means dlin and the other finance users are pseudonymized in the shared version, the vendor-contact data on the platform is referenced by system and record class only, and the internal IP addresses and proxy port are generalized. The record describes the click neutrally (“followed the link at 09:10 UTC”) with no judgment of care: dlin is the first victim, not the root cause. The indicator list shared outside the team carries its TLP label.

Step 3. Link related artifacts

The record links to: the original alert in the SIEM (ALERT-2026-0303-0191), the IR incident (INC-2026-0303-001) and IR’s post-incident report, the compliance and DPO thread opened at 09:45, the vendor request (opened 09:48, escalated 14:35), the platform owner’s confirmation that the session was ended, and the detection-engineering tickets below. Every relevant artifact is one click away.

Step 4. Feed detection engineering

The case surfaced two detection gaps and one rule-precision opportunity, and the triage analyst’s brief names each. Gap one: the rule’s network leg reads only the web proxy, so the identical chain on laptop-finance-12, off the corporate network without the VPN, raised nothing; the leg should also read EDR network events. Gap two: nothing alerted when a non-browser process opened the browser and read its cookie store at 09:19, or when an existing session was used from a hosting-provider address at 10:41; either would have surfaced the theft hours earlier. Precision: the alert should carry the RunMRU value and the browser’s last visit to the destination domain as fields, because together they separate a pasted lure from an administrator opening PowerShell by hand at a glance. Each becomes a tuning request in the detection-engineering queue, routed per the detection-feedback routing table.

Step 5. Submit for review

The record is submitted to the SOC manager for closure review. The review is not theater; it is the quality check that ensures the record meets the standard, run against the closure review checklist. The reviewer either accepts the record, requests clarification, or flags it as a training case for the team. This one is flagged as a training case, for the 09:24 tripwire.

Step 1. Capture the record

The nine-section event report is filled under the decision header the Escalation decision wrote (verdict on both axes, priority, confidence, provenance). Sections 01-04 (event overview, timeline, origin & scope, actions taken) carry forward from the closure record: the alert, the phases, the High/Low P3 hold and its clean re-score, and the explicit “no containment” justification. Sections 05-09 are filled with the benign-close-specific content: business impact is “none; legitimate activity on a developer workstation”; IOCs are the binary hash, the bundled extension ID and the vendor TLS endpoints, recorded as known-good rather than malicious; lessons learned is the rule’s calibration on developer hosts and the proposed pattern entry; post-event recommendations are the alert-enrichment request and the pattern-entry proposal; appendices hold the signature chain, the extension inventory, the fleet prevalence query, and the Risk-phase reasoning. The decision header’s open-uncertainty line names the two accepted gaps and the reopen triggers.

What a less experienced analyst could miss: the known-good marking on the IOC section. A binary hash filed in an incident record without that label tends to migrate: into the intel platform, into a blocklist, into a hunt query someone writes next quarter. Then every developer running the same signed IDE lights up as “matching a known incident artifact.” Recording the hash as known-good, in the field where future correlation will find it, is what keeps this benign fire from breeding a family of new ones.

Step 2. Sanitize for sharing

The Cursor case has less sensitive content than the finance-team intrusion, but the same discipline applies. The named developer’s identity is pseudonymized in the version stored for team-wide review. The binary hash and vendor endpoints stay in the detailed version. Internal source-control identifiers (repository, module, and branch names) are generalized, and the prompt the user gave the coding agent is paraphrased rather than quoted, because it names them.

Step 3. Link related artifacts

The record links to: the original alert in the SIEM, the case in the case-management system, the detection-engineering requests (alert enrichment and the pattern-entry proposal), the rule’s existing calibration record, the fleet prevalence query saved in the analytics library, and (this one matters) the training-archive entry: the Cursor case is a textbook example of “looks like Empire, isn’t Empire,” and of checking what the signed IDE ran, not only who signed it. It lives in the SOC’s onboarding curriculum.

Step 4. Feed detection engineering

The case surfaced no rule defect: the rule fired on exactly what it describes, and its calibration record already notes the developer-host benign-fire rate. The triage analyst writes a brief with two asks, routed per the detection-feedback routing table. First, enrich the alert with the extension ID, the child’s command line and the destination set. Second, pattern entry PTN-031 (draft), keyed to a tuple: the Cursor build the MDM reports, the bundled extension ID loaded from inside the signed bundle, and the vendor destination set. The entry names its discriminators (child script inside the bundle, destinations within the set, no credential-path reads, no persistence writes), an owner in detection engineering, a 30-day expiry, and re-fire triggers: a Cursor version change (the owner re-validates), a new extension ID, a destination outside the set, a rule change, or observed abuse. It needs a second person’s approval before it goes live, carries the machine-close flag off, and suspends itself if a close against it is ever reversed. What it would take to turn the flag on is worked through on Governing automated triage. While it is live, an exact-tuple fire on a host that passes the eligibility gate can close at Level 0, by an analyst, against the five-field record. Signer and install path alone never key a suppression.

Step 5. Submit for review

The record is submitted for closure review. A benign-close record is reviewed by the SOC manager with the same eye an escalation record gets, perhaps with extra attention, because benign-close records are how the SOC’s discipline gets calibrated. The reviewer either accepts the record, requests clarification, or flags it as a training case. This one is flagged for training.

Step 1. Capture the record

The nine sections fill from the handoff packet, with one identity-specific discipline: the raw artifacts are exported into the case now, not merely referenced. The IdP’s sign-in records (the 08:53 proxied sign-in and both presentations of the session it produced), the inbox-rule definition, the consent-grant event, and the item-level mail-access records are all subject to platform retention windows and license tiers that the SOC does not control. A record that points at a log the platform will age out stops being evidence the day it does, and for identity sign-in logs that can be 7 to 30 days by default (Microsoft Entra ID, depending on license tier), not the 90 days some other providers keep. The exports, with their retrieval timestamps, go into the appendices. Most were taken at 09:22-09:24, before containment changed anything (the order is laid out on Preserve before you contain); Documentation checks that each one is in the case and adds the access records Uncover pulled later.

Step 2. Sanitize for sharing

This case carries the most sensitive sharing surface of the three: the mailbox contents the attacker synced are customer data, and the record must describe the collection without reproducing it. The report records counts, categories, and thread types (“~1,800 items including billing correspondence”), never message bodies. rvega is pseudonymized in the training version, and the record states plainly that she is a victim, not a suspect, so the training artifact never reads as blame. The second click-through user appears only by role.

Step 3. Link related artifacts

The record links to: the SIEM alert, the IR ticket, the compliance determination thread (still open at closure; linked as pending), the item-level message list sent to compliance at 10:22, the finance team’s out-of-band verification confirmation, and the tenant sweep queries saved as reusable hunts. The pending links are themselves part of the record: an auditor reading it later sees what was still in motion when triage closed its side.

Step 4. Feed detection engineering

The brief credits what worked and names what was missing: the two-signal correlation rule caught the case and its design should be reused; a consent-grant alert for unverified publishers would have fired at 09:09 independent of the session signal; the IdP recorded the 09:03 risk event, but nothing paged on it alone, and a standalone alert on its high-fidelity form (a session ID re-presented from a new ASN with no authentication ceremony, rather than the noisy new-ASN signal) would have paged at 09:03, twelve minutes before the 09:15 correlation. Earliest of all, an interactive, MFA-satisfied sign-in from a hosting ASN within two minutes of a gateway-recorded link click would have fired at 08:53, ten minutes before the replay. Each becomes a ticket. The control gaps (push MFA that is not phishing-resistant, no token protection or compliant-device requirement, user consent open to unverified publishers) go to IR’s recommendations, not the detection backlog, as the detection-feedback routing table routes control gaps. The lure domain, the two attacker IPs, and the kit fingerprint feed the intel platform for retro-hunting across the estate.

Step 5. Submit for review

The SOC manager’s review flags this record for the training archive alongside the Cursor case: it is the SOC’s reference example of an intrusion with no endpoint evidence, and of an escalation tripwire that fired at the end of Alert, with containment that was preserved first, ordered, and verified. The record closes with the compliance thread and IR’s open questions explicitly marked as continuing under their own owners.