The short answer
Historian Security
The historian is where everyone outside the control room wants to connect, which makes it the natural bridge for an attacker from the office to the plant. The design that prevents that is two historians: one in the control zone that collects from the controllers and the SCADA, and a replica in the DMZ that receives data one way from it and serves the office, the reports, and any cloud connection. Nothing in the office connects to the control zone historian, the DMZ replica cannot write back, accounts on the replica are read-only, the data path from control zone to DMZ is a one-way replication or a unidirectional gateway where the risk warrants it, and the archives on both are protected, backed up, and logged as the regulatory records they are.
Key points
- The historian is the server the office needs, which makes it the server the attacker wants.
- Two historians: collect in the control zone, serve from a replica in the DMZ.
- Data flows one way, control zone to DMZ; the replica cannot write back and the office cannot reach the collector.
- Read-only accounts for everyone who reads; the collector service account has the minimum rights to write.
- Archives are regulatory records: access controlled, backed up off site, and audited.
- Cloud and enterprise connections attach to the DMZ replica through a broker or a gateway, never to the collector.
The exposure
| Who wants historian data | Typical connection | Risk if connected to the control zone historian |
|---|---|---|
| Managers and office staff | Trend and dashboard clients on office computers | Every office computer becomes a path into the control zone |
| Reporting and compliance | Report servers, spreadsheets with database connections | Credentials in spreadsheets; report servers reachable from the office |
| Maintenance and laboratory systems | Database connections, scheduled exports | Enterprise systems with their own vulnerabilities reaching inward |
| Cloud analytics and vendor services | Internet connections from the historian | The control zone historian talking to the internet |
| Regulators and consultants | Exports, occasionally remote access | Remote access to a control zone server |
The design
The collecting historian lives in the control zone, or in the supervisory zone beside the SCADA servers, and collects from the controllers and the SCADA tag server. It is reached only by control zone clients and by the replication process. A second historian in the DMZ receives the data from the first through a one-way replication configured in the historian product, or through a unidirectional gateway or data diode where the utility has decided that the risk justifies hardware enforcement. The DMZ historian serves everything outside: office trend clients, report servers, database connectors, and the connection to any cloud service, which itself goes out through the DMZ. The firewall permits the replication from inside to the DMZ on its ports, permits the office to reach the DMZ historian, and permits nothing from the DMZ or the office into the control zone.
Accounts and access
- The collector service account on the control zone historian has rights to write history and nothing else, with no interactive login.
- The replication account has rights to read from the collector and write to the replica, and nothing else.
- Every reader on the replica has a read-only account, individual where the product allows and otherwise a role with no write rights; report servers and connectors use service accounts that are read-only.
- Engineering configuration of the historian is done from the control zone with an engineer account, not from the office.
- Web interfaces of the historian are enabled on the replica only, with encryption and authentication, and disabled on the collector.
- Vendor connectors and cloud agents run on the replica or on a separate DMZ host, never on the collector.
Archives as records
The archive files hold years of compliance measurements, and their integrity matters as much as their confidentiality. Access to the archive directories is restricted to the historian service and the backup process; administrators reach them through change management. The archives are backed up on a schedule, off the server and off site, with the backups themselves protected. Deletion and modification of archives are logged, and the historian audit log, where the product has one, is forwarded to the log collector. A retention policy says how long the records are kept, and a periodic export in a plain format provides a record that does not depend on the historian software at all.
Cloud and enterprise
A utility that sends data to a cloud analytics service, a regional operations platform, or an enterprise data lake does so from the DMZ, one way, through a broker or a gateway that publishes what has been selected and accepts nothing back into the control zone. Any inbound value from those systems, such as a demand forecast or an optimization setpoint, arrives in the DMZ, is validated, and is written to a designated SCADA tag by a controlled process, never directly to a controller. The connection uses encryption and certificates, the credentials live on the DMZ host, and the outbound firewall rule is specific to the destination.
Frequently asked questions
- Is a data diode necessary?
- For most water utilities a software replication through a firewall with one-way rules is proportionate. A unidirectional gateway is chosen where the consequences justify hardware enforcement, where a regulator or an insurer expects it, or where the utility wants to eliminate the possibility of a firewall misconfiguration. The two-historian design is the same either way; the diode replaces the firewall rule on that one path.
- The reporting tool needs to write calculated results back. Where do they go?
- Into the DMZ historian or a DMZ database, where the office and the reports can read them. If a calculated value must reach the SCADA for display, a controlled process in the control zone reads it from the DMZ through a one-way pull, validates it, and writes it to a designated tag. Nothing in the DMZ pushes into the control zone.
- What about the historian web interface that the vendor promotes?
- It is convenient and it is a web server on a control system machine. Run it on the DMZ replica only, with encryption, authentication, and the same patching as any DMZ server; disable it on the collector.
- How is historian access audited?
- By the historian audit log where the product provides one, by the operating system logon logs on the historian servers, and by the firewall logs for the connections that reach them, all forwarded to the log collector and reviewed on a schedule for readers who should not be there and for configuration changes.
Related topics
- Historian ArchitectureHow process history is collected, stored, and served: the collector, the archive, and the client layers, where the historian sits relative to SCADA and the DMZ, single-server and tiered designs for a utility, the store-and-forward buffer that survives outages, and the sizing that decides how many years fit on a disk.
- Industrial DMZ DesignThe buffer zone between the business network and the control system: what goes in it, the no-direct-path rule, push-not-pull data flows, the firewall pair, and the services a utility actually needs to place there.
- Data DiodesHardware that lets data flow one way only, from the control network outward, with no physical return path: what a data diode and a unidirectional gateway are, where they belong, what they can and cannot carry, and when a firewall is enough instead.
- SQL IntegrationConnecting SCADA and historian data to relational databases: why a utility does it, the methods, a schema that handles time series, the query patterns for totals and reports, the mistakes that flood a database or stall a server, and security.
- Long-Term StorageKeeping historian data for years: a retention policy by data class that follows the record rules, tiered storage from online to offline copies, downsampling, archive management, exports that outlive the historian, and the annual proof that old data reads.
- User Accounts and RolesWho can do what on the SCADA and how it is enforced: roles from view-only to administrator and their permission matrix, individual accounts including the operator console, service and vendor accounts, same-day offboarding, and the quarterly review.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.