OT and ICS Security: Protecting the Industrial World

1. Introduction

OT and ICS security has become one of the strategic priorities of industrial cybersecurity. While confidentiality dominates the CIA triad in IT, availability and integrity are absolute in OT environments: a failing PLC can stop a production line, cut the power supply or compromise people’s physical safety. In this article we explore how to protect these critical systems with a practical methodology based on standards such as IEC 62443.

The IT/OT convergence, driven by Industry 4.0, has exposed industrial plants to the same threats as corporate networks: ransomware, APTs and insecure remote access. OT and ICS security is no longer optional: it is a regulatory, operational and financial necessity. Studies from 2026 confirm that more than 60% of industrial organizations suffered at least one cybersecurity incident in the previous year, and half of them originated through the corporate network or poorly protected remote access.

To grasp the scale of the problem, recall public incidents such as the Colonial Pipeline attack in 2021 or the multiple assaults on water and energy infrastructure in 2023 and 2024. In every case, the pattern was identical: an IT entry point granted access to the OT network, and a lack of segmentation did the rest. That is why any OT and ICS security strategy must start by understanding the Purdue reference model and the trust zones defined by IEC 62443.

Throughout this article we build a conceptual and technical lab: a simulated OT network, zone-based segmentation, monitoring of industrial protocols with community tools, and an OT incident response plan. By the end, you will have a clear roadmap to raise the OT and ICS security of your organization, exactly as Jaymon Security does in our clients’ industrial projects.

2. Understanding the Purdue Model and IEC 62443

The Purdue Reference Model (or ISA-95) organizes industrial infrastructure in levels that go from physical devices to enterprise management:

Level	Zone	Typical systems	Risk
0	Physical processes	Sensors, actuators, motors	High
1	Basic control	PLCs, RTUs, DCS	High
2	Supervision	SCADA, HMIs, historians	Medium
3	Operations	MES, plant scheduling systems	Medium
4	Enterprise	ERP, email, internet access	Low

Fig. 1 – Purdue model levels and typical systems per zone.

IEC 62443 provides the security framework: it defines zones and conduits, defense in depth, and the technical requirements per Security Level (SL). The core idea is that traffic between zones must only cross controlled conduits, ideally through industrial firewalls or unidirectional gateways (data diodes) when the flow is read-only.

OT and ICS security therefore requires a design where no level 0-2 device is reachable from the corporate network without passing through an industrial DMZ. It is usually the first control recommended by any industrial security audit.

2.1. Security Levels (SL) in IEC 62443 in detail

IEC 62443 defines four Security Levels (SL). SL 1 protects against accidental errors; SL 2, against casual attackers with simple means; SL 3, against skilled attackers with moderate resources able to exploit known vulnerabilities; and SL 4, against sophisticated adversaries that design tailored attacks, such as the APT groups operating against critical infrastructure. Most real plants only reach SL 2, when the recommended target for energy, water or process industries is SL 3. Comparing the achieved SL with the target defines the improvement path: moving from SL 2 to SL 3 demands strong authentication across network assets and data integrity protection.

3. Industrial protocols and their vulnerabilities

3.1. Modbus and DNP3

Modbus remains the most widely deployed protocol in electrical and automation installations. Sadly, it is a protocol without authentication or encryption: any node on the network speaking Modbus can read and write registers on a controller. Tools such as modbus-cli or Scapy allow discovering devices and manipulating them in seconds:

# Discover Modbus devices on the OT network
python3 -m pip install modbus-cli
modbus discover 192.168.10.0/24

# Read register 0 of device 1
modbus read 192.168.10.11 1 0 10

# Write a register (dangerous in production)
modbus write 192.168.10.11 1 0 9999

Fig. 2 – Example Modbus enumeration with common offensive tools.

DNP3, widely used in the electric sector, incorporates datalink and application layers with optional authentication, but most legacy deployments do not enable it. The underlying transport is usually plain TCP/IP, without TLS, which allows spoofing and replay attacks.

3.2. OPC UA and the future of convergence

OPC UA is the modern standard and does support encryption and certificate-based authentication. However, its complexity causes many integrations to be deployed with security disabled by default, creating a false sense of protection. Auditing the configuration of OPC UA servers must be part of any OT and ICS security checklist.

3.3. Real attacks on PLCs and HMIs: Stuxnet and Industroyer

Stuxnet (2010) rewrote the firmware of Siemens S7-300 PLCs to alter the speed of the Natanz centrifuges without operators noticing: a compromised controller can sabotage the physical world from the digital ring. Industroyer (2016) and its variant Industroyer2 (2022) opened breakers of the Ukrainian power grid by sending perfectly valid DNP3 frames, without exploiting any relay vulnerability: knowing the protocol and reaching the control network was enough. The lesson for OT and ICS security is twofold: watch not only write functions but the logical origin of every command, and protect engineering workstations, because a compromised HMI allows rewriting PLC firmware and erasing traces, exactly as Stuxnet did.

4. Lab: a segmented simulated OT network

We will build a lab with two virtual machines and containers:

# Simulated OT network with Docker
docker network create -d bridge --subnet=192.168.10.0/24 ot_net
docker network create -d bridge --subnet=192.168.99.0/24 it_net

# Simulated PLC (OpenPLC)
docker run -d --name plc1 --network ot_net -p 502:502 openplc/openplc:v3

# HMI (Scada-LTS)
docker run -d --name hmi --network ot_net -p 8080:8080 scadalts/scadalts:latest

Fig. 3 – Deploying a simulated plant with OpenPLC and Scada-LTS.

From the IT-level machine (192.168.99.x) we verify that direct access to the PLC must be denied. Only the industrial firewall (implemented with iptables on a bridge node) allows the specific flow: IT → DMZ → OT:

# Industrial firewall: only allow HMI -> PLC on port 502
iptables -A FORWARD -i eth_it -o eth_ot -j DROP
iptables -A FORWARD -i eth_ot -o eth_it -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth_it -o eth_ot -p tcp --dport 502 -j ACCEPT

Fig. 4 – iptables rules implementing a controlled conduit between zones.

This exercise demonstrates that a well-designed segmentation turns an exposed system into an isolated one, without replacing existing PLCs.

4.1. Plant asset inventory and criticality

Before segmenting you must know what you are protecting. A typical water treatment plant inventory would look like this:

Asset	Level	Criticality	Protocol
PLC1 (pumping)	1	Critical	Modbus TCP
PLC2 (chlorination)	1	Critical	DNP3
RTU telemetry	1	High	DNP3
SCADA historian	2	High	OPC UA

Each row becomes an industrial firewall rule and helps spot orphan assets when real traffic does not match what was declared, an essential check in any OT and ICS security audit.

5. Monitoring and detection in OT environments

Visibility is the first problem in any plant: legacy OT equipment does not generate security logs nor support conventional agents. The answer is passive network traffic analysis (SPAN/TAP) with tools such as Zeek or Suricata with industrial protocol signatures:

# OT traffic analyzer with Zeek
zeek -i eth_mirror -r capture_ot.pcap
# Review Modbus events
cat modbus.log | head -20

# Suricata with industrial protocol rules
suricata -i eth_mirror -S /etc/suricata/rules/ot.rules

Fig. 5 – Passive capture of OT traffic to detect anomalous commands.

It is also worth correlating with a SIEM such as Wazuh, which already includes decoders for Modbus and DNP3 via community plugins. Basic detection rules: writes outside maintenance windows, network scans inside the plant, or configuration changes on PLCs.

5.1. Detection rules specific to OT protocols

Beyond the general analysis, we can define signatures for concrete behaviors, such as Modbus writes to process registers:

# Zeek signature: alert on Modbus writes to process registers
signature modbus_write_alert {
    ip-proto == tcp
    dst-port == 502
    event "Modbus write to process register"
}

Suricata needs the Modbus decode enabled and suspected functions signed; correlating both in the SIEM reveals internal scans and PLC configuration changes, key indicators for monitoring OT and ICS security.

6. Secure remote access and OT incident response

Remote maintenance access is the most frequent entry vector. The best practice is a bastioned jump host in the OT DMZ with MFA, session recording (as with Teleport or Guacamole) and temporary provisioning. In parallel, the OT incident response playbook must prioritize physical containment: isolate the zone, avoid blind system reboots (evidence lives in memory), and talk to plant operators before any technical action.

An OT and ICS security plan must include periodic drills, backups of firmware and PLC configurations, and an updated asset inventory with criticality. Ransomware response in OT, for example, differs from IT: stopping the process can be costlier than the ransom itself, and decisions must be made by mixed operations and cybersecurity teams.

6.1. OT incident response playbook in measurable steps

The plan must be written, tested and assigned. A proven sequence for incidents on PLCs and HMIs is:

Step	Action	Owner	Target time
1	Confirm and classify the incident	Operations center	15 min
2	Isolate the zone without stopping the process	Plant + SOC	30 min
3	Preserve memory evidence, no reboot	Incident response	1 h
4	Restore firmware and configuration from backups	Industrial team	4 h
5	Resume in degraded mode and run root cause analysis	SOC + operations	8 h

Every drill must validate these times: in the plant, minutes of downtime translate into immediate losses, and coordination with process operators distinguishes a good OT response from an avoidable blackout.

7. Conclusion

OT and ICS security requires a different approach from corporate networks, but it uses known principles: zone segmentation, visibility, access control and tested response plans. The Purdue model and IEC 62443 provide the map and the rules; open-source tools let you start today without big investments.

At Jaymon Security we help industries and operators audit and strengthen their OT and ICS security: from asset inventory and segmentation to continuous monitoring and incident drills. If your plant is connected, it is worth knowing whether it is protected. Find out more at our contact page, in the IEC 62443 framework and in CISA’s OT guidance.

Need help with OT and ICS security?

At Jaymon Security, we help organizations protect their systems. From security audits to SIEM/SOC implementation, our expert team designs custom solutions.