Network Baseline

What a network baseline captures

A network baseline records the ordinary shape of traffic for a defined environment, such as a site, subnet, host, or application. It gives defenders a reference point for noticing what has changed, not just what is present.

That distinction matters because many significant events begin as deviations from routine, such as a new external destination, an unexpected internal peer, or a service that starts talking after long inactivity. A baseline makes those shifts visible in context instead of treating every connection as equally normal.

What belongs in a useful baseline

A strong baseline is more than a list of IPs. It usually captures who talks to whom, which ports and protocols are normal, how much data flows, when activity happens, and whether the pattern is steady, bursty, or seasonal.

Good baselines also reflect business reality. Maintenance windows, batch jobs, backup traffic, software updates, and regional office usage can all be normal, but only if they are observed and documented. Without that context, defenders risk mistaking expected behaviour for threat activity, or missing abnormal traffic that blends into noise.

In practice, the baseline should be scoped to the right layer of analysis. A host baseline can be very different from a segment baseline, and an application baseline may differ again once encrypted transport, load balancers, or service meshes are involved.

How network baselines support detection

Baselines are most valuable when they feed detection logic, triage, and investigation. They help defenders spot anomalies such as rare destination geographies, sudden east-west movement, abnormal DNS patterns, or dormant systems that begin generating traffic outside their usual role.

They also help reduce false positives. A mature program compares alerts against expected behaviour so analysts can separate meaningful change from harmless variance. NDR Guide is useful background for this operational use case because network detection and response depends on traffic context, sensor placement, and anomaly analysis.

For industrial and OT environments, baseline discipline is even more important because many systems are stable, tightly scoped, and sensitive to disruption. OT Asset Visibility Guide is relevant here because knowing what assets exist and how they normally communicate is the foundation for safe monitoring and anomaly spotting.

How organisations build and maintain a baseline

A baseline should come from observation, not assumption. Teams usually gather flow data, packet metadata, firewall logs, DNS telemetry, and application logs over a representative period, then validate that the pattern matches known business functions and topology.

It must also be maintained. Network behaviour changes when applications are moved, cloud services are added, remote work expands, or integrations are introduced. A stale baseline can be as misleading as no baseline at all, because it either normalises suspicious activity or flags legitimate change long after the environment evolved.

Baselines work best when they are tied to inventory, ownership, and change control. If defenders cannot explain why a peer relationship exists, they cannot confidently decide whether a new communication path is benign, risky, or unauthorized.

Risk and Threat Considerations

A weak or outdated baseline creates blind spots. Attackers can hide inside “normal” traffic once they establish a foothold, especially when they use common ports, legitimate protocols, or internal movement that resembles everyday application chatter.

Failure mechanism: If the baseline is too broad, too old, or built from incomplete telemetry, abnormal communications may be treated as expected behaviour and malicious activity can persist without timely review.

Impact: Detection quality drops, lateral movement becomes harder to see, and response teams lose the context they need to distinguish real compromise from routine variation.

Practitioner Guidance

Why practitioners should care: The most useful baseline is one that is specific enough to detect change without being so rigid that it drowns analysts in noise. Treat it as an operational reference, not a one-time documentation exercise.

What to watch for: Rebuild or revalidate the baseline after major topology changes, application migrations, cloud expansion, or telemetry gaps. If the environment has changed materially, the baseline should change with it.

Practitioner takeaway: A network baseline is only defensible when it is continuously tied to real traffic, current architecture, and active monitoring.

Related resources from NHI Mgmt Group

• Why has identity replaced the network perimeter as the primary security boundary?
• Why are identity-based attacks growing faster than traditional network attacks?
• What is the difference between network controls and identity controls for infrastructure access?
• What is the difference between network trust and request-level identity trust?