Network detection and response (NDR) is bought to see what endpoint agents and logs miss, yet many deployments end up watching only the internet edge while attackers move between servers, cloud workloads and unmanaged devices unseen. NDR platforms analyse network traffic to detect and help contain attacker activity, using some mix of flow records, protocol metadata, full packet capture, signatures and behavioural models. Products differ most in where their sensors can go, what they keep, how they detect and what they can do about it. This vendor-neutral buyer's guide is for SOC leads, network architects and procurement teams writing an RFP or replacing an IDS, and ends with a proof of concept that tests detections against real attacker techniques.
Key takeaways
- Coverage decides value. Map east-west, data centre, cloud and OT segments before you compare products; a sensor you cannot place detects nothing.
- Know what the platform keeps. Flow records, enriched metadata and full packets have very different investigative value, storage cost and privacy impact.
- Encrypted traffic is the norm. Ask how detections work without decryption (handshake and certificate analysis, fingerprints, timing and volume) and what is lost.
- Test detections, do not trust coverage maps. Run known techniques in the proof of concept and measure what alerts, how fast and with what evidence.
- Response actions use privileged credentials. API keys that let NDR block on firewalls, isolate hosts through EDR or quarantine through NAC are high-value non-human identities.
Define requirements
D3FEND defines network traffic analysis as "Analyzing intercepted or summarized computer network traffic to detect unauthorized activity" and lists about twenty child techniques, from DNS Traffic Analysis (D3-DNSTA) to Remote Terminal Session Detection (D3-RTSD) (MITRE D3FEND). NIST SP 800-94 treated network-based intrusion detection and "network behavior analysis" as separate classes; NDR products combine both and add response, so an IDS replacement should test signatures and behavioural detection alike. Then record the environment the product must fit.
- Network segments: internet egress, data centre core, campus, branches, remote access, cloud VPCs, Kubernetes and OT. Mark which are east-west and where a tap or SPAN port exists.
- Throughput: peak and sustained bandwidth per segment, including bursts during backups. Sensors that drop packets at peak miss the traffic that matters.
- Cloud telemetry: flow logs and traffic mirroring differ. AWS Traffic Mirroring copies traffic from an elastic network interface to "out-of-band security and monitoring appliances" and is charged per active session plus data transfer (AWS). Google Cloud Packet Mirroring "captures all traffic and packet data, including payloads and headers" and consumes bandwidth on the mirrored instance (Google Cloud). Azure virtual network flow logs record 5-tuple, direction, flow state, encryption state and byte counts at one-minute intervals, without payload (Microsoft Learn).
- OT protocols: if OT is in scope, list protocols in use (for example Modbus TCP on 502, DNP3 on 20000, EtherNet/IP on 44818, S7comm on 102, BACnet/IP on UDP 47808). Sensors in OT must be passive. See the OT Security Guide.
- SOC integration: your SIEM, SOAR, EDR, firewalls and NAC, and whether an MDR provider will triage NDR alerts.
- Privacy and retention: captured payloads can include personal data and credentials. Agree retention, access and data location with your data protection officer and run a DPIA where required under GDPR Article 35. See the DPIA Guide: Running a Data Protection Impact Assessment.
| Telemetry | What it holds | Strengths | Limits |
|---|---|---|---|
| Flow records (NetFlow, IPFIX, cloud flow logs) | ATT&CK DC0078 Network Traffic Flow: addresses, ports, protocol, timestamps and volume "without storing full packet payloads" | Cheap to keep for months; good for scanning, beaconing and volume anomalies | No application detail; sampled flows miss short connections |
| Enriched metadata | Parsed protocol fields: DNS queries, TLS handshake and certificate fields, HTTP headers, SMB, Kerberos and RDP details | Most detections run here; weeks to months of retention is practical | Quality depends on the parsers; unknown protocols become bare flows |
| Full packet capture | ATT&CK DC0085 Network Traffic Content: headers and payload, enabling "deeper protocol inspection, payload decoding, and forensic investigations" | Definitive evidence; file carving; replay against new detections | Storage cost limits retention to days; highest privacy impact; little value for encrypted payloads |
A mid-sized organisation with one data centre and one cloud may get most value from metadata at a few choke points plus cloud flow logs. A large or regulated enterprise usually needs distributed sensors, 90 days or more of metadata and alert-triggered packet capture. The multi-agency CISA, NSA and partner visibility guidance advises "a strong network flow monitoring solution" and, "If appropriate", packet capture "as part of the broader visibility effort".
Evaluation criteria
Weight these to your requirements. An illustrative split: 25% sensor coverage, 25% detection quality, 15% investigation and retention, 15% response and integration, 10% scalability and operations, 10% commercial terms.
| Criterion | What good looks like | Weak signs |
|---|---|---|
| Sensor coverage | Physical, virtual and cloud sensors from one console; ingest of cloud traffic mirroring and flow logs; Kubernetes visibility; published throughput per sensor model with no packet drop at peak | Cloud coverage from flow logs only, sold as equivalent to packet analysis; no drop counters |
| Encrypted traffic analytics | Detection from TLS handshake fields, certificates (D3-PCA Passive Certificate Analysis), client fingerprints such as JA4, session timing and size; optional integration with your own decryption points | Claims of "full visibility" into encrypted traffic without explaining how; reliance on decryption you cannot deploy |
| Detection approaches | Signatures, behavioural baselines and machine learning combined, each alert explaining which model or rule fired and on what evidence; mapping to ATT&CK technique IDs you can verify | "AI" scores with no explanation; ATT&CK coverage heatmaps that cannot be traced to specific detections |
| Custom detections | You can write and test your own rules (for example Suricata-compatible signatures or queries over metadata) and replay stored traffic against them | Closed detection content only; no way to tune or suppress noisy models |
| Retention and investigation | Configurable retention per data type; fast search over months of metadata; packet capture triggered by alerts; evidence export (PCAP, JSON) | Metadata kept only days; packets only in proprietary formats |
| Identity context | Parses Kerberos, NTLM, LDAP and RDP; maps IPs to users and devices via IdP, DHCP and EDR; alerts on service accounts used from unusual hosts | IP addresses only; no user or device attribution |
| Response integrations | Tested actions to EDR (host isolation), firewalls (block), NAC (quarantine) and SOAR; human approval option; full audit of automated actions | One-click actions with no approval or rollback; integrations listed but never certified |
| OT protocol coverage | Deep parsing of the industrial protocols you use, asset identification from passive traffic, alerts on writes and firmware changes (D3-RFUM Remote Firmware Update Monitoring) | OT "support" that means port numbers only; active scanning on OT networks by default |
| Scalability and SIEM integration | Documented ingest and storage sizing; alerts and metadata streamed to your SIEM in a documented schema; multi-site management | Separate console per site; alerts only by email or proprietary syslog |
| Privacy controls | Field masking, role-based access to payloads, access logging, regional storage, deletion on schedule | All analysts can read all captured payloads; no access log |
Where identity fits
NDR is one of the few controls that sees authentication protocols on the wire, which makes it useful for spotting lateral movement with stolen credentials, unusual Kerberos ticket requests and service accounts logging in from workstations. ATT&CK lists network traffic flow as a data source for T1021.004 Remote Services: SSH, T1046 Network Service Discovery and T1133 External Remote Services, among others. See the Lateral Movement Guide and the ITDR Guide. The platform also holds credentials: API keys or service accounts that read from your IdP and EDR, and that write to firewalls, NAC and SOAR. A stolen key from a security product can be as damaging as an administrator password, as the BeyondTrust breach showed. Require scoped, expiring keys with named owners, a separate identity per integration and logs of every action taken. See the API Key Management Guide and the Service Account Security Guide.
Questions to ask vendors
- What is the tested throughput of each sensor model at our traffic mix, and how do we see packet drops?
- For each cloud we use, do you analyse mirrored packets, flow logs or both, and which detections are lost with flow logs only?
- Which detections work on encrypted traffic without decryption, and which need it? Do you use JA4+ fingerprints, and if so, under which licence? (Only JA4 itself is BSD-licensed; the other JA4+ methods use the FoxIO License, which is "not permissive for monetization".)
- For five ATT&CK techniques we name, show the specific detections, the data they rely on and an example alert.
- Can we write our own detections, replay stored traffic against them and suppress noisy models per segment?
- How long is each data type retained at our volume, where is it stored, and who at your company can access it?
- Which response actions are supported for our EDR, firewalls and NAC, what permissions do the integrations need, and can actions require approval?
- Which OT protocols do you parse in depth, and is any active probing ever performed?
- What does the licence count (bandwidth, sensors, IPs, users or data retained), and how does cost change when we add cloud traffic or longer retention?
Red flags
- ATT&CK coverage claims that list techniques but cannot show the detection logic or a test.
- Machine learning alerts with no explanation of what was anomalous compared with what baseline.
- Cloud coverage that turns out to be flow logs only, with no mention of the gap.
- Automated response that can block or isolate without approval, audit or rollback.
- Integration keys with full administrative rights on your firewall or EDR, or that never expire.
- No answer on who can read captured payloads and how that access is logged.
Proof of concept
- Scope and baseline: place sensors on one internet egress, one data centre core link (east-west), one cloud VPC through traffic mirroring, and, if relevant, one OT segment in passive mode. Run for two weeks before testing so behavioural models can learn, and record sensor drop rates at peak.
- Agree the test plan: pick 8 to 12 techniques you care about from ATT&CK v20, for example T1046 Network Service Discovery, T1021.004 SSH lateral movement, T1071.004 DNS command and control, T1048 Exfiltration Over Alternative Protocol and T1133 External Remote Services. Write pass criteria: alert raised, time to alert, evidence attached, correct host and user.
- Run the techniques: use a controlled adversary emulation or breach and attack simulation tool on test hosts, including one encrypted command and control channel and one slow, low-volume exfiltration. Score each candidate on the same runs. See the Detection Engineering Guide.
- Measure noise: count alerts per day per segment, and the share an analyst judges actionable. A platform that detects everything but drowns the SOC fails.
- Test investigation: from one alert, pivot to related flows, DNS, certificates and packets over the past 30 days. Time how long a full investigation takes and export the evidence.
- Test response and roll back: trigger an EDR isolation, a firewall block and a NAC quarantine on a test host with approval switched on, confirm each action is logged with the integration identity used, then reverse it. See the Network Access Control (NAC) Guide.
- Test SIEM integration and privacy: stream alerts and metadata to your SIEM, check field mapping, then confirm masking and payload access controls work for a non-privileged analyst. See the SIEM Guide.
Keep measuring after go-live: percentage of critical segments with a sensor, sensor packet drop rate, techniques detected in each quarterly emulation run, mean time from network activity to alert, actionable alert ratio, and age of integration keys.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: SIEM Guide · Detection Engineering Guide · Lateral Movement Guide · Network Segmentation Guide