Deep Packet Inspection for ICS Security: Signature-Based vs. Protocol-Specific
Someone recently asked me the best way to describe Deep Packet Inspection (DPI). If you're not familiar with DPI, it describes two technologies used by firewalls to detect and block unwanted communications. I pondered the question and came up with the following 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 however, is where the real information lies protected; this is where DPI really happens.
In terms of a firewall with DPI technology, this is what's actually happening. The firewall looks at the specific letters (if you will) in that packet on the wire. Yet, 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–meaning 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.
Signature-based DPI is prevalent in the IT world and is heavily used by Internet service providers (ISPs). One common use would be for BitTorrent traffic.
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 read about further challenges with the signature-based approach read the Tripwire blog post Why Antivirus Standards of Certification Need to Change.