Why effective IT-OT monitoring requires visibility across the entire attack chain

An OT sensor alone does not tell the whole story.

Passive network monitoring has become the standard in industrial environments for good reason. A passive sensor monitors network traffic without sending packets to PLCs, controllers or other sensitive OT equipment itself. This provides valuable visibility without disrupting the production process. However, simply deploying a sensor in the OT network does not constitute comprehensive IT-OT monitoring.

The main challenge is not simply recognising Modbus, S7Comm or EtherNet/IP traffic. The real value emerges when events from the IT network, the transition zone and the OT network are correlated.

The most important monitoring points are not limited to OT

Many attacks on industrial environments originate on the IT side. An attacker may, for example, compromise a user account, laptop, VPN connection or remote management environment and subsequently attempt to move towards the production environment.

For integrated IT-OT monitoring, at least three monitoring points are therefore relevant:

1. The IT network, where the attack often begins.
2. The transition zone or industrial DMZ, containing systems such as a jump host, historian or OPC UA server.
3. The OT network, where PLCs, controllers and other industrial systems operate.

These monitoring points are not merely required to collect more network traffic. More importantly, they are needed to connect the different stages of an attack.
 

Each sensor sees only one part of the attack

Traffic from IT to OT rarely travels directly from a user's laptop to a PLC. There are usually several security layers and intermediary systems between the two environments, such as a firewall, jump host, engineering workstation, historian or OPC UA server.

From the perspective of the OT network, the source of the traffic is therefore often not the attacker's original laptop. The OT sensor only sees the intermediary server that ultimately communicates with the PLC.

Under normal circumstances, that server may be authorised to communicate with the PLC. The individual steps preceding it may also appear legitimate. A user logging on to a jump host is not inherently suspicious. Nor is an OPC UA server requesting information from a controller.

The attack only becomes visible when these events are correlated based on factors such as time, systems, user accounts, network connections and processes.

No individual sensor tells the complete story. The attack chain only becomes visible when the individual links are connected.
 

Example scenario: from IT account to PLC

Suppose an attacker obtains the login credentials of a maintenance engineer through a phishing email.

At 09:12, the attacker logs in to the organisation's VPN environment from an unknown laptop. A connection is then established from the IT network to a jump host in the industrial DMZ.

On its own, this connection may not immediately trigger an alert. After all, the maintenance engineer regularly uses the jump host for maintenance activities.

At 09:18, a connection is initiated from the jump host to an OPC UA server. This may also appear legitimate, as these systems are normally permitted to communicate with each other.

A few minutes later, an unusual connection is established from the OPC UA server to a PLC. A write command is sent to a register that is normally modified only during scheduled maintenance.

Each of the different monitoring points sees only part of the activity:
 

Viewed in isolation, these events may not appear serious enough to constitute an incident. However, once they are correlated by time, host and user account, a clear attack chain emerges:

Compromised account → VPN → jump host → OPC UA server → PLC

The OT sensor sees the final command but, without additional context, does not know who the original user was. The IT sensor sees the VPN login but not the action that was ultimately performed on the PLC. The real value emerges when these two worlds are brought together.
This makes it possible not only to report that unusual OT traffic has been detected, but to provide a much more complete picture of the incident:

A maintenance account was used from an unknown system to send an unusual write command to a PLC via the jump host and OPC UA server. For a SOC analyst, administrator or incident response team, this is considerably more useful than an isolated technical alert.
 

Suricata detects, Zeek provides context

Within an IT-OT sensor, Suricata and Zeek fulfil different but complementary roles. Suricata is well suited to identifying known attack patterns, anomalous packets and unwanted network behaviour. In OT environments, this can include detecting:

• malformed industrial network packets;
• illegal or unusual commands;
• reconnaissance and scanning activity;
• known ICS malware families;
• communication with suspicious external infrastructure.

Most initial attacks and malware activity often become visible on the IT side first. Suricata can, for example, identify exploit traffic, command-and-control communication, lateral movement and other attack patterns before an attacker reaches the OT environment.

Zeek focuses more on analysing and structuring network communications. Rather than simply generating an alert, Zeek records detailed metadata about connections, systems, protocols and actions performed.

Suricata primarily helps answer the question:
Is this traffic suspicious?

Zeek helps answer the questions:
Which systems are communicating with each other, which protocol are they using and what exactly is happening?

Combining both technologies provides significantly more context than either detection method alone. Which protocols are relevant depends heavily on the equipment in use and the industry. A Siemens environment, for example, requires visibility into S7Comm and PROFINET. In Rockwell environments, EtherNet/IP and CIP are important. Energy environments commonly use protocols such as DNP3 and IEC 104.
 

Available OT protocol support in Zeek

The additional protocol parsers are available through the Zeek Package Manager. The ICSNPP plugins are developed and maintained by CISA and Idaho National Laboratory.

For protocols that are not directly supported by this set, we determine which additional parser or detection component is required for each customer environment.
 

OT detection based on MITRE ATT&CK for ICS

In addition to protocol parsers, ACID is also available: ATT&CK-based Control-system Indicator Detection. This Zeek plugin is designed to detect indicators associated with attack techniques from MITRE ATT&CK for ICS. This allows network activity not only to be recorded at a technical level, but also to be mapped to recognisable attacker tactics and techniques.

Here too, context remains essential. A single technical event does not necessarily indicate an attack. Combining multiple indicators, systems and timelines makes it possible to distinguish normal operational activity from an actual attack chain.
 

SPAN port or hardware TAP?

A passive sensor can only analyse the traffic it actually receives. The technical assessment should therefore establish at an early stage how the relevant network traffic will be copied to the sensor. In many environments, this is done using a SPAN or mirror port on a managed switch. OT environments, however, frequently use older or unmanaged switches. These do not always provide the ability to mirror network traffic to a sensor. In such cases, a hardware TAP is often the preferred solution. It is physically installed in the network connection and creates a copy of the traffic for the sensor, without making the sensor an active part of the communication.

An assessment should therefore document not only the protocols and systems in use, but also:

• the type and manufacturer of the switches;
• the availability of SPAN or port mirroring functionality;
• the physical locations of network connections;
• link capacity and redundancy;
• the desired and practically feasible monitoring points.

Modest hardware, extensive visibility

One advantage of OT networks is that traffic volumes are often relatively low. Industrial protocols typically transmit small amounts of data, and many OT connections are predictable and repetitive. As a result, a relatively modest sensor can monitor a large number of systems and network connections. The scalability and bandwidth challenges familiar from larger IT environments are far less significant in many OT networks. This makes passive IT-OT monitoring not only technically effective, but also practical and scalable.
 

From network packet to attack chain

A good OT sensor identifies protocols, systems and anomalous commands. A good IT-OT monitoring solution goes one step further. It correlates events from the IT network, the industrial DMZ and the OT network. This reveals how an attacker moves through the environment and which systems, accounts and network connections are part of the same incident.

The key distinction, therefore, is not deploying yet another sensor. It is correlating the entire attack chain.

Our IT-OT sensor combines passive network monitoring, protocol analysis and detection with contextual information from the rest of the environment. The result is not merely an alert indicating that something unusual has occurred, but an evidence-based picture of who did what, when it happened and which route was taken.