Why We Chose Suricata Over Snort as Our IDS Engine

Choosing an Intrusion Detection System engine for an operational technology network is not the same decision as choosing one for a corporate IT environment. In OT, a misconfigured active probe can freeze a PLC mid-cycle. A single dropped packet from an overloaded sensor can mean a missed Modbus write command that represents an attacker moving laterally through a substation. The consequences of a wrong choice are not a degraded user experience — they are production shutdowns, safety system interference, or worse.

For years, the conversation defaulted to Snort. Cisco backs it. Major MSSPs standardize on it. It ships inside commercial ICS security appliances from multiple vendors. The ecosystem is deep and the community is enormous. So when we began evaluating the IDS engine at the core of NETRUDER's detection pipeline, Snort was the starting assumption. Walking away from that required rigorous justification. This post documents that process and why we landed on Suricata.

A Fair Look at Snort

Snort deserves its reputation. First released in 1998 and now stewarded by Cisco, it is the most widely deployed open-source IDS engine ever written. Its rule format is the lingua franca of network intrusion detection — commercial rule providers, threat intel vendors, and ICS security researchers all publish in Snort syntax first.

What Snort gets right is substantial:

• Rule ecosystem maturity. Decades of signatures covering IT and OT attack patterns, including Cisco Talos coverage of ICS-specific exploits and Emerging Threats rulesets with dedicated industrial protocol categories.
• Predictable, stable behavior. OT environments prioritize availability above all else. Snort's long operational history means its failure modes are well understood and its resource consumption is predictable — valuable properties when your sensor sits on the same management VLAN as a DCS historian.
• Integration breadth. Many commercial OT security platforms ship Snort as their embedded detection engine. If your stack already uses it, replacing it introduces risk.
• Cisco support. For organizations with existing Cisco contracts and Firepower deployments, Snort is a natural fit with enterprise-grade support.

If your OT environment is a single facility with modest traffic and a team already fluent in Snort tuning, it remains a defensible choice. We acknowledged this openly during our evaluation.

Where Suricata Pulls Ahead

Multi-Threading Architecture and Passive Monitoring at Scale

OT networks increasingly span large geographic footprints — substations, remote pump stations, distributed manufacturing cells — each generating continuous telemetry across IT/OT boundary points. When you aggregate that traffic to a centralized monitoring node via SPAN or TAP, you are frequently looking at sustained multi-gigabit throughput with bursting during process events.

Snort 2.x is single-threaded per instance. Scaling means running multiple independent processes, each with separate rule loads, separate flow tables, and separate memory footprints. In OT environments where the sensor hardware is often a ruggedized appliance with constrained resources, this approach is operationally painful.

Suricata was architected from the ground up around multi-threading, using a pipeline model where packet acquisition, decoding, detection, and logging operate in dedicated thread pools. With AF_PACKET in cluster_flow mode, it distributes flows across worker threads while preserving per-flow ordering — critical for stateful detection of industrial protocols where sequence matters. A single Suricata instance handles what would require a load-balanced Snort fleet, without the coherence problems that come from splitting flow state across processes.

For passive monitoring deployments — which is the only acceptable approach in most OT environments — this directly translates to fewer sensors, simpler architecture, and no dropped packets under load. NETRUDER sensors are deployed exclusively via SPAN port or network TAP. The multi-threaded Suricata engine is what makes it possible for a single NETRUDER appliance to sustain full-rate monitoring of high-throughput OT aggregation points without requiring a sensor cluster.

ICS Protocol Detection and OT-Specific Rule Syntax

This is where the gap between the two engines is most significant for OT deployments.

Suricata includes native application-layer parsers for protocols that are foundational in industrial environments: Modbus, DNP3, IEC 60870-5-104 (IEC 104), ENIP/CIP (EtherNet/IP and Common Industrial Protocol), and S7comm. These are not port-based heuristics — they are genuine protocol parsers that decode the structure of each message and expose individual fields to the rule engine.

This means you can write rules that target specific ICS operations directly. For example, detecting unauthorized Modbus write coil commands from an unexpected source — the kind of lateral movement a threat actor uses after compromising an engineering workstation:

# Suricata: alert on Modbus write coil (function code 5) from non-HMI source
alert modbus any any -> $PLC_SUBNET any (
  msg:"Modbus write coil from unauthorized source";
  modbus.func:5;
  threshold: type limit, track by_src, count 1, seconds 10;
  sid:9100001; rev:1;
)

Or detecting a DNP3 direct operate command outside of an expected maintenance window — a pattern associated with adversaries attempting to manipulate field devices:

# Suricata: DNP3 direct operate command (function code 3)
alert dnp3 any any -> any any (
  msg:"DNP3 direct operate command detected";
  dnp3.func:3;
  flow:to_server,established;
  sid:9100002; rev:1;
)

