Behavioral detections as code close the UEBA gap in TQL

At a glance

What this is: This article explains how behavioral detections can be built as code in TQL using entity-specific baselines, mergeable models, and readable scoring logic.

Why it matters: It matters because detection teams can govern anomalous behavior without opaque UEBA tooling, while preserving the auditability and review discipline needed in SOC and identity-adjacent analytics.

By the numbers:

• NHIs outnumber human identities by 25x to 50x in modern enterprises.
• Only 5.7% of organisations have full visibility into their service accounts.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read TENZIR's article on behavioral detections as code in TQL

Context

Behavioral detection fills the gap between single-event rules and opaque analytics platforms. A rule can state that a process name matches or a byte threshold is exceeded, but it cannot express whether this host has ever run that binary or whether this source is unusually chatty for its own history. In identity-adjacent detection, that same problem appears when a service account, workstation, or workload suddenly behaves outside its learned pattern.

TENZIR’s approach treats those questions as data problems rather than product problems. It routes OCSF events, learns per-entity baselines, and scores new observations against the history of the same entity, which makes the logic readable and versionable instead of hidden inside a black box. That is a practical shift for SOC teams that want behavioral analytics without giving up control over detection logic.

For identity and NHI practitioners, the intersection is real: service accounts, workstations, and workloads all exhibit entity-level behavior that can be baselined, but only if the underlying identity or asset is stable enough to key the model correctly. The article’s starting point is typical for modern detection engineering, where teams need per-entity context rather than fleet-wide averages.

Key questions

Q: How should security teams implement behavioral detection as code without using opaque UEBA tools?

A: Teams should express behavioral logic in queryable pipelines, keep baselines as data, and tie each detector to a stable entity key such as host or account. That makes the scoring reproducible, testable, and reviewable in the same change-control process as rules. The goal is not more analytics theatre, but detection logic that analysts can inspect and improve.

Q: Why do entity-specific baselines reduce false positives in detection engineering?

A: Because the same activity can be normal for one entity and suspicious for another. A workstation that rarely contacts a destination should be judged differently from a monitoring server that does it constantly, and a process common on one host may be a first sighting on another. Entity-relative scoring preserves context that fleet-wide thresholds erase.

Q: What are the signs that a behavioral model is not working as intended?

A: Common signs include high alert volume on predictable hosts, scores that do not change when behavior clearly shifts, and baselines that cannot be printed or inspected. If analysts cannot explain why a score was produced, the model is too opaque to govern. If the key is too broad, the baseline is probably mixing unrelated behavior.

Q: How do teams choose between set, count, and distribution models for behavioral analytics?

A: Use a set model when you care whether something has been seen before, a count model when you care how many distinct things occurred, and a distribution model when you care how the shape or mix changed. The control question should determine the model, not the other way around.

Technical breakdown

Why single-event rules fail for entity-level behavior

Single-event rules answer whether an observation matches a condition, but they cannot answer whether the observation is normal for that specific entity. Behavioral detection needs a baseline keyed to the entity itself, such as host, source IP, or account, because the same value can be routine for one asset and anomalous for another. That is why a threshold, allowlist, or Sigma-style rule often produces false positives or misses slow, low-and-slow deviation. The architectural shift is to compare current events with a stored model of past behavior instead of a fixed policy value.

Practical implication: build per-entity baselines before tuning thresholds, or you will keep encoding fleet averages into controls that need local context.

Mergeable models for sets, shapes, counts, and drift

The article separates behavior into four model types. Frequency tables capture sets such as process names or queried domains. t-digests capture numeric shapes such as bytes out or session lengths. HyperLogLog captures distinct counts such as how many destinations a source reaches in a window. Model divergence compares distributions, which matters when the mix changes even if no single value is novel. Because each model is mergeable, the detector can learn in batches, store a compact row per entity, and later enrich live events with that row.

Practical implication: choose the model type that matches the question, because set membership, count extremes, and distribution drift are different control problems.

Behavioral detection as code and the identity of the model

The strongest architectural point is not the scoring formula but the fact that the model is transparent data. A baseline can be printed, diffed, tested, and version-controlled like any other artifact, which makes behavioral detection reviewable instead of opaque. The article also treats the baseline as part of the lookup key, so one feature cannot overwrite another. In practice this is a governance issue as much as a detection issue, because the model has an identity, a lifecycle, and a scope that must be managed explicitly.

Practical implication: treat behavioral baselines as governed assets with ownership, versioning, and feature-specific keys, not as hidden detector state.

NHI Mgmt Group analysis

Behavioral detection becomes governable only when the model is visible. Opaque UEBA products often hide the scoring logic, the baseline, and the feature selection behind vendor-managed models that analysts cannot inspect. By expressing behavioral logic as TQL and storing the baseline as queryable data, the control becomes reviewable and auditable rather than implied. That matters to SOC and identity teams because detection quality is inseparable from governance quality.

