When something goes wrong in a control system, the first question is what happened and when. Operators with good logs can answer in minutes. Operators without them often cannot answer at all, which makes it hard to tell a cyber event from an equipment fault, a bad configuration change, or human error.
Small operators often assume that visibility requires a dedicated security team and expensive monitoring. It does not. A modest, well-designed logging approach gives you most of the value.
Separate Process Alarms From Security Events
Operators already live with process alarms: pressure, temperature, flow, and equipment status. These are about the physical process. Security events are different: a new device on the network, a failed login, a configuration change, a remote session at an odd hour.
Both matter, and they can overlap. A sudden change in setpoints might be a process issue or a malicious change. Teams that review both types together understand incidents faster.
What to Log First
Start with high-value sources that are practical to collect:
- Remote access. Who connected, from where, when, and for how long. This is often the highest-risk entry point.
- Authentication. Logins and failures on engineering workstations, historians, and HMIs.
- Firewall and boundary devices. Allowed and denied connections between IT and OT zones.
- Configuration changes. Changes to controller logic, setpoints, network devices, and user accounts.
- New devices. Anything that appears on the network that was not there yesterday.
- Endpoint protection events. Where antivirus or application control is used on Windows-based OT machines.
Not every legacy device can produce logs. For those, use network-level visibility at the boundary to capture what you can.
Keep Time Consistent
Logs are only useful if they can be lined up. Make sure devices use a common time source. When an investigator tries to align a firewall log with an HMI event and the clocks differ by several minutes or hours, the story gets muddy.
Decide Where Logs Live
Store logs somewhere that an attacker on the control network cannot easily erase. For small environments this can be a central log server on the IT side or a managed logging service, with one-way or tightly controlled transfer from the OT zone. The principle is simple: the system being investigated should not hold the only copy of its own record.
Set retention based on how long it takes you to notice a problem. If you review quarterly, a few weeks of logs is not enough. Ask your insurer, regulators, or customers if specific retention is required.
Decide Who Looks
A log nobody reads is just storage. Assign responsibility:
- A named person or provider reviews key alerts daily or at an agreed frequency
- A short list of alert triggers goes straight to a phone: remote access outside business hours, repeated failed logins, new device on the control network, configuration changes outside a maintenance window
- Someone owns the decision on what to do when an alert fires, including when to call operations, IT, and outside help
Write the response steps down. An alert at 2 a.m. should lead to a known action, not a debate.
Tune to Avoid Alert Fatigue
Too many alerts produce ignored alerts. Start with a small set of high-confidence triggers and add more as the team gains confidence. Review false positives monthly and adjust. In OT, normal behavior is often highly regular, which makes unusual activity easier to spot than in a typical office network.
Protect the Logging Itself
Treat the logging system as a security asset. Restrict who can change settings, use multifactor authentication for its console, and monitor for sudden gaps in logs. A device that stops reporting can be as meaningful as one that reports something odd.
Connect It to Maintenance
Tie your change management to your logs. When a technician or vendor performs maintenance, record the ticket or work order and the expected window. Then an authorized change inside the window looks normal and an unexplained one stands out.
Start Small
A practical first project is to capture remote access and boundary firewall logs into one protected location, with a handful of alerts that notify a named person. That alone dramatically improves your ability to answer what happened.
Ironfield Cyber helps energy services firms and small utilities design right-sized logging for control environments, with attention to uptime and safety. If you want a practical starting design, we can walk the site with your operations team.