Why SCADA Firewalls Need to be Stateful – Part 3 of 3
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. |
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.
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. |
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.
This article is a collaboration between Joel Langill and Eric Byres.
Related Content
|
Practical SCADA Security Article: "Why SCADA Firewalls Need to be Stateful"
|
Related Links
- Why SCADA Firewalls Need to be Stateful – Part 1 of 3
- Why SCADA Firewalls Need to be Stateful – Part 2 of 3
- SCADAhacker Demonstrates Attacking a Stateless Firewall
- SCADA Security & Deep Packet Inspection – Part 1
- SCADA Security & Deep Packet Inspection – Part 2
- Tofino Modbus TCP Enforcer Loadable Security Module
Comments
non-client initiated comms
I generally like this idea of stateful firewall. However this doesn't seem to address the operation of technologies like IEC 61850 now becoming common in electrical installations from power stations, substations, wind farms, hydro plants, Distributed Energy Resources and even Elec Vehicles.
IEC 61850 includes the request/response type SCADA mechanisms but also includes Reporting in the Client/Server model based on event triggers and also includes the Publisher/Subscriber multicast messaging such as GOOSE. In these mechanisms the Server device is the initiator of the message without a specific client request.
Publish /Subcribe Message Strategy and Firewalls
This is a great question – so good that it probably deserves another blog. Like your IEC 61850 example, there are a number of industrial protocols that have a Publisher/Subscriber multicast messaging strategy that makes deploying good security just a bit more interesting.
Ethernet/IP is another one that comes to mind. Plus there are protocols like OPC Classic that have “call-backs” where server initiates a message with the client after the client initially registers.
Clearly any good firewall has to allow this traffic or people will simply just remove the firewall – after all security can’t get in the way of running the plant or power company.
Depending on the protocol, there are a number of strategies to deal with the above challenges. For some protocols, you simply set up the firewall so it knows that the server is the initiator of each session. This can be pretty easy to do – for example with the Tofino running in Test mode, the firewall will prompt you to do this when it sees server messages with no rule in place.
Other protocols like OPC are more complex. IT requirements led us to build a special module called the Tofino OPC Enforcer(https://www.tofinosecurity.com/products/Tofino-OPC-Enforcer-LSM) that specifically tracks the underlying RPC protocol and then dynamically modifies the rule sets based on previous client session requests. This is where deep packet inspection and stateful inspection work together to create a true ICS security solution that is usable and secure.
If you want more detail check out the joint Tofino/OPC Foundation white paper Securing Your OPC Classic Control System (http://www.tofinosecurity.com/professional/securing-your-opc-classic-con...).
I will let our IEC 61850 expert, Oliver Kleineberg specifically address GOOSE in the next comment.
IEC 61850 and GOOSE
As for your example of the GOOSE protocol, the configuration on a stateful firewall like Tofino is relatively simple. It involves creating a configuration based on the L2 Multicast MAC address/Ethertype. Directionality would be set from the publisher toward the subscriber(s), no multicast traffic in the other direction.
Because GOOSE L2 MC MAC addresses for each publisher are chosen at engineering time from a defined Set of MC addresses (One MAC Address for each GOOSE control block), the setup in large Substations for GOOSE can be a little bit tedious.
A single publisher IED can be publisher to more than one GOOSE Control block, the same is true for each subscriber, which means a number of rules will be required. But that is not a state issue, just a configuration effort.
It is also worth mentioning that in the IEC 61850 specification, there is a client/server model that is separate from the GOOSE protocol. It is mainly used to transmit management and configuration information between an IEC 61850 SCADA system and the IEDs. The communication protocol used there is MMS (Manufacturing Messaging Specification) over TCP/IP and here state tracking completely applies.
I am not familiar with the
I am not familiar with the SCADA platform but it was very much interesting to read about the stateful inspection and its importance in securing ICS and SCADA systems. The article was really worth reading. Thanks a lot for sharing. Keep posting.
Add new comment