SCADA (Supervisory Control and Data Acquisition) and ICS (Industrial Control Systems) differ significantly from conventional IT systems, especially when it comes to communication protocols. Unlike the standardized TCP/IP stack that underpins traditional IT networks, SCADA/ICS environments use a wide variety of protocols—often unique to each manufacturer—which complicates integration and security efforts.

SCADA/ICS Manufacturers

A large number of vendors produce SCADA and ICS hardware, each often using distinct and sometimes proprietary protocols. Key industry players include:

Siemens

Honeywell

Toshiba

Allen-Bradley

Mitsubishi

GE

Schneider Electric

Rockwell Automation

Among others

These manufacturers design diverse systems with different communication standards, which contributes to the complexity of securing these environments. The lack of standardized protocols has, in some cases, provided a layer of “security through obscurity,” since many cyber attackers are not familiar with these unique systems.

Common ICS Communication Protocols

For professionals conducting penetration tests or working within OT (Operational Technology) security, a basic understanding of ICS protocols is essential. Some of the most commonly used protocols include:

Modbus

DNP3

ICCP

CIP (Common Industrial Protocol)

• EtherNet/IP
• CompoNet
• ControlNet
• DeviceNet

OPC (OLE for Process Control)

PROFIBUS

Foundation Fieldbus H1

Each of these operates differently and will be explored in depth in future articles here at Ouroboros Security. For now, let’s delve into the most prevalent one: Modbus.

Modbus Overview

Modbus RTU (Serial)

Developed in 1979 by Modicon (now a part of Schneider Electric), Modbus RTU has become one of the most widely adopted communication protocols in industrial automation. It’s a lightweight, public domain protocol designed for serial communication, supporting data payloads up to 253 bytes.

Operating at the application layer (Layer 7 of the OSI model), Modbus uses a simple request-response mechanism that is efficient and demands minimal computing resources. It was initially deployed using RS-232C (for direct, point-to-point connections) and RS-485 (for multi-device setups), with up to 32 devices on a shared line. Each device on the network has a unique identifier.

The protocol follows a master-slave (or client-server) structure, where only the master can initiate communications. The slaves, which can be devices like sensors, actuators, or drives, simply respond to commands or queries. These responses can be targeted to a specific device or broadcast to all, though only direct queries elicit a response. Slaves cannot initiate communication, they only react.

A Modbus message typically contains the slave address, a function code, relevant data, and an error-checking field. Function codes define the type of operation requested and are a core part of the protocol’s functionality.

Below is a list of function codes.

Function Codes and Diagnostics

One of the most critical function codes is Function Code 8, used for diagnostics. Within this, various sub-function codes exist. For instance, Sub-function Code 04 (Force Listen Only Mode) can potentially be exploited to trigger a Denial of Service (DoS) in some systems.

Modbus TCP

Modbus TCP adapts the original protocol for use over TCP/IP networks. While it maintains the same structure, function codes, and data limits, it discards the RTU-specific checksum since TCP/IP already includes its own error-checking mechanisms.

Modbus TCP communications occur over port 502 and add a 7-byte Modbus Application Protocol (MBAP) header to the RTU frame. This header includes:

Transaction Identifier (2 bytes)

Protocol Identifier (2 bytes)

Length (2 bytes)

Unit Identifier (1 byte)

This format makes it suitable for use in more modern networking environments while maintaining backward compatibility in functionality.

Security Concerns in Modbus

Despite its widespread use, Modbus suffers from several security vulnerabilities:

No Authentication: There’s no built-in mechanism to verify the identity of devices or users. Anyone can send a valid-looking Modbus message and expect a response.

Lack of Encryption: All Modbus communications are transmitted in plain text, making them easy to intercept and analyze.

Weak Integrity Checks: While Modbus RTU includes a basic checksum, Modbus TCP relies on lower-layer transport checks, which can be manipulated.

Broadcast Abuse: Without limitations on broadcast traffic, attackers can potentially flood the network with messages, causing a denial-of-service.

These weaknesses make Modbus an easy target for attackers if the network is exposed or improperly segmented.

Final Thought

While SCADA/ICS systems offer powerful control and automation capabilities, their reliance on diverse, often outdated communication protocols like Modbus makes them particularly vulnerable from a cybersecurity standpoint. Understanding the structure and limitations of protocols such as Modbus is essential for securing modern industrial environments.