Using Modbus PLC's? Here's How To Protect Them

Last week I wrote about a malicious attack on an industrial control system (ICS) initiated by outsiders. This week I'll discuss a PLC accident caused by an insider, and suggest some possible solutions for both of these incidents.

The accident happened at a petroleum company in Texas in 2001. A testing and programming facility for the petroleum company's PLCs was set up by an engineering consultant in at their head office in a distant city. An engineer, who had just returned from the plant site, used his laptop to connect to a PLC he believed was in his office. Instead the programming software connected to the last connected PLC, which was a live PLC at the plant site, 400 miles away. Not realizing this, the engineer uploaded some trial software to the live PLC causing the shutdown of a critical pipeline. The pipeline was down for 4 hours, and the resultant loss of revenue was estimated to be in excess of $100K.

Coincidently, in both this incident and the Venezuelan oil terminal incident the PLC used was a Schneider Modicon product running  the Modbus/TCP protocol. Modbus/TCP is very typical of the legacy SCADA and ICS protocols in use today. It started out as a serial protocol running on RS-232 or RS-485 connections, migrating to TCP when Ethernet was deployed on the plant floor.

Modbus has no security features whatsoever – for example, there is no concept of a ‘user name’ and ‘password’ in the protocol to authenticate users or devices that attempt to connect to a Modbus PLC. A few PLC vendors have layered their own password systems onto Modbus, but these are primitive and easily exploited. Where Modbus/TCP is used, the rule of thumb is “if you can ping the PLC – you own it."

Reflecting on this incident, it seems that one of the factors contributing to the accident was that the control network was ‘flat’ – there was a clear path over the network all the way from the engineering office to the plant floor (via a VPN of course), so any engineering user could connect to any device in the plant. A good first step might be to put some access control policies in place, defining who has access to the plant floor, and under what conditions.

Great idea - but how do you actually enforce this policy when there are no security mechanisms in the communication protocols? One answer is to install a security appliance that includes a firewall. The firewall permits the control engineer to configure rules that define which network devices are allowed to talk to each other and what protocols they can use. As you might have guessed, the Tofino Security Appliance is one such device that can do this. When Tofino’s firewall is operational, any traffic that doesn’t match the defined rules is blocked by the device and an alarm message is sent to the management console.

So far so good – we now have rules in place that restrict access to only ‘authorized’ computers, which is a substantial improvement over the ‘flat’ network that existed before. However a firewall can only control which devices are allowed to connect to each other – it cannot filter or control the actual commands and responses that are passed back and forth.

So what if a malicious attacker was able to take control of one of the ‘authorized’ computers in the plant? Any Modbus command would be allowed through the firewall, which in the case of Schneider Modicon (and many other vendors) includes commands to reset the PLC; put it into test modes; re-load new ladder logic; upload new firmware; and other potentially dangerous operations.

A conventional firewall will likely block accidental intrusions, but they cannot stop a directed attack like the one in Venezuela. To deal with this type of threat, we need technology that can filter individual protocol commands. The Tofino Modbus TCP Enforcer was developed precisely for this reason.

In addition to the normal firewall protection, the Modbus TCP Enforcer allows the control engineer to specify which Modbus/TCP function codes each authorized master device can issue to a client, and which coil and register addresses it is allowed to access. Any function code that is not on the ‘approved’ list, or any register address outside the allowed range, will be blocked by the appliance and sent to the management console as a security alarm. In addition, it will do other good things like check the traffic for compliance with the Modbus protocol specification so that an attacker cannot send malformed traffic to the slave device.

Modbus TCP Enforcer has been extremely popular with our clients who operate safety or revenue-critical devices or processes. Too late for our victims mentioned in these incidents unfortunately, but again our goal is to learn from experience – especially others’ experience – to make our plants safer and more reliable.