Snort has no equivalent native ICS protocol parsers. Achieving similar detection in Snort requires byte-level content matching with fixed offsets — fragile rules that break under protocol variations and produce significantly higher false positive rates against the diverse firmware versions found across an OT asset inventory.

Suricata is also fully compatible with existing Snort rules. Any signature written for Snort loads without modification, so migrating an existing OT ruleset is non-destructive.

In NETRUDER, alerts generated from these ICS-aware rules are surfaced with full protocol context — not raw IP addresses. A Modbus alert includes the function code, unit ID, and register address. A DNP3 alert includes the application layer function and the affected object group. This enriched context is mapped directly to the asset inventory, so analysts see which specific PLC or RTU was targeted and what its role is in the process — without a separate CMDB lookup.

Extended Rule Syntax for IT/OT Boundary Detection

Modern OT networks are not air-gapped. IT/OT convergence means there is always boundary traffic to monitor — remote access sessions, historian data flows, vendor VPN tunnels, and the inevitable shadow IT that appears in operational networks over time. Suricata's extended sticky buffer syntax handles this boundary traffic with precision that Snort's content matching cannot match.

Detecting unauthorized remote desktop access into an OT DMZ via TLS SNI inspection:

# Suricata: TLS to known remote access infrastructure from OT segment
alert tls $OT_SUBNET any -> any any (
  msg:"TLS from OT host to remote access domain";
  tls.sni; content:".vendor-remote.example.com"; endswith;
  threshold: type limit, track by_src, count 1, seconds 300;
  sid:9100003; rev:1;
)

The dataset keyword adds another layer of operational value. It enables rules to match against dynamically updated watchlists — known-bad IP ranges, certificate fingerprints of compromised vendor tools, domain indicators from ICS-CERT advisories — refreshed at runtime without restarting the engine or interrupting monitoring:

alert dns $OT_SUBNET any -> any any (
  msg:"OT host DNS query matches ICS threat intel feed";
  dns.query;
  dataset:isset,ics-threat-domains,type string,
          load /etc/suricata/intel/ics-domains.lst;
  sid:9100004; rev:1;
)

For environments that subscribe to ICS-CERT, CISA, or sector-specific threat intelligence feeds, this runtime-reloadable capability means new indicators are active within minutes of publication — not after a maintenance window that allows a reload.

Lua Scripting for Behavioral and Process-Aware Detection

Industrial protocols carry operational context that static signatures cannot fully reason about. Whether a setpoint change is legitimate depends not just on the function code but on the current process state, the time of day, the source address, and the magnitude of the change. This is exactly the kind of conditional logic that Suricata's Lua scripting interface is designed for.

A Lua script embedded in a detection rule can maintain stateful context across multiple flows, calculate entropy on Modbus register values to detect covert data encoding, or apply process-aware thresholds that distinguish a legitimate batch startup from an anomalous command sequence:

alert modbus any any -> $PLC_SUBNET any (
  msg:"Modbus register write pattern matches anomaly model";
  flow:to_server,established;
  luajit:modbus-write-anomaly.lua;
  sid:9100005; rev:1;
)

This extensibility transforms Suricata from a signature engine into a detection platform capable of encoding OT-specific domain knowledge directly into the detection layer.

EVE JSON Output and OT SIEM Integration

OT security operations require correlating IDS alerts with asset inventory data, process historian events, and compliance audit trails. Suricata's EVE JSON output produces structured, machine-readable logs for every event type — alerts, DNS queries, SMB sessions, TLS metadata, file extractions, and full network flow records — in a schema that maps cleanly to Elasticsearch, Splunk, or any SIEM ingesting structured JSON.

Critically, EVE JSON includes protocol-specific fields. A Modbus alert includes the function code, unit ID, and register address. A DNP3 alert includes the application layer function and object group. This enriched context means OT analysts can correlate an IDS alert directly against the asset inventory without a separate lookup step — reducing mean time to triage in environments where every alert carries potential operational significance.

Snort's unified2 output is binary and requires Barnyard2 or equivalent tooling to parse. That additional dependency is manageable in a mature IT SOC but becomes a meaningful operational burden when the sensor is deployed at a remote substation or field site with limited connectivity and constrained maintenance windows.

NETRUDER consumes EVE JSON natively. Every alert, flow record, protocol transaction, and file event is ingested directly into the platform's analytics layer and automatically correlated against the asset inventory. An analyst reviewing an alert sees the affected asset's name, Purdue level, vendor, and communication peers — not an IP address that requires a separate lookup to contextualize.

Side-by-Side Comparison

