The SCADA Historian as a Lateral Attack Vector from IT to OT

The role of the historian in the industrial network

The SCADA historian, also called a process historian or data historian, is a component found in nearly every medium and large industrial plant. Its role is to continuously collect and store the process data coming from the control systems: temperature, pressure and flow values, machine states, alarms, and operational events. Everything that happens in the plant ends up in the historian, sampled at intervals that can range from seconds to tenths of a second for the most critical variables.

The most widespread products in the European market include OSIsoft PI System (now AVEVA), AVEVA Process Historian (formerly Wonderware), and other systems developed by automation vendors such as Siemens and Rockwell. Each system has its own technical specifics, but the function is the same: to be the centralized repository for the historical memory of the industrial process.

This function makes the historian indispensable: operations use it to analyze process performance, maintenance uses it to correlate mechanical anomalies with historical data, quality uses it for compliance analysis, and management uses it for production KPIs. The historian is not a niche system: it is the data infrastructure on which daily operational decisions rely.

The architectural problem: a foot in two networks

To do what it must do, the historian has to communicate with both worlds: it collects data from the OT network (where the PLCs, control systems, and sensors live) and exposes it to the IT network (where the business systems, reporting clients, and management dashboards live).

This position straddling the two networks is the reason for its usefulness and, at the same time, the source of its risk from a security standpoint. In well-designed architectures, the historian sits in an industrial DMZ, a separate zone that allows controlled communication between OT and IT without direct connectivity between the two networks. In less carefully designed architectures, which are more common than one would like, the historian has active interfaces in both the OT network and the IT network without any meaningful separation.

Even in the DMZ version, the historian is still a system with visibility into the OT network. It has open connections toward the OPC servers (which aggregate data from the PLCs), toward the field gateways, and sometimes toward the PLCs themselves. If an attacker manages to compromise the historian, they automatically gain access to these connections.

The attack path: from IT to OT through the historian

Lateral movement from IT to OT through the historian is a documented vector, not a speculative one. The attack chain follows logical and relatively simple steps for anyone with offensive skills.

Step 1: compromising an IT system

The initial entry point is typically in the IT network: a phishing email that installs ransomware or a RAT on an office computer, the compromise of a VPN account through stolen credentials, or the exploitation of a vulnerability on an exposed system. The attacker gains a foothold in the corporate IT network.

Step 2: reconnaissance and identification of the historian

Once inside the IT network, the attacker performs reconnaissance: scanning the network to identify hosts, services, and connections. The historian is easy to identify: TCP port 5450 for PI System, the presence of specific OPC or DCOM services, the host name that often includes variants of "historian", "pi-server", or "scada-server". It is not hard to find.

Step 3: exploiting the historian

This is where several possible vectors come into play. The historian often runs on Windows Server and may have unpatched operating system vulnerabilities, weak service configurations, or weak access credentials for the application interface. Some historian systems have had specific CVEs over the years, some with public exploits available.

A simpler alternative: if the historian uses default credentials or credentials shared with other already compromised systems, access does not even require complex technical exploitation.

Step 4: access to the OT network

Once the historian is compromised, the attacker inherits all of its connections. They can reach the OPC servers the historian is connected to and, through them, if segmentation is not strict, the PLCs and field devices. They can read process data in real time, identify the control systems present, and study the layout of the industrial process.

Step 5: potential manipulation

In the most advanced phase, an attacker with access to the OPC servers may not stop at reading: some configurations allow them to write values, modify setpoints, and send commands to field devices through the same channels the control system normally uses. This capability depends on the specific configuration of the installation (not all installations have writing enabled) but it is a real possibility in environments where the separation of roles and authorizations is not carefully configured.

Why this vector is underestimated

The historian tends to be managed by the IT department or by a specialized operational team, not by the OT team. It is perceived as an IT system, it runs on Windows, it is managed like a server, and so it is included in the IT patching and backup processes. But its connections toward the OT network and its interactions with field protocols make it a hybrid system, with security implications that neither the IT team nor the OT team typically manages completely.

The IT team does not know exactly what the historian connects to in the OT network, and it does not have the tools to monitor those connections. The OT team knows that the historian collects data but considers it an "IT-side" system and does not include it in its monitoring perimeter. The result is a critical system that falls into a gray area of responsibility and visibility.

What to monitor: the signals in the traffic

Monitoring the traffic to and from the historian is one of the controls with the best cost/benefit ratio for industrial networks that have this component.

Connections to the historian from unexpected hosts

Normal traffic toward a historian has predictable origins: the reporting clients, the dashboards, the business intelligence systems, the backup processes. A connection from a host that is not part of this set (a laptop, an IT server with a different function, a system that does not normally connect to the historian) is a signal to investigate.

Unusual queries or anomalous read volume

The historian responds to queries to retrieve historical data series. An attacker performing reconnaissance to understand the structure of the plant tends to make exploratory queries: requesting the list of available tags, retrieving period data for many different variables, querying metadata about the configuration. This pattern is different from normal operational queries, which tend to be repetitive and focused on a limited set of variables.

Large data exports outside business hours

A transmission of process data toward an external destination or toward an unexpected internal host, especially at times outside normal operational activity, is an indicator of possible exfiltration. An attacker who wants to understand the industrial process before acting has an interest in collecting long historical series.

Connections originated by the historian toward the OT network outside the baseline

Normally the historian connects to a defined set of OPC servers and field gateways. A new connection toward a PLC or an unexpected OT segment, especially if originated at unusual hours, indicates that someone is using the historian as a bridge to explore the OT network.

Failed authentication attempts on the historian interface

As with any system that has an authentication interface, multiple failed attempts, especially from unusual sources, are a signal of an attempted brute-force or the use of stolen credentials that have not yet been corrected.

Architectural measures to reduce the risk

Beyond monitoring, certain architectural measures structurally reduce the risk associated with the historian.

Industrial DMZ with unidirectionality: in a robust architecture, the historian sits in a DMZ that receives data from the OT network but cannot initiate connections toward it. Data flows only outbound from the OT network. This is achieved with firewalls configured to allow only connections established from the OT side, or with hardware data diode devices. It does not eliminate the risk on the DMZ, but it significantly limits what an attacker who has compromised the historian can do toward the OT network.

Separation of read and write accounts: if the architecture does not allow complete unidirectionality, at least the accounts used for data collection (read) must be separated from any accounts with write privileges. The account the historian uses to read data from the PLCs must not have write permissions.

Hardening of the operating system and historian software: the historian runs on Windows Server and must be included in the IT patching processes. Treating it like any other server is not enough: the specific ports and services of the historian software must be configured carefully, removing everything that is superfluous.

Periodic review of active connections: document and periodically verify which connections the historian has open toward the OT network. Legacy connections toward decommissioned systems or toward addresses that no longer correspond to anything known must be removed.

The historian is an emblematic example of how the network architecture in Italian industry has often evolved to meet operational needs without a systematic analysis of the security implications. It is not a problem of malicious design: it is the result of years of reasonable decisions made in isolation, which taken together create a significant risk vector. Understanding it is the first step to managing it.

The MON5 angle

Monitoring the historian means knowing its legitimate connections and noticing when new ones appear: exactly the kind of control that MON5 performs with passive, out-of-band NDR. The platform observes the traffic between the historian, the OPC servers, and the control network on native OT protocols, builds a baseline of the communications, and flags out-of-pattern connections, exploratory queries, and anomalous exports with ML anomaly detection.

The first step, however, is to truly map that bridge between IT and OT: how many connections the historian has, toward what, and since when. An OT assessment clarifies this without touching production systems.