Did you know that it’s National Cyber security Awareness Month? During the month of October, everyone is encouraged to raise awareness about the vital role cyber security plays in the lives of U.S. citizens. In honor of National Cyber security Awareness Month, I’ve decided to revisit a topic that I’ve blogged on before, because of the important role it plays in the advancement of network security for industrial control systems. The topic: Deep Packet Inspection (DPI)
At the beginning of this year, I had the opportunity to present at S4x17 in Miami on the topic of Deep Packet Inspection technologies and the ways in which you could evaluate products that tout DPI features. At first glance, I thought, “Sure, no problem. How hard could it be?”
It turns out that this is actually a difficult problem for several reasons. The first being that most companies don’t just hand out their codebase outlining how their DPI implementation is written, so to truly compare, it would require black-box testing that includes fuzz testing of each device. At the same time, different protocols have different complexities and idiosyncrasies that may or may not be important or handled by a DPI implementation. Different vendors may also have vendor-specific functions that only loosely adhere to the protocol specification that should be taken into account when developing a DPI implementation.
These examples are only a small set of elements to consider when comparing products. I’d like to go through a methodology, or at least a starting framework, that can take some qualitative ideas and convert them into a quantitative scheme for comparison.
Understanding Deep Packet Inspection and Why It’s Important
To begin with, we must understand the concepts of the control plane and data plane. The data plane encompasses commands in which the HMI is reading pressure or temperature data from a programmable logic controller (PLC) or writing to a specific register in an interval. This is the actual process data or ladder logic running on your PLC. Meanwhile, the control plane is the total number of actions that can update the firmware or stop the controller entirely. Its commands encompass the underlying operating system (OS) that is running the PLC. This is akin to executing a Windows update on your Windows PC. It is also important because many PLCs utilize the same network stream to update their PLC firmware version that you would use for reading data.
Essentially, the control plane and data plane traffic traverse the same transmission control protocol (TCP) connection. This is why the need for DPI is important. Users will certainly want to receive data from their HMI, but not at the cost of leaving their PLC vulnerable to firmware updates from a non-authenticated source. Without a DPI firewall, you cannot differentiate between the data plane and control plane messages. There are multiple approaches to implementing a DPI firewall, including a full-protocol implementation, a signature-based approach, a proxy-based approach or machine learning.
Choosing the Right DPI Implementation
It is my opinion that a signature-based approach is the least effective mechanism to use in an industrial control system (ICS) world. This is because a signature-based system is only a reactive mechanism. The signatures are built from an already discovered vulnerability; this means the attack vector is already out in the wild and could affect running systems. Signatures provide a shallow inspection and require signature database updates. (Internet access on the plant floor? Absolutely not.) A signature is typically made for a specific vulnerability. If one byte changes (malware mutation) in the attack vector, you must now build a new signature to mitigate it.
In addition, this approach is effectively building a blacklist rather than whitelist, which won’t be as useful. Think of it like building a wall that is 6ft tall. The attacker can simply use a 7ft ladder to hop over the wall. So, then you build the wall 8ft to stop the 7ft ladder. But alas, the attacker has already built a 10ft ladder and hops over the 8ft wall you spent so much time on. You get the picture. This illustrates why a proactive approach is more effective.
The depth of an implementation is more important than breadth. A firewall vendor may say they support 500 protocols, but to what extent? Validating a single byte in one protocol does not mean ‘you support DPI’ for that protocol.
Comparing DPI Products: Six Essential Areas
With that aside, it’s important now to discuss some items to consider when coming up with a grading scheme for comparing products. How do we actually compare products? What elements are the most important for a DPI implementation? When you think about the top 80-90 percent of ICS-CERT vulnerabilities, they all fall under the same category: the malware/packet-fuzzing/buffer-overflow/poor implementation grouping.
What that boils down to is this question: does the packet structure of a certain protocol adhere to the protocol specification (if a Modbus FC3 should be X length and nothing else)? If it does not, then drop the packet.
With all the above in mind, it makes sense to outline the six elements that must be in a well-structured DPI implementation, or essentially the elements that you could not leave out, which are as follows:
- Sanity Check: This is the ability for the DPI engine to understand the entirety of a protocol and all the permutations of the packet structures. If it is an EtherNet/IP CIP message with a length field on a ‘Get Attribute All’ acting on an ‘Analog Input object’, what does that mean? What are the allowed lengths, or how many bytes per field? The DPI implementation HAS to know the protocol inside and out, especially if it is to catch 80-90 percent of the ICS-CERT vulnerabilities.
- Action Filter: The ability to allow/deny specific function codes, CIP services in EtherNet/IP and DNP3 objects in DNP3, to name a few. This is the ability to differentiate between those control plane and data plane actions. It gives a user the ability to still monitor their temperature gauges or pressure and be assured that a firmware update action will be blocked.
- State Checking: This investigates whether a response has a corresponding request. Has a response come back after an initial request? This ensures spurious responses are dropped.
- Response Validation: If you look at DNP3, a majority of published vulnerabilities are actually attacks on the HMI rather than the PLC or RTU. This implies the depth in which response messages are validated.
- Vendor Specific Support: Otherwise known as vendor specific validation. Think of Modbus FC 90 from Schneider (Unity) or PCCC/CSPv4 with Rockwell. If the DPI engine understands vendor-specific elements that your installation utilizes, then this is important as a metric.
- Pipeline Support: This is where a TCP or UDP message contains multiple ICS protocol messages in its payload. Think of putting 4 Modbus messages in a single frame. The DPI implementation must be able to handle this and iterate through each message ensuring no write commands or firmware updates are embedded.
So, taking the above six ‘must haves,’ I translate this into a grading scheme of sorts.
Figure 1 – DPI Grading Scheme
What constitutes a 4 for Sanity Check? Or any value for that matter? This is the harder part. We now have a general sense of aspects to evaluate and a grading mechanism. Based on the protocol, a “4” would denote that not every field is validated. As an example, Modbus FC15 (Write Multiple Coils) does not validate the quantity of outputs in general; perhaps it does not validate quantities of all replies.
Figure 2 – Modbus FC15 Structure
Along those lines, a “6” would mean that the DPI engine validates every field and ensures the packet is an exact match of the protocol specification.
While going through this exercise, I had realized a few things that I alluded to earlier. Depth is hard to gauge without fine details of a product. Is the company willing to outline to what depth they validate the protocol in question? Numbers are subjective in the grading scheme, and each DPI feature could be broken down into sub-categories for a more accurate picture.
Undoubtedly, you could also compare methods of DPI as well as signature-based system vs. full protocol conformance or proxy setup. In addition, the depth of each protocols’ DPI engine may differ from one to the next, so it would make sense to also compare protocol to protocol, not product to product. Upon inspecting multiple products, the values of each may change in relation to one another, i.e. “product X can do this better than product Y – to me, this is more valuable.”
Selecting DPI Products: Final Considerations
Finally, there are probably other elements to consider. A DPI engine that supports ‘everything’ but provides a cryptic user interface is not very useful to a customer.
What actions are important if a DPI engine identifies an invalid frame?
- Drop the frame?
- Send a TCP reset (if TCP)?
- Generate an Event message?
Throughput and latency are not mentioned because this is about the functionality, not how fast / slow the product is. However, this should be at least thought of for protocols like GOOSE that require low latency. In general, remember not all DPI implementations are created equal.
I see this as a first step to coming up with some mechanism to compare DPI products. In general, I would not rely on marketing speak to gauge product capabilities. The proof, as they say, is in the pudding.
To learn more about how DPI technologies are improving security in industrial control systems, download Belden’s white paper: “Understanding Deep Packet Inspection for SCADA Security.”
- Blog: SCADA Security and Deep Packet Inspection - Part 1
- Blog: SCADA Security and Deep Packet Inspection - Part 2
- Blog: Defense in Depth Part 2: Layering Multiple Defenses
- Blog: ICS Security: Essential Firewall Concepts
- Blog: 3 Ways Firewall Learning Mode Simplifies ICS Security
- Tripwire blog: Why Antivirus Standards of Certification Need to Change