Dimension	Snort 3	Suricata 7.x
Architecture	Multi-threaded (Snort 3)	Multi-threaded, pipeline model
Threading model	Shared state, single stream processor	Per-flow worker threads, AF_PACKET cluster
ICS protocol parsers	None native	Modbus, DNP3, IEC 104, ENIP/CIP, S7comm
Rule compatibility	Native Snort rules	Snort rules + extended OT-aware syntax
IT/OT boundary detection	Byte matching, limited app-layer	Sticky buffers: tls.sni, dns.query, http.uri, smb fields
Performance at scale (10G+)	Multiple instances required	Single instance, native multi-core, no dropped packets
Threat intel integration	External tooling required	Native dataset keyword, runtime-reloadable ICS feeds
Behavioral / process-aware detection	Not supported	Lua scripting via luajit
File extraction	Not native	Native, with MD5/SHA1/SHA256 hashing
Output format	Unified2 (binary, requires Barnyard2)	EVE JSON with protocol-specific fields
JA3/JA3S fingerprinting	Not native	Native — useful for vendor VPN and remote access detection
Community size	Very large (decades)	Large and growing; active ICS ruleset contributors
Commercial support	Cisco Talos	OISF + Stamus Networks + OT vendor integrations
Learning curve	Low for existing users	Moderate — ICS parser configuration requires deliberate tuning

Our Decision-Making Process

We ran a parallel evaluation over six weeks across three representative OT network environments: a simulated substation IT/OT boundary, a manufacturing cell network with mixed Modbus and ENIP/CIP traffic, and a remote access aggregation point handling vendor VPN sessions.

Both engines ingested identical PCAP replays of known-bad scenarios — including Industroyer-style DNP3 manipulation sequences, Modbus scan patterns consistent with pre-attack reconnaissance, and covert C2 over DNS from OT segment hosts. We measured detection coverage, false positive rate against normal operational traffic, CPU utilization on identical hardware, and integration effort with our EVE JSON-based analytics pipeline.

Suricata matched or exceeded Snort on every detection benchmark. The ICS protocol parsers eliminated entire categories of false positives that byte-offset Snort rules produced against legitimate process traffic — particularly in DNP3 environments where message structure varies significantly across firmware generations. Suricata also ran the full ruleset on a single instance with 30% lower CPU utilization than an equivalent three-process Snort deployment.

The honest trade-offs we documented:

• Community size and OT-specific documentation. Snort's community is larger and more thoroughly indexed. Suricata's ICS parser configuration — particularly tuning DNP3 and IEC 104 detection thresholds for specific process environments — required more internal research. Teams without dedicated OT IDS expertise will face a steeper initial ramp.
• Snort 3 is closing the gap on general detection. For IT/OT boundary monitoring without a strong ICS protocol detection requirement, Snort 3's modernized architecture is a more competitive option than it was two years ago. The decision is less clear-cut in that scenario.
• ICS parser tuning requires operational knowledge. Suricata's Modbus and DNP3 parsers are powerful, but writing accurate rules against them requires understanding the specific function codes and object groups in use in your process environment. That knowledge has to come from the OT team — it cannot be imported from a generic ruleset.

For our specific requirements — passive monitoring of mixed OT protocol environments, ICS-protocol-aware detection, runtime threat intelligence feed integration, and structured EVE JSON output for OT SIEM correlation — the trade-offs favored Suricata decisively.

Conclusion

Snort remains the industry standard for good reasons, and its presence in commercial OT security platforms reflects a practical reality: it works, it is well understood, and its failure modes are predictable. For organizations with existing Snort deployments and no pressing need for native ICS protocol parsing, an immediate migration is not necessary.

But for environments where the detection requirements are genuinely OT-native — where you need to reason about Modbus function codes, DNP3 application layer commands, and ENIP/CIP object classes at the rule level — Suricata is the more capable engine. The combination of native ICS protocol parsers, extended sticky buffer syntax for IT/OT boundary traffic, runtime-reloadable threat intelligence datasets, and Lua scripting for process-aware behavioral detection represents a meaningful capability advantage that Snort's rule syntax cannot replicate.

In OT security, the cost of a missed detection is not measured in user complaints. It is measured in process integrity, operational continuity, and — in critical infrastructure — safety. That calculus drove our decision. Suricata is the engine that lets us build the detection depth those environments require.

The NETRUDER OT IDS platform is built on this Suricata foundation and extends it with OT-specific asset enrichment, automatic Purdue Model classification, compliance reporting mapped to NERC CIP and IEC 62443, and an analyst interface designed around industrial operations rather than a generic SOC workflow. The engine choice was a prerequisite; everything else NETRUDER delivers is built on top of it.

This post reflects our internal engineering evaluation and production deployment experience across OT environments. Your network architecture, traffic profiles, and ICS protocol mix will differ — validate both engines against your own PCAP samples and operational baselines before committing.