What changed? Behavioural baselines for database accounts

Imagine a service account that runs the same overnight report every weekday. One night it reads far more data than usual. The credentials are valid, and the query is allowed. Should someone investigate?

A fixed rule may have nothing to say about that event. A behavioural baseline adds another piece of context: how this account normally behaves. That can help an analyst decide where to look, provided the alert explains what changed.

Start with the account’s own history

Different database accounts have different jobs. A reporting account and an application login should not share a single definition of normal. Even one account can have several patterns: daytime traffic, an overnight batch, and a quieter weekend.

A useful baseline compares activity with the relevant history. Volume and time of day can both matter. A larger read during a scheduled reporting window deserves a different interpretation from the same read at an unfamiliar hour.

The alert should help reconstruct that comparison. Which account changed? Over what period? How far did its activity move from the expected range? A score without this context leaves the analyst doing the work again.

An unusual event still needs an explanation

Suppose the report changed because the finance team added another business unit. The spike is real, but it has a legitimate cause. A new integration, a recovery exercise, or a month-end job can produce the same sort of surprise.

This is why an anomaly is a reason to investigate, rather than a finding of misuse. Check the change record, the source of the connection, and the account’s purpose before deciding what happened. Keep the explanation with the alert so the next person can follow the decision.

Watch the learning period

An account with little history gives you little to compare against. A quiet learning period can also make the first busy week look suspicious. At the other extreme, harmful activity that persists can become part of the history you treat as normal.

Keep explicit security rules alongside the baseline. Known prohibited actions should remain prohibited even if they happen often. Review changes to a baseline when the account’s job changes, and keep monitoring collection gaps: missing events make any comparison less useful.

Our choice in Vyrell

Vyrell’s deployed behavioural analytics use statistical scoring, including volume and time-of-day comparisons, with an explanation view for investigating the result. They work alongside the security rule library.

We describe that approach as statistical because it describes what runs. It is not a claim that statistical methods always outperform machine learning. The practical test is whether the system surfaces useful changes and gives the person reviewing them enough information to act.

When evaluating a baseline, bring an ordinary batch job and a deliberately unusual test event. Ask to see why each scored as it did. That tells you more than an impressive label on the dashboard.