Protocol Filtering

What is Protocol Filtering?

Protocol Filtering is a security technique in which a firewall or gateway allows or blocks network traffic based on the protocol used, the individual commands and the content of the messages, rather than only on IP address and port. In OT networks, protocol filtering is used to stop unwanted or malicious traffic on industrial protocols such as Modbus, OPC UA, S7 and DNP3. An HMI, for example, may read measured values from a PLC, but may not load a new program or stop the CPU.

Protocol filtering therefore provides fine-grained control over industrial communication, whereas traditional firewall rules only decide which system may talk to which other system.

🧠 How does protocol filtering work?

A filter that understands industrial protocols uses Deep Packet Inspection to dissect each message and then checks it at four levels:

The second level is often overlooked, yet it is valuable: many vulnerabilities in PLCs and RTUs are exploited with malformed packets that crash a poorly written protocol stack. A filter that rejects such packets therefore also protects devices that have not (yet) been patched, such as legacy systems.

Traffic that does not comply with the rules is blocked, logged or both. Alerts go to a SIEM or to anomaly detection, so that an attempted misuse also becomes visible to the OT SOC. Even permitted traffic yields visibility at protocol level: you see which system uses which commands.

🔄 What is the difference between protocol filtering, DPI and an ordinary firewall?

In short: DPI is the means, protocol filtering is the application. A passive IDS uses DPI to report anomalous commands; an inline industrial firewall uses the same technique to actually block them.

🏭 Which commands should you filter per industrial protocol?

Which commands are really needed differs per installation. An HMI that lets operators change setpoints does need write access, but only to a limited number of registers. With Siemens, also check the generation: the S7-1200 and S7-1500 use the newer S7CommPlus alongside classic S7comm, and not every filter can decode it. Programming, firmware loading and restarts belong to the engineering station, preferably only during a planned change under change management.

🔐 Which attacks does protocol filtering protect against?

The best-known OT attacks used legitimate protocols with valid commands. A port filter lets such traffic through; a command filter does not.

• Stuxnet (discovered in 2010) loaded manipulated code into Siemens PLCs over the S7 protocol via an infected engineering station.
• Industroyer sent switching commands via IEC 60870-5-104 and IEC 61850 in Kyiv in December 2016 to open circuit breakers.
• TRITON (2017) targeted a Schneider Electric (Triconex) safety instrumented system at a petrochemical plant and used the proprietary TriStation protocol to load code into the controller.
• FrostyGoop used Modbus TCP in January 2024 to manipulate control equipment of a heating utility in Lviv; around 600 apartment buildings were left without heating.

MITRE ATT&CK for ICS lists “Filter Network Traffic” (M0937) as a mitigation against, among others, Program Download, Device Restart/Shutdown, activating firmware update mode and a rogue master that poses as a legitimate control system. Protocol filtering also protects against insiders, misconfigured systems and malware moving from a compromised workstation towards the control system.

🧭 How do you implement protocol filtering step by step?

1. Build an inventory - create an asset inventory and passively map who communicates with whom, via a SPAN port or TAP and tools such as Wireshark or a passive monitoring platform such as Nozomi or Claroty.
2. Define zones and conduits - following the zones and conduits model of IEC 62443. Protocol filtering belongs on the conduits between zones, for example between the supervisory network and the PLC cell.
3. Define roles - what may the HMI do, what the historian, what the engineering station? Write this down per protocol, command and address range.
4. Start in learning mode - let the firewall only log for a few weeks, including maintenance, batch changes and faults, so that rare but legitimate commands also come into view.
5. Switch to blocking per conduit - start with the least critical cell, outside production peaks and with a fallback plan.
6. Choose the failure behaviour deliberately - fail-open keeps the process running if the filter fails, fail-close keeps the boundary shut. A safety function must never be hindered by it.
7. Maintain the rules - every process change may require a new rule. Include filter rules in change management and review them periodically.

Example: a Dutch wastewater treatment plant has a SCADA server that communicates with twelve PLCs via Modbus TCP. The rules become: the SCADA server may use function codes 1–4 everywhere and function code 6 only on the setpoint registers; the engineering station may program, but only when the administrator temporarily activates that rule; all other Modbus traffic is blocked and reported. For more on the sector, see OT security in the water sector.

