2017 IEEE 30th Canadian Conference on Electrical and Computer Engineering (CCECE)
Enhancing Suricata Intrusion Detection System for
Cyber Security in SCADA Networks
Kevin Wong, Craig Dillabaugh, Nabil Seddigh and Biswajit Nandy
Solana Networks, Ottawa, Canada
{kwong, cdillabaugh, nseddigh, bnandy}@solananetworks.com
Abstract — Industrial Control and SCADA (Supervisory
Control and Data Acquisition) networks control critical
infrastructure such as power plants, nuclear facilities, and water
supply systems. These systems are increasingly the target of
cyber attacks by threat actors of different kinds, with successful
attacks having the potential to cause damage, cost and injury/loss
of life. As a result, there is a strong need for enhanced tools to
detect cyber threats in SCADA networks. This paper makes a
number of contributions to advance research in this area. First,
we study the level of support for SCADA protocols in well-known
open source intrusion detection systems (IDS). Second, we select
a specific IDS, Suricata, and enhance it to include support for
detecting threats against SCADA systems running the
EtherNet/IP (ENIP) industrial control protocol. Finally, we
conduct a traffic-based study to evaluate the performance of the
new ENIP module in Suricata - analyzing its performance in low
performance hardware systems.
Keywords—SCADA; Industrial Control; Cyber Security;
Intrusion Detection Systems, IDS, Suricata; EtherNet/IP Protocol
I. INTRODUCTION
Industrial Control Systems (ICS) refer to the networked
equipment and software used to control and monitor industrial
processes. Such systems are used in critical infrastructure
sectors and other industries including electrical, water,
wastewater, oil and natural gas, chemical, manufacturing and
transport. These systems may be localized, as in the case of a
manufacturing facility, or highly distributed, as in the case of
an oil or gas pipeline or electrical grid. ICS are composed of
specialized components including Programmable Logic
Controllers (PLCs), Distributed Control Systems (DCSs), and
Supervisory Control and Data Acquisition (SCADA) systems.
In this paper we use the term SCADA and ICS interchangeably
as is common in the literature - noting however, that SCADA
systems are but one component of ICS networks.
Historically, proprietary technologies were utilized for
SCADA and ICS networks including specialized protocols
such as Modbus, DNP3, Profinet, BACnet and EtherNet/IP
(not to be confused with either the Ethernet or IP protocols).
This proprietary nature greatly assisted in their security – a
factor sometimes referred to as “security by obscurity”. The
standardization of various elements of ICS networks over the
last few years coupled with the trend of connecting these
systems to WAN (Wide Area Networks), Enterprise Networks
and the Internet, has opened up access to such networks.
-1-
978-1-5090-5538-8/17/$31.00 ©2017 IEEE
Opening up of ICS networks has led to a number of security
issues. This is because the specialized protocols at the heart of
ICS devices such as PLCs (Programmable Logic Controllers)
were designed for an environment which did not consider the
impact that networking would have on security of such systems
- leaving the ICS systems susceptible to cyber security threats.
In seeking to protect ICS networks from cyber attacks,
security tools including firewalls and Intrusion Detection
Systems (IDS) must support the different specialized SCADA
protocols - support which has been limited to date.
This paper presents the results of research focused on
broadening the coverage of IDS systems to support additional
SCADA protocols. As part of the study, we analyzed multiple
open source IDS systems and implemented support in the
well-known Suricata IDS to detect cyber threats against
industrial controllers running the ENIP (EtherNet/IP) protocol -
a protocol widely used in the manufacturing sector. Finally,
through an experimental study, we evaluated the performance
of running the ENIP-enabled version of Suricata on resource
constrained hardware. This is important because it would allow
the solution to be deployed on small form factor industrial
grade hardware which could be cheaply and widely deployed
in a large number of places in an industrial control network -
thus ensuring higher cyber security coverage.
The rest of this paper is organized as follows. Section 2
discusses related work. Section 3 evaluates open source IDS
systems for SCADA protocol support. Sections 4 and 5 analyze
the Suricata IDS design and present enhancements to support
ENIP. Section 6 provides a description of the performance
study and results. Section 7 concludes the document.
II. RELATED WORK
Signature based intrusion detection systems are one of the
key components of a cyber security solution in IT networks. In
[1], the authors studied and compared the performance of the
three most popular open source Intrusion Detection System
(IDS) tools - Snort, Suricata[2] and Bro. In the study, each IDS
was built with default settings. The throughput of the multi-
threaded Suricata IDS is striking in comparison to the other
two systems - Snort in particular. In [3] the authors study the
performance of Snort and Suricata on the Windows and Linux
operating systems. However, none of these studies focus on
SCADA protocols specifically.
 2017 IEEE 30th Canadian Conference on Electrical and Computer Engineering (CCECE)

