ICS Security: Essential Firewall Concepts

Firewalls play an important role in blocking threats and containing internal cyber incidents that could impact safety, reliability and productivity. They control the flow of communications and filter packets to block or contain harmful network traffic.

There are a number of technologies that today’s industrial Layer-2 and Layer-3 switches, routers, firewalls and security appliances support. These include Access Control Lists, Stateful Inspection and Deep Packet Inspection, each of which filters message differently.

This article examines the essential firewall filtering concepts you need to know to make informed choices for designing a Defense in Depth security architecture.

Keeping the power grid (including the water gate of this dam) operational, safe and secure requires different types of firewalls at different places in the SCADA network.

Packet Structure Basics: UDP and TCP

To understand packet filtering, it is first important to understand how messages (packets) are constructed.

Today’s industrial networks are built on standard Internet technologies. At the physical layer, Ethernet provides a “pipe” to move packets from one place to another. Typically the payload of an Ethernet frame carries an Internet Protocol (IP) packet. Within the IP packetare:

1. The IP address of the device sending the message (AKA the source IP)
2. The IP address of the device receiving the message (AKA the destination IP)
3. Priority information

The name of the protocol in the payload portion of the packet is typically identified using either the UDP or TCP protocols. Here are the differences between the two:

Packets can be structured using either the TCP or UDP communication protocols.  UDP has the advantage of low latency whereas TCP has the advantage of being stateful.

The concepts of “connection-oriented” and “stateful” need to be explained. In a connection-oriented protocol, conversations between devices are like telling a story. The conversation has a start, a body, and an end. The words in the body are delivered in sequential order so the story makes sense.

We say communication between devices is stateful because each packet is in some way dependent on previous packets. In a network, “state” involves information such as which device started the session, which one last sent a message, was the last message rejected because of errors and so on.

In a connectionless protocol, there is no start that establishes a conversation, or end that indicates it is over. Messages are just sent to the destination as needed, with no context based on previous messages.

TCP is a stateful protocol; UDP is stateless. This significant difference in capabilities is important and useful when building Defense in Depth into industrial Ethernet networks (more on this later).

With this background on the structure of packets and TCP and UDP, we can now look at different packet filtering mechanisms. Remember, the goal of packet filtering is to ensure that only the traffic you want to pass across your network is traversing it.

What Packet Filtering Does 

Packet filtering is simply monitoring and controlling traffic flowing within or between networks. It starts by capturing traffic passing through the network and comparing it to a predefined set of rules.

Messages that do not match these rules are discarded. In principle, all information within an Ethernet frame, including the payload, can be used to create a rule. This includes destination and source IP and MAC addresses, protocol information, ports etc.

Using an Access Control List for Packet Filtering

As you might guess by its name, an Access Control List (ACL) is simply that, a list (or table) of authorized network traffic based on values within the Ethernet, IP and TCP/UDP headers. ACLs can also specify bandwidth limitations or traffic shaping and prioritize specific communications.

ACL functionality is built into switching chips, enabling ACLs to operate at “wire speed”, which means it does not add significant delay to the forwarding mechanism of the frame. ACLs operate on each packet individually (that is, they are stateless). ACLs provide security by restricting network communications to a specific set of senders, receivers, and protocols (ports).

Putting this all together, imagine you only want to allow ModBus TCP traffic between a client at IP address 192.168.1.10 and a destination with an address of 192.168.1.20. Since Modbus uses TCP/IP, you would need to create two rules to cover the bi-directional communications. You would construct ACL rules like this:

“Allow Src=192.168.1.10 Dst=192.168.1.20 Port=502 Protocol=Modbus”
“Allow Src=192.168.1.20 Dst=192.168.1.10 Port=502 Protocol=Modbus”

While ACLs have the advantage of rapid filtering, they have the disadvantage of not being able to block “inbound” packets that are not the direct result of an “outbound” request. They cannot determine if an incoming TCP message is part of an on-going TCP connection or is an unsolicited and possibly malicious rogue or destabilizing packet.

Thus, while layer 2 or 3 switches with ACLs play an important role in Defense in Depth by excluding unwanted packets, they will not block out-of-sequence packets. Depending on your application, however, such as high-speed robotics, an Access Control List may be your only option for packet filtering.

Using Stateful Inspection for Packet Filtering

