Someone recently asked me the best way to describe Deep Packet Inspection (DPI) in laymen’s terms. If you are not familiar with DPI, it describes two technologies used by firewalls to detect and block unwanted communications.
I pondered the question briefly and came up with this scenario:
Think of an envelope in snail mail. You can recognize it as an envelope and you can even see who it is from and where it is going. This could be mapped to a standard firewall where you can limit the IP address by source and destination, and even port information, but that is as complex as it gets. In terms of this example, the content inside the sealed envelope, such as a friendly letter, is where the real information lies protected; this is where DPI really occurs.In terms of a firewall with DPI technology, this is what is actually happening. The firewall looks at the specific letters, if you will, in that packet on the wire. But how does a signature-based system (such as Snort) differ from a truly protocol-specific DPI engine?
With standard firewalls you can identify who a message is from (source), where it is going (destination) and maybe the language of the contents (port). You don’t know anything about the letter’s content though.
Signature-Based Deep Packet Inspection: A Reactive, Packet Matching Strategy
Going back to the envelope and letter analogy, in the case of a signature-based approach, it is akin to saying that the letter can only have certain words in a certain order and they can only be presented in this specific way.
A signature-based system is a reactive system in which a vulnerability (vuln) must already be known so as to be able to design the signature to identify it, which in turn also implies that the vuln is already out in the wild. This signature functions by essentially being overlaid on a packet (mapping a set of bytes against a known byte pattern) of a specific vulnerability.
There are two ways you could utilize the signature-based approach. You could use it to identify known vulnerabilities (blacklisting) and thus your signatures only identify those specific anomalies and allow everything else through the firewall – this means it would certainly not catch any new or non-published vulnerabilities.
On the other hand, if you built a signature list to allow only a certain packet set -- meaning you would have a very large signature database -- (whitelisting) and drop all packets that are not in that set, then your protective mechanism is only as good as your allowed set of signatures. To be truly effective, those allowed signatures would have to be as detailed as possible.
Signatures are not simple to write and should be as granular to a specific plant as possible; that means the plant operator or engineer would have to write a custom signature. In my mind, this is a stretch too far. This is why the signatures are usually just blacklisted items with the default policy to allow everything else.
In general, signatures come in the form of a large database to be updated weekly or daily (think virus software). This also means some process must be in place to actively grab these signature files and bring them to a plant floor to be pushed out to the security devices. As we all know, the plant network should be well segmented and thus no direct Internet connection should reach the ICS.
Protocol-Specific Deep Packet Inspection – A Proactive “All-Knowing” Strategy
On the other hand, in a DPI system that validates a protocols structure, the sequence of packets and proper byte values is far more robust than a signature-based system (in my opinion). In fact, it can also be used to limit specific register ranges of a protocol, or even validate that a specific value at a specific range can only be x,y,z, for example.
This ‘all knowing’ knowledge of the protocol is proactive rather than reactive in that it can potentially protect vulnerabilities in a PLC’s protocol implementation without having to be updated. In addition, it could theoretically protect against vulnerabilities not yet known. This is because it would already have the ability to catch an ‘off-by-one’ error or a buffer overflow since it is already validating maximum size of fields as outlined in the protocol specification.
With signature-based DPI this message would be rejected only if it is in the signature database in this exact format. Protocol-specific DPI, on the other hand, has the smarts to know this is “bad grammar” and would proactively block it.
Deep Packet Inspection – Important for Defense in Depth
In the SCADA/ICS industry there is a real need to enhance or implement security, even more so now that everything is rapidly becoming interconnected. Both signature-based and protocol-specific DPIs provide additional layers of filtering. Before DPI, a plant engineer could only require the firewall to open a port and let every read or write command flow down to their PLC.
Signature-based DPI has a role to play in Defense in Depth, though it is difficult to keep the signatures up-to-date in industrial networks that are segmented from the outside world and highly sensitive to change.
Protocol-based DPI is more robust and gives plant engineers the ability to limit the use of a write command or block writes entirely for a particular industrial protocol. It is also more suited to the industrial environment, as it does not require engineers to write signatures and it can provide protection to PLCs without requiring frequent updates.
To learn more about this topic, download the white paper available below.
To read about further challenges with the signature-based approach don't miss Tripwire's blog Why Antivirus Standards of Certification Need to Change.
- Blog: Defense in Depth Part 2: Layering Multiple Defenses
- Blog: SCADA Security and Deep Packet Inspection - Part 1
- Blog: SCADA Security and Deep Packet Inspection - Part 2
- 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
Belden Products for Deep Packet Inspection
- PDF: Tofino Modbus TCP Enforcer Datasheet
- PDF: Tofino OPC Classic Enforcer Datasheet
- PDF: Tofino EtherNet/IP Enforcer Datasheet
- Webpage: EAGLE20/30 Industrial Firewalls with HiSecOS 3.0 Software