Network Detection and Response: Traffic Visibility, Behavioral Analytics, and Investigation

 

Network detection and response focuses on what systems are communicating, how that communication differs from expected behavior, and what evidence defenders can use when an alert or investigation crosses network boundaries. NDR is especially useful when endpoints are unmanaged, agents are unavailable, or attackers move between systems in ways that create observable traffic patterns. Its value depends on visibility, baselines, protocol understanding, and the ability to connect network evidence to identities, hosts, and incidents.

Start with the traffic you can actually see

Before building detections, map where traffic can be observed. Internet gateways, data-center firewalls, cloud flow logs, DNS, proxies, load balancers, VPNs, and east-west monitoring points provide different views.

Network evidence only makes sense when the collection point and session fields are understood. Palo Alto traffic monitoring shows how source, destination, action, timing, and policy data become useful investigation context rather than raw counters.

Visibility gaps create false confidence

Traffic that bypasses a sensor is invisible to that sensor. Cloud-to-cloud communication, encrypted tunnels, direct SaaS access, remote users, and local network segments can all create blind spots.

An NDR program should document what it cannot observe. “No suspicious traffic detected” is not equivalent to “no suspicious traffic occurred” when important paths are not monitored.

Metadata often remains useful without decryption

Encrypted traffic can hide payload content, but metadata still matters: source and destination, ports, timing, volume, DNS, certificates, session duration, and connection frequency. Those features can reveal unusual behavior even when inspection is not appropriate.

Deeper inspection can improve visibility, but it also creates privacy, legal, performance, and trust trade-offs. SSL decryption and visibility helps define when decryption changes the evidence available to NDR and what operational cost comes with it.

Baselines should be contextual, not static

A baseline is not a single average. Server-to-server traffic differs from employee browsing, backup systems, development workloads, and seasonal business activity. Useful analytics compare behavior with an appropriate peer group and time pattern.

Baselines should also tolerate planned change. A new software release or cloud migration can alter traffic dramatically without representing an attack.

Behavioral detections need a reasoned story

Examples include a workstation contacting many internal systems unexpectedly, a server sending data to a rare external destination, DNS patterns consistent with tunneling, or a service initiating communication that its role does not require.

The alert should explain what changed and why it matters. A vague “anomalous connection” gives analysts little direction.

DNS is a high-value evidence source

DNS can reveal newly observed domains, algorithmic-looking names, unusual query volume, and relationships between hosts and external infrastructure. It can also help explain connections that appear only as IP addresses elsewhere.

DNS evidence should be interpreted with caching, resolvers, content-delivery networks, and legitimate software update behavior in mind.

Identity and asset context improve network signals

An IP address alone may be transient. Enrich network events with host identity, user sessions, asset criticality, cloud account, and workload role. This helps analysts distinguish a lab system from a privileged administrative host.

Network location is not enough to determine trust because the same connection can have very different meaning depending on identity, resource, and session context. zero trust security reinforces that broader decision model.

East-west traffic matters for lateral movement

Many organizations monitor internet edges more thoroughly than internal communication. Attackers can exploit this asymmetry after initial access.

Observe important internal paths, especially around identity systems, management networks, data stores, and high-value applications. The goal is not to capture every packet forever but to retain enough evidence to identify unexpected movement.

NAT, proxies, and load balancers can hide identity

Shared egress addresses and intermediary devices can make many users appear as one source. Preserve original client identity where appropriate and understand how proxies, gateways, and load balancers rewrite connection details.

During an investigation, analysts should know which field identifies the true client, which identifies the intermediary, and whether that mapping is retained long enough to reconstruct a session.

Correlate network and endpoint evidence

Network telemetry can show that a host contacted a destination; endpoint telemetry can show which process initiated the connection. Together they produce stronger evidence.

When one source is missing, the other can still help define scope. This is why NDR and EDR should be designed as complementary investigation systems rather than competing products.

DDoS detection needs a different baseline

Availability attacks produce different signals from intrusion activity, including abrupt connection-rate changes, source distribution shifts, protocol anomalies, and saturation. DDoS warning signs illustrates that distinct evidence pattern.

The response may also involve providers, upstream filtering, application teams, and capacity controls rather than only the SOC.

Tune around known infrastructure carefully

Load balancers, scanners, proxies, backup systems, and monitoring tools can create large or unusual traffic patterns. Create narrow exceptions using known assets, ports, schedules, or authenticated identities where possible.

Broadly excluding infrastructure ranges can hide attacker activity on compromised administrative systems.

Investigation should follow communication paths

When an alert fires, ask where the connection began, what process or identity initiated it, which intermediate systems handled it, whether the destination is expected, and what happened immediately before and after.

A path-oriented investigation is more useful than staring at a single session record.

Containment can happen at several layers

Possible actions include blocking an indicator, isolating a host, disabling an identity, changing segmentation, removing a route, or modifying application access. The safest layer depends on the evidence and business impact.

NDR containment often depends on network controls that analysts do not operate directly. Fortinet network defense provides vendor-specific context for firewall policy, inspection, and segmentation skills that support those actions.

Preserve network evidence long enough to investigate

Flow logs, DNS, proxy records, and firewall sessions often have different retention periods. Align retention with typical detection delay and incident needs.

If detailed packet data cannot be retained broadly, preserve higher-value metadata and capture deeper evidence selectively around critical segments.

Protect the monitoring architecture

Attackers benefit if they can disable collectors, alter firewall logging, or bypass monitored paths. Monitor sensor health and configuration changes. Treat administrative access to NDR and network-security systems as privileged.

Investigators who understand how defensive network devices are administered can interpret policy and telemetry more accurately. Fortinet network security path connects that operational skill set with the broader network-security role.

Connect NDR to incident response

A network alert becomes actionable only when there is a known path to contain, preserve evidence, coordinate cloud or endpoint changes, and recover safely. incident response team design defines the organizational ownership behind that workflow.

The SOC should know when a network anomaly is a case, when it is an incident, and who can make disruptive changes.

Validate analytics with controlled scenarios

Safe simulations can confirm that expected network evidence appears at the right sensors and that alerts contain enough context. Test both successful detection and known blind spots, such as encrypted traffic, asymmetric routing, or short-lived cloud workloads.

A failed test should become an engineering task: improve the sensor placement, logging, parsing, or response playbook rather than simply lowering expectations.

Measure coverage and investigative value

Useful metrics include monitored critical paths, source health, detection acceptance, time to investigate, evidence completeness, and blind spots discovered during incidents.

Do not measure NDR success by traffic volume or alert count. The objective is better visibility and faster, more defensible security decisions.