Scoping an unexplained authorized_keys entry, you find a config-management run deployed it — why not close as benign?

## The trap This leaf's characteristic failure is not missing evidence. It is the analyst who forms a benign hypothesis, goes looking, finds exactly what they expected, and stops. Confirmation bias plus premature closure, at the precise moment when widening was supposed to start. The asymmetry is what makes it expensive. Spending another thirty minutes on an authorised key costs thirty minutes. Closing a genuine intrusion as benign ends *all* further work on it — no second host is checked, no other account is reviewed, and the case label tells the next analyst there is nothing here. ## Why the config run is not an answer Configuration management deploying the key answers the mechanical question: the key arrived because a run applied a desired state that contained it. It leaves the security question untouched: - **Who put the key into that desired state?** - **Was that change reviewed, and by whom?** - **Does the change correspond to a request anyone can point to?** An adversary who obtained commit rights to the configuration repository — through a stolen developer credential, a compromised CI token, or a self-approved change — deploys persistence *through your automation*, and the resulting host state is indistinguishable from an authorised deployment. Automation is a distribution channel, not an authorisation. ## The technique: name the discriminating observation A disciplined widening step states both hypotheses and then asks which observation separates them. | | Benign hypothesis | Adversary hypothesis | | --- | --- | --- | | Config run applied the key | predicted | predicted | | Key present on all group hosts | predicted | predicted | | Reviewed commit by a named engineer who recognises the change | predicted | not predicted | | Commit authored by an identity whose owner denies it, or pushed outside the normal path | not predicted | predicted | The first two rows carry no information, which is precisely why finding them feels like progress and is not. The decisive evidence lives in the repository and the identity that wrote to it, not on the host. This works in the other direction too: an analyst who *expects* an intrusion will read a legitimate administrator's key as an implant and escalate on the same reasoning error. The cure is the same — state what would have to be true for the other hypothesis, then look for it. ## What this does to scope The finding should expand the investigation before it can end it: - **Hosts**: the population is now the membership of that configuration group, which you can enumerate exactly. One host became N, and you know N precisely rather than guessing. - **Accounts and identities**: the interesting identities are no longer only the service account on the host, but everyone with write access to the configuration repository and the pipeline that applies it. - **Time**: git history does not rotate the way host audit logs do, so the commit date may answer a "since when" that `auditd` could not. That is why this is a scoping question rather than a verdict question. Discovering the deployment path changes all three axes at once. ## Closing it properly when it *is* benign If the repository shows a reviewed commit by a named engineer, you confirm out of band — ask the engineer, not the commit message — and record the commit id, author and reviewer in the case. Then close it as a **benign true positive**: the detection was correct, the artefact was real, the activity was authorised. Closing it as a *false positive* would be wrong and harmful, because it feeds a tuning signal saying the rule misfires on something it actually caught correctly. ## What you are not doing here You are still scoping. Declaring an intrusion, isolating hosts and notifying anyone are separate decisions with separate owners, and reconstructing the intruder's full path is a different exercise again. The output of this step is a bigger, better-bounded picture and a named piece of evidence that decides the question — not the decision itself.