Error message

The spam filter installed on this site is currently unavailable. Per site policy, we are unable to accept new submissions until that problem is resolved. Please try resubmitting the form in a couple of minutes.

SCADA Security & Deep Packet Inspection – Part 1 of 2

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 message1.

  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)2 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 firewalls3 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. 

Time to Move Beyond Traditional Firewalls for SCADA Security

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.

1 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.
2 Full Disclosure: the Honeywell Modbus Read-only Firewall product is developed by Tofino Security and MTL Instruments.
3 Full Disclosure:  The Modbus DPI firewalls used were Tofino Security Appliances with the Tofino Modbus TCP Enforcer firewall.

Related Content to Download

Note: You need to be a member of tofinosecurity.com and logged in to have access to the document below. Register here to become a member.

Application Note - "Defense in Depth Protection for the Honeywell Experion"

 

Download this document and find out:

  • How a Tofino Security Appliance protects a system that is migrated from an older DCS to a modern Ethernet Experion™ PKS system
  • How a Honeywell Modbus TCP Firewall protects the Modbus Process Control Data Interface in Experion 310

This Application Note does not discuss deep packet inspection per se.  However, it provides a good explanation of how a firewall designed for an industrial protocol contributes to defense in depth.

Related Links

 

RSS Feed Subscribe to the "Practical SCADA Security" news feed

Author Eric Byres

Comments

3

Thanks for the post. But isn't there a way to have one device like the firewall or IPS that will do DPI. Installing devices in every location like the Honeywell MODBUS firewall is not scalable and it will work with limited PLCs. Meaning that you will be securing part of the infrastructure

To be clear, there is nothing that says DPI functionality needs to be right in front of the PLC. Using a firewall or IPS that supports SCADA/ICS DPI technology is a good idea.

Where the DPI capability is located is a different discussion. In fact, it is closely related to my March 21, 2012 Defense in Depth blog (http://www.tofinosecurity.com/blog/defense-depth-part-2-layering-multipl...) rather than the above DPI blog.

Where the DPI technology is located should be influenced by what threats you want to protect your system against. Install DPI at the business/ICS boundary firewall and you protect your system against hostile outsiders or problems originating from corporate systems. On the other hand, putting the DPI technology right in front of a PLC would help protect against threats like a disgruntled employee sitting in the control room or worms on your HMIs.

What you want to protect against is driven by your risk assessment. If you are running a pet food plant, putting the DPI at the edge of the ICS may be fine. On the other hand, if you run a uranium enrichment plant (grin) you might want DPI technology VERY close to your PLCs.

For the seaway project I mentioned in the blog, the Tofino DPI Firewalls were installed at each lock station on the incoming WAN connection. This way a single unit protected all the PLCs in that station from any remotely driven security issues. Of course, if the attacker broke into the station and connected directly to the PLC network, he/she could control the PLCs in that station, as the Tofino DPI firewall would be "outside the loop". But the seaway operating company decided that this particular threat (a physical break-in) could best be handled by mix of other technologies such as steel doors, cameras and the Tofino's Secure Asset Management (SAM) module (FYI, SAM detects new devices joining the control network, such as a contractor's laptop).

Even the Honeywell MODBUS firewall can be used in different locations, depending on the desired risk reduction requirements. In the downloadable application note, the use case was between the safety system and the primary control system, so two units were protecting many SIS controllers.

The important point is for the industry to move beyond simplistic port number filtering and start looking into the contents of the SCADA/ICS messages. Without that, then we are letting bad traffic sneak right under our noses.

The Honeywell Tofino modbus firewalls do not use source or destination filtering. Does this offer sufficient security? Some users prefer to customize them by adding source / destination MAC filters. This makes replacement of a failed module more difficult, so maybe more secure but less flexible.

Has there been non targeted attacks ( for example malware) that have exploited the modbus protocol / software? What would be your recommendation?

Add new comment