Entity Resolution for Users, Hosts, Sessions, Workloads, and Resources
Relate users, sessions, devices, workloads, applications, and resources across changing identifiers without turning uncertain joins into false identity or causality.
An identifier is not yet an entity
A record contains [email protected]. Another contains a directory object identifier. A third names a local account called alex. The strings may refer to one person, several identities controlled by that person, or unrelated subjects in different namespaces.
An identifier is a value used to refer to something within a scope. An entity is the user, device, session, application, workload, resource, or organization the analysis reasons about. Entity resolution is the evidence-based process of deciding which identifiers refer to the same entity or to related entities.
Keep entity type and authority beside the value. A cloud account ID, email address, host name, IP address, certificate subject, and container name have different issuers and reuse rules. Lowercasing strings does not resolve identity; it only normalizes spelling.
Relationships have direction and validity time
A person owns an account. A session authenticates as that account. A device hosts the session. An application acts under delegated authority. These are different edges, and each can begin and end.
Record source and target entity, relationship type, evidence source, confidence, valid-from and valid-to time, and observation time. Today’s device owner should not be attached automatically to an event from before the device was reassigned. A group membership removed this morning can still explain access yesterday.
Use event time and late data carefully. A directory update may arrive after an activity event while taking effect before it. Resolution should evaluate the relationship as of the behavior, not simply use the newest value available at query time.
Strong keys and weak clues should not look equal
A provider-assigned immutable object ID within a tenant is usually stronger than a display name. A cryptographically bound session identifier is stronger than a shared network address. A hostname plus time may be a useful clue when stronger keys are absent, but its uncertainty should remain visible.
Define a hierarchy of evidence for each entity type. Prefer authoritative immutable IDs, then scoped stable IDs, then composite keys, and finally probabilistic or contextual clues. Do not merge records permanently because one weak clue matched once.
Where resolution is uncertain, preserve candidate relationships or confidence instead of creating one canonical truth. An analyst can use ambiguity; a hidden wrong merge can contaminate every correlation and risk score built on top of it.
Shared infrastructure creates convincing false joins
A proxy gives many users one public address. Network address translation reuses ports over time. Virtual desktop hosts serve several sessions. Service accounts execute work requested by many people. Containers and cloud instances reuse names and addresses after termination.
Test concurrent activity, identifier reuse, reassignment, federation, aliases, nested groups, shared mailboxes, workload identities, and missing logout events. A join that works in a simple fixture can fail precisely where incident volume is highest.
Correlation should expose the join path: these events share a session ID issued by this provider, or these records were related by user, device, and a ten-minute interval. The consumer needs to know whether the edge is observed, authoritative, or inferred.
Resolution quality limits every downstream claim
When a risk score combines activity for the wrong person, the score is not merely noisy; its explanation is false. When a sequence joins two concurrent sessions, order can look causal. When current ownership enriches old access, an innocent employee can inherit a predecessor’s history.
Monitor unmatched identifiers, ambiguous matches, one-to-many expansion, stale relationships, namespace collisions, and sudden changes in merge rate. Version resolution logic and preserve which version produced each derived entity.
An alert should carry original identifiers and the resolved entity relationship. State the fact recorded by each source, the resolution used to connect them, and what would change the conclusion. Entity resolution is part of the evidence, not invisible plumbing.
Frequently asked questions
Why not join security events by username or IP address?
Because names and addresses can be reused, shared, renamed, translated, or observed in different namespaces. Resolution needs entity type, authority, tenant, validity time, and evidence for the relationship.
