Entity Resolution in Practice

This consumes more deployment time than any other single issue, and it is the one most likely to be discovered late, after models have trained on fragmented data.

The problem, concretely

A single employee may appear as: a directory account, a separate administrative account, an email address, a cloud identity in a different namespace, a VPN username, an employee number in HR records, and a source IP address during any given session.

Every one of those appears in logs. Unless they are joined to one entity:

Baselines fragment. Six identifiers produce six sparse behaviour profiles, none with enough data to model well.

Cross-identity movement is invisible. An attacker who compromises a standard account and escalates to the administrative one has crossed a boundary the system does not know exists. To the model, two unrelated entities each did something slightly unusual.

Peer comparison breaks. Fragments do not map cleanly to groups.

Investigation is manual. An analyst reconstructs the join by hand, every time.

The joins that matter, in order

Standard account to privileged account. The highest-value join and the one most often missing, because administrative accounts are frequently created outside the normal provisioning process with unrelated naming.

Directory identity to cloud identity. Usually solvable through the identity provider, and frequently broken for accounts created before federation or migrated between tenants.

Account to email address. Straightforward where naming is consistent, and it rarely is across a decade of hiring.

IP address to user session. Requires DHCP, VPN and NAT records with retention matching your log retention. Very commonly the missing piece that renders network telemetry unattributable.

Account to person. Via HR records. Necessary for peer grouping and for departure triggers. Carries privacy obligations covered elsewhere.

Service account to owner. Not a person doing the acting, but a person accountable for it. Frequently unknown, and discovering it is itself a security exercise.

How to build the mapping

Start from the identity provider. Modern directories hold most of the links already. Export them and see what fraction of your log identifiers resolve.

Measure the gap explicitly. Take a day of authentication events and calculate what percentage of identifiers map to a known entity. Deployments routinely discover twenty to forty percent unresolved on first measurement, and nobody looks until they are asked.

Handle the naming conventions. Administrative accounts usually follow a pattern — a prefix, a suffix, a separate OU. Encode the pattern, then verify a sample manually, because the pattern will have exceptions.

Treat the residue as a finding. Identifiers that resolve to nothing are either stale accounts, undocumented service accounts, or something worse. This list is worth reviewing regardless of the UEBA deployment.

Store the mapping outside the product so it survives replacement and can be corrected without vendor involvement.

Shared accounts

A shared account is entity resolution in reverse: several people appearing as one entity.

The baseline becomes the union of everyone's behaviour, which is wide enough that almost nothing deviates. Detection does not degrade gracefully here — it stops.

Find them before deployment. Indicators: concurrent sessions from different locations, activity spanning the whole working day and beyond, an implausible breadth of systems touched, and authentication from more distinct devices than one person uses.

Then choose. Eliminate the account, or exclude it from behavioural analytics and cover it with rules instead. Leaving it in produces false confidence, because the dashboard shows it as monitored.

Maintenance

Entity resolution is not a project. It degrades continuously:

New accounts created outside the process. People changing name. Contractors converting to employees with new identifiers. Systems migrated to new naming. Service accounts repurposed.

Re-measure the resolution rate monthly. A falling rate is an early indicator that something upstream changed, and it is one of the few genuinely useful health metrics for a UEBA deployment.

Measuring the resolution rate

The one metric that tells you whether behavioural analytics can work at all, and it takes an hour to produce.

Take one day of authentication events. Count the distinct identifiers. Count how many map to a known entity in your directory or mapping table.

Report the percentage. First measurements commonly land between sixty and eighty percent. Anything below ninety means a substantial fraction of your activity is either unattributed or attributed to fragments.

Break the residue down. Stale accounts, service accounts outside the directory, local accounts, machine accounts, external identities, malformed identifiers. Each category has a different remedy.

Track it monthly. A falling rate is an early warning that something upstream changed — a new provisioning path, a migration, a naming convention that drifted.

Very few deployments produce this number. Those that do usually find the explanation for output they had attributed to model quality.

Common false positives

Resolution failures generate a distinctive class of noise:

Fragmented identities producing thin baselines that flag ordinary activity, because the model has seen too little of it.

One person's two accounts appearing as two entities that each look unusual, when together they would look normal.

Shared accounts either flagging constantly or never flagging, depending on which way the union of behaviours falls.

Renamed accounts appearing as a brand new entity with no history, generating first-observed events for everything the person routinely does.

Case and domain variants of the same account treated as separate entities, splitting a baseline three ways.

Blind spots and assumptions

That the identity provider is complete. Local accounts on servers, accounts in applications with their own user stores, and legacy systems predating federation all sit outside it.

That one identifier means one actor. Shared accounts, service accounts used interactively by administrators, and break-glass credentials all violate this.

That the mapping is current. A mapping built at deployment and never refreshed is wrong within a quarter.

That unresolved means unimportant. The unresolved residue disproportionately contains the accounts nobody manages, which is where risk concentrates.