Monitoring is where many small operators stall. The word suggests a room full of screens and analysts, and the vendor pitches that follow can feel out of reach. But monitoring an operational technology network is, at its core, about knowing what normal looks like and noticing when something changes. Small teams can do a meaningful version of this with modest tools and clear priorities.
Why monitoring matters in OT
Operational networks tend to be stable. The same devices talk to the same devices in the same patterns day after day. That predictability is a gift: unusual activity stands out more clearly than in an office network full of changing users and applications. A new device, an unexpected connection, or a controller receiving commands from an odd source is worth investigating.
Monitoring also supports safety and reliability. The same visibility that reveals an intruder can reveal a failing switch, a misconfigured device, or a vendor connection nobody approved.
Start with an inventory
You cannot notice a new device if you do not know which devices belong. Begin with a list of assets and expected communications: which systems talk to which, over what protocols, and why. Even a simple diagram helps. This baseline is the reference against which everything else is compared.
Choose what to watch
Network boundaries
The most valuable place to watch is where IT and OT networks meet, and where outside connections enter. Log and review:
- Firewall allow and deny events at the boundary.
- Remote access sessions, including who connected, when, and to what.
- New or unexpected connections crossing the boundary.
New devices
Detect devices that appear on the network without approval. Many switches and monitoring tools can alert when an unknown device connects. Even a periodic scan, done carefully and with vendor guidance so as not to disrupt sensitive equipment, can reveal surprises.
Critical servers and workstations
Engineering workstations, historians, and servers in OT environments are good places for logging. Watch for:
- Failed and successful logins, especially outside normal hours.
- New user accounts or privilege changes.
- Software installations or changes to configurations.
- Use of removable media.
Configuration changes
Unexpected changes to controller logic or device settings can indicate a mistake or an attack. Where tools allow, compare current configurations with approved baselines and alert on differences.
Passive monitoring tools
Specialized OT monitoring products observe network traffic passively, typically through a mirrored switch port, so they do not interfere with operations. They can learn normal communication patterns, identify devices, and flag anomalies. For operators with larger or more critical environments, these tools are worth evaluating. For smaller sites, centralized logging from firewalls and servers plus a regular review routine may be enough to start.
Decide who looks at the data
The most common failure is collecting logs that nobody reads. Decide in advance:
- Who reviews alerts, and how often?
- What counts as urgent, and who is called after hours?
- Who in operations can confirm whether an activity is expected?
- When does an alert become an incident?
Monitoring is a partnership. IT or a security provider can analyze alerts, but only operations knows whether a change in controller activity was planned maintenance.
Keep alerts meaningful
Too many alerts become noise. Begin with a short list of high-value alerts:
- New device on an OT network.
- Remote access outside approved windows.
- Multiple failed logins on a critical system.
- A new connection from IT to OT that was not in the baseline.
- Disabled security tools or cleared logs.
Add more only when you can handle them.
Protect the logs
Store logs in a place attackers cannot easily alter. If logs live only on the compromised machine, an intruder may erase them. Forward logs to a central system and retain them long enough to investigate, since intrusions are often discovered long after they begin.
Tie monitoring to response
Detection without response is just observation. Pair your monitoring with an incident response plan that says who to call, how to isolate a system without causing a safety problem, and when to involve vendors and operations leadership.
Practice
Run a short exercise: simulate an unknown device appearing on a control network. Time how long it takes to notice, identify, and decide what to do. Use the result to refine alerts and responsibilities.
A reasonable first phase
- Build the asset and communication baseline.
- Collect logs from boundary firewalls and key servers.
- Alert on a handful of high-value events.
- Assign a reviewer and an escalation path.
- Evaluate passive monitoring for your most critical areas.
How Ironfield Cyber helps
Ironfield Cyber helps energy and industrial operators design practical monitoring, from log collection to alert tuning and response planning. If you would like a realistic starting point for your environment, we can scope it with you.