There have been attempts to utilize Snort and Suricata in vulnerabilities for various SCADA related threats related to
SCADA networks as well. However, support for SCADA other technologies such as ODBC and ActiveX.
protocols is limited for these IDS systems. The Digital Bond
project Quickdraw provided signatures for the Modbus and As part of the Quickdraw project DigitalBond also
DNP3 protocols. These modules have been part of the Snort developed SCADA IDS preprocessors and plugins for the
distribution since 2012. Quick draw also appears to have Snort IDS. Early in the project, rules were also developed for
support [4] for the EtherNet/IP protocol which can be utilized the ICCP protocol, but ongoing support for the rules was
with Snort. As of November 2014, the Suricata IDS only dropped as they were found to be ineffective without a
supported signatures and detection of attacks against the preprocessor, which apparently had not been developed [8].
Modbus protocol. The SCADA preprocessors allow the usage of keywords
Academic research on intrusion detection for SCADA that can be used in Snort rules to evaluate the decoded content
systems has continued. In one example, signatures for ICS of the preprocessor. In 2011 the Open Information Security
protocols used in electrical utilities were developed [5] by a Foundation [9] announced that work would be carried out to
team in the United Kingdom and added as a module to Snort. ensure that these preprocessors would be updated to work with
In [6], Niventhan and Papa proposed a framework for dynamic the latest versions of Snort. However, this no longer appears to
be part of the plans. DigitalBond dropped support for the
rule generation and deep packet inspection. Their approach is
applicable for both Snort and Suricata. preprocessors and moved the signatures to GitHub around
April 2015 [10]. In addition, Emerging Threats does not
While the majority of work on signature based methods in appear to have done any work to upgrade the signatures or
Academia has focused on the popular Snort IDS, Lin et al. [7] preprocessor.
examined adapting the well-known Bro IDS to support
SCADA protocols. Like Quickdraw, while this research B. Findings and Proposed Approach
initially presents an add-on product to an existing open source TABLE I. presents a summary of our findings. Our study
IDS, aspects of this research have since been integrated into the indicates that Snort had the best support with preprocessor and
mainline Bro distribution signatures for all three SCADA protocols under review, while
Bro had support for Modbus and DNP3. At the time, Suricata
III. OPEN SOURCE IDS-COVERAGE OF SCADA PROTOCOLS only had support (under development) for Modbus. At the time
Our initial research focused on studying the level of support of publication we understand that DNP3 support may also be
available in existing open source IDS tools to detect cyber available in a future distribution of Suricata.
threats against SCADA networks. IDS systems almost
exclusively rely on signature based threat detection in which TABLE I. SUPPORT FOR SCADA PROTOCOLS IN OPEN SOURCE
network packets are examined to find traffic which matches the IDS (AS OF JANUARY 2016)
bit patterns (signature) for known threats. Due to a variety of
reasons, IDS support for SCADA protocols lags behind IDS Protocol Preprocessor Signatures
support for more commonly used IT network protocols. Such Snort Modbus Yes Yes
systems lack both extensive libraries of signatures, and base DNP3 Yes Yes
support for decoding the protocols themselves. EtherNet/IP No Yes
Suricata Modbus Yes Yes
A. Study of SCADA Protocol Coverage DNP3 No Yes
EtherNet/IP No Yes
Our work covered multiple open source IDS systems with
Bro Modbus Yes Modbus Events
particular focus on the three most widely deployed systems-
DNP3 Yes DNP Events
Snort, Suricata, and Bro. We initially sought to study the level
EtherNet/IP No No
of support for a wide-range of SCADA protocols. However,
due to the paucity of support, we refocused our efforts on three
of the more popular SCADA protocols - Modbus, DNP3, and As a result of the above, steps were taken to design and
EtherNet/IP. implement a new module for Suricata with support for the
We examined two aspects of protocol support, first whether EtherNet/IP protocol. Suricata was selected because it had
the system included a pre-processor capable of handling the more widespread deployment relative to Bro, provides
protocol specifically, and whether the systems could employ significant performance advantages over Snort, and yet had
signatures for known threats. A pre-processor is important less SCADA preprocessor support than the other 2 older open
because in its absence, cyber attackers can use packet source IDS tools.
fragmentation to defeat the signature matching engines.
IV. SURICATA IDS
The Quickdraw package referenced earlier in this paper
took an important first step to enhance Snort with SCADA Suricata [2] is a newer IDS. It was initially funded by the
protocol support. The package provides a number of Snort Department of Homeland Security's Directorate for Science
SCADA rules that can be used by Snort and Suricata. There and Technology and is designed to work with the Snort
are 23 DNP3 rules, 16 EtherNet/IP rules, and 14 Modbus TCP rulesets. Rule sets are available from Emerging Threats or
rules in total. In addition there are rules to identify 85 Emerging Threats Pro.

