Common ICS Protocols and Risks

Industrial protocols are the language controllers, SCADA, and field devices use to exchange data and commands. Most were designed for isolated, trusted networks and therefore lack the authentication and encryption we expect in IT.

Understanding their weaknesses tells you exactly what an attacker on the OT network could do, and what compensating controls are needed.

Modbus is one of the oldest and most widespread industrial protocols, simple and easy to implement. Modbus/TCP carries it over Ethernet.

• A master reads and writes registers/coils on slave devices
• No authentication: any device that can reach a slave can command it
• No encryption: traffic is plaintext and easy to read or forge
• No integrity checks against a malicious sender

An attacker on the segment can simply write a coil to actuate equipment.

DNP3 (Distributed Network Protocol) is common in electric and water utilities, designed for unreliable long-distance links with features like time-stamping and report-by-exception.

• Richer than Modbus but the base protocol still lacks built-in security
• Vulnerable to spoofing and replay on an open network
• A Secure Authentication (DNP3-SA) extension exists but is not always deployed

Where DNP3-SA is unsupported, network controls must compensate.

The OT landscape has many protocols; a few you will frequently meet:

• EtherNet/IP (CIP) — widespread in manufacturing automation
• PROFINET / PROFIBUS — common in European industrial settings
• IEC 60870-5-104 — power utilities, similar role to DNP3
• IEC 61850 — substation automation
• OPC / OPC-UA — a data-exchange standard; OPC-UA notably supports security

OPC-UA stands out because it was designed with authentication and encryption as options.

The most consequential weakness across legacy protocols is the absence of authentication. The protocol cannot tell a legitimate master from an attacker.

• Any host on the network can issue valid-looking commands
• There is no concept of credentials or authorization in the message
• The device trusts whatever it receives

This is why network access control is the front-line defense: if attackers cannot reach the protocol, they cannot abuse it.

Plaintext protocols expose the process to anyone passively watching the wire.

• An attacker can map the process from observed reads and writes
• Setpoints, alarms, and commands are visible
• With a position inline, traffic can be modified in transit

Capturing such traffic for analysis must be done carefully and only on systems you are authorized to assess; passive taps avoid disturbing the live process.

Without authentication or freshness guarantees, recorded traffic can be reused.

• Replay — capture a legitimate command and resend it later to repeat an action
• Command injection — craft a valid protocol message to actuate equipment
• False data injection — feed the HMI fabricated sensor values

False data injection is especially dangerous: operators may see normal readings while the process drifts into an unsafe state.

An attacker positioned between SCADA and a controller can both read and rewrite the exchange.

• Show the operator safe values while sending harmful commands to the PLC
• Suppress alarms so a fault goes unnoticed
• Alter setpoints without the operator's knowledge

This blinding of operators while sabotaging the process is a hallmark of sophisticated ICS attacks and motivates integrity monitoring at the network level.

Where the equipment supports it, prefer protocol options that add security.

• OPC-UA with security policies enabled provides authentication, signing, and encryption
• DNP3-SA adds challenge-response authentication to DNP3
• TLS wrappers or secure gateways can protect legacy traffic between zones

These are not universally available on old devices, so design assumes many endpoints remain insecure and protects them at the network boundary.

Because you often cannot fix the protocol, you detect abuse instead. OT-aware monitoring understands these protocols and flags anomalies without injecting traffic.

• Build a baseline of normal masters, slaves, and command patterns
• Alert on unexpected write commands or new devices
• Detect out-of-range setpoints or commands from unauthorized hosts
• Use passive taps so monitoring never disturbs the process

Because legacy protocols cannot defend themselves, the network must defend them.

• Segment so only authorized hosts can speak the protocol to a controller
• Use protocol-aware firewalls to allow only expected function codes
• Deploy passive intrusion detection tuned to ICS protocols
• Where possible, migrate to secure variants

This sets up the architecture defenses in the final lesson.

Reason about the core risk of legacy ICS protocols.

You learned the protocols and their inherent weaknesses.

• Modbus, DNP3, and peers were built for trusted networks and lack auth and encryption
• This enables sniffing, replay, command injection, false data injection, and MITM
• Attackers can blind operators while sabotaging the process
• Prefer secure variants (OPC-UA, DNP3-SA) where supported
• Otherwise defend with segmentation, protocol-aware firewalls, and passive monitoring

Next: architecting protection for critical infrastructure.