📏 Which standards and laws call for protocol filtering?

• IEC 62443-3-3 - SR 5.2 (zone boundary protection) requires monitoring and controlling communication at zone boundaries. Requirement enhancement 1 asks for deny by default, allow by exception: only explicitly allowed traffic may pass, which amounts to least privilege per protocol command.
• NIST SP 800-82 - NIST’s OT security guide (revision 3 was published in September 2023) recommends boundary protection and filtering of industrial protocols as part of a layered architecture.
• NIS2 and the Dutch Cybersecurity Act - the Dutch law (Cyberbeveiligingswet), in force since 15 August 2026, does not prescribe a specific technique, but requires appropriate network security measures. For a water or energy company, protocol filtering is a common way to meet that demonstrably.

Protocol filtering is therefore not a replacement for network segmentation, but a refinement of it within defence in depth, together with access control and network monitoring.

⚠️ What are the limitations of protocol filtering?

• Encryption - OPC UA in SignAndEncrypt mode or traffic over TLS is unreadable to a filter. There is a trade-off: encryption protects the connection, filtering checks the content. One solution is filtering at the endpoint or in a trusted gateway.
• Unknown protocols - without a decoder for a proprietary protocol, the filter falls back to port level.
• Latency - inline inspection costs processing time. Time-critical traffic such as PROFINET RT also runs at layer 2 within a cell and does not cross a routed zone boundary; there, passive detection is usually chosen instead.
• Protocol and process knowledge - good rules require knowledge of the industrial protocols and of the process data: which register holds a setpoint, which command belongs to maintenance. Without that knowledge, rules end up too loose or too strict.
• Risk of downtime - an overly strict rule can block a legitimate command and halt a production line. That is why learning mode and good rule management are essential.
• A complement to the device itself - many devices offer their own protection, such as the PUT/GET access setting and protection levels on Siemens S7-1200/1500, DNP3 Secure Authentication (against replay and injection attacks) and Modbus/TCP Security with TLS. Use these where possible alongside the network filter.

❓ Frequently asked questions

Is protocol filtering the same as Deep Packet Inspection?

No. Deep Packet Inspection is the technique for dissecting the content of network packets. Protocol filtering is the security policy that uses that content to decide per protocol and command what is allowed. Protocol filtering therefore needs DPI, but not every DPI application filters.

Which Modbus function codes may an HMI use?

An HMI that only displays data needs nothing more than read function codes 1 to 4. If an operator must change setpoints, function code 6 or 16 is required, preferably limited to the registers that hold those setpoints. Programming and diagnostic functions do not belong to an HMI.

Can protocol filtering inspect encrypted OPC UA traffic?

Protocol filtering cannot read the content of OPC UA traffic in SignAndEncrypt mode, because the filter does not have the keys. The filter then only sees addresses, ports and message size. Content checks must in that case take place in the OPC UA server itself, through user permissions per node.

Where do you place a protocol filter in an OT network?

A protocol filter sits on the conduits between zones, for example between the SCADA network and a PLC cell, or in front of a critical controller. This is often done with an industrial firewall in the control cabinet. At office boundaries, an ordinary firewall with a DMZ is usually sufficient.

Does IEC 62443 require protocol filtering?

IEC 62443-3-3 does not mention protocol filtering literally, but SR 5.2 requires zone boundary protection and, through its first enhancement, deny by default. Protocol filtering is a common way to meet that requirement per command. SR 3.1, by contrast, concerns communication integrity, not filtering.

What happens when a protocol filter fails?

What happens when a protocol filter fails depends on its setting: fail-open lets traffic through, fail-close blocks everything. In OT, fail-open is often chosen on non-critical conduits so the process keeps running. IEC 62443-3-3 only requires fail-close from Security Level 3, and a safety system must never be hindered.

📌 In summary

Protocol Filtering secures industrial networks by allowing, per protocol and per command, only what a system really needs, so that valid but malicious instructions are stopped as well. It is a refinement of segmentation under IEC 62443 and an indispensable layer of modern OT security, in line with the principle of least privilege.