-2-
 2017 IEEE 30th Canadian Conference on Electrical and Computer Engineering (CCECE)
Suricata was developed to be a “next generation IDS
engine” with IPS (Intrusion Prevention System) capabilities
designed to be backwards compatible with Snort rulesets.
Suricata was designed as a multi-threaded system, enabling it
to take advantage of multiple cores. On a single core machine,
Snort has been shown to outperform Suricata. However,
Suricata exhibits superior performance on multi-core machines
with rulesets optimized for Suricata. As a result, it can easily
examine large volumes of traffic without having to reduce the
number of rules. Suricata is also distinguished by its ability to
provide visibility into the Application layer and faster parsing
of HTTP Streams. It can examine HTTP traffic regardless of
the port number used and does not rely on port numbers to
identify traffic. Suricata also allows inspection inside protocol
streams and as a result can extract files from HTTP sessions for
further examination [2].
Fig. 1. Suricata Architecture [11]
With the high speed of today's networks and increasing
sophistication in cyber attacks, there is a need for high
performance IDS tools to rapidly process packets, reconstruct
streams and apply pattern matching for signature-based threat
detection. Performance of such systems depends on multiple
factors including the performance of its pattern matching
engine where incoming packets are checked against signatures
(rulesets) representing known security threats. A typical IDS
ruleset may contain tens of thousands of signatures.
In seeking to develop a high-performance IDS, Suricata
was designed to take advantage of the advent of cheap multi-
core processors which enable parallelization of packet
processing operations. In order to fully utilize the available
processing power in a multi-core system and to avoid processor
race conditions, there is a need to ensure even Load Balancing
(LB) among cores. The aim of Suricata's LB is to dispatch the
workload equally across all cores and to minimize idle time -
as depicted in the Suricata architecture illustrated in Fig. 1.
In terms of SCADA protocol support, we note that Modbus
support was added to the mainline Suricata code repository
very recently - in November 2014. This update occurred after
the release of version 2.0.4 of Suricata in September 2014.
Conversely, support for Modbus/DNP3 in the mainline Snort
distribution was added to Snort version 2.9.2 around the start
of 2012 [12].
-3-
V. DESIGN TO SUPPORT ENIP PROTOCOL
In order to develop support for a new protocol in an IDS
system it is first important to understand and deconstruct the
protocol. EtherNet Industrial Protocol (EtherNet/IP) is an
industrial network protocol that combines standard Ethernet
technologies with the media-independent Common Industrial
Protocol (CIP). CIP is widely used as a unified communication
architecture in the manufacturing sector.
The EtherNet/IP encapsulation protocol can be used over
TCP and UDP. The same reserved port number (44818) is
used for TCP/UDP communications on EtherNet/IP devices.
EtherNet/IP can be viewed as consisting of two parts: (i) the
EtherNet/IP encapsulation and (ii) CIP. The EtherNet/IP
encapsulation header contains data describing the connections,
sessions, and methods of communications. The CIP portion
contains the information on objects, instances, attributes and
values.
CIP connected messages fall into one of 7 transport classes
(labeled 0 through 6). Class 0 and 1 connections are
transmitted using UDP, while class 2 and 3 are transmitted
using TCP. In both cases the messages are encapsulated using
the encapsulation protocol (with a full Encapsulation Header
and Encapsulated Data section). Classes 4, 5 and 6 do not use
the encapsulation protocol described here.
Fig. 2. Suricata EtherNet/IP Parser
EtherNet/IP (ENIP) defines two message types as follows:
1. Explicit Message – runs over TCP and contains the ENIP
encapsulation header and the encapsulated data which has
the CIP portion. Explicit Messages are one of two types:
Connected and Unconnected.
2. Implicit Message – runs over UDP and does not contain the
ENIP header. It includes just the CIP portion.
Designing and implementing support for the ENIP protocol
in Suricata involves the following high level work (i) Rule
definition for the new protocol (ii) Parse the rule and store it in
the rule matching data structure (iii) Adding an ENIP packet
parser
Two different design solutions were implemented for the
ENIP module - one based on examining individual packets and
 2017 IEEE 30th Canadian Conference on Electrical and Computer Engineering (CCECE)
