Logging and Monitoring for OT: What to Collect First

You cannot defend what you cannot see. Start OT monitoring with a small set of logs and alerts that give operators real visibility without overwhelming staff.

3 min readBy Ironfield Cyber Team

Many industrial environments have little visibility into what is happening on their networks. If a controller is reprogrammed, a vendor logs in at midnight or a new device appears, nobody knows until something breaks. Logging and monitoring close that gap, but the task can feel overwhelming, especially for small operators with limited staff.

The practical approach is to start small, collect the logs that answer the most important questions and build from there.

Why OT monitoring is different

Industrial systems prioritize safety and availability. Aggressive scanning or intrusive tools can disrupt fragile equipment, and many older devices produce few logs. Monitoring in OT usually leans toward passive observation, collecting data from network boundaries and key servers rather than poking at controllers.

Any monitoring project should involve operations staff early. Their knowledge of normal behavior is what makes alerts meaningful.

Questions your logs should answer

  1. Who connected to the control environment, from where and when?
  2. What devices are on the network, and did anything new appear?
  3. What changed on critical systems, such as logic, configuration or user accounts?
  4. Is traffic crossing between IT and OT networks as expected?
  5. Did anything try and fail repeatedly, such as logins?

If you can answer those, you have a solid foundation.

What to collect first

Boundary logs

The point where IT meets OT is the highest-value place to watch. Firewall logs show allowed and denied connections, remote access sessions and unusual traffic. Start here.

Remote access records

Record every remote session, including vendor connections: who, when, to what system and for how long. If your remote access tool supports session recording, consider it for sensitive systems.

Authentication logs

Collect logs from domain controllers, jump servers and engineering workstations. Repeated failures, logins at odd hours and use of privileged accounts are worth attention.

Engineering workstation and server events

Systems used to program or supervise controllers deserve close watching. Track software installs, USB device use, new user accounts and changes to key files or projects.

Network device inventory and changes

Know what is connected and alert when new devices appear. Passive network monitoring tools can help build and maintain an inventory without active scanning.

Backup and configuration change records

Track when controller logic and configuration backups are made and when they differ from the previous version. Unexpected changes may signal tampering or an unauthorized edit.

Keep alerts few and meaningful

A flood of alerts gets ignored. Begin with a short list that people will act on:

  • A new device on the OT network
  • A remote session outside approved hours
  • Repeated failed logins to critical systems
  • Traffic from the OT network to the internet, if it is not expected
  • Configuration or logic changes on a controller outside a change window

For each alert, write down who receives it, what they do and how quickly.

Retention and protection

Logs help only if they exist when you need them.

  • Send logs to a central location separate from the systems that create them, so an attacker cannot easily erase them
  • Keep them long enough to investigate an incident, often months rather than days
  • Protect the log system with its own access controls and backups
  • Make sure clocks across systems are synchronized so events line up

Build in stages

  1. Month one: capture boundary firewall and remote access logs. Write down what normal looks like.
  2. Month two: add authentication logs and engineering workstation events.
  3. Month three: add passive asset discovery and a handful of alerts.
  4. Ongoing: review alerts, tune them and add sources as capacity allows.

A hypothetical example

Consider a hypothetical small operator of a gas gathering system. A vendor technician connects remotely every few weeks. After enabling logging on the remote access gateway, the operator notices a connection at 2 a.m. that nobody scheduled. It turns out the vendor's credentials were shared with a subcontractor. The log did not stop an attack, but it exposed a risky practice and led to better access rules.

Who watches the logs

Collecting logs without anyone reviewing them is of limited value. Decide who looks at them and how often. Smaller organizations often rely on a managed provider for monitoring, with clear escalation paths to operations staff.

Next steps

Ironfield Cyber helps operators and energy service companies design practical OT logging, select which sources matter and set up alerts operations teams can use. If you have little visibility into your control environment today, we can help you take the first steps without disrupting operations.