ICS Security: Essential Firewall Concepts

Wednesday, May 4, 2016 @ 03:05 PM gHale


By Jeff Lund
While there are benefits that have come to ICS and SCADA networks through the increased use of standard networking and Internet technologies, there is no doubt it has made the need to secure them ever more critical.

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.

RELATED STORIES
Security and Transportation Systems
Defining Deep Packet Inspection
Security Basics: Securing a PLC
Substation Defense in Depth

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.

The following examines the essential firewall filtering concepts a user would need to know to make informed choices for designing a Defense in Depth security architecture.

Packet Filtering
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 packet are:
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: 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 end up 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.

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 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 end up used to create a rule. This includes destination and source IP and MAC addresses, protocol information, ports etc.

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.

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 or have functionality built into other network devices.

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

Deep Packet Inspection
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 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.

The type of DPI described above can be described as “protocol-specific” or “content inspection.” Be aware 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.

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.

Different Packet Filtering Technologies
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.

Jeff Lund is senior director of product line management – industrial IT. He is responsible for Belden’s vision and product initiatives related to the Industrial Internet of Things (IIoT). He also drives and coordinates cyber security and wireless product direction across Belden industrial IT product groups. Click here to view the entire blog.