a second based on examination of packet streams. The second
solution was ultimately adopted and accepted for integration as
part of the main distribution of Suricata. The remainder of this
paper concentrates on the second solution.
We elaborate briefly on the parser design. The parser
performs the task of decoding the EtherNet/IP encapsulation
header as well as most of the encapsulated data and placing it
in a data structure for use by the Match function. As illustrated
in Fig. 2, the packet parser call graph involves:
1. Add session initializer to store EtherNet/IP packet data
2. Parse EtherNet/IP packet based on specification details
outlined earlier in this document
3. If command is of type SendUnitData, parse common
packet format with DecodeCommonPacketFormat().
Otherwise, skip and continue.
4. DecodeCommonPacketFormat() would determine if we
are looking at a Connected data item. If so then we
would call DecodeCIP() which would parse the CIP
portion of the common packet format.
5. DecodeCIP() would decode the CIP requests and
responses. The requests and responses may have
multiple services within them so we would need to be
able to parse each one.
6. For the individual service request/response we would
need a decoder to extract the CIP service code.
7. A parser can be added for the CIP path but it will be
unused - a decision needs to be taken whether to add
the parser at this time or leave this as a future task.
8. Store all data from the above steps in ENIP_PACKET
structure.
VI. PERFORMANCE STUDY AND EVALUATION
We sought to experimentally evaluate the performance of
the new Suricata ENIP module to match signatures against
monitored packet traffic. We were particularly interested in the
performance when Suricata was run on a hardware platform
with low resource footprint (small memory and CPU),
potentially allowing one hardware unit with Suricata to be
deployed in front of each PLC deployed in a field network.
A. Experimental Setup - Systems
The experimental setup included two computers. One
computer generated traffic while the other computer ran
Suricata. Both computers had a Gigabit EtherNet adapter
ensuring that they would not drop packets during testing.
The computer hosting Suricata had a Intel Core2Duo dual
core processor (CPU E7300) running at 2 x 2.66GHz with 3Gb
RAM. Suricata v3.2 was used for the tests, running on the
Ubuntu Linux v14.04 operating system.
In the tests, Suricata was installed with a set of
approximately 18,000 rules taken from a standard package at
the Emerging Threats website [13] along with a baseline of 250
rules which come installed by default with the Suricata
-4-
package. We also expanded the HOME_NET and
EXTERNAL_NET in the suricata.yaml configuration file so no
packets would be filtered based on IP addresses.
B. Test Approach - Traffic Generation
An offline test approach was utilized to test Suricata which
relied on replaying previously captured traffic. Since it is not
easy to obtain large traffic traces from SCADA networks we
created a synthetic traffic trace as described below.
To generate traffic during the tests, we used a packet
capture (pcap) file made available by the makers of
TCPREPLAY. This file (smallFlows.pcap) is often used for
benchmarking the performance of IDS systems. We merged
this file with a pcap file from Digital Bond which contained
EtherNet/IP traffic - CL5000EIP-FirmwareChange.pcap. Care
was taken to ensure that disparate timing and IP addresses in
the two files did not conflict.
The original packet trace was 12.265Mb in size consisting
of a 5 minute packet capture which included 24,988 packets,
83pkt/per second rate, with 229 conversations (bi-directional
flows between the same end-points). This original trace
generated traffic at a rate of 324Kbps.
In order to replay the traffic at a faster rate, we used the Bit-
Twist Libpcap-based EtherNet packet generator. Bit-Twist read
the packet traces and replayed the packets from the traffic
generation computer to the host running Suricata. We ran Bit-
Twist with the "-l 0 -m 0" options which configures Bit-Twist
to run in a loop and send out the packets as fast as possible.
Replaying a single file as fast as possible generated traffic at a
rate of approximately 18Mbps. In order to achieve higher rates,
multiple instances of Bit-Twist were run.
C. Results & Analysis
The experiments involved running each test 5 times at
different throughput rates. Each time we recorded the
percentage of packet drops and the CPU usage percentage.
The same experiments were repeated while limiting the
memory usage of Suricata. One test limited Suricata to using
750MB while the other ran with 1.5GB of Memory. The
following figures capture the results of the tests and represent
the average rate seen over a 1 minute run of Bit-Twist.
Fig. 3. Suricata Packet Drop - Constrained Memory - 750Mb & 1.5Gb
 2017 IEEE 30th Canadian Conference on Electrical and Computer Engineering (CCECE)