A stateful firewall, on the other hand, looks at other parameters and keeps an internal record that tracks the details of the session state. This information is then used to analyze the reasonableness of each packet. Inbound traffic to the client device is allowed only if it is in response to an outbound request.

Stateful firewalls can be dedicated devices, such as the Hirschmann EAGLE firewalls or Tofino Xenon Security Appliance, or have functionality built into other network devices, such as the Hirschmann OpenBAT wireless access point.

An Access Control List cannot prevent denial-of-service attacks on PLCs due to a flood of inbound requests that are not associated with previous outbound requests. A stateful firewall (also known as a SPI firewall) will block such attacks because they recognize that the inbound messages are not adhering to the proper sequence of events.

Building on our previous ACL rule example, consider a packet that meets the criteria of:

• Being from the Modbus port
• Originating from an authorized source
• Going towards an authorized destination

Nonetheless, this packet would be blocked if it was not part of an ongoing TCP session, protecting the network from externally initiated attacks.

Because of additional processing to determine “state,” stateful inspection does not operate at wire speed and introduces delays in forwarding packets. Depending on your application and your security strategy, stateful firewalls might be used at network boundaries (including wireless ones), to segment the internal network, or at the field level.

A seaway management company uses endpoint firewalls with DPI functionality to secure the PLCs that control its locks and bridges. The firewall restricts Modbus commands from monitoring computers to read-only commands but allows programming commands from the HMIs of designated onsite engineers.

Using Deep Packet Inspection for Packet Filtering

So far we have introduced two security technologies, ACLs to restrict the types of messages traversing the network and Stateful Inspection that ensures that a given packet makes sense in the context of previous communications. While both of these are useful protections, neither mechanism can prevent packets with “bad intent.”

Let’s go back to our example. With ACLs or Stateful Inspection you either allow Modbus messages through or you block them all. Fine-grained control of the protocol is impossible.

Thus, if you allow data read messages from an HMI to a PLC to pass through, you are also allowing programming messages to pass through. This is a serious security issue. If you do the reverse, and block all Modbus messages, then the messages necessary for running the control network are blocked.

These broad rules might be appropriate for upper layers of the system where we are only concerned that packets are using allowed protocols and going from and to authorized devices. But, as we go deeper into our system to PLCs and other control devices, finer grained protection is required.

This is exactly what Deep Packet Inspection does. It goes beyond looking at message headers to decode the payload itself, allowing us to define very narrow rules. For example, it can

• Restrict PLCs to receiving only read messages from the HMI. Any write messages from the HMI are deemed suspicious and blocked.
  
  
• Allow a device with IP address to 192.168.1.15 to issue Modbus write requests to a just a specific range of registers.
  
  
• “Sanity check” traffic for strangely formatted messages or unusual behaviors, such as 10,000 reply messages in response to a single request message. This blocks traffic created by a failed device flooding the network or a hacker trying to crash a PLC.

In short, Deep Packet Inspection allows us to ensure that all messages required for our application are passed and that all others are blocked.

As you might imagine, because of the additional processing required to fully decode and analyze each packet at the application protocol level, DPI imposes the greatest processing overhead and network delays.

However, its granular protection is ideal for securing the conduits between various zones of field level devices, as per IEC 62443 or protecting your most operationally important systems such as safety systems, RTUs, turbines etc.

Examples of devices with Deep Packet Inspection functionality are the Tofino Xenon Security Appliance and the EAGLE 20/30 firewall.

The type of DPI described above can be described as “protocol-specific” or “content inspection.” Be aware that there is another type of DPI, “signature-based,” that is very different. It works by mapping a set of bytes against known byte patterns provided in a signature database. We compare and contrast the two in this blog article.

While signature-based DPI can protect against known vulnerabilities, it does not provide the broad protection against malformed packets that protocol-specific DPI provides. To truly secure ICS and SCADA networks, protocol-specific DPI is usually required in the lower levels of control systems.

Use Different Packet Filtering Technologies for Defense in Depth

By understanding the filtering mechanisms of

• an industrial Ethernet switch using an Access Control List versus
• a SPI firewall, router or wireless access point versus
• a Deep Packet Inspection security appliance

you are better equipped to design a Defense in Depth strategy with the appropriate level of protection at each point in your network architecture.