Network Detection and Response (NDR) Guide

Attackers who get past the endpoint still have to cross the network, and most organisations cannot see that traffic well enough to notice. Network detection and response (NDR) analyses traffic between hosts, users and the internet to find lateral movement, command and control, exfiltration and protocol abuse, then feeds or triggers a response. This guide explains what NDR is and how it differs from IDS, flow analysis and XDR, where to put sensors on premises and in the cloud, what encrypted traffic analysis can and cannot tell you, which detections are worth building, and how to roll it out and measure it. It is written for SOC leads, network security engineers and architects deciding how much network visibility they need and how to make it useful.

Key takeaways

• NDR is a telemetry choice before it is a product. Decide what mix of flow records, protocol metadata and packet capture you need, and where, before comparing tools.
• East-west traffic is where intrusions hide. Perimeter sensors miss SMB, RDP, WinRM and Kerberos between internal hosts, which is where lateral movement happens.
• Encrypted does not mean invisible. Handshake fingerprints such as JA4, certificates, DNS, timing and byte counts still reveal beacons and odd clients without decryption.
• Cloud needs its own design. Flow logs are cheap and broad but carry no payload; traffic mirroring gives depth at a cost, so use both selectively.
• Response is the hard part. NDR earns its keep when alerts are enriched with asset and identity context and wired to containment through EDR, NAC or firewalls, with a tested rollback.

What NDR is, and how it differs from IDS, flow analysis and XDR

NDR is a market term rather than a standard, so it helps to anchor it to established categories. NIST SP 800-94 described four classes of intrusion detection and prevention system: network-based, wireless, network behaviour analysis (NBA) and host-based. NDR grew out of the network-based and NBA classes: it combines signature matching with behavioural baselines over rich protocol metadata, keeps that metadata for investigation, and adds response integration. MITRE D3FEND names the defensive family Network Traffic Analysis (D3-NTA): "Analyzing intercepted or summarized computer network traffic to detect unauthorized activity."

Choose NDR alongside EDR, not instead of it: EDR sees processes on managed hosts, NDR sees every host on a monitored segment, including appliances and devices where an agent was disabled. See the EDR Evasion and Defence Guide and the SIEM Guide.

Telemetry: flows, metadata and packets

MITRE ATT&CK v20 has retired the old Network Traffic data source (DS0029) in favour of data components and detection strategies. The relevant components are Network Traffic Flow (DC0078), Network Traffic Content (DC0085), Network Connection Creation (DC0082) and Network Communication (DC0113). DC0078 is defined as "Summarized network packet data that captures session-level details such as source/destination IPs, ports, protocol types, timestamps, and data volume, without storing full packet payloads."

Joint guidance for communications infrastructure from CISA, NSA, FBI and Australian, Canadian and New Zealand partners (December 2024) puts it plainly: "Implement a strong network flow monitoring solution." It adds "If appropriate, implement a packet capture capability as part of the broader visibility effort for the enterprise," and "Determine capture location(s) and retention policies based on organizational demands." Size retention for the investigation window you need, then budget storage to match. See the Log Management and Retention Guide and the Security Data Pipeline Guide.

Sensor placement: north-south, east-west and cloud

• North-south: place sensors inside the internet edge (behind NAT, so internal addresses are preserved), at egress proxies and on partner and remote access links. This catches command and control and exfiltration, not internal spread.
• East-west: tap core and distribution switches, data centre spines and the segments holding domain controllers, file servers, databases and management networks. Lateral movement over SMB, RDP and WinRM only appears here. See the Network Segmentation Guide.
• Taps versus SPAN: taps copy every packet; SPAN ports are cheaper but drop packets under load. Use taps on high-value links and monitor capture loss either way.
• Virtualised hosts: traffic between virtual machines or pods on one host never touches a physical switch; use virtual taps or platform flow logs.
• Management planes: the same December 2024 guidance recommends an "out-of-band management network that is physically separate from the operational data flow network." Monitor it: an attacker on the management network controls everything else. The Salt Typhoon telecom intrusions show how long an actor can persist inside network infrastructure.

Cloud traffic

Cloud providers offer two different things, and most designs need both.

