I have talked repeatedly about something called Deep Packet Inspection (DPI) and why it is so important for SCADA / ICS security (for example, see Air Gaps won't Stop Stuxnet's Children). The trouble is, I have never described what DPI actually is. So in today’s blog I will back up and explain what DPI firewall technology is all about.
Some Firewall Basics
To understand DPI, it is first important to understand how the traditional IT firewall works. A firewall is simply a device that monitors and controls traffic flowing in or between networks. It starts by capturing traffic passing through it and comparing that traffic to a predefined set of rules (called Access Control Lists or ACLs). Any messages that do not match the ACLs are then discarded.
The traditional IT firewall allows the ACLs to check three primary fields in a message*.
1. The IP address of the computer sending the message (AKA the source IP),
2. The IP address of the computer receiving the message (AKA the destination IP),
3.The upper layer protocol contained in the IP frame as defined in the field “TCP Destination Port Number”.
The TCP Destination Port Number needs a bit more explanation. These ports are not physical ports like an Ethernet port, but instead are special numbers embedded in every TCP or UDP message to identify the application protocol being carried in the message. For example, Modbus/TCP uses port 502 and HTTP uses port 80. These numbers are registered under the Internet Assigned Numbers Authority (IANA) and are rarely ever changed.
So to put this all together, imagine you only want to allow web traffic (i.e. HTTP traffic) from a client at IP address 192.168.1.10 to a web server with an address of 192.168.1.20. Then you would write an ACL rule something like
"Allow Src=192.168.1.10 Dst=192.168.1.20 Port=HTTP"
You would load this ACL in the firewall and as long as all three criteria were met, the message would be allowed through.
Or say you want to block all Modbus traffic from passing through the firewall. You would simply define a rule that blocks all packets containing 502 in the destination port field.
Seems simple, doesn't it?
The Problem: SCADA / ICS Protocols have no Granularity
The problem with this simple scheme is that it is very black and white. You either allow a certain protocol or you block it. Fine-grained control of the protocol is impossible.
This is bad because the SCADA / ICS protocols themselves have no granularity. From the perspective of the port number, a data read message looks EXACTLY like a firmware update message.
So if you allow data read messages, from an HMI to a PLC, to pass through a traditional firewall you are also allowing programming messages to pass through. This is a serious security issue.
The Solution: Deep Packet Inspection
Clearly the firewall needs to dig deeper into the protocols to understand exactly what the protocol is being used for. And that is exactly what Deep Packet Inspection does. After the traditional firewall rules are applied, the firewall inspects the content of the contained messages and applies more detailed rules.
For example, a Modbus DPI firewall (such as the Honeywell Modbus Read-only Firewall)** determines if the Modbus message is a read or a write message and then drops all write messages. Good DPI firewalls can also "sanity check" traffic for strangely formatted messages or unusual behaviours (such as 10,000 reply messages in response to a single request message). These sorts of abnormal messages can indicate traffic created by a hacker trying to crash a PLC and need to be blocked.
DPI SCADA Security in the Real World
Fine-grained control of SCADA / ICS traffic can significantly improve the security and reliability of a system. For example, consider the case of a seaway management company. It uses Schneider PLCs at all its control locks and bridges to ensure the safety of ship and vehicle traffic. Making sure that these PLCs are not tampered with is critical for the safety of both the ships and the public traveling over bridges at the locks.
The problem the company faced was that a number of operations computers needed to continuously access PLCs for data. However only special control computers should be permitted to send commands and impact the operation of equipment. Traditional password or IT firewall solutions were not considered secure, because they didn't offer the fine-grained control needed.
The solution was to use Modbus DPI firewalls*** to control all traffic to the PLC. Only Modbus Read messages were allowed to reach the PLCs (except for a few high security computers). All remote Modbus programming commands were blocked so that programming was restricted to onsite engineers. A total of 54 DPI firewalls were installed in 24 locations and the system has run without incident since late 2008.
Providing security by simply blocking or allowing entire classes of protocols between networks is no longer sufficient for modern SCADA / ICS operations. The protocols that our systems depend on are simply too powerful and too insecure. It is time to consider how we can use technologies like DPI to make our systems safer and more reliable.
Let us know where you see DPI fitting into your SCADA / ICS security plans.
* Technically speaking, there are other fields that the typical IT firewall can check, but these three fields account for 99.9% of all firewall rules.
** Full Disclosure: the Honeywell Modbus Read-only Firewall product is developed by Tofino Security and MTL Instruments.
*** Full Disclosure:The Modbus DPI firewalls used were Tofino Security Appliances with the Tofino Modbus TCP Enforcer firewall.
- Data Sheet:Honeywell Modbus Read-only Firewall
- Press Release:Honeywell selects Tofino™ Modbus Read-only Firewall to Secure Critical Safety Systems
- Tofino Modbus TCP Enforcer Loadable Security Module
- PLC Security Risk: Controller Operating Systems
- Video: MTL Instruments security video showing a worm on a USB key attacks a PLC over Modbus TCP using a zero-day PLC vulnerability