NDR Sensor Deployment: Network Detection and Response in Practice

Placement decisions follow two axes: inline versus out-of-band, and north-south versus east-west. Out-of-band sensors receive a copy of traffic via a network TAP or a SPAN/mirror port on a switch; they cannot block, but they cannot fail open either, which matters for high-availability requirements. Inline sensors sit in the traffic path and can block, but introduce a failure domain. For most enterprise deployments, out-of-band is the right starting point; revisit inline only for specific high-trust segments where automatic blocking is justified. North-south placement at the internet egress and DMZ catches C2 beaconing, data exfiltration, and inbound exploitation. East-west placement at the data center core or between security zones catches lateral movement, which is where the high-value detections live. For VLANs that aggregate at a single core switch, SPAN the uplink trunk; for spine-leaf data center fabrics, deploy sensors at each spine or use a packet broker (Gigamon, Garland, Niagara) to aggregate and filter before delivery to the sensor. Plan sensor capacity at 2x peak observed throughput so you do not drop packets during incident bursts; dropped packets are the first thing a sophisticated attacker probes for.

Enumerate the device classes the NDR is meant to cover. IoT and OT: building HVAC, badge readers, cameras (notoriously vulnerable to default credentials), VoIP phones, conference room hardware. Medical devices in healthcare environments: infusion pumps, imaging workstations, EHR endpoints with proprietary OS. Printers and MFPs: often unpatched, frequently used as a foothold for credential capture via fake SMB shares. Embedded Linux appliances: load balancers, storage arrays, NAS devices, network equipment management interfaces. Contractor and BYOD: laptops that connect to a guest or contractor VLAN without your EDR. Hypervisor management: ESXi, Hyper-V, KVM hosts where agent installation is unsupported. ESXi in particular has become a primary ransomware target because attackers know it is unmonitored; an NDR sensor at the management VLAN that watches for outbound traffic from ESXi hosts to the internet or for unusual SSH activity catches the prelude to a hypervisor encryption event. Map each device class to a specific network segment and confirm the segment is in coverage; coverage gaps in the device class to sensor placement map are the gaps an attacker will find first.

Out of the box, an NDR will alert on roughly 10 to 50 times more events than your SOC can triage. The tuning phase is non-optional and typically takes 60 to 90 days before the alert rate is sustainable. The framework: baseline normal first, then suppress, then alert. Baseline normal by running the sensor in observe-only mode for 14 days and exporting the top 100 source-destination-port tuples by volume; verify each is expected business traffic and add to the allowlist with an owner and a review date. Suppress expected scans: vulnerability scanner traffic, monitoring system SNMP polls, backup agents, configuration management agents (Ansible, Puppet, Chef). Whitelist by source IP, not by signature, so a compromised scanner host still alerts. Tune the protocol anomaly thresholds; the defaults for SMB write volume, DNS query rate, and HTTP request rate are usually set for a small office and will fire constantly in a data center. Document every suppression in source control with a justification, an owner, and a 90 day review date; suppression rules without expiration accumulate into a security gap nobody remembers creating.

TLS 1.3 plus encrypted SNI removes most of the content-based detection options that worked in the TLS 1.2 era, but it does not remove metadata-based detection. JA3 (and the newer JA4, JA4S, JA4H, JA4L family from FoxIO) fingerprint the TLS client hello and server hello based on the ordered cipher suites, extensions, and elliptic curves; the fingerprint is stable per TLS library version and effectively identifies the client software regardless of the user agent string. Malware families have distinct JA4 fingerprints, and an unfamiliar JA4 from an internal host to an internet destination is high-fidelity signal. Certificate anomalies are equally valuable: self-signed certificates outbound from a workstation, certificates with very short validity windows from non-Let's-Encrypt issuers, certificates with mismatched SNI versus subject CN, certificates from issuers not normally seen by your environment. TLS timing patterns matter too: C2 beaconing produces regular intervals (every 60 seconds plus jitter) that stand out from human-driven web traffic. Build detections that combine multiple weak signals (uncommon JA4 plus regular timing plus low-reputation destination IP) rather than relying on any single one; this is where the NDR product's analytics engine earns its license cost.

The integration anti-pattern is to forward every NDR detection to the SIEM as a separate alert, which creates noise and duplication. The correct pattern is two-tier: the NDR maintains its own console for first-line triage and the SIEM receives only correlated, multi-signal detections plus a stream of context events for retrospective hunting. Forward NDR detections to SIEM at three priority levels: high (immediate triage, paged), medium (queued for next-shift review), low (suppressed from alert queue, available in the data lake for hunting). Pipe Zeek-style connection logs and protocol metadata into the SIEM at low priority so analysts can pivot from an EDR or identity alert into network context without context-switching to the NDR console; this is more valuable than the alerts themselves. For SOAR enrichment, build playbooks that take an NDR alert with a suspicious internal IP and automatically pull the asset inventory, EDR detection history, and recent identity events for the user assigned to the host. Avoid forwarding raw packet capture metadata into the SIEM at scale; the volume will wreck your ingestion budget and the SIEM is the wrong tool for pcap analysis.

On-premises NDR sensors do not see cloud traffic. The options for cloud network visibility, in increasing order of fidelity and cost: flow logs (VPC Flow Logs in AWS, NSG Flow Logs in Azure, VPC Flow Logs in GCP) give 5-tuple data and byte counts but no payload, sufficient for connection-level anomaly detection and lateral movement scoping but not for protocol analysis; cloud-provider IDS services (AWS Network Firewall with managed rule groups, Azure Firewall Premium IDPS, GCP Cloud IDS) give signature-based detection inline; traffic mirroring (VPC Traffic Mirroring in AWS, vTAP in Azure, Packet Mirroring in GCP) sends a copy of full packet streams to an NDR sensor running in a cloud VM or appliance, giving full protocol visibility at substantial cost. For most workloads, flow logs plus a managed IDS service is the right starting point; reserve traffic mirroring for the highest-value subnets (DMZ, PCI scope, sensitive data tiers). Tag the cloud visibility coverage gap in your asset inventory so you know which workloads have only flow-log-level visibility versus full protocol inspection.