Modelling Privileged Users

Privileged accounts are the smallest population, the highest consequence, and the one most likely to be excluded from behavioural analytics because they generate too many alerts.

That exclusion is the single most common self-inflicted blind spot in this field.

Why they generate noise

Administrators legitimately do what the model was built to find suspicious: touch many hosts, use elevated rights, work outside hours during maintenance, access systems outside any single role, run unusual commands.

Compared against a general workforce baseline, an administrator is anomalous continuously.

The wrong fix and the right one

Wrong: exclude the account. Now the credentials with the broadest access in the environment are unmonitored, which is precisely inverted from where scrutiny should concentrate.

Right: model them separately, against each other, on different features.

Features that work for this population

General workforce features are poor here. These work better:

Target sensitivity, not target count. An administrator reaching thirty workstations is routine; reaching a domain controller from an unfamiliar source is not. Weight by what was touched.

Deviation from the administrator peer group. Compare administrators to administrators. The group is small but behaviourally coherent, which partially offsets the size problem.

Command and action profile. Which administrative operations does this person normally perform? Someone who administers databases suddenly touching directory objects is meaningful.

Elevation pattern. With just-in-time access, the request pattern itself is behaviour: frequency, duration, scope, time of day, and whether requests correlate with tickets.

Source host set. Administrators normally work from a small number of jump hosts or workstations. A privileged credential used from an unfamiliar source is high-precision.

Standard-to-privileged pairing. Whether the administrative account is used at times when its owner's standard account is inactive. Divergence between an administrator's two identities is one of the strongest available signals and requires the entity resolution join.

Actions against the logging and monitoring infrastructure. Rare, high signal, and this population is the one that can perform them.

Detections with near-zero false positive rates

Available immediately and worth enabling regardless of any modelling:

Service account interactive logon. Administrative group membership change outside a change window. Creation of a new privileged account. Modification of logging or audit configuration. Access to a domain controller from a non-administrative subnet. Use of a break-glass credential. Privileged authentication from a source that has never issued one.

These require no baseline and catch a meaningful share of realistic scenarios.

The structural problem

The people who administer the monitoring platform are frequently the people being monitored.

Forward logs to a platform they do not administer. Different credentials, different team, retention they cannot shorten. Without this, administrative activity records are not evidence.

Audit access to monitoring data, and route that audit outside the security team.

Require two people for the highest-consequence actions — bulk export, logging configuration changes, mass permission changes.

This is uncomfortable to propose because it implies distrust of colleagues. The framing that works is that it protects them: an administrator whose activity is independently logged cannot be plausibly accused later.

Third-party administrators

Managed service providers hold privileged access, sit outside HR processes and are invisible to departure workflows.

Distinguishable identities, so they can be filtered in every log. Time-bound access by default. Named internal sponsor per account. Contractual notification when their staff change.

The most common serious finding in any access review is an active administrative account belonging to a contractor who left the supplier two years ago.

An administrator monitoring baseline

A specification for the population that most needs it, implementable without a product.

Per administrative account, maintain: the set of source hosts used, the set of target systems reached, the set of administrative operation types performed, the normal elevation request pattern, and the times of day of privileged use.

Compare against the administrator peer group, not the general workforce.

Alert on set additions weighted by target sensitivity, not on counts.

Pair the administrative account with its owner's standard account. Divergence — the administrative account active while the standard one is dormant — is among the strongest available signals and requires only the entity resolution join.

Review the whole population monthly rather than alerting continuously. Administrators are few enough that a periodic review is feasible and produces better judgement than a queue.

Common false positives

Administrative work that resembles compromise, and how each is recognised:

Incident response, where responders access everything urgently and legitimately.

Migrations and upgrades, touching many systems in a compressed period.

On-call work, producing night activity that is scheduled.

Break-glass use during a genuine outage.

Automation run under an administrator's credentials rather than a service account, which is a hygiene finding as well as a noise source.

Vendor support sessions, where a third party operates through an internal account.

Correlating against the change calendar and the ticketing system resolves the majority of these before an analyst sees them.

Blind spots and assumptions

That administrators would notice misuse of their own credentials. They frequently would not; their normal activity is broad enough to hide a great deal.

That the peer group is meaningful. With four administrators, statistical comparison is weak, and set-based features work better than statistical ones.

That exclusion is temporary. Exclusions written during a noisy first month become permanent.

That privileged means administrative. A finance approver, an HR system owner or a database analyst may have more consequential access than a domain administrator, and none is in the administrators group.