Why SCADA Firewalls Need to be Stateful – Part 1 of 3
Following on from Eric Byres’ discussion of Deep Packet Inspection (DPI), this article discusses a second and equally important aspect of effective firewall security referred to as “stateful inspection”.
In order to understand exactly what is meant when we talk about “state”, we need to look at the specifics behind the TCP communication sessions that are most common in modern day industrial control systems (ICS) and SCADA applications1. The figure below illustrates the model.
Figure 1: The abstraction layers typically used in TCP/IP communications for ICS and SCADA systems.
The DPI that was previously discussed is actually analyzing and making decisions based on the information contained in the upper layer of the model. This layer is where you would typically see specific application operands such as a Modbus Read Coil (e.g. function code 2) or a Modbus Write Single Register (e.g. function code 6).
Clearly this DPI provides the highest level of granularity when it comes to managing communication between hosts on a network. An example of an industrial firewall that offers this is the Tofino Modbus TCP Enforcer.
It is also possible for appliances to offer what is called “Shallow Packet Inspection” or SPI, which looks at data lower in the protocol stack. This is where the concept of “state” becomes important.
State in Data Communications
Just like communications between people, communications on a network rarely just involves a single message. There is a constant exchange of packets, where each is in some way dependant on previous packets. For example, if your computer receives a message containing a web page from a web server, it can only be interpreted with the knowledge of what request was sent earlier. If your computer never sent a message asking for the page, then the only reasonable thing to do with the message is to discard it.
This understanding of the previous traffic is what we call “state”. Basically the computers involved in the information exchange have to understand the “state” of the exchange at all times. They need to know state information such as which device started the session, who last sent a message, was the last message rejected because of errors and so on. Without this, communications quickly break down.
The Hazards of Stateless Security
Compared to the devices actually communicating, a security device has a little more flexibility regarding understanding the state of the traffic it is securing. In theory, it can try to manage the traffic while ignoring the state of the sessions on the network. Unfortunately, ignoring state comes at a price – badly degraded security. Let’s explore why this is so.
A “stateless” or “packet filter “appliance only analyzes each packet in isolation of other information relating to the communication session. It has a series of static rules and uses them to take action upon received packets on an individual basis. It bases decisions to allow or deny packets on simple filter criteria such as:
- the source and destination IP addresses in the message (Layer 3)
- the source and destination protocol number in the message (first part of Layer 4).
The following rules can easily be handled by a stateless packet filter firewall:
- Accept Domain Name Service (DNS) response packets on User Datagram Protocol (UDP) port 53
- Block any traffic to or from Internet Protocol (IP) address 24.116.25.21
- Prevent web surfing by blocking outgoing packets from accessing Transmission Control Protocol (TCP) ports 80, 443, 3128, 8000 and 8080, unless they are directed to the corporate intranet web server's IP address
Unfortunately, a packet filter firewall’s inability to understand the relationships between a series of packets is a serious weakness. For example, the broad rule "Accept DNS response packets on UDP port 53" contains a serious flaw. What if no DNS query was ever issued, but a spoofed DNS "response" packet came in instead? This simplistic firewall would accept the packet and deliver it to the "requesting" host, possibly causing it to become confused.
In Part 2 of this article I will explain how straight forward it is to hack a stateless firewall. Part 3 will discuss how stateful firewalls operate and provide some design considerations for ICS security systems. In the meantime, let me know your questions or comments about stateful inspection.
1 The model discussed in this article is a simplification of the OSI 7-Layer Model
|
Joel Langill This article is a collaboration between Joel Langill and Eric Byres. |
Related Content to Download
|
White Paper - "7 Steps to ICS and SCADA Security"
|
Related Links
- Why SCADA Firewalls Need to be Stateful – Part 2 of 3
- Why SCADA Firewalls Need to be Stateful – Part 3 of 3
- SCADA Security & Deep Packet Inspection – Part 1
- SCADA Security & Deep Packet Inspection – Part 2
- Why VLAN Security isn't SCADA Security at all
- Tofino Modbus TCP Enforcer Loadable Security Module
Comments
Perhaps you meant by-pass?
I think the sentence "how straight forward it is to hack a stateless firewall" is rather inaccurate. A stateless firewall (provided you can find one these days) is not less secure than a stateful one because of its "stateless" nature.
It is true though that a stateless firewall can be by-passed more easily.
Re: Perhaps you meant by-pass?
In principle, I agree with your comment, however, I believe it is just a matter of semantics as to whether this is a 'hack' or a 'bypass'.
In my context, the term 'hack' is used to define a condition by which the intended function of a particular device is circumvented resulting in unauthorized access (in this case, to the trusted network). In no way have I disturbed the firewall, so in that respect, I see your point is just stating it as a 'bypass'.
Thank you for your comments.
Yes, indeed we could discuss
Yes, indeed we could discuss for hours about it. However, this is what Wikipedia says about it:
"Hacking means finding out weaknesses in a computer or computer network and exploiting them"
Now, if a certain system/device was not designed with certain features (stateful inspection), how can anybody find out a weakness and exploit in features that are simply not there?
Re: Perhaps you meant by-pass?
> "A stateless firewall (provided you can find one these days)"
Actually you would be surprised how common stateless firewalls really are. Of course, you won't find a reliable security company like Cisco, Checkpoint or Juniper selling them, but they are quietly sold by a number of ICS and network product vendors. And of course those vendors don't stand up and announce "THIS IS A STATELESS FIREWALL". You have to ask (or test) carefully.
But by far the worst offenders are user installed layer 2 switches with ACL rules. Many controls engineers think a switch with rules is a firewall. It is so far from it. Joel makes one of the reasons clear in this series.
If an engineer believes that
If an engineer believes that a switch and ACLs make a firewall, sorry, but that's an issue you have to fix by educating him/her better.
A complete different story is when a vendor "forgets" to advertise certain non-features of its products. However, the article is not clear about the fact that no major vendor (like those you mentioned) will ever ship a stateless firewall these days. Actually, since middle 1990's.
I do understand that some ICS vendors, and again, I believe they are a narrow percentage, and definitely not companies like ABB, Emerson, Rockwell, Yokogawa, Honeywell, which basically control 90% of the whole market, might ship a stateless firewall without stating in bold characters.
If I would advocate the importance of using SSL for online banking, and tell that it's very easy to leak data from non-SSL connections, but without telling that perhaps only in Iran and few other places in the world SSL is not in place, and that the remaining 99% of the banks use it worldwide, do you believe I provided a non-biased picture of the issue?
So, yes, the problem of stateless firewall is real, but it affects ~0.1% of end users. Same as not using SSL for online banking.
If an engineer believes that a switch...
> "If an engineer believes that a switch and ACLs make a firewall, sorry, but that's an issue you have to fix by educating him/her better."
Guess what - Educating engineers and control systems professionals about security is what this blog is all about!
That is why Joel wrote this article and why we published it - because every week we meet people involved in ICS and SCADA engineering that don't know the difference between stateless and stateful firewalls (or why it matters). This blog series is written for them.
As for your statistic that stateless firewalls affect ~0.1% of ICS end users, based on numerous site surveys we have done over the past decade, I respectfully disagree. I have found many stateless firewalls (and switches pretending to be firewalls), installed by consultants and vendors who should know better. If we hadn't found these, we would never have wasted blog space on this topic. But unfortunately, we found them...
Eric, this is your "home" and
Eric, this is your "home" and so this is the last message I will post about this topic (don't want to turn this into a flame :-)
I still believe that the post offers a biased view. A better title would have been "A switch and some ACLs don't make a firewall". It doesn't make a clear distinction between "serious" vendors (Cisco, Checkpoint, Juniper, Fortinet, Astaro, etc.) and the rest.
Can you please give an estimate (don't need to name them) of how many vendors sell stateless firewalls (or switch with ACLs) pretending those are stateful?
ICS Firewalls are not the same as IT Firewalls
This is all great dialogue, and I appreciate the input, comments and critiques from so many. Remember that we are talking about ICS/SCADA security here, and as such, I never meant to imply that we were referring to the firewalls that are typically installed between levels 3/3.5 and 4 (per ISA95 model) separating the production and office zones.
I am talking about the firewalls that are used to protect the highest risk components in the ICS architecture - the control devices. These devices are physically connected to the process under control, and as such, have a different security profile than other areas. When we look at vendors that supply these industrial "field" firewalls (that are typically fanless, industrialized for harsh environments, operate on low-voltage DC, and are ICS protocol friendly), there are many differences when you look "under the hood"!
I will always protect the confidentiality of the results of my assessments in public forums, but compare for yourself the difference between how Tofino Eagle 20, Hirshmann Eagle, Innominate mGuard, Secure Crossing ZenWall, Siemens Scalance, Honeywell Control Firewall, Emerson's DeltaV Controller Firewall, ABB's FOX Firewall, and others handle state (my blog topic) and application layer content inspection (Eric's previous blog).
I have studied the SCADA
I have studied the SCADA Firewalls when I was doing my graduation. It was really interesting to know about why it needs to be stateful. I will recommend this article to my friends. Thanks a lot for sharing. Please keep on sharing.
Add new comment