Feature Engineering for Behaviour

A model can only detect deviation in what it measures. Feature selection is therefore the most consequential design decision in a UEBA deployment, and it is usually inherited from a vendor default nobody examined.

Families of feature

Volume. Counts per window: events, bytes, files, records, sessions. Cheap, robust, and the basis of most real detections.

Diversity. Distinct values per window: hosts touched, applications used, destinations reached, records accessed. Frequently more informative than volume, because breadth changes before depth in most intrusion patterns.

Novelty. Whether a value has been seen before for this entity. Powerful and noisy; see the entry on rarity.

Temporal. Hour of day, day of week, session duration, inter-event gaps. Fragile for distributed workforces and covered separately.

Ratio. Failures over attempts, reads over writes, external over internal. Ratios are robust to overall volume changes, which makes them stable when raw counts are not.

Relational. Properties of pairs — this user and this host, this host and this destination. Where lateral movement lives.

Sequence. Order and timing of event types. Expensive and the only way to catch patterns defined by ordering.

What makes a feature good

Stable when nothing is wrong. If a feature varies wildly for legitimate reasons, deviation carries no information. Test this before deploying: compute it over a quiet month and look at the variance.

Responsive when something is wrong. A feature that stays flat during a known incident is not earning its place. Replaying a past incident, or a red team exercise, is the only reliable way to check.

Cheap to compute. Features requiring joins across large windows constrain how often you can score.

Explainable. An analyst must be able to say what it measures without consulting a data scientist. This is not a nicety; it determines whether findings can be defended.

Not a proxy for something you may not use. Hour-of-day is a proxy for working pattern, which correlates with caring responsibilities, disability and religion. Location is a proxy for several things. Check what a feature is really measuring.

Aggregation windows

The same feature at different windows detects different things.

Short windows — an hour — catch bursts and miss slow accumulation.

Long windows — thirty days — catch drift and miss bursts entirely.

Several windows for the same feature is usually the right answer, at the cost of correlated scores that must be handled in aggregation.

The common error is a single daily window for everything, which is too coarse for bursts and too fine for drift.

The correlation trap

Features derived from the same underlying activity are not independent evidence.

Bytes transferred, files transferred, and duration of transfer all measure one action. A scoring function treating them as three independent deviations triples the contribution of one fact.

Check correlation between features on real data before combining them. Where features are highly correlated, keep one or model them jointly. This is a half-day of work that materially improves score quality and is almost never done.

Features worth adding that vendors rarely include

Access to resources outside the entity's role, joined against entitlement data. High precision because the business rationale is absent by construction.

Ratio of failed to successful authentication, per entity. Stable, cheap, and it moves early in credential attacks.

Distinct destinations for data egress, rather than volume. Breadth is a better signal than size for collection behaviour.

Time since last activity. Dormant accounts waking up are a strong signal and few models include dormancy.

Deviation of an entity's baseline from its peer group's baseline. Not deviation of today's behaviour, but of the entity's own normal. This catches entities whose baseline was poisoned during training, which nothing else does.

Testing a feature before you deploy it

Four checks, each cheap, that between them prevent most feature-related noise.

Variance over a quiet period. Compute the feature across all entities for a month with no known incidents. A feature whose values swing wildly for ordinary work will produce deviation that means nothing.

Correlation against existing features. If it moves with something you already have, it is not new evidence. Compute the correlation matrix once; it takes minutes and it prevents double counting.

Response to known activity. Replay a past incident, or a red team exercise, and check whether the feature moved. A feature that stays flat when something real happened is not contributing.

Distribution across populations. Compare the feature's distribution across departments, locations and working patterns. A feature that differs sharply by region or by working hours is measuring circumstance, not behaviour, and it will produce persistent bias.

Then check what it costs. Computation, storage and the join complexity it introduces.

Common false positives

Feature-driven noise has recognisable signatures:

Volume features on sources with duplicate delivery, which double for affected entities only.

Diversity features counting technical artefacts — a script iterating over hosts inflates distinct-host counts without meaningful behaviour.

Ratio features with small denominators, where two failed logins out of three attempts produces an extreme ratio from trivial activity.

Temporal features on entities with no reliable local time.

Novelty features during any rollout, which fire for the whole population at once.

Aggregation windows misaligned to the work, splitting one task across two windows.

Blind spots and assumptions

That more features are better. Beyond a point they add correlation and noise. A dozen well-chosen features outperform sixty defaults.

That vendor defaults suit your environment. They were selected against a reference environment that is not yours.

That a feature measures what its name says. "Data transferred" may exclude a protocol. "Systems accessed" may count only those with logging enabled.

That features are static. As the environment changes, some stop carrying signal. Reviewing feature contribution annually is worth the afternoon it takes.