The named concept here is entity-relative anomaly scoring. The article is really about judging one entity against its own history, not against a global norm. That is a better fit for hosts, users, and service accounts because normal behavior varies sharply by entity type, workload, and role. For practitioners, the implication is straightforward: if the baseline is not entity-specific, the anomaly is probably not either.

Detection engineering and NHI governance now overlap operationally. The same logic used to spot a host running an unfamiliar process can also surface unusual service-account or workload behavior when the identity is stable enough to baseline. That does not make the detector an IAM control, but it does mean identity context improves detection fidelity. Teams that can tie alerts to the right identity scope will reduce noise and improve response.

Model lifecycle matters as much as model quality. A baseline that is stale, immature, or keyed too broadly will produce misleading scores even when the math is sound. The article’s insistence on per-entity rows, mergeable state, and readable outputs reflects a broader control pattern: the detection artifact needs ownership, refresh, and testability. Practitioners should manage behavioral models as living controls, not one-time analytics outputs.

What this signals

Entity-relative anomaly scoring is increasingly the practical bridge between SOC analytics and identity context. As organisations add more service accounts, workloads, and automated processes, the value is shifting from fleet-wide rules to controls that understand what is normal for one identity or host at a time. The NIST Cybersecurity Framework 2.0 remains useful here because detection quality depends on the quality of the underlying asset and identity inventory, not just on the alerting layer.

The operational signal for practitioners is that detection engineering is becoming a governed data discipline. Baselines need owners, review cycles, and feature-level scope boundaries, otherwise the model itself becomes a hidden privilege point in the stack. That is especially true when identity context matters, because a weak entity key creates noisy alerts that obscure real behavioural change.

Teams that already struggle with service-account visibility should assume the same blind spots will affect behavioral analytics unless they connect detection pipelines to lifecycle controls. The NHI Lifecycle Management Guide is the right companion resource when the problem is not only anomaly scoring but also knowing which identities exist, who owns them, and when they should be retired.

For practitioners

• Implement per-entity lookup keys Key behavioral baselines by the smallest stable entity that makes sense, such as host, source IP, or account, and keep feature identities separate so one model cannot overwrite another.
• Match the model to the question Use frequency tables for sets, t-digests for numeric distributions, HyperLogLog for distinct counts, and distribution-divergence scoring for mix changes instead of forcing one detector style everywhere.
• Version and test baseline logic Store behavioral pipelines in Git, add fixtures for known-normal and known-anomalous patterns, and review scoring changes the same way you review rule updates.
• Tie behavioral alerts to identity context Enrich detections with asset and identity metadata so analysts can distinguish a normal process on a server from the same process on a workstation or service account.

Key takeaways

• Behavioral detections work best when they compare each entity to its own history rather than to a fleet-wide rule.
• Readable, mergeable models make anomaly scoring auditable, versionable, and easier to operate than opaque UEBA tooling.
• Identity-aware baselines improve detection quality, but they still depend on lifecycle discipline, ownership, and stable entity keys.

Key terms

• Entity-Relative Anomaly Scoring: A detection method that evaluates an event against the past behavior of the same host, user, account, or workload. It is more precise than fleet-wide thresholds because normal behavior varies by entity, role, and environment, and that variation is often the signal analysts need.
• Frequency Table: A compact model that records how often each categorical value appears for an entity, such as process names or destination domains. It supports first-sighting and familiarity-style detections by showing whether a value is common, rare, or entirely unseen for that specific entity.
• T-Digest: A bounded sketch that approximates numeric distributions while staying small enough to store and merge efficiently. In behavioral detection, it is useful for comparing a live value against the historical shape of bytes, durations, or other numeric telemetry without keeping every raw event.
• Model Divergence: A comparison method that measures how much one distribution differs from another. In this context it helps detect behavior changes where no single value is novel, but the overall mix of activity has shifted enough to indicate drift, abuse, or an attack in progress.

What's in the full article

TENZIR's full article covers the operational detail this post intentionally leaves for the source:

• Runnable TQL pipelines for frequency tables, t-digests, HyperLogLog, and model divergence across OCSF streams.
• Concrete examples for Sysmon, Zeek, and mixed Windows telemetry that show how the same scoring pattern adapts by feature.
• Lookup-table patterns for storing and refreshing per-entity baselines without rewriting detector logic.
• Demo dataset instructions for reproducing the detections on sample traffic before adapting them to production data.

👉 TENZIR's full article shows the runnable pipelines, baselines, and demo data behind the examples.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It gives practitioners a common control language for programmes that now span people, workloads, and automated systems.