What is NDR?

Start with Gartner's market definition

NDR products apply behavioral analytics to network traffic data, analyzing raw packets or traffic metadata inside the network (east-west) and between internal and external networks (north-south). They include automated responses such as host containment or traffic blocking, built in or through integration with other security products. Gartner positions NDR as a complement to tools that alert on rules and signatures, and names ransomware, insider threats and lateral movement as the post-breach activity organizations buy it to catch.

The idea is older than the acronym

NIST SP 800-94, the 2007 guide to intrusion detection and prevention systems that remains NIST's final publication on the subject (a 2012 draft revision was retired), splits these systems into four classes: network-based, wireless, network behavior analysis (NBA) and host-based. NBA, in NIST's words, examines network traffic to identify threats that generate unusual traffic flows, such as DDoS attacks, certain forms of malware and policy violations. Modern NDR is NBA with more protocols decoded, learned baselines in place of fixed thresholds, weeks of metadata kept for hunting, and response actions attached.

NDR gets compared with IDS, EDR and XDR

An IDS such as Suricata, which describes itself as a network IDS, IPS and NSM engine, matches traffic against rules and raises an alert per match: it tells you a known-bad pattern crossed the wire. NDR asks whether a host is behaving differently from its own history and from its peers, which covers traffic no rule describes. Some NDR platforms bundle an IDS engine as well (ExtraHop sells an IDS module for RevealX), so the difference is which method leads.

EDR sees inside one host: processes, command lines, files and the connection each process opened. NDR sees only the wire, but it sees every device that sends traffic past a sensor, including printers, IP cameras, OT controllers and unmanaged laptops that can't run an agent. It keeps watching when an attacker turns the EDR agent off, the kind of move ATT&CK v19 files under TA0112 Defense Impairment.

XDR correlates endpoint, identity, email, cloud and network signals into one incident, and NDR is one of the feeds it can correlate.

The SIEM stores and searches all of it, NDR detections included.

Under the hood, most of the evidence is connection metadata

Zeek, the open-source network monitor that RITA and CISA's Malcolm suite both ingest, writes one line per connection to conn.log: ts (start time), uid, id.orig_h and id.orig_p (who opened it), id.resp_h and id.resp_p (who answered), duration, orig_bytes, resp_bytes and conn_state. Connection states carry a lot of detection value:

• S0 is a connection attempt seen with no reply,
• REJ is an attempt that was rejected,
• and SF is a normal establishment and termination.

Suricata's EVE JSON output writes a flow record per connection (bytes_toserver, age and more) and, when enabled in its configuration, JA3 and JA4 fingerprints of the TLS handshake, which can tell one client implementation from another without decrypting anything. Malcolm takes the same three inputs, PCAP, Zeek logs and Suricata alerts, and normalizes them for analysis.

Here is a beacon in conn.log

(Simulated example generated by SOCSimulator Research.)

Workstation 10.20.4.17 opens a short TLS connection to 203.0.113.45 on port 443 roughly every five minutes, all day:

{"ts":1791763200.000000,"id.orig_h":"10.20.4.17","id.resp_h":"203.0.113.45","id.resp_p":443,"duration":0.41,"orig_bytes":1318,"resp_bytes":245,"conn_state":"SF"}

then the same pair at ts 1791763489.43, then at 1791763768.48. Each connection lasts under a second, the request is about the same size every time, the reply is small, and over 24 hours there are 288 of them. No single line looks wrong; the evidence is the regular interval across all of them.

On Zeek logs in the tab-separated format, zeek-cut and awk are enough to surface pairs like that:

zeek-cut ts id.orig_h id.resp_h id.resp_p < conn.log |
  sort -k2,2 -k3,3 -k4,4 -k1,1n |
  awk '{k=$2" "$3":"$4; if(k==p){g=$1-t; n[k]++; s[k]+=g; q[k]+=g*g} p=k; t=$1} END{for(k in n) if(n[k]>=50){m=s[k]/n[k]; sd=sqrt(q[k]/n[k]-m*m); if(sd<0.2*m) printf "%s conns=%d avg=%.0fs sd=%.1fs\n", k, n[k]+1, m, sd}}'

It groups connections by source, destination and port, measures the gap between consecutive connections in each group, and prints the groups with at least 50 gaps whose standard deviation stays under 20% of the average. Against the simulated day it prints:

10.20.4.17 203.0.113.45:443 conns=288 avg=299s sd=17.5s

a five-minute beacon with about 10% jitter. Software that polls on a timer (update agents, monitoring) shows up too, so the next questions are which process opened the connections, an EDR question, and how old the destination is. RITA runs this kind of beacon scoring at scale on imported Zeek logs and also flags long connections, the C2 style that holds one session open and leaves no gaps to measure.

Connection states expose internal scanning the same way. A workstation that produces hundreds of S0 and REJ entries against many internal addresses on 445 or 3389 within minutes is doing Network Service Discovery (T1046), and the sensor records it whether the scanner is a dropped tool or something already on the box. ATT&CK notes that Volt Typhoon did this step with commercial tools, living-off-the-land utilities and appliances already present on the system.

The limit of all of this is sensor placement. NDR sees only the segments it is attached to, so east-west coverage depends on where the taps, SPAN ports and cloud traffic mirroring actually sit.