• Flow logs: AWS VPC Flow Logs, Azure virtual network flow logs and Google Cloud VPC Flow Logs record connection metadata without payloads. Azure virtual network flow logs record a flow tuple with timestamp, source and destination address and port, protocol, direction, state (Begin, Continuing, End or Deny), encryption state and packet and byte counts each way, collected "at one-minute intervals". Enable flow logs everywhere; they are the cloud equivalent of NetFlow.
• Traffic mirroring: AWS Traffic Mirroring copies packets from an elastic network interface to out-of-band appliances, using a source, filter, target and session, with appliances behind a Network Load Balancer or Gateway Load Balancer. Mirrored packets are VXLAN-encapsulated on UDP 4789. AWS charges per active session hour plus data transfer, so mirror selectively with filters and packet truncation. Google Cloud Packet Mirroring follows the same idea.
• Control plane logs: cloud attacks using stolen keys are API calls, not unusual flows. Pair network telemetry with cloud audit logs. See the CNAPP Guide.

Encrypted traffic analysis without decryption

Decrypting all TLS is expensive, legally sensitive and breaks some applications. NDR still extracts a great deal from what stays visible:

• Handshake fingerprints: JA4+ is a suite of fingerprinting methods from FoxIO. JA4 fingerprints the TLS client, JA4S the server response, JA4H the HTTP client, JA4X X.509 certificates, JA4SSH SSH sessions and JA4T the TCP client. In 2023 Chromium began randomising TLS extension order, which the project describes as "a tactic to prevent JA3 detection"; JA4 sorts extensions first, so it is not affected in the same way. JA4 is BSD 3-Clause licensed; the other JA4+ methods use the FoxIO License 1.1, so check licensing before commercial use.
• Names: the TLS Server Name Indication and DNS queries still reveal destinations, unless Encrypted Client Hello (ECH) or DNS over HTTPS hides them. Watch ECH adoption, and steer DNS to resolvers you log. See the DNS Security Guide.
• Certificates: in TLS 1.2 the server certificate crosses the wire in clear, exposing self-signed, newly issued or mismatched certificates. TLS 1.3 encrypts it, so passive certificate analysis (D3-PCA) increasingly relies on certificate transparency and active collection.
• Shape of the traffic: packet sizes, timing, session duration and byte ratios survive encryption and drive beacon and exfiltration analytics.

Treat a fingerprint as a pivot, not a verdict: a server using a scripting library or unusual SSH client may be legitimate. Where you need payload visibility for specific flows, see the TLS Inspection Guide.

Detection use cases worth building

Map each detection to the ATT&CK technique it targets and the D3FEND analysis that finds it (IDs checked against ATT&CK v20).

Network Traffic Community Deviation (D3-NTCD), "Establishing baseline communities of network hosts and identifying statistically divergent inter-community communication," is a useful behavioural idea for east-west traffic: a finance workstation speaking SMB to a build server is suspicious even when each host is normal on its own. Build and test these as code. See the Detection Engineering Guide, the Lateral Movement Guide and the Data Exfiltration Guide.

Open-source building blocks

Many NDR products build on or export to the same open formats. These tools are described from their own documentation, not recommended.

• Zeek: "A powerful framework for network traffic analysis and security monitoring." Zeek "ships with analyzers for many protocols, enabling high-level semantic analysis at the application layer" and writes per-protocol logs (conn.log, dns.log, http.log, ssl.log, files.log, x509.log, notice.log, weird.log). Its scripting language "enables site-specific monitoring". BSD licensed.
• Suricata: "a high performance Network IDS, IPS and Network Security Monitoring engine," developed by the Open Information Security Foundation (OISF) under GPLv2. It runs signature rules, can operate inline as an IPS, and emits alerts and protocol records as EVE JSON.
• Arkime: "An open-source, large-scale, full packet capturing, indexing, and database system." It stores packets as standard PCAP, indexes session metadata in OpenSearch or Elasticsearch, and can index metadata only and skip PCAP.

The trade-off is people, not licences: open-source sensors need engineers to tune, scale and write detections, while commercial NDR buys analytics, a console and support.

Response actions and SOC integration

NDR rarely acts alone. Decide in advance which actions are automatic, which need approval and how each is reversed.

Automate only actions with a reliable rollback and a low false positive history. See the SOAR and Security Automation Guide and the Incident Response Guide.

Where identity fits

• Service accounts on the wire: NDR sees Kerberos and NTLM authentication between hosts. A service account suddenly authenticating from a workstation, or over NTLM, is a strong lateral movement signal. See the Service Account Security Guide and the ITDR Guide.
• Cleartext secrets: metadata and PCAP often surface API keys and tokens sent over plain HTTP. Treat each as exposed and rotate it. See the API Key Management Guide.
• The NDR platform's own credentials: API keys that let SOAR push firewall blocks or isolate hosts, and accounts on sensors, are privileged non-human identities. Vault them, scope them and log their use.

