When people hear monitoring, they picture a security operations center and a wall of dashboards. For a small operator or contractor with control systems to protect, that picture is both unaffordable and unnecessary. What you need is a short list of events that tell you when something changed, someone connected or something behaved unusually, plus the discipline to look at them.
Why monitoring matters in OT
Control systems are built to run, not to explain themselves. Older devices produce little logging, and many sites have none. That means an unauthorized change, a stray laptop or a vendor connection can go unnoticed for months. Monitoring does not prevent incidents, but it shortens the time from something wrong to someone knowing, which usually decides how bad the outcome becomes.
Monitoring in OT also has a different constraint from IT: do not disrupt the process. Choose passive and low-impact methods, and coordinate any change with operations.
Start with the questions you want answered
Instead of collecting everything, decide what you need to know.
- Who connected remotely, when and to what?
- Did anyone change controller or safety logic?
- Did a new device appear on the control network?
- Are devices talking to places they should not?
- Did a critical server, engineering workstation or gateway behave unusually?
- Did anyone log in with an administrator account outside normal hours?
Each question maps to a specific data source.
High-value things to collect
Remote access records
Log every remote session: user, time, source, destination and duration. If vendors connect, record which vendor and which work order. This is the single most valuable log for most small operators.
Authentication events
Collect successful and failed logins on engineering workstations, historians, human-machine interface servers and domain controllers that support the control environment. Watch for repeated failures, logins at odd hours and use of shared accounts.
Configuration and logic changes
Where controllers and software support it, log program downloads, changes to logic and mode changes. Where they do not, compare periodic backups of controller programs against known-good copies, and investigate differences.
Firewall and network device logs
The firewall between business and control networks should record allowed and denied connections. Denied attempts show who is knocking. Unexpected allowed connections show where rules need tightening.
Asset changes
A new device on the network, or a known device with a changed address, deserves a look. Passive network monitoring tools designed for industrial environments can discover assets and alert on changes without sending probes that could disturb controllers.
Endpoint alerts on Windows-based OT systems
Where antivirus or endpoint protection is supported by the vendor, forward its alerts. Confirm with the vendor that agents will not interfere with the application.
What to skip at first
- Verbose debug logs with no clear use.
- Collecting logs you have no plan to review.
- Complex correlation rules before the basics are working.
- Tools that actively scan fragile devices without vendor approval.
A small set of reviewed logs beats a large archive no one reads.
Decide who looks and how often
Logs matter only if someone reviews them and knows what to do. Assign roles.
- Daily: automated alerts go to a named person or provider.
- Weekly: review remote access and change summaries.
- Monthly: review administrator accounts, new devices and firewall rule changes.
- After any incident or vendor visit: review activity during the window.
Write down what normal looks like for your environment. Anomalies are easier to spot against a baseline.
Protect the logs
Store copies of logs somewhere an attacker on the control network cannot easily erase, such as a separate logging server or a managed service. Keep synchronized clocks across devices so events can be lined up during an investigation. Set retention based on your needs, remembering that investigations often start long after the event.
Connect monitoring to response
An alert needs a next step. For each important alert, write a short instruction: who to call, what to check and when to involve operations before changing anything. Test it during a tabletop exercise. Remember that in OT, an automatic response like disabling a device can cause a process upset, so human judgment and operations input come first.
Regulatory context
If you are subject to NERC CIP, TSA pipeline directives or similar obligations, logging and monitoring expectations may be defined for covered systems. Even where they are not, these frameworks and general CISA guidance provide a useful baseline for what to capture.
A practical starting point
- Log and review all remote access.
- Enable logging on the boundary firewall.
- Back up controller programs and compare them periodically.
- Passively monitor for new devices.
- Assign an owner and a review schedule.
Support from Ironfield Cyber
Ironfield Cyber helps operators design monitoring that fits their size and process constraints, and can provide managed detection for the IT side of the house. If you would like help deciding what to collect first, we can start with a short assessment of your control environment.