UEBA, NDR, EDR: Where Behavioral Anomaly Detection Actually Fits
A normal-looking login at 2 p.m.
A maintenance host gets an interactive login at 2:14 p.m. The account is real. The password works. The binary that opens the session is a standard remote-access tool the environment already allows. Nothing looks like malware. On the clock, it looks ordinary: middle of the workday, authorized user, allowed path.
Your stack may still stay quiet, and not one of these tools has a reason to fire. Endpoint tools often see an authorized user and a known process. Network tools often see allowed internal traffic on expected ports. Identity analytics may fire if that account is out of character, and may stay silent if the account is supposed to reach that server. Here is what almost nobody models: nobody logs into this box at 2 p.m. The ops team only touches it after hours. Its normal is the opposite of the corporate calendar, so the one thing that should have raised a flag, a login in the middle of the afternoon, is the one thing that looks most routine. Rules and signatures never had a chance. There was no known-bad hash, and no rule written for "valid user, wrong time-of-day for this box."
That is not a failure of those tools. It is what they were built to look for. The honest way to tell categories apart is two questions: where does it look, and what does it assume is normal? Those two answers explain what a tool will catch, what it will miss, and why you run more than one of them.
None of these categories is dead weight. Each earns its place. The point is to see clearly what each was built to do, so the gap they share comes into focus, and so you can decide whether anything you run today is filling it.
What each category is good at
SIEM and the signature layer
Intrusion detection systems and SIEM correlation rules catch two things well: known-bad, and exactly what you told them to look for. A network IDS matches traffic against published signatures. A SIEM rule fires when events line up in a pattern an engineer wrote down. This is fast, precise, and explainable, and it is the backbone of most detection programs for good reason.
The catch is in the premise. These tools find what is already known or already specified. A novel technique with no signature, or an attack that never trips a rule someone thought to write, passes through clean.
EDR (and XDR)
Endpoint detection and response lives on the host. EDR is strong on known-bad at the endpoint, and modern EDR adds real behavioral logic: suspicious process trees, credential-dumping patterns, ransomware-style file activity. It is telemetry-heavy, which is its strength and its cost. It sees process creation, command lines, and module loads in detail.
XDR is often that same endpoint-heavy telemetry plus broader correlation across email, identity, or cloud signals. The center of gravity is still the endpoint stack and known-bad or suspicious patterns, not a private model of how each individual machine usually behaves at 2 p.m. on a Tuesday, or after midnight on the same box.
Much of the heavier analysis runs in a cloud backend. For most enterprises that tradeoff is fine. For secure networks that limit or deny cloud access, it is a hard constraint. Even when the analysis is on-prem, the analytic object is usually "does this match a threat pattern?" more than "is this host still itself?"
NDR
Network detection and response watches traffic instead of the host. NDR analyzes flows, protocols, and connection patterns to surface beaconing, lateral movement, and data movement that looks wrong. It sees the parts of an attack that cross the wire, including activity on devices that cannot run an agent at all.
NDR is often delivered as an appliance or routed through a cloud analysis tier. It reasons about the network as a whole rather than about what any single host is doing minute to minute. That is why it remains essential for agentless and east-west visibility, and why it can miss a quiet host-level shift that never looks wrong on the wire.
UEBA
User and entity behavior analytics looks at accounts and entities. It is usually a module on top of a SIEM, and it asks whether a user is acting like themselves: logging in at odd hours, reaching systems they never touch, moving more data than usual. UEBA is genuinely useful for insider and compromised-account cases.
It is also the category closest in spirit to behavioral anomaly detection: both compare recent activity to a learned normal. The difference is the object. UEBA's frame is the identity across the environment. Host-level behavioral detection's frame is the machine: a deep, per-host model of how that box behaves across many metrics, split by time of day. Same idea of deviation, different unit of analysis, different data, different blind spots. An account that is "allowed" can still drive a host that is no longer behaving like itself.
| Category | Looks at | "Normal" means | Strong at | Blind to when… |
|---|---|---|---|---|
| SIEM / signatures | Events + known patterns | What rules and signatures encode | Known-bad, specified sequences | Nothing matched a rule or signature |
| EDR / XDR | Endpoint telemetry | Known-bad and suspicious patterns | Process trees, malware-like host activity | Activity looks authorized and pattern-clean |
| NDR | Network flows | What traffic should look like | Beaconing, lateral movement on the wire, agentless devices | Host behavior changes without ugly network shape |
| UEBA | Users and entities | How this identity usually acts | Account misuse, odd access and data movement | The account is plausible but the host is not itself |
The gap they share
Put those layers side by side and a shape is missing from the middle.
None of them is built, as its center of gravity, to answer one specific question: is this particular host behaving the way this particular host normally behaves, right now, at this hour, across a private baseline of many metrics rather than a shared threat pattern?
- The signature layer asks whether the activity matches something known.
- EDR centers the endpoint but leans on known-bad and suspicious behavioral patterns, often at cloud scale.
- NDR centers the network.
- UEBA centers the account.
A private, per-host, time-aware behavioral baseline, one that knows a quiet afternoon on this box is not the same as its busy after-hours window, sits in the seam between them.
Go back to the 2 p.m. login on the after-hours host. Rules never saw a signature. EDR may have seen a valid session. NDR may have seen allowed internal traffic. UEBA may have stayed quiet if the account was in bounds. Calendar-based "business hours" logic would have called 2 p.m. normal. The question nobody owned was whether that host, at that hour, had stopped looking like itself.
Two practical constraints sharpen the same gap. First, where the model lives. A large share of behavioral and self-learning tools assume they can reach a cloud backend. In a secure network that limits or denies cloud access, that assumption fails and the coverage goes with it. Second, what is being baselined. Even online, many "behavioral" products optimize for fleet-scale patterns or opaque model scores rather than a readable, per-host, time-of-day normal you can take apart in a handoff. A score you cannot explain is a score an analyst cannot defend in a report or an audit.
Where Qato fits
Qato is behavioral anomaly detection at the host level, built for that seam. It is not a replacement for the layers above.
Lightweight agents on Linux and Windows hosts report behavioral metrics: process creation, network connections, listening ports, authentication events, and more. The server learns a private baseline for each metric on each host, with separate profiles for business hours, off-hours, and weekends. A host is judged against its own normal at the right time of day. There is no public baseline list for an attacker to download and pre-test against.
Every score is explainable by construction: how far each metric drifted from that host's baseline, summed into a total the analyst can read metric by metric. Recurring anomalies on one host group into a detection. Related detections across hosts assemble into an episode, a kill chain or an outbreak, so the queue shows a narrative instead of a pile of disconnected alerts.
What it does not do matters for placement. It does not replace EDR, NDR, UEBA, or SIEM. It does not prevent or block. It does not own agentless OT the way NDR can, or identity misuse the way UEBA can. It detects when a host has stopped behaving like itself, explains which behaviors moved, and hands that to the stack you already trust.
How to think about layering these
The categories are not a tournament with one survivor. They are layers that fail in different directions, which is why you run several.
When you review your own program, ask:
- Known-bad and specified patterns. Do rules, signatures, and EDR cover the threats and sequences we already understand?
- The wire and agentless. Does NDR (or equivalent) see east-west and devices that cannot run an agent?
- Identity. Does UEBA (or equivalent) catch accounts that stop acting like themselves?
- This host, this hour. Does anything learn a private, per-host, time-aware baseline, score deviation in a way an analyst can take apart, and surface when a machine is no longer itself?
Qato is honest about its boundary: it is built for question four. It is additive. The question is not which acronym wins. It is whether anything you run today is genuinely answering, per host, at the right hour, with reasoning you can read: is this machine still itself?
If the answer is no, that is the seam, and it is the seam a quiet, malware-free intrusion is built to use.
Beyond signatures. Beyond rules. Detect the unknown.