When people picture an attack on industrial systems, they often imagine a controller being hijacked directly. In practice, two other kinds of systems tend to be the most exposed and most valuable: engineering workstations and historians. Engineering workstations are where programs are written and downloaded to controllers. Historians collect and store process data, and they often sit where IT and OT networks meet.
Because both are ordinary computers running familiar operating systems, they can be protected with familiar techniques, provided you account for operational constraints.
Why these two systems matter
An engineering workstation typically has the software and credentials to change how controllers behave. Anyone who controls it can potentially alter logic, change setpoints, or disrupt production.
A historian gathers data from many controllers and makes it available to business users, analysts, and sometimes vendors. That connectivity makes it a bridge between networks. If it is compromised, an attacker may use it to reach the control side, or to read sensitive process information.
Engineering workstation basics
Dedicate it to the job
Do not use the engineering workstation for email, web browsing, or general office work. Every additional use adds risk. If staff need to read documentation or research a fault, give them a separate computer.
Control who can log in
- Use individual accounts, not a shared login.
- Limit local administrator rights to those who need them.
- Require strong passwords and, where supported, MFA.
- Disable accounts promptly when staff leave.
- Lock the machine physically or in a restricted room.
Protect the project files
Controller programs are valuable and fragile. Store master copies under version control or in a controlled repository, keep an offline backup of every program and configuration, and record each change with who made it and why. In a ransomware event or a failed update, those backups can save days.
Manage software and patches carefully
Patching in OT must be tested, because an update can break vendor software or communication with devices. Create a process:
- Track which vendors support which operating system versions
- Test patches on a spare machine or during a planned outage
- Apply security updates on a schedule that fits maintenance windows
- Where a system cannot be patched, add compensating controls such as stricter network isolation
Limit what it can reach
Use firewall rules so the workstation can communicate only with the controllers and servers it needs, and not freely with the internet or the business network.
Historian basics
Place it deliberately
Historians often live in a demilitarized zone between the control network and the business network. Make sure traffic flows in the right direction, and that the business side pulls data from the historian rather than connecting directly into control devices. Ask who has designed and documented these paths.
Reduce what is exposed
- Disable unused services and default accounts
- Change vendor default passwords
- Restrict access by user group and need
- Keep remote access tightly controlled and logged
- Avoid giving vendors permanent access
Protect the data and the database
Back up the historian database and test restoring it. Historical data is often needed for regulatory records, performance analysis, or incident review. Also consider who may read it, since process data can reveal operational details.
Watch the connections
Monitor which systems connect to the historian and from where. New or unusual connections are worth investigating.
Both systems: logging and recovery
Turn on logging and send it to a central location. Document how to rebuild each system from scratch, including software versions, license keys stored securely, and configuration steps. A rebuild guide turns a multi-day crisis into a managed recovery.
A hypothetical scenario
Consider a hypothetical small water utility with one engineering laptop and one historian server. The laptop is also used for email, and a vendor has permanent remote access to the historian. By separating the laptop for dedicated use, removing the standing vendor access in favor of scheduled sessions, and testing a restore of the historian database, the utility would reduce two of its most likely points of failure, with little change to daily operations.
Coordinate with operations
Any change should involve the people who run the process. Plan work in maintenance windows, have a rollback plan, and test on non-production equipment where possible. Security improvements that cause an outage lose support quickly.
Where Ironfield Cyber helps
Ironfield Cyber helps energy and industrial operators review these critical systems and design practical improvements that fit operational realities. If you would like a walkthrough of how your engineering workstations and historians are configured, we can start with a focused review.