Why must an EDR console's audit trail tie each destructive command to a named human?

## The question the trail has to answer An audit trail is not built to record activity in general. It is built so that specific questions can be answered later, by people who were not there. For standing response privilege, there are exactly two: 1. **Was this one of ours?** During an investigation into the console itself, every action taken through it has to be sorted into *our response work* and *not our response work*. Anything unsorted is a lead. 2. **Who authorised it?** When a destructive action turns out to have been wrong — the wrong host, the wrong file, an executive's laptop, a system whose data mattered to a legal matter — someone will ask which human decided, on what basis, and whether anyone checked. Both questions are about **a person**, and neither is answered by a record that says an action happened. ## How attribution gets lost Three patterns destroy it, and all three are common: - **A shared operator login.** One console account with the credential in the team password store. Every entry names the same principal, and the trail's value drops to a timestamp. - **An automation identity that swallows the human.** A SOAR platform holds an API client with the execute role and runs every containment step through it. The console records the client; the decision was made in the other system, and the two records are only joined if you deliberately join them. - **An action initiated somewhere with no identity at all** — a chat command, a script on a jump host, a scheduled job — where the console sees only the API client at the end of the chain. The failure looks identical whether the cause is sloppiness or an intruder, which is precisely why it matters: an intruder who uses a shared account or a stolen API client is hiding inside your own attribution gap rather than defeating a control. ## What a usable record contains Per command, not per session: | Field | Why it is there | | --- | --- | | Authenticated principal | The named human, federated from the identity provider, never a shared local account | | Session identifier and source address | Lets you group a burst of commands and spot a session you cannot place | | Verb and full arguments | "Ran a script" is not reviewable; the script and its parameters are | | Target host or scope | Distinguishes one workstation from the whole fleet | | Case or ticket reference | The reconciliation key: every legitimate action should tie to an open case | | Approver, where required | The auditor's actual question, and the only field that records that a second person looked | The case reference is the field teams skip and later wish they had. It is what turns reconstruction from *reading a list of commands and remembering* into *reconciling two records*, and unreconciled entries then stand out on their own. ## Automation still names a human A machine-initiated action does not escape the requirement; it moves it. The trail should carry the automation's own identity **and** the authorising chain behind it: which rule or playbook fired, who owns it, and — for a run a person kicked off — who that person was. When a playbook is later found to have done something destructive at scale, the useful record is not "the SOAR account did it" but "playbook X, owned by Y, triggered by detection Z, on case N". ## Where the trail lives In a fully vendor-hosted console with no on-premises component, the administrative audit trail exists in one place: the vendor's platform, under retention the vendor sets, reachable by whoever holds console administrator rights. Two consequences follow. First, retention may be shorter than your investigation window, and you will find that out at the worst moment. Second, the record you would use to investigate console misuse sits inside the system being investigated. The practical answer is to export it continuously into your own log platform — operator authentications, role grants, API-client lifecycle events, and the per-command response history — so that it survives the vendor's retention default and so that queries against it do not depend on the console still being trustworthy. ## The direction of the claim Be careful about what a named entry proves. It proves that **a principal was authenticated when the command was submitted**. It does not prove that the named human was at the keyboard — that is the whole reason a hijacked session is dangerous — and it does not prove the command succeeded on the host. Attribution to a person is a *starting point* you can then test against the case record, the roster, the source address and the endpoint's own telemetry. A candidate who treats a console entry as proof of who acted has skipped the step that investigations turn on.