Choosing an approach

• Small organisation, mostly SaaS and cloud: start with cloud flow logs, DNS logging and firewall logs in the SIEM, plus EDR. Full NDR rarely pays off without significant on-premises or data centre traffic.
• Mid-sized, hybrid: one or two sensors at the internet edge and the data centre core, metadata into the SIEM, flow logs for cloud, and mirroring only for crown-jewel workloads.
• Large or regulated: distributed sensors on east-west links, packet brokers, selective PCAP with defined retention, and integration into SOAR. Add OT monitoring where relevant. See the OT Security Guide.
• Standalone NDR versus an XDR module: choose standalone NDR for unmanaged devices or packet-level forensics; an XDR module may suffice where endpoints are well covered.
• Managed service: if the SOC cannot staff network analysis, an MDR provider can consume your NDR telemetry. See the MDR Guide.

Rolling out NDR

1. Define questions first: list the attacks you must detect, the segments that matter and the investigation window you need.
2. Map traffic and assets: document chokepoints, east-west links and cloud networks, and feed an IP-to-asset-to-owner mapping into the platform.
3. Pilot one segment in passive mode: deploy at the edge or data centre core, no inline blocking. Verify capture loss, protocol decoding and time synchronisation.
4. Baseline for two to four weeks: document legitimate scanners, backup jobs and management tools, and suppress them precisely.
5. Tune and test detections: replay known traffic or use breach and attack simulation to confirm each priority detection fires. See the Breach and Attack Simulation (BAS) Guide.
6. Integrate: send alerts and metadata to the SIEM, build SOAR playbooks for enrichment, then add response actions one at a time with documented rollback.
7. Expand in rings: add east-west segments, then cloud mirroring for high-value workloads. If a sensor causes performance or SPAN issues, remove the mirror session or move it to a tap; passive deployment means no traffic disruption.

Detection and measurement

Monitor the sensors as closely as the network: capture loss (Zeek writes a capture_loss.log), disk, decoder errors and flow log delivery gaps. A silent sensor looks like a quiet network.

Framework mapping

Common failure patterns

• Perimeter-only sensors: the NDR sees the initial beacon at best and none of the internal spread. Prioritise east-west links to domain controllers and data stores.
• No asset context: alerts name IP addresses that change with DHCP and autoscaling, so triage stalls. Integrate CMDB, cloud inventory and identity data before go-live.
• Unmonitored sensor health: SPAN ports oversubscribed, flow logs disabled in a new account, a sensor full disk. Alert on telemetry gaps.
• Infrastructure treated as trusted: routers, VPN appliances and management networks are left out of scope. The Ivanti Connect Secure exploitation shows how edge appliances become a foothold for stealing credentials and sessions.
• Blanket suppressions: allowlisting whole subnets or IT tools also hides attackers using them. Suppress by host, protocol and destination.
• Automated blocking too early: containment before baselines settle causes outages and ends trust in automation.

Practitioner checklist

• Write down the attacks, segments and investigation window NDR must cover before choosing a tool.
• Enable flow logs in every cloud account, VPC and VNet, and send them to central storage.
• Place sensors on east-west links to domain controllers, file servers and management networks, not only the edge.
• Feed asset, owner and identity context into the platform so alerts name systems and accounts.
• Collect TLS, DNS and JA4 metadata and use fingerprints as pivots for investigation.
• Build and test detections for lateral movement, beaconing, DNS tunnelling and exfiltration, mapped to ATT&CK and D3FEND.
• Alert on sensor capture loss and flow log gaps.
• Automate response only for actions with a tested rollback, starting with enrichment.
• Vault and scope the API keys that let NDR and SOAR change firewalls or isolate hosts.
• Review coverage, retention and detection performance quarterly.

Standards and references

• MITRE D3FEND: Network Traffic Analysis (D3-NTA)
• MITRE ATT&CK: Network Traffic Flow (DC0078)
• CISA, NSA, FBI and partners: Enhanced Visibility and Hardening Guidance for Communications Infrastructure
• NIST: SP 800-94 Guide to Intrusion Detection and Prevention Systems (IDPS)
• AWS: What is Traffic Mirroring?
• Microsoft Learn: Virtual network flow logs
• FoxIO: JA4+ Network Fingerprinting
• OISF: What is Suricata

Related NHI Mgmt Group resources: SIEM Guide · Detection Engineering Guide · Lateral Movement Guide · Log Management and Retention Guide · ITDR Guide