What it means
OT network monitoring baselines describe expected devices, peers, protocols, commands, direction, timing, volume, and maintenance behavior so meaningful deviations can be investigated.
Why it matters
Industrial traffic is often regular, but simplistic baselines create noise during maintenance or miss low-and-slow misuse that uses valid protocols and paths.
Practical focus
- Build baselines by process state, shift, recipe, startup, shutdown, maintenance, failover, vendor activity, and emergency mode.
- Model not only connections but industrial function codes, commands, writes, scans, role changes, new peers, timing, and sequence.
- Validate alerts with operators and engineers, protect sensors, and link anomalies to asset, change, identity, and process context.
- Preserve this evidence: Retain baseline definitions, observation period, process context, approved exceptions, alert logic, investigations, tuning, and detection tests.
- Exercise this failure scenario: A malicious write blends into permitted protocol traffic, or maintenance generates chronic false positives that teach analysts to ignore the signal.
Common mistakes
- Using the label OT Network Monitoring Baselines without defining scope, ownership, decision authority, and the exact data, systems, people, or process affected.
- Treating a policy, contract, diagram, dashboard, or tool demonstration as proof that OT Network Monitoring Baselines operates consistently in production.
- Closing work without retaining the evidence needed to reconstruct the decision and verify the intended control outcome.
- Testing only the normal path and never rehearsing the failure condition: A malicious write blends into permitted protocol traffic, or maintenance generates chronic false positives that teach analysts to ignore the signal.
Certification relevance
This subject appears in or supports the following certification bodies of knowledge: