SECURITYATLAS✳

✳ The reference desk / In practice

NDR

Detection and investigation based on network traffic or metadata rather than host agents alone.

Network detection and response

What it means

NDR uses network observations to identify and investigate suspicious communication. Inputs may include packet captures, connection metadata, flow records, and protocol details available at the sensor. This can help with systems where endpoint agents are unavailable. Visibility depends on where sensors sit and which traffic reaches them. Encryption usually hides application contents; metadata such as destinations, timing, and volume may remain useful. NDR findings need asset and operational context, and a network anomaly is a lead rather than proof that an attacker is present.

The idea at a glance / Detection

A network lead can stop at the encrypted boundary.

Keep the observation point, TLS connection and bounded baseline beside what they cannot reveal.

Passive M125 sees a synthetic wired uplink before NAT. Retained N125 records 10.23.0.7 contacting 198.51.100.80:443 at 09:00 UTC; a matching handshake record identifies TLS. B125 covers that source’s observed destinations from September 23 to September 30. The destination is absent from this selected baseline. No TLS keys or decrypted payload are available.

NDR: Keep the observation point, TLS connection and bounded baseline beside what they cannot reveal. The explanation below describes the relationships.Network trail · N125New destination in a bounded baselinePassive sensor · M125Wired uplink · before NATVPN bypass outside this viewRetained TLS flow · N12510.23.0.7 → 198.51.100.80TCP 443 · payload unavailableSelected baseline · B125Sep 23–30 · destination not seenRule R125 stores lead AL125Investigation · still openProcess / user / content unknownNo blocking action performedNEW DESTINATION ≠ PROVEN ATTACK

READ THE PICTURE

Evidence and limits

N125 reaches a destination absent from B125. AL125 preserves that lead; encrypted contents, process, user and business context remain unknown.

Keep in mindR125 flags a destination new to B125, not proven command-and-control or data theft. M125 does not see a bypassing VPN path. IP/time mapping, packet availability and baseline completeness are exercise assumptions, not a guarantee about an estate. The process, person, method, payload and business approval remain unknown. No blocking action occurs.

Read the complete example
  1. Evidence and limits. N125 reaches a destination absent from B125. AL125 preserves that lead; encrypted contents, process, user and business context remain unknown. M125 is a passive mirror of the wired uplink before NAT; traffic using a bypassing VPN is outside this view. N125 is synthetic TCP 10.23.0.7:55125 to documentation address 198.51.100.80:443, starting 2026-09-30T09:00:00Z and lasting 60 seconds. A same-connection handshake record identifies TLS; port 443 alone does not establish the protocol. The selected 2026-09-23 inclusive–2026-09-30 exclusive B125 snapshot contains 198.51.100.40 for the same source, not .80. R125 compares the destination against that bounded snapshot and stores AL125 citing N125/B125. This is a novelty lead, not proof of malicious traffic or disclosure. The passive sensor has neither TLS keys nor decrypted method, URL or payload. No process or human is inferred from the source IP, and no block is performed. Missing baseline or traffic would require an unknown result, rather than a clean verdict.

R125 flags a destination new to B125, not proven command-and-control or data theft. M125 does not see a bypassing VPN path. IP/time mapping, packet availability and baseline completeness are exercise assumptions, not a guarantee about an estate. The process, person, method, payload and business approval remain unknown. No blocking action occurs.

Diagram references: Zeek: sensor placement and visibility · Zeek: connection records and encrypted TLS

AN ILLUSTRATIVE SCENARIO

A destination new to one observed baseline

Passive M125 sees N125 from 10.23.0.7 to 198.51.100.80:443. A matching TLS handshake record supplies the protocol; no decrypted method or payload is available. R125 finds that destination absent from the selected seven-day B125 snapshot and stores a lead. A bypassing VPN path is unseen. Process, person and business context remain unknown, and no traffic is blocked.

Put it to work

  1. Map important communication paths and choose sensor locations deliberately. Record network segments, remote users, or cloud traffic that the deployment cannot observe.
  2. Identify asset owners and expected communication patterns. Preserve time and connection identifiers so observations can be compared with endpoint or application records.
  3. Monitor packet loss, data collection health, and retention. Agree investigation and response procedures, especially where blocking traffic could interrupt a physical process.

How to check your work

Generate approved test traffic along a known path and find it in the expected records. Check sensor placement, direction, timestamps, and loss indicators. Document what the test establishes and which encrypted details remain unavailable.

Connect the ideas

  • EDR

    Telemetry and response capability on laptops and servers for process, file, and similar host activity.

  • Log

    A record emitted by a system that something happened, which may later be used as evidence.

  • Exposure

    Whether and how a vulnerability or service can actually be reached in this environment.

  • TLS

    A protocol that encrypts and integrity-protects an application conversation and checks a certificate for a name.

Explore a field lesson

Find your next idea.

Tip: press / to open search. Escape closes this window.