Network Detection and Response (NDR) collects and analyzes network traffic or network-event data to identify suspicious behavior, support investigations, and guide containment. NDR can reveal communication between systems even when an endpoint sensor is missing, but its visibility depends on where traffic is observed and what metadata or content is available.
What does NDR stand for?
NDR stands for Network Detection and Response. It observes communications rather than relying only on an agent installed on each endpoint. The “response” portion may alert an analyst, enrich an incident, request a firewall or access-control change, or integrate with another platform; it does not mean every NDR product blocks traffic inline.
Data sources used by NDR
- Packets from a network tap, switch mirror/SPAN port, virtual switch, or cloud traffic mirror.
- Flow records such as NetFlow, IPFIX, VPC flow logs, or equivalent cloud telemetry.
- DNS, DHCP, proxy, firewall, VPN, and identity context.
- TLS, protocol, timing, volume, and connection metadata.
- Asset inventory and threat intelligence used to enrich observations.
What NDR can detect
- Unexpected internal scanning and lateral movement.
- Beaconing or periodic command-and-control connections.
- Unusual data-transfer volume, destination, protocol, or time.
- Connections to known malicious infrastructure.
- Protocol misuse, tunneling, or communication inconsistent with an asset's role.
- Activity from unmanaged, embedded, operational-technology, or guest devices.
An anomaly is not automatically malicious. Backups, vulnerability scanners, software distribution, monitoring, and business batch jobs can resemble attack behavior.
Encrypted traffic visibility
NDR often cannot read the application payload of properly encrypted traffic. It may still analyze source and destination, certificate details, protocol fingerprints, DNS context, packet sizes, timing, and session behavior. TLS interception can provide more content visibility but introduces privacy, certificate-management, legal, performance, and security risks. It should be limited to an approved architecture and policy.
NDR versus IDS, IPS, and firewall
| Control | Primary role |
|---|---|
| IDS | Detects suspicious network activity and generates alerts, often from signatures and protocol rules. |
| IPS | Operates inline and can block selected traffic automatically. |
| Firewall | Enforces connection policy using addresses, ports, state, identity, or application information. |
| NDR | Combines network telemetry, analytics, investigation context, hunting, and response workflows. |
NDR versus EDR and XDR
- EDR provides deep process, file, user, and response visibility on onboarded endpoints.
- NDR observes communication across selected network paths and can cover devices without agents.
- XDR correlates multiple security domains and may consume both EDR and NDR signals.
These controls are complementary. A network alert gains meaning when it can be tied to the responsible process, account, email, or cloud event.
Deployment pitfalls
- A mirror port is oversubscribed and silently drops packets.
- East-west, cloud, remote-user, or encrypted-tunnel traffic bypasses sensors.
- NAT or missing DHCP/identity context prevents reliable asset attribution.
- High-volume storage and retention are planned without a clear investigation need.
- Baseline learning treats an existing compromise as normal.
Deployment and response checklist
- Map critical traffic paths and identify visibility gaps before placing sensors.
- Synchronize time and enrich network data with asset, identity, DNS, and cloud context.
- Validate packet loss, flow completeness, and retention.
- Baseline known scanners, backups, proxies, update services, and business workflows.
- Define who can capture content and how sensitive traffic is protected.
- Test response actions such as firewall blocks, endpoint isolation, and credential revocation with human approval appropriate to risk.