What are the key Network Baseline best practices?

Build a Network Baseline from normal traffic patterns for users, services, devices and time periods, then refresh it as the environment changes. Define expected peers, ports, protocols and volumes, and compare new activity against that profile. Investigate sustained deviations, because attackers often hide command-and-control, scanning or data movement inside low-confidence changes.

How to build a useful Network Baseline

A strong baseline starts with ordinary behaviour, not edge cases. Capture who talks to whom, on which ports and protocols, at what times, and at what volumes across users, services, devices and sites. Include business schedules and maintenance windows, then treat the baseline as a living reference that is refreshed when applications, dependencies or traffic patterns change.

The practical goal is to make the baseline specific enough to support triage. If it is too broad, almost any deviation looks normal; if it is too narrow, normal change becomes noise. Teams usually get the best results when they baseline at the level of business unit, subnet, workload cluster, or service tier rather than trying to force one enterprise-wide pattern.

What should be inside the baseline profile?

The most useful profiles describe expected peers, destinations, and communication paths in addition to raw traffic volume. They should show which services initiate connections, which systems are allowed to receive them, and which protocols are legitimate for the environment. That gives analysts a reference for spotting unexpected east-west movement, unusual internet egress, and low-frequency connections that do not belong to the normal operating model.

Volume alone is rarely enough. A spike in flow count may be harmless during a batch window, while a small but new connection to an unfamiliar host at an unusual time may be more suspicious. Good baselines therefore mix several dimensions: peer relationships, timing, protocol mix, byte counts, session duration, and repeated patterns over days or weeks.

Baseline quality also depends on the visibility source. Flow logs, packet metadata, DNS data, proxy logs, and sensor telemetry each reveal different parts of the picture, so the best baseline is built from corroborating sources rather than one dataset. For deeper detection work, the NDR Guide is a useful companion because it ties baseline building to sensor placement, traffic analysis, and response workflows.

How to use deviations without drowning in noise

Not every deviation is a problem, but every sustained deviation deserves context. A baseline should help you separate one-off change from a pattern that repeats, broadens, or aligns with a suspicious destination. The most useful investigations ask whether the new activity is expected, whether it correlates with a known change, and whether it persists beyond the maintenance or deployment window.

Analysts should focus on deviations that combine novelty and persistence. A single new connection may be innocuous; a recurring connection from a workstation to an external endpoint every night, or a service suddenly talking to a new peer set, deserves more attention. Attackers often try to blend command-and-control, scanning, or data movement into traffic changes that are small, intermittent, or easy to mistake for routine variation.

In environments with a large number of services or devices, the best practice is to baseline by segment and role, then compare new activity against the closest valid peer group. That reduces false positives and makes it easier to spot when a server, endpoint, or appliance starts behaving unlike the class of system it is supposed to represent.

Risk and Threat Considerations

Network baselines fail when they are treated as static or overly coarse. If the reference profile is stale, attackers can hide in the gap between what the environment used to do and what it now accepts as normal, and defenders can miss low-and-slow abuse that never trips a simple threshold.

Failure mechanism: Normal change, such as new SaaS dependencies, patched services, or altered batch schedules, expands what looks acceptable unless the baseline is refreshed and segmented. That creates blind spots where command-and-control, reconnaissance, or exfiltration traffic can look like ordinary drift.

Impact: Analysts lose detection confidence, triage volume rises, and malicious activity can persist longer because it resembles legitimate variance instead of a clear anomaly.

Practitioner Guidance

What to prioritise: Start with the traffic that matters most to operations and risk, such as internet egress, admin subnets, server-to-server flows, and critical service tiers. Those areas usually produce the highest-value detections because attackers prefer them for persistence and movement.

What to verify: Confirm that baseline exceptions are tied to an owned change, a business schedule, or an approved dependency. If you cannot explain why a peer, port, or protocol is present, treat it as an investigative lead rather than a benign baseline update.

What good looks like: A good baseline is narrow enough to flag meaningful deviation, but flexible enough to survive normal releases and seasonal shifts. The right measure is not zero anomalies, it is whether the team can quickly distinguish normal churn from suspicious persistence.

Practitioner takeaway: The value of a network baseline is not prediction, it is discrimination: build it around real peer, port, protocol, timing and volume relationships so that abnormal behaviour stands out even when the attacker is trying to look routine.

Related resources from NHI Mgmt Group

• What are the key network containment best practices?
• What are the key Privacy control baseline best practices?
• What are the key network traffic analysis best practices?
• What are the key network security architecture best practices?