How should authentication events be attributed to a person?¶
Authentication events should be attributed to a person only after the account, credential, device, session and surrounding circumstances have been considered together.
The log itself normally identifies a technical identity, not a human being.
Avoid the dangerous assumption¶
The dangerous assumption is that the named account holder must have performed every successful authentication event.
That is unsafe.
Credentials may be shared, stolen or stored on a device. Sessions and tokens may continue without fresh password entry. Devices may be borrowed, remotely controlled or used by several people.
A strong attribution may combine the authentication method, device ownership, source network, physical possession, communications, user behaviour and activity immediately before and after the event.
Investigators should first describe the technical fact: the system accepted authentication for a particular account, device or session at a recorded time.
Then assess the attribution evidence. Was the device seized from the person? Was it unlocked and in use? Did messages or statements show knowledge of the account? Did the activity match other independent records?
Alternative explanations should be considered and tested. These may include account sharing, compromise, remote access, automation, service accounts or administrator action.
Where the evidence supports association but not certainty, use proportionate wording. It may be appropriate to say that the event is consistent with use by the account holder, rather than that it proves they logged in.
Preserve the provider’s records and the evidence used to make the link. Make clear which conclusions are direct observations and which are inferences.
Operational takeaway¶
Authentication events should be attributed through correlation of account, credential, device, session and independent evidence, with language that reflects the strength of the link rather than assuming the account name identifies the person.