Building Behavioural Analytics In-House

The analytics in a UEBA product are not exotic. Per-entity aggregation, percentile baselines, peer comparison and an isolation forest are a few weeks of work for a competent data engineer on a platform that already holds the logs.

This makes building genuinely viable, and it makes the decision turn on something other than capability.

What building gets you

Features suited to your environment. You know which systems matter and what your business processes look like. Vendor defaults were chosen elsewhere.

Full explainability by construction. You know exactly how the score is computed, which matters enormously when a finding is challenged.

No opaque retraining. Your model changes when you change it.

Data stays where it is. No export to a vendor's platform, which simplifies the privacy assessment considerably.

Iteration at your pace. A new detector is a pull request, not a support ticket.

Much lower licence cost, offset by engineering cost.

What building costs

Ongoing engineering, not a project. Someone maintains the pipeline, updates parsers, watches for drift, adds detectors. This is the cost that sinks most builds, because it is invisible at the start.

Reinventing the operational layer. The analytics are the easy part. Case management, triage workflow, adjudication capture, access control, audit logging and reporting are most of the product and most of the work.

No vendor research. Product teams see many environments and encode patterns you have not encountered.

Key person risk. A homegrown system understood by one engineer is a liability when they leave, and this is the single most common way builds fail.

No support at 3am.

The hybrid that usually wins

Most successful builds are not full replacements.

Buy the platform, build the analytics. Use the SIEM or data platform for ingestion, normalisation, storage and case management. Build behavioural detections on top as scheduled queries and jobs. This is the pattern that most mature detection engineering teams converge on, and it captures most of the benefit at a fraction of the effort.

Buy for one population, build for another. A product for the general workforce, custom analytics for the ten systems that actually matter.

Buy the model, build the enrichment. Vendor analytics with your own context layer, which is frequently where most of the triage value sits.

What a minimal build contains

For an organisation considering it:

Per-entity, per-day aggregation of a dozen features. Rolling percentile baselines with a configurable window. Peer comparison where groups exceed a minimum size. A small set of high-precision rules alongside. Deviation scoring with visible per-feature contributions. Output into whatever queue your analysts already use.

That is a few weeks of engineering and it covers a large share of what a product delivers. What it does not cover is the maintenance, which is the actual question.

The honest test

Do you have an engineer who will own this for three years? Not a project team. A named person with allocated time.

If yes, building is frequently the better choice: cheaper, more explainable, better fitted.

If no, buy — because an unmaintained homegrown system decays faster than an unmaintained product, and it decays without anyone able to diagnose it.

A minimum viable build

For a team that has decided to build, the specification that gets to useful output fastest.

Daily per-entity aggregation. Twelve features: event volume, distinct hosts, distinct applications, distinct destinations, bytes out, authentication failures, failure ratio, distinct source addresses, privileged operations, off-hours proportion in local time, new-host indicator, new-application indicator.

Rolling percentile baselines, ninety-day window, per entity per feature, stored with observation counts.

Peer aggregation for the same features where the group exceeds fifteen members.

A deviation score as a weighted combination, with per-feature contributions stored alongside.

Six high-precision rules running independently of the scoring.

Output to your existing case queue, with the eight enrichment fields attached.

Four pipeline health metrics, as described in the data quality entry.

That is a few weeks of engineering and it delivers most of what a first-year product deployment delivers, with complete explainability.

Common false positives

Homegrown systems fail in their own characteristic ways:

Silent job failures, where a scheduled aggregation stops and nobody notices because there is no vendor dashboard.

Schema changes upstream breaking a parser that only one person understands.

Baseline recomputation errors after a backfill, producing a day of nonsense.

Feature definitions drifting as the query is edited without documentation.

Timezone handling implemented inconsistently between features written months apart.

No versioning, so a finding cannot be reproduced after the logic changed.

Every one of these is preventable with tests and documentation, which is exactly the work that gets deferred.

Blind spots and assumptions

That the analytics are the work. They are perhaps a fifth of it.

That the build is done when it works. It is done when someone else can maintain it, which requires documentation and tests nobody budgets for.

That buying avoids engineering. Integration, entity resolution and tuning are engineering regardless of who wrote the model.

That you can switch later. Migrating between either direction means rebaselining and retuning from scratch.