Network Detection and Response (NDR): — Seeing the Attacker the Firewall Missed

① Why NDR — prevention is a wall with no cameras behind it

Meet Sneha, an L1 SOC analyst at Infosys. Her dashboard shows the perimeter firewall blocked tens of thousands of known-bad packets overnight — a comforting green number. But last Tuesday a finance user clicked a link in a convincing invoice email, and a foothold quietly landed on his PC (10.20.4.17). The firewall logged that web request as allowed — because to it, it looked like normal browsing. From that moment the firewall is blind to what happens next.

Here is the structural problem. A prevention control (firewall, IPS) can only inspect traffic that physically crosses it, and it mostly decides using signatures — patterns of things already known to be malicious. Two gaps fall straight out of that: anything never seen before has no signature, and anything that never crosses the firewall — like one internal server talking to another — is simply not on its radar.

Networks have two directions of traffic. North-south is traffic in and out to the internet — it crosses the firewall, so prevention sees it. East-west is traffic between internal systems: the foothold PC probing the file server, then pivoting to the domain controller. That east-west traffic almost never touches the perimeter firewall, so it is exactly where an attacker hides — and exactly what NDR is built to watch.

So what does NDR actually consume? It taps a copy of network traffic — via a hardware TAP, a switch SPAN/mirror port, or flow records (NetFlow/IPFIX) — and turns those packets into metadata: who talked to whom, when, how often, how many bytes, which TLS fingerprint, which DNS names. Because it sits out-of-band (off to the side, not in the data path), it can never become a bottleneck or accidentally drop your production traffic — it just observes.

Four behaviours prevention misses — and NDR catches

Tap each card. These are the four moves an attacker makes once inside, none of which trips a perimeter signature.

② How NDR detects — baselining, metadata, encryption & ATT&CK

The heart of NDR is one shift in thinking: instead of asking "does this packet match a known-bad pattern?" (the IDS question), it asks "is this behaviour normal for THIS host?". To answer that, it first learns a baseline — what each host and each role usually does — typically over a learning window of around two weeks. After that, a connection that breaks the baseline scores high even if no signature exists for it.

Crucially, NDR does this on metadata, not payload. From every connection it extracts the timing, byte counts, ports, connection duration, the SNI, the certificate fields, and the DNS query shape. Machine learning then clusters hosts into peer groups (all the developer laptops behave alike; all the print servers behave alike) so 'abnormal' is judged against the right neighbours, not the whole network.

Over 85% of modern attack traffic rides inside TLS, so "just decrypt everything" sounds tempting — but it's costly, breaks on pinned certs, and raises privacy and compliance headaches. Encrypted-traffic analysis sidesteps it. The handshake leaks features even when the payload doesn't: a JA3 / JA4 fingerprint hashes the client's TLS Client Hello, and malware's home-grown TLS stack frequently fingerprints differently from Chrome or Firefox. Add packet sizes, timing, a self-signed or brand-new certificate, and a rare SNI, and you can flag a C2 channel without decrypting a single byte.

Finally, NDR makes its findings actionable by mapping each detection to a tactic and technique in MITRE ATT&CK. A beacon becomes T1071 (Command-and-Control over a standard application protocol); an internal scan becomes T1046 (Network Service Discovery); data smuggled out becomes T1048 (Exfiltration Over Alternative Protocol). That common vocabulary is what lets an analyst chain isolated alerts into one coherent attack story.

NDR vs IDS/IPS — the distinction interviewers love

Students mix these up constantly. An IDS/IPS is mostly signature-driven and acts per packet or session: an IPS sits inline in the data path and can block, which is powerful but means it must be fast and can become a bottleneck. NDR is behavioural and lives out-of-band on a tap; it does not block by itself — its job is detect → investigate → hunt, and it triggers response by handing off to other controls. Pithy version: IPS is the lock on the door; NDR is the CCTV that watches the corridors. They complement each other; NDR does not replace the firewall.

# A Zeek sensor writes connection metadata; this is one TLS session to a C2
$ cat conn.log ssl.log | zeek-cut id.orig_h id.resp_h resp_bytes orig_bytes ja3 server_name
# fields: client  server  bytes_in  bytes_out  ja3_hash  sni

10.20.4.17   203.0.113.45   612      48211    e7d705a3286e19ea42f587b344ee6865   cdn-update.example-sync.top
10.20.4.17   203.0.113.45   598      47980    e7d705a3286e19ea42f587b344ee6865   cdn-update.example-sync.top
# NOTE: same JA3 as known Cobalt Strike default; tiny in / huge out; rare TLD .top

③ NDR in the SOC — the visibility triad & response

NDR is not a lone tool; it's one leg of the SOC visibility triad. EDR sees what happens on a host (processes, files, the actual malware binary). NDR sees what happens between hosts (the connections, the beacon, the lateral move) — and it needs no agent, so it covers IoT, printers, OT and BYOD that EDR can't reach. SIEM collects the logs from everything and correlates. An attacker might evade one, but evading all three at once is very hard.

Walk a real flow. NDR raises the beacon alert on host 10.20.4.17 (the network signal). The analyst pivots to EDR on that host and finds the malicious process and parent (the endpoint signal). They pivot to SIEM and pull that user's AD authentication logs and the DC events around the same time (the log signal). Three sources, one story: phished user → foothold → beacon → attempted lateral move. That's the triad doing its job.

An NDR alert feeds two workflows. First, investigation: the alert arrives with context (the hosts, the ATT&CK technique, the supporting flows) so the analyst can triage fast. Second, threat hunting: even with no alert, a hunter uses NDR's searchable metadata to proactively look for weak signals — "show me every internal host with a perfectly regular outbound connection to a rare destination" — that no single rule fired on.

Then comes Response — the R in NDR. Because NDR is out-of-band, it usually doesn't block traffic itself; instead it orchestrates other controls. It can push a block of the C2 IP/domain to the firewall, tell NAC to drop the infected host into a quarantine VLAN, or fire a SOAR playbook that isolates the host via EDR, opens a ticket and notifies the on-call. Detection without response is just a louder alarm; the integrations are what make it matter.

④ Running NDR — sensors, tuning & a worked beacon hunt

Detection quality starts at sensor placement: NDR can only see the traffic you feed it. The classic mistake is tapping only the internet edge — that gives you north-south but leaves the entire internal network (where lateral movement lives) dark. The fix is to also SPAN the core switch and inter-VLAN boundaries so you capture east-west. A real-world caveat: under heavy load a SPAN port can be oversubscribed and silently drop mirror packets, so for high-throughput links a hardware TAP is more reliable than a SPAN.

Next, baselining. The model needs roughly two weeks of clean traffic with stable host roles to learn what normal is; if you onboard a sensor in the middle of a big migration, it bakes the chaos into 'normal'. And after a major change — a new app, a VLAN re-design, a merger — you re-learn, or the baseline lies to you.

Then the daily grind: tuning false positives. The biggest noise sources are legitimately periodic traffic that looks exactly like beaconing — backup jobs, patch/AV agents phoning home, NMS pollers, vulnerability scanners, SaaS sync clients, CDN connections. The fix isn't to lower sensitivity globally (you'll miss real beacons); it's to allowlist the known-good by destination, JA3 or host-role so the genuine anomalies stay loud.

A worked hunt — finding a beacon by flow periodicity

A beacon betrays itself by periodicity: a human browses irregularly, but malware checks in like clockwork. Aditya, hunting at Airtel, pulls connection records and computes, per source→destination pair, the time gaps between connections. A pair whose gaps are tightly clustered around (say) 60 seconds with low jitter, to a rare external destination, is a prime beacon suspect.

# Score each host-pair on how regular its connection timing is
$ rita show-beacons soc-mumbai | head -6
# (or: zeek-cut ts id.orig_h id.resp_h < conn.log | beacon-analyze)

SCORE   SOURCE        DESTINATION      CONNS  AVG_GAP  JITTER  DST_PORT
0.971   10.20.4.17    203.0.113.45     1422   60.04s   0.21s   443/tcp
0.118   10.20.9.3     10.20.1.10       88     varies   high    445/tcp
# top row: 1422 check-ins, ~60s apart, near-zero jitter = textbook C2 beacon

Before / after, in one line. Before NDR: the implant on 10.20.4.17 beacons every 60s over HTTPS/443 to 203.0.113.45 — to the firewall it's just 'allowed outbound web', completely hidden. After NDR: the same flow is flagged because its periodicity (1422 check-ins, ~60s, near-zero jitter), its byte ratio (tiny in, large out), its JA3 (known malware stack) and its rare new destination all break the host's baseline — and it's labelled T1071 for the analyst. Same packets, a completely different outcome, because NDR read the metadata the firewall ignored.

For your certification path, this lesson sits right in the blue-team / detection blueprint. GCIA (GIAC Certified Intrusion Analyst) and SANS SEC503 are built on exactly this — network traffic analysis, sensor placement, IDS/NDR tuning with tools like Zeek and Suricata, and reading flows to spot intrusions. Security+ covers the concepts in its monitoring/detection and architecture domains (NDR vs IDS/IPS, the visibility triad, indicators of compromise). Nail this lesson and you can answer the two questions that come up in every SOC interview: "how do you find a beacon you have no signature for?" and "why isn't a firewall enough?"