ICS Network Baseline

What an ICS Network Baseline Represents

An ICS network baseline is not a static diagram, it is an operational reference for normal communications in the control environment. It captures the expected device-to-device relationships, protocol use, port patterns and timing behaviour that make an industrial network look “healthy” versus suspicious.

This matters because industrial environments often depend on stable, repeatable communication paths. When the baseline is accurate, defenders can spot new peers, unexpected remote access, unusual protocol talkers, or traffic timing that falls outside normal process behaviour. That makes the baseline a detection aid as much as an inventory artifact.

Why Baselines Matter in OT Detection

In industrial networks, defenders often cannot rely on noisy, agent-heavy monitoring. A baseline gives context to passive telemetry, allowing teams to separate routine process chatter from activity that deserves review. It is especially useful where fixed-function assets, legacy protocols and long-lived communications are common.

A strong baseline also helps distinguish approved engineering traffic from abnormal access paths. If a PLC, HMI or engineering workstation begins talking to a new destination, the change may be benign, but it may also indicate misconfiguration, shadow connectivity or compromise. The baseline turns those changes into visible events instead of invisible drift.

For a practical monitoring approach, many teams pair baselining with passive network visibility and protocol-aware parsing, as described in OT Network Security Monitoring Guide and Zeek Network Monitoring Guide.

What to Capture in an Effective ICS Baseline

An effective baseline usually includes who talks to whom, which industrial protocols are present, which ports are used, and what timing relationships are expected between assets. It may also include site, cell or line context, because the same protocol can be normal in one part of the plant and unusual in another.

Baseline quality depends on completeness and stability. If it is built from a short observation window, maintenance periods or commissioning activity, it may encode abnormal traffic as normal. If it is too vague, it will miss the difference between a legitimate control path and a dangerous one.

Because the baseline is only as useful as the visibility behind it, asset discovery and traffic understanding need to be aligned. OT Asset Visibility Guide is useful where teams need the inventory and protocol context that make a network baseline trustworthy.

How Baselines Support Segmentation and Change Detection

Baselines become more valuable when they are tied to segmentation design and change control. In a segmented OT environment, each zone should have a clearer communication pattern than a flat network, which makes deviations easier to see and easier to explain.

They are also useful after network redesigns, migrations or remote-access changes. A new engineering path, a remote vendor tunnel or an added historian feed may be legitimate, but it still changes the communication model and should be reflected in the documented baseline. Without that update, defenders can end up chasing known-good activity as if it were suspicious, or worse, accepting suspicious activity as normal.

For the architectural side of that problem, OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide explains how zone boundaries shape the communications a baseline should expect.

Risk and Threat Considerations

ics network baselines are vulnerable to drift, incomplete observation and attacker adaptation. If the baseline is stale, defenders may miss new command paths, covert remote access or lateral movement that blends into outdated “normal” traffic.

Failure mechanism: Attackers and misconfigurations both exploit the gap between documented communications and actual communications. Once an unexpected connection becomes routine, or a routine connection is redefined as normal without scrutiny, the baseline loses detection value.

Impact: The organisation can lose early warning for unauthorised access, process disruption and stealthy compromise. In an OT setting, that can delay response long enough for safety, availability or production impact to widen.

Practitioner Guidance

Why practitioners should care: Treat the baseline as a living operational control, not a one-time documentation task. It should be reviewed whenever assets, vendor access, protocols or network zones change, because those changes alter what “normal” means.

What to watch for: Focus on new peer relationships, new remote sources, protocol shifts, and timing changes that do not match the process state. Those are often the earliest indicators that the baseline no longer reflects the real network.

Practitioner takeaway: A useful ICS baseline is one that can be defended with evidence from current traffic, not just historical assumption.

Related resources from NHI Mgmt Group

• Guide: NDR Guide
• Why do unpatched ICS environments and flat network designs create such high risk for critical infrastructure operators?
• How does Network Baseline work?
• What are the key Network Baseline best practices?
• What breaks when OT security monitoring stays inside the ICS network boundary?