A UEBA peer group has one member after a reorg - how does that distort the user's risk score?

## Where a peer group comes from A UEBA peer group is a cohort the product compares a user against, in addition to comparing them with their own history. It is almost never hand-drawn. It is derived from identity attributes imported from the directory or the HR system - department, job title, cost centre, manager, office location - or inferred from behaviour, such as which applications and file shares a set of accounts have in common. Either way, the membership is data whose freshness depends on a sync, and the sync is on someone else's schedule. That matters because peer-relative reasons are among the most persuasive-looking things a UEBA console produces. "Read volume above the 95th percentile for this user's peers" sounds like a strong claim about a population. It is only as strong as the population. ## What breaks when the population is one After a reorganisation, three failure shapes appear: - **A group of one.** A team is split, people move, and one person keeps a title nobody else now holds. The percentile is computed over a single sample - themselves. - **A stale group.** The user moved role six weeks ago but the HR attribute has not synced, so they are compared against people whose work they no longer do. Every part of the new job is an outlier. - **A newly created group.** A cohort that came into existence last week has no accumulated history to compare against, so the comparison is either unavailable or thin enough to be meaningless. In the group-of-one case the specific damage is that the peer baseline stops being an independent second opinion. The product's design intent is that two different comparisons - "unusual for you" and "unusual for people like you" - reinforce each other before the score gets high. With one member, both comparisons measure the same thing, so the redundancy is gone and the score rises on evidence that is one observation wearing two labels. ## The worked case A large enterprise reorganises its finance function. One analyst is now the sole holder of a reporting role. At quarter end she does what that role does every quarter: connects over VPN late into the evening for four consecutive nights, logs on to a reporting file server she touches four times a year, and pulls tens of gigabytes of statements off a share. The timeline lights up. "First logon to this server in 90 days." "Read volume 8x her 30-day median." "Read volume above peer 95th percentile" - true, trivially, because the peer set is her. "VPN session outside normal hours", four nights running. The queue is worked top-down and she is rank 1 with 92 points. Everything the tool said is factually correct. Nothing about it is a finding. ## How to work it, and how to close it Collapse the breakdown to the distinct observations: four VPN sessions, one new server, one volume of reads. Then look for authorisation *outside* the security tooling - the reporting calendar, her manager, the finance close schedule, whether the same pattern exists in the prior year's records for the person who used to hold the role. Confirm the credential use is consistent with her actually working: a successful authentication record on its own proves only that a credential was accepted, so corroboration from her own account of the week matters. Then label it correctly. This is a **benign true positive**: the activity occurred, it did deviate from the baseline, and it was authorised. It is *not* a false positive. The distinction is not pedantry - it tells whoever maintains the analytics that the detection logic worked and the *population* was wrong, which is a completely different repair from re-tuning a threshold. ## Fixing the population, not the case The score itself will decay on its own; there is usually nothing to retract. The durable fix is membership: - Rebuild the cohort at the level that has enough members to be a real distribution - the finance function rather than the single title. - Make the peer-group source data a monitored dependency. If the HR sync is stale or a group has fewer than some minimum number of members, that is a data-quality problem the SOC should see, not a silent scoring change. - Watch out for the inverse: over-broadening the cohort until everyone's behaviour is normal somewhere in it, which suppresses the score you actually wanted. And expect recurrence. Role-specific rhythm repeats - quarter end comes back. If the only thing you did was close a case, the same person tops the queue again in three months, and the third time an analyst sees her name they will start reading it as a pattern about her rather than a pattern about the group.