Notifications
Clear all
Topic starter
06/09/2026 6:21 pm
TL;DR: Behavioral questions that single-event rules cannot answer are handled by baselining each entity against its own history with mergeable models for sets, shapes, counts, and drift, according to TENZIR. The result is detection logic that teams can version, test, and operationalise without opaque UEBA products, which makes behavioural analytics more governable and easier to audit.
NHIMG editorial — based on content published by TENZIR: behavioral detections as code in TQL
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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.
👉 Read TENZIR's article on behavioral detections as code in TQL →
Behavioral detections as code: can TQL replace opaque UEBA?
Explore further
06/09/2026 6:21 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Behavioral detections as code close the UEBA gap in TQL
