Entities: Beyond Modelling Only Users

The acronym contains an E for a reason that most deployments ignore. Modelling users is the obvious half; modelling everything else is where a substantial part of the detection value sits.

What counts as an entity

Human users. The default. Behaviour is variable, baselines are noisy, and the population is smaller than people assume.

Service accounts. Machine identities running scheduled jobs, integrations, application connections. In most enterprises these outnumber human accounts, frequently by a factor of two or more, and they hold disproportionate privilege.

Hosts. Workstations and servers. A host has a behavioural profile independent of who is logged into it — which processes run, which network destinations it reaches, what it does at 3am.

Applications. An application's access pattern to a database is a behaviour worth modelling.

Network segments and IP ranges. Coarse, and useful for detecting activity from places that should not generate it.

Devices without users. Printers, cameras, building systems. Frequently the least monitored and the most stable, which makes deviation unusually meaningful.

Why service accounts are the best target

This is the argument worth making to anyone deciding where to spend deployment effort.

Their behaviour is exceptionally stable. A service account does the same operations, against the same systems, on the same schedule, indefinitely. The variance that makes human baselines noisy is largely absent.

That stability makes deviation high-precision. A backup service account that suddenly performs an interactive logon, or reaches a system outside its normal set, is anomalous in a way that admits few innocent explanations. Compare that to a human doing the same thing, where "they were covering for a colleague" is always available.

They hold privilege. Service accounts routinely have broader access than the humans who administer them, because narrowing it required effort nobody spent.

They are a known attacker target. Credentials in configuration files, in scripts, in source control. Compromise of a service account provides persistent access with legitimate-looking activity.

Nobody watches them. Most monitoring programmes are built around people, and the machine identities pass unremarked.

If a deployment has capacity to baseline one population well, service accounts return more per unit of effort than human users.

The entity resolution problem

Modelling entities requires knowing which events belong to the same entity. This is harder than it sounds and it is where deployments silently degrade.

One person may appear as several identities: a standard account, an administrative account, a cloud identity, an email address, a VPN username, an employee number. Unless these are joined, the model builds several thin baselines instead of one useful one — and an attacker moving between a user's standard and administrative accounts crosses a boundary the model cannot see.

Conversely, a shared account is several people appearing as one entity. The baseline becomes the union of everyone's behaviour, which is wide enough that almost nothing deviates from it. Shared accounts do not just weaken detection; they defeat it, and identifying them is a prerequisite worth doing before deployment.

This subject has its own entry on this site because it consumes more deployment time than any other single issue.

Modelling entities in relation to each other

The more interesting analytics are not per-entity but about pairs.

User to host. Which machines does this person normally use? A logon to a host they have never touched is meaningful in a way that neither the user's behaviour nor the host's behaviour alone reveals.

User to application. Which systems does this role normally reach?

Host to host. Which machines normally communicate? This is the basis of lateral movement detection, and it is a relationship model rather than an entity model.

Account to account. Which credentials are normally used from the same source?

Products vary enormously in whether they model relationships or only entities. It is worth asking directly during evaluation, because the difference determines whether lateral movement is detectable at all.

Practical starting points

Inventory the entities you have. Most organisations cannot produce an accurate count of service accounts. Producing one is itself a security exercise and frequently finds accounts nobody owns.

Classify service accounts by function. Backup, integration, application, scheduled task. Behaviour differs by class, and baselines are better per class than in aggregate.

Find the shared accounts. Then either eliminate them or exclude them from behavioural analytics, because keeping them in produces noise and false confidence.

Join identities before baselining. Retrofitting entity resolution after a model has trained means retraining everything.

Building the entity inventory

The inventory is the deliverable that makes everything else possible, and most organisations do not have one.

Start from the directory, then add what the directory does not hold: local accounts on servers, accounts inside applications with their own user stores, cloud identities in unfederated tenants, and API credentials.

Classify each entity by type — human, service, administrative, shared, external — because each class needs a different baseline window, a different feature set and a different set of plausible explanations during triage.

Assign an owner to every non-human entity. Not the person who created it; a named individual accountable for whether it should still exist. The accounts that cannot be assigned an owner are the finding.

Record what each service account is supposed to do. Which hosts, which operations, on what schedule. This document is itself a detection capability: a monthly comparison against reality catches misuse without any product involved.

Re-run quarterly. New entities appear continuously and the inventory decays faster than any other reference data.

Common false positives

Service account repurposing. An account originally created for one job is quietly reused for another. Behaviour changes completely, the model flags it, and the explanation is a change nobody documented.

Host reimaging. A machine reassigned to a different user has a baseline describing its previous role.

Automation changes. A scheduled job rewritten to run at a different time or against different systems.

Shared workstations. Reception desks, laboratory machines and shop-floor terminals have a behavioural profile that is the union of everyone who uses them.

Test and staging identities that mirror production accounts and generate parallel activity.

Blind spots and assumptions

That every event carries an entity identifier. Many do not. Network flow records, some cloud audit events, and older application logs frequently identify a source address and nothing else, which requires resolution against DHCP or VPN records that may not be retained.

That the entity is stable over time. People change roles. Service accounts get repurposed without documentation. Hosts get reimaged and reassigned. Each event invalidates a baseline, and few deployments detect it automatically.

That an entity has one baseline. A laptop used by a developer during the week and left running scheduled tasks at the weekend has two behavioural modes, and a single model averaging them fits neither.

That machine accounts are less risky because they are not people. The opposite is usually true: they have more privilege, less oversight, and no one to notice something is wrong.