Join our Newsletter — 33% off our NHI Course

Communications Baselining

Communications baselining is the process of measuring normal network or application communication patterns so deviations can be detected later. It usually records expected endpoints, ports, protocols, timing, and volume across a defined environment, giving security teams a reference point for spotting unusual traffic, lateral movement, or command-and-control activity.

What communications baselining measures

Communications baselining turns raw network and application telemetry into a picture of normal behaviour. The goal is not to catalog every packet, but to define the expected relationships, endpoints, ports, protocols, timing, and volume that make later deviation meaningful.

That baseline is only useful if it reflects a stable enough environment to be comparable over time. In fast-changing estates, the practical challenge is distinguishing true anomalies from routine application change, seasonal load, and legitimate new integrations.

Why it matters for detection and investigation

A baseline creates context for hunting because many hostile behaviours look ordinary in isolation. Lateral movement, beaconing, command-and-control traffic, data staging, and unusual service-to-service communication are easier to spot when the normal communication graph is already understood.

Good baselining also reduces alert fatigue. Security teams can tune detections around actual environment behaviour instead of relying only on generic thresholds that miss low-and-slow activity or create noise during expected business peaks.

What makes a baseline trustworthy

The value of communications baselining depends on coverage and recency. It needs enough telemetry from representative workloads, users, subnets, and applications to capture ordinary patterns without overfitting to a short observation window.

A weak baseline is one that is too narrow, too old, or too dependent on manually curated assumptions. If infrastructure, application paths, or identity-driven access patterns change frequently, the baseline should be updated so that legitimate change does not mask genuine anomalies.

Useful baselines are usually layered. Endpoint-level, application-level, and network-flow views each expose different forms of normality, and a deviation in one layer may be explainable only when correlated with the others.

How teams use it in practice

Practitioners use communications baselines as a reference point for detection engineering, threat hunting, and incident triage. The baseline helps answer a simple question: is this communication pattern expected for this asset, at this time, and in this context?

When investigating a deviation, teams usually compare the observed traffic against the known role of the system, the business process it supports, and the peers it normally talks to. That comparison is often more useful than checking a single indicator in isolation.

Baselining is strongest when it feeds other controls, including segmentation, anomaly detection, and review of approved service paths. A baseline should support decisions, not replace them.

Risk and Threat Considerations

Communications baselining matters because attackers often hide inside normal-looking traffic. If the baseline is missing, stale, or too broad, unusual flows can blend into expected noise and let lateral movement or command-and-control activity persist longer than it should.

Failure mechanism: An incomplete baseline creates blind spots, while an overly permissive one normalises abnormal communications and weakens anomaly detection. That failure is especially dangerous when environments contain many services, frequent change, or shared network paths.

Impact: Security teams may miss early signs of compromise, investigate too late, or spend time on false positives that were only “normal” because the baseline was poor. The result is weaker detection, slower containment, and higher exposure to follow-on intrusion.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
MITRE ATT&CK T1021 — Remote Services Baselining expected communication paths helps spot unusual remote access and lateral movement.
T1071 — Application Layer Protocol The term centers on normal protocol and timing patterns used by application-layer C2 traffic.
Recommendation — Map unexpected internal remote access against T1021 and investigate new host-to-host paths. Baseline application-layer protocol use and hunt for covert command-and-control over normal-looking traffic.
NIST SP 800-53 Rev 5 AU-6 — Audit Record Review, Analysis, and Reporting Baseline comparisons rely on reviewing telemetry to identify deviations and suspicious patterns.
SI-4 — System Monitoring This subject depends on monitoring network and application communications for abnormal behaviour.
Recommendation — Review communication telemetry for deviations and correlate anomalies into actionable alerts. Monitor network and application communications continuously for suspicious deviation from the baseline.
NIST CSF 2.0 DE.CM-01 — Networks and network services are monitored to detect potentially adverse events Communications baselining is a direct method for monitoring network services for adverse events.
Recommendation — Use baseline monitoring to detect adverse network and service communication patterns early.

Practitioner Guidance

Why practitioners should care: Treat communications baselining as an operational control, not a one-time analytics exercise. Its usefulness depends on how well it reflects current architecture, legitimate change, and the traffic patterns that matter most for detection.

What to watch for: Re-baseline when application ownership changes, new integrations appear, or infrastructure is replatformed. Those are the moments when an old reference model is most likely to become misleading.

Practitioner takeaway: The best baseline is the one your team can still trust after the environment changes, because stale “normal” is often worse than no baseline at all.