Fig. 3 captures the percentage of packets dropped when
Suricata processes traffic at different throughput rates. From
the figure we make two key observations: (i) There are no
packet drops for either test until the throughput reaches
37Mbps (ii) As the traffic reaches 50Mbps, the test with lower
memory begins to drop more packets than the higher memory
test.
Fig. 4 captures the CPU utilization when Suricata processes
traffic at different throughput rates. From the figure, we make
the following observation and analysis: (i) At a throughput of
~18Mbps, CPU utilization is around 20% which is a very
reasonable and sustainable figure for a machine with 2 cores
(ii) CPU utilization continues to increase almost linearly with
increased throughput. Utilization of 120% for a 2 core machine
is a concern if the test is intended to represent constrained
hardware that can be procured cheaply. We note however, that
the throughput tested (130Mbps) represents high levels of
bandwidth in an industrial control network and would only be
experienced during peak periods for very short intervals. The
bandwidth of 18Mbps is a more realistic measure of bandwidth
on such networks.
Fig. 4. Suricata CPU Usage - Constrained Memory- 750Mb and 1.5Gb
The above tests were rerun with the set of EtherNet/IP rules
enabled - 30 rules were added which exercise the EtherNet/IP
module added to Suricata. These tests were run in order to
study the impact of the ENIP-supported Suricata running on a
hardware platform with limited resources. We do not reproduce
the graphs from those tests as the results are very similar to the
results in Fig. 3 and Fig. 4.
Analysis of the tests carried out in this section lead to two
strong conclusions: (i) Addition of a module to parse the
complicated ENIP protocol and maintain flow state
information does not adversely impact Suricata packet drop
and CPU performance for the range of throughputs tested (ii)
The performance tests for 750Mb indicate the viability of
running Suricata on resource constrained hardware which can
be deployed at cheap cost in front of individual PLC systems -
leading to improved cyber security protection for IC networks.
VII. CONCLUSION
This paper reports on an effort to enhance the Suricata open
source IDS with a new module to allow specification of rules
which detect cyber threats against SCADA software and
-5-
devices using the EtherNet/IP protocol. We conducted tests to
study the performance of the ENIP-enhanced Suricata on
constrained-resource hardware platforms. We make two
observations from the study (i) At a throughput of 18Mbps
representing many SCADA networks, Suricata can viably
operate on hardware platforms with smaller memory and a less
powerful CPU. (ii) Addition of a module to process ENIP rules
on Suricata did not impact performance in terms of CPU
utilization or Packet Drops. In general, we observe that the 3
most popular open source IDS systems have varying levels of
support for 3 SCADA protocols.
The ENIP implementation used for the experiments in this
paper was integrated into Suricata Release 3.2beta1 in October
2016 [14]. Since December 2016, it has been available as part
of Release 3.2 in the main Suricata distribution. For future
work, we recommend addition of pre-processor based support
for additional SCADA protocols such as ICCP.
ACKNOWLEDGMENT
We are grateful for the discussions with Paul O' Brien and
Frank Turbide in completing aspects of this work. We
acknowledge that some of this work was carried out during a
project with Public Safety Canada and Defence R&D Canada.
REFERENCES
[1] M. Pihelgas,"A Comparative Analysis of Open-Source Intrusion
Detection Systems", Master's Thesis, Tallin Univ. of Technology, 2012
[2] http://suricata-ids.org/ Accessed 23/02/2017
[3] B. Brumen and J. Legvart, "Performance analysis of two open source
intrusion detection systems", MIPRO Conference, May 2016, Croatia
[4] D. Peterson “Quickdraw: Generating security log events for legacy
SCADA and control system devices.” Conference for Homeland
Security, 2009. CATCH’09. pp. 227-229. IEEE, 2009.
[5] Y. Yang , K. McLaughlin, T. Litter, S. Sezer, B. Pranggono, H. F.
Wang; “Intrusion Dtection System for IEC 60870-5-104 based SCADA
networks”, IEEE Power & Energy Society General Meeting, 2013
[6] J. Nivethan and M. Papa, “Dynamic Rule Generation for SCADA
Intrusion Detection,” in IEEE Symposium on Technologies for
Homeland Security (HST), May 2016
[7] H. Lin, et al. “Adapting Bro into SCADA: Building a specification
based intrusion detection system for DNP3 Protocol”, 8th Cyber
Security & Info Intelligence Research Workshop, ACM, 2013.
[8] D. Peterson, Blog. “Quickdraw IDS4.1 Release.” Accessed 24/02/2017
http://www.digitalbond.com/blog/2011/02/28/quickdraw-ids-4-1-
release/
[9] Open Information Security Foundation. “EnergySEC and OISF
announce new SCADA Research.” Posted Aug., 29th, 2011, accessed
24 February 2017; https://lists.emergingthreats.net/pipermail/emerging-
sigs/2011-August/015545.html
[10] D. Peterson, Personal Communication. December 2014.
https://github.com/digitalbond/quickdraw; Last Accessed 24 Feb 207
[11] H. Jiang, G Xie and K Salamatian. “Load Balancing by Ruleset
Partition for Parallel IDS on Multi-Core Processors.”, ICCCN 2013
[12] M. H. Pelaez, “Snort 2.9.2 now supporting SCADA protocol checks”
Posted 8 Jan 2012, Accessed 22/02/2017.
https://isc.sans.edu/diary/Snort+2.9.2+now+supporting+SCADA+protoc
ol+checks/12346
[13] https://rules.emergingthreats.net/open/snort-2.9.0/emerging-all.rules
Accessed 23/02/2017
[14] https://suricata-ids.org/2016/10/03/suricata-3-2beta1-ready-for-testing/