Blog
One Year on from the JLR Cyber Attack: what could have changed the outcome?
Cyber Security
Holly Ellwood
18 August 2026
Secure data optimisation & proactive backup
Proactive Licensing, Compliance & Asset Management
Agile, Modular, & Secure Cyber Security & Managed Siem
Manage & Transform Multi-Cloud, Hybrid & On-Premise
Manufacturing and industrial environments face a distinctive security challenge. Attacks often originate on the IT side, move through a transition zone, and then target operational technology where production takes place. A single OT sensor, no matter how sophisticated, captures only one part of this journey.
The real protection comes from correlating events across all three zones simultaneously. This is where most industrial security programmes fall short.
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.
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:
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.
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.
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:
| Monitoring point | What is observed? |
|---|---|
| IT network | A VPN login and a connection to the jump host |
| Industrial DMZ | A session from the jump host to the OPC UA server |
| OT network | A technically valid but unusual write command to the PLC |
| Endpoint and identity logging | The account is being used from an unknown device and at an unusual time |
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.
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:
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: Is this traffic suspicious?
Zeek helps answer: 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.
| Protocol | Support |
|---|---|
| Modbus | Available natively in Zeek, with a more comprehensive parser available through CISA/INL |
| DNP3 | Available natively in Zeek, with a more comprehensive parser available through CISA/INL |
| MQTT | Available natively in Zeek |
| BACnet | Plugin provided by CISA/INL |
| BSAP | Plugin provided by CISA/INL |
| ANSI C12.19 | Plugin provided by CISA/INL |
| EtherNet/IP and CIP | Plugin provided by CISA/INL |
| EtherCAT | Plugin provided by CISA/INL |
| GE-SRTP | Plugin provided by CISA/INL |
| Genisys | Plugin provided by CISA/INL |
| HART-IP | Plugin provided by CISA/INL |
| Omron FINS | Plugin provided by CISA/INL |
| OPC UA | Plugin provided by CISA/INL |
| PROFINET | Plugin provided by CISA/INL |
| ROC Plus | Plugin provided by CISA/INL |
| S7Comm and COTP | Plugin provided by CISA/INL |
| Synchrophasor | Plugin provided by CISA/INL |
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, the relevant parser or detection component is determined for each customer environment.
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.
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.
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:
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.
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.
Celerity combines passive network monitoring, protocol analysis and detection with contextual information from the rest of your environment. This means your IT and OT worlds are no longer seen in isolation.
Our managed SIEM and MDR services work across IT and OT networks to correlate events in real time. Rather than generating isolated alerts from individual sensors, we provide a unified picture of how an attack moves from user account to PLC, across firewalls, jump hosts and intermediary systems.
This approach—moving from scattered monitoring points to correlated, actionable intelligence—is especially critical for manufacturing and industrial environments, where production uptime and safety are non-negotiable. We help organisations understand their OT security posture through free, tailored assessments that combine external threat intelligence with a structured view of your IT and OT controls.
When an incident does occur, visibility across the entire attack chain enables faster response. Our incident response team can trace the origin of an attack, identify all affected systems, and contain the threat before it escalates into production downtime.
The result is not merely an alert indicating that something unusual has occurred. It's evidence-based protection: a clear understanding of who attacked your systems, how they got in, what they could access, and where they were stopped.
If you operate manufacturing, industrial, or critical infrastructure systems, a single free assessment can reveal where your monitoring and detection gaps are. We combine external threat intelligence with an internal review of your IT and OT controls, giving you a prioritised view of what matters most.
Request your free OT security assessment
Request a free trial for 30 days
Blog
18 August 2026
21 July 2026
Blog
08 June 2026