This article is a collaboration between Joel Langill and Eric Byres. Joel is the CSO at SCADAhacker.com. He can be reached at joel@scadahacker.com.

In Part 1 of this series I explained what "state" means in network communications and the hazards of stateless security. Part 2 detailed the behavior of a stateless firewall and included a demonstration of me attacking one. In this closing article, I describe stateful inspection and its importance in securing ICS and SCADA systems.

Stateful Firewall Inspection

Stateful Inspection occurs when a security appliance understands the relationship between the latest message received and previous messages in a given network connection.

At its most basic, the stateful security device knows if an inbound "reply" packet is in response to an outbound request. But stateful inspection can be more than just that.  

Pic-1-Stateful-Penguins_490

Two way communication where one party is responding in reaction to another, as with stateful communication.

Stateful filtering requires that the appliance look at additional parameters contained within the TCP/IP Headers. This additional information will indicate the state of the communication session as the device sending the message believes it to be. Typically this includes:

  • Source and Destination TCP port number
  • IP Status flags
  • Sequence Number
  • Acknowledgement Number

At the same time, the security appliance also creates an internal record that tracks its understanding of the session state. Together the state information as received, and the state information as previously recorded, can be used to analyze the reasonableness of each packet.

Inbound Traffic must Match Outbound Requests

In the figure below, Stateful Inspection means that inbound traffic to the client device will only be allowed if it is in response to an outbound request. All other traffic, even if it contains the correct IP address and TCP port number would be dropped. The figure below illustrates this session and some of the additional TCP data included in the inspection.

Fig-1-Stateful-Diagram_490

Figure 1: With Stateful Inspection, inbound traffic to the client is only allowed if in response to an outbound request.

With "Stateful" inspection, an attacker that attempts to spoof a valid host's IP address and the TCP port number used would not be able to traverse the firewall appliance.

PLC Security Example

In the earlier blogs, we looked at the issues of traffic going out of the control network to an external web server. With a stateless firewall it was pretty simple to blast fake reply messages back into the control network.

But let's take the same protocol, namely HTTP, and look at a different example. As followers of this blog (and others like Digital Bond's blog) have heard, many PLCs have a small embedded web server that allows a user to point their browser to the PLC to make configuration changes. The user makes an HTTP request, using their browser, to the PLC to view the configuration options available to them.

Behind the scenes the browser has made an HTTP request (using TCP on port 80) to the PLC. In doing so the browser has made the initial 'request' to that PLC, with the PLC making the initial 'reply' to that request. This is a matching sequence of events. How would a stateless firewall versus a stateful firewall handle this transaction?

In the case of a stateless firewall, the sequence of events is irrelevant. As long as the data is TCP and sent to port 80, it would be allowed through the firewall, regardless of what sequence of events happened before.

This makes it extremely easy for a hacker to execute a denial-of-service attack against the PLC. A hacker can simply send the exact same TCP packet with destination port 80 thousands of times and the firewall will permit this traffic through.

It does not take into account any previous packets sent. The traffic will overwhelm the PLC and the stateless firewall is unable to prevent the attack.

Pic-2-Stateless-Penguins_490 

A lot of communication occurring without regard to the sequence of messages. This might be fine for penguins, but it's bad for control systems!

A stateful firewall would map each request and reply to a state in which this is valid according to how this communication sequence should behave. It builds an internal record of each step of the communication so that if a hacker were to send random out-of-sequence data to TCP port 80, it would drop all data not adhering to the proper sequence of events.

The stateful firewall also has a maximum limit of the number of new TCP sessions allowed, thus protecting the PLC from becoming overwhelmed with connections.

In summary, the stateful firewall will block the out-of-sequence packets and permit only a maximum number of new connections, therefore stopping a hacker in their tracks.

Designing Secure Industrial Control Systems

Considering what you have learnt about "state", I would like to offer one design aspect for your consideration. What do you think is important when you are selecting a security appliance to protect a high-risk device such as a PLC that is connected directly to your manufacturing process?

In previous blog articles we have learnt about the importance of using deep packet inspection to manage the actual content of the traffic sent to a PLC. This prevents unauthorized commands from being maliciously or accidentally sent to the PLC from otherwise authorized computers. However, when would state be equally important?

If all of the equipment is installed on a local network that offers strong physical security, there is lower risk that an attacker could successfully originate an attack from the "Trusted" PLC side of the security appliance.

However, consider this same PLC installed at the end of a wide area network connection, a situation that is quite typical in distributed SCADA architectures. In this case, extra attention should be given to making sure that a physical breach of a remote location does not allow unrestricted access to the internal control networks.

The Relevance of Stateful Firewalls in Today's ICS

Why does the modern controls engineer need to understand state and know when to demand it? First, it is important to understand the concepts of "stateless" and "stateful" and be able to assess the importance of stateful inspection given the risk mitigation desired.

Next, do not assume that a vendor's firewall or security appliance is stateful. While many are, there are significant differences amongst suppliers. Remember that we are talking about the firewalls that are used to protect the highest risk component 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 is required in other areas. Our experience shows that industrial field firewalls (that are typically fanless, industrialized for harsh environments, operate on low-voltage CD and are ICS protocol friendly) vary greatly in how they handle state.

In addition, do not make the mistake of thinking that a layer 2 switch with ACL rules is a firewall. It is not. It will not block out-of-sequence packets, nor prevent denial-of-service attacks to a PLC.

No "One Size Fits All"

There are always trade-offs between performance, security, ease of use and ease of maintenance that must be considered when considering the appropriate security appliance. However, what is most important is to understand the advantages of each type of firewall, and the specific risk mitigation they provide when designing a particular architecture.

In ICS / SCADA security, there is no "one size fits all". Each solution should be based on a consistent risk-based approach to threat management.

New call-to-actionRelated Links