Towards Accelerating Intrusion Detection Operations at the Edge Network using FPGAs

In the current paper, we present our work towards accelerating intrusion detection operations at the edge network using FPGAs. Cloud computing and network function virtualization have led to a new appealing paradigm for service delivery and management. Unfortunately, this paradigm fails to correctly support IoT applications and services that seek better communication platforms. Security as a Service can also be seen as a cloud-based model that needs to be accommodated to fulfill these services requirements. Again, one of the main issues to be addressed in this context is how to improve the performance of such systems or services in order to make them capable of coping with the huge amount of data while remaining reliable. A potential solution is the FPGA based edge computing, which is a powerful combination offering FPGA acceleration capabilities together with edge and fog benefits. Indeed, our work focusses on devising an Intrusion Prevention architecture called FORTISEC (40SEC), that is meant to operate in a completely softwarized as well as in an FPGA mode. Thereby, we present suitable algorithms, design principles and well defined components towards the implementation of accelerated intrusion prevention on the edge. We also present a testbed being utilized for the implementation of 40SEC and its performance testing.


INTRODUCTION
Virtual Network Functions are network services or capabilities that are softwarized and can also run on commodity hardware. Contrary to functions running on dedicated hardware, virtual functions offer flexibility and easy deployment. The services that can be softwarized include firewalls, Domain Name System (DNS), Network Address Translation (NAT), and Intrusion Detection/Prevention Systems (IPS/IDS) [11].
It can be fairly said that virtualization enabled moving a huge number of services and applications to the cloud. However, the related performance was not always as expected. This is the case for instance for Internet of Things (IoT) [11]. The latter is being used in a variety of systems and services in our daily life. The quality of these services certainly depends on the security solutions put in place in order to protect them. Utilizing Intrusion Detection Systems (IDS) in the cloud, in order to secure IoT services might not be the appropriate way as with the huge amount of data to be analyzed, the response time might face delays and the alerts could be received after the attack has taken place.
Edge computing is a paradigm that particularly came to optimize network bottlenecks that can be faced when using clouds. The idea behind this concept is to perform data processing and knowledge generation at the periphery of the network and close to the originating sources. If we wish to develop an IDS for protecting IoT services, we need to ensure that: (1) it is lightweight enough to be deployed at the edge, and (2) the performance of the detection operations will be better than if the detection is made in the cloud.
In this paper, we discuss our research towards specifying and prototyping an Intrusion Prevention System (IPS) that can be used in Edge computing scenarios. Our solution, called FORTISEC (or simply 40SEC), resembles to a Virtual Security Appliance (vSA) that is composed of a firewall and an IDS. Although, the focus in this paper is on edge computing, our solution can be utilized in a variety of other scenarios (e.g. enterprise security). One of the main characteristics of our vSA is the fact that the parts of the IDS that need intensive processing are implemented on Field Programmable Gate Arrays (FPGAs) that are known for their potential for accelerating computational intensive workloads [12]. It was mentioned for instance in [12] that convolutional Neural Networks (CNN) can be improved for image classification on AlexNet up to 2,0/2,5 times in terms of processing time -i.e. when utilizing FPGAs in comparison to CPUs.

II. RELATED WORK AND PROGRESS BEYOND STATES-OF-THE-ART
Implementing Intrusion Detection Systems on FPGA is a topic that has been more or less discussed in literature. The topic was approached from different angles, since existing algorithms such as Wu-Manber [19] and Aho-Corasik [20], which could be efficient in accelerating rule-matching operations, are applicable to strings. However, the rule sets that intrusion detection systems like Snort use, are based on regular expressions (regex). An ideal situation could have been the utilization of the above-mentioned fast algorithms with the rule sets offered by the existing IDS. Unfortunately, this option is not easy to realize. Snort, for instance, provides already a huge variety of rules where most of them are written in Perl Compatible Regular Expressions (PCRE) [23], which cannot be integrated with the above high speed string-matching approaches in a simple way.
The authors of [16] proposed a solution integrating network interface hardware and packet analysis hardware into a single FPGA chip. To realize this, they implemented a complete and functional network IDS on a Xilinx Virtex II/Pro FPGA that performs packet filtering on multiple Gigabit Ethernet links using Snort rules [16]. In [18], an FPGA based high performance pattern matching architecture was implemented. The authors claim that the developed deep network packet filter can protect a network of 1.6 Gbps and their design can fit on very cheap FPGA hardware. Moreover, as the part in the IDS that requires intensive processing is the string matching, several solutions implementing the related operations on FPGA were suggested. For instance, the authors of [17] presented a module utilizing non-deterministic finite automata to create efficient circuits for matching patterns defined through a standard rule language. In order to have complete IDS, the mentioned module was integrated with other hardware and software components. The authors of [17] claim that their technique led to circuits that are more than twice as dense as other proposed designs, while the throughput necessary for processing at gigabit line speeds and even beyond was maintained. The IDS software versions like Snort use some rule matching algorithms (such as the above-mentioned Wu Manber [19] and Aho-Corasik [20]), which can be implemented on hardware in order to potentially accelerate the detection operations [21]. These algorithms need to be redesigned in order to use regular expressions.
In [22], a hardware based regular expression engine for Snort was built by transforming the PCRE opcodes generated by the PCRE compiler from Snort regular expression rules. The hardware implementation was tuned by using Nondeterministic Finite Automaton (NFA) and greedy quantifiers. Two hundred PCRE engines were implemented and tested on a Virtex-4 LX200 FPGA. The authors claim that this implementation performs much better (up to 353 times faster) than software based PCRE execution [22].
Sidhu and Prasanna [29] investigated the acceleration of grep regular expression searches with FPGAs by utilizing a compilation technique that quickly converts a regular expression into an FPGA circuit. The regular expression is compiled into a Nondeterministic Finite Automata (NFA) that is directly implemented on the FPGA hardware. Another way for handling regular expression operators, based on standard regex syntax is to use JHDL [30], which is a complete Java based design environment. Indeed, one can write complex circuit generation algorithms in Java and combine them with JHDL circuit libraries, in order to create sophisticated module generators [24]. Unfortunately, this tool is not easy to use and cumbersome to learn and use by unexperienced engineers.
Our approach differs from the above-mentioned work in the following aspects,  Both signature and anomaly based detection techniques are considered in our design  Our implementation considers pattern matching algorithms that are already used by well know intrusion detection solutions (e.g, Snort)  "high-level" programming languages like C/C++ have been used for implementing the pattern matching algorithms on Xilinx Vivado. This makes the update of the code easier. Vivado also enables the generation of bit streams that can be uploaded on the FPGA hardware The edge gateway platform, on which our virtual Security Appliance (40SEC) runs, is a XILINX KRM-3Z7030 50mm x 70mm module [14] composed of an ARM processor and an FPGA part, and carried by a KRC3701 Carrier Kit [15]. It is worth mentioning that virtualizing security appliances has to deal intrinsically with performance restrictions. In the past, optimal performance was provided through a dedicated hardware. In virtualized environments, applications and services running on an operating system compete for the same hardware computing resource, which might slow down the performance. One of the main objectives of this work is to investigate how the performance behaves when the 40SEC entirely runs on the ARM processor and when some of the related security parts -that require more processing -are moved to FPGA. For this reason, we decided to have the 40SEC architecture in two different versions. In the first one, the entire 40SEC appliance runs on the ARM processor. However, in the second version, the parts that require intense processing are moved to the FPGA part, in order to speed up the detection operations. Figure 1 depicts the main components of the ARM based 40SEC architecture as well as the interfaces in between. As previously mentioned, the entire 40SEC appliance is implemented on the ARM processor in the first version. For that purpose, various related components were dockerized and made available. Since some existing Intrusion Detection Systems -such as Snort -are available as open source and offer a security level comparable to commercial security solutions, we decided to explore their capability of running on the ARM processor and measure their performance. Within the 40SEC architecture, Snort was utilized due to its 2020 Fifth International Conference on Fog and Mobile Edge Computing (FMEC) popularity. Based on these high-level elucidations, the following subsections discuss on vital aspects and processes within the 40SEC architecture depicted in Figure 1.

A. Packet Capturing
Packet Capturing makes all incoming network packets available for further processing. The easiest and typical way to receive all packets in Linux is to open a raw socket. Such a socket will pass received Ethernet frames directly to the user space application without any preprocessing (thus all network headers are incorporated into the data). In Python, such a socket can be created with the socket module and a call to In this connection call, the first argument indicates the address family (Packet, Internet Protocol 4, etc.), the second argument describes the socket type (raw or datagram), while the third one indicates that packets from all protocols will be received. Received calls on the socket will then return single packets, where the headers of the nested protocols must be parsed manually to extract source, destination and other metadata.

B. Packet Filtering
In the following, the process of packet filtering is explained along the legacy iptables technology. iptables [13] is a program for the configuration of the Linux kernel firewall. It is based on rules that are organized in chains. The rules are managed internally and can be added, modified and deleted through a user space application. To update the firewall rules programmatically, one can dynamically build up strings and configure them from a user space application via operating system calls (e.g. with the function os.system in Python).
A different approach to filtering (but tightly connected to iptables) was implemented within netfilter. This Linux kernel interface allows one to create hook functions that will be called on every incoming packet. Such a function can then decide to accept or reject the packet. This gives direct control over the firewall functionality, in contrast to the configuration-based approach of iptables. Because the rules' data is stored in the module and can be modified by program code (in the case of netfilter), it is much easier to update the rule set in a consistent way -e.g. all rules matching certain criteria can be deleted easily or multiple rules can be merged into a single one with a corresponding IP range. Adding complex functionality is therefore more straightforward than keeping track of all the rules of iptables and updating them accordingly. Because the hook functions are inserted directly into the kernel network stack, a netfilter-based firewall has to be often developed as a kernel module in the C programming language. Thus, with the greater flexibility also comes greater responsibility, as a crash of the firewall as a kernel module will bring down the entire system. Additionally, a communication channel between the firewall and user space has to be established to enable a REST service for configuration. Indeed, a sysfs interface is used for this purpose. Commands are inserted into a file in a virtual file system that is being listened to by the kernel module.

C. Decision Engine
The Decision Engine enables the 40SEC appliance to actively react on intrusions by analyzing the alerts generated from the IDS and adapting the firewalls configuration to stop the attack. Thereby, the firewall configurations and/or the IDS decisions are designed and verified according to the above described design, modelling and code generation process. V. THE FPGA BASED ARCHITECTURE Intrusion Detection Systems can be anomaly based or signature based. If we take a signature based IDS as an example, we can see that it is composed of three main functionalities: 1. Data processing: Here, the network traffic is collected and formatted, in order to be analyzed by the detection algorithms 2. Detection: This operation investigates the difference between "normal" traffic and an intrusion. 3. Response: Here, appropriate alerts are generated based on the decision criteria and the intrusions detected The typical and most straightforward way of detecting intrusions is to compare string patterns (attacks signatures) to the payload of the traffic packets. It has been shown ( [1], [4]) that utilizing existing efficient string matching algorithms (e.g. [2], [3]) leads to significant costs. For instance, the measurements performed recently with Snort on a production network and reported in [4] show that almost 31% of the total processing effort can be traced back to string matching. The same report also emphasizes that in case of intensive web traffic, the processing cost increases to 81% of the total processing time. For these reasons, we would like to explore how the performance of our 40SEC, in particular the IDS part, will behave when the string matching algorithms run on FPGA instead of the ARM processor. The belonging architectural vision is depicted in Figure 2 illustrating the separation between the software part (i.e. ARM part) and the FPGA based hardware accelerator. To realize the above mentioned vision for signature based IDS, we have decided to implement on FPGA the Wu-Manber algorithm that Snort uses in a simplified version. For anomaly detection, we have chosen to implement two well-known techniques from the flooding/DoS attacks detection domain. The first one is based on adaptive thresholds, while the second one relies on change point theory. It is worth to mention that the algorithms that will be discussed below are applied for IP packets in the current work, and can similarly be used for other packet types such as SYN and ICMP.

A. Statistical Algorithms
In the following, key algorithms are presented that fit into the abstract 40XLERATOR architecture.

Adaptive Threshold Algorithm
Flooding attacks detection cannot rely on static thresholds. In fact, two main factors can affect the detection process. These factors are the attack type and the situation of the communication channel (burst or not). An attacker can flood the target system gradually with malicious traffic. If the channel is not in a burst mode and the threshold was assigned a high value, the attack will not be detected. On the other side, if the threshold was set to a small value and the channel experiences a huge amount of traffic, the detection process will lead to many false alarms. One way to overcome this problem is to use a threshold that adapts to the traffic behavior.
The algorithm we propose here relies on checking whether the number of IP packets over a given time interval exceeds a particular threshold. In order to take into account daily and weekly traffic variations and trends, the threshold value is computed adaptively based on an estimate of the mean number of IP packets. Let us assume is the number of IP packets in the n-th time interval, and −1 is the mean value calculated from measurements prior to n. In this case, an alarm will be generated at time n if, is a strictly positive parameter representing the percentage above the mean value that we consider to be an indicator of an intrusion [5].
The mean can be calculated over some past time window or using an exponential weighted moving average (EWMA) of previous measurements, where is the EWMA factor. Like any other statistical algorithm, false positives could be a serious issue. In order to reduce the amount of false positives, the authors of [5] suggest sending alarms only after a minimum number of consecutive violations of the threshold. In addition, in the course of the FORTIKA project [25], we are further investigating how to tune the parameters: , the length of the measurement time interval, and the number of successive threshold violations, in order to increase detection efficiency, while keeping the amount of generated false alarms to the minimum.

Change Point Detection (Cumulative Sums Algorithm -CUSUM-)
Change points represent sudden variations in time series data. They may reflect changes that occur between states. The change point theory is a powerful tool for investigating time series and has been used in different applications including health monitoring, climate change detection [7] and DoS attacks detection and prevention ( [8], [5], [9]). If we take DoS attacks as an example, although intrusions happen at unpredictable points in time, they are often accompanied with a change of some statistical properties of the network traffic. This makes Change Point detection schemes suitable for investigating such changes. Often these techniques use Cumulative Sums (CUSUM) of data that are computed over time, and the resulting series is observed to localize the change points that might occur. The CUSUMs are often used because of their simplicity and low computational complexity. There are two variants of these techniques: the first one, called parametric CUSUM, assumes that the observed variable follows a known distribution (e.g. Poisson distribution). This assumption is in general not true. The second variant, called non-parametric CUSUM, does not require that the undertaken measurements exhibit a certain pattern.
Implementing the Change Point techniques on FPGA will certainly lead to the acceleration of the applications being considered. Unfortunately, from the research point of view, only few papers discussing such implementations are available. In [10], a nonparametric CUSUM that serves as a hardware plugin for Software Defined Monitoring (SDM) was implemented on a Network Interface Card (NIC) and used to detect anomalies directly in FPGA. The authors claim to be able to realize different detections simultaneously without any loss in throughput. In [10], an online Change Point detection algorithm based on an Auto Regression (AR) model, called ChangeFinder, was implemented on a NIC. The proposed solution computes the change-point score from time series data received from the 10GbE (10Gbit Ethernet) NIC. The objective of the authors was to reduce the host workload and improve the performance by offloading the ChangeFinder algorithm from host to the NIC [10]. According to their evaluation results, an improvement of 16,8x in change point detection throughput was realized compared to the baseline software implementation while keeping the same accuracy. To apply Change Point theory to DoS attacks detection, three parts are needed: (1) The network traffic variable that will be measured and which will be the basis for the time series to be observed -here, measurements related to protocols such as TCP, UDP, ICMP, and SIP can be used. It is also possible that pairs like TCP SYN-FIN [8], where a strong correlation exists in between, can be observed and utilized by the CUSUM techniques. (2) Once the time series is defined, it may need to be made stationary (i.e. a time independent normalization would need to be applied before feeding values for alarm generation) through appropriate transformations, in order to be used by the CUSUMs. (3) A bunch of parameters and thresholds must be set and potentially optimized in order to detect the attacks and reduce the amount of false alerts. Concretely, the CUSUM technique we are implementing in FORTIKA [25] follows the algorithm discussed by Siris in [5]. Let us assume we are observing the number of IP packets entering the network under consideration during a period of time that is divided into time intervals of the same duration. As mentioned earlier, we can observe TCP, UDP, and ICMP packets or even pairs such as TCP SYN-FIN, instead of IP packets. Let be the number of IP packets collected within the n-th time interval and the corresponding mean rate at time n. The value is calculated using an exponentially weighted moving average, where is the exponentially weighted moving average (EWMA) factor and 0 = 1 . To give some more details, the exponential weighted moving average is a weighted average where the weighting decreases in an exponential way with each following measurement with respect to previous measurement values. The EWMA is also used in our context to avoid explicitly taking into account the seasonability and the trend factors ( [5], [9]). As the time series , n = 1, 2, ... is in general non-stationary because of the just mentioned factors, it can be made stationary by using the following transformation (according to [8], [5]), The nonparametric CUSUM algorithm is given by, where a is a positive real number defined experimentally to minimize the false alarm rate [8]. As it was discussed in [9], assigning an appropriate value to the parameter a can be done by taking it sufficiently large with respect to the historical estimate (̃) for the expected value (̃) representing the normal behavior. Indeed, an estimate (̃) of (̃) can be calculated experimentally, and then it can be set to the sum of (̃) and a multiple of the estimate of the corresponding standard deviation, i.e, is an appropriate non negative number and (̃ ) is an estimate of the standard deviation of the normal traffic.
Another parameter that is needed is the stopping time. The latter is the time when a change in the CUSUM algorithm occurs and can be formulated as follows, The threshold Thr can be seen as a positive number specifying the value that when exceeded, an attack is signaled. This value can also be defined as a multiple of the estimated standard deviation (̃ ). This means Thr will be of the form (̃ ) where is a positive number reflecting the size (in terms of the standard deviation) of the shift we want to detect [9].

B. Signature based Algorithms
Sun Wu and Udi Manber developed the Wu-Manber algorithm in 1994. It has its origins in the Boyer-Moore and Rabin-Karp matching algorithms, whereas the Wu-Manber advantages are a high average case performance and a less required small memory space. Some restrictions have to be mentioned for the Wu-Manber algorithm: (1) The amount of patterns that can be processed simultaneously is less than a few hundred. (2) There should not be a high deviation in the length of the patterns that has to be matched, in order to ensure reasonable performance. (3) Searching time increases inversely proportional to the length of patterns. This means that too short patterns require a lot more time for searching.

C. The Wu-Manber Algorithm
The initial proposed Wu-Manber algorithm in 1994 provided a basis for many further implementations of that algorithm with several improvements. Beside other Intrusion Detection Systems, snort uses a simplified variant of the Wu-Manber algorithm too.
Recently published studies -dealing with the performance of Snort using the Wu-Manber pattern search algorithm instead of the formerly used Set-Wise Boyer-Moore and Aho-Corasick algorithm -pointed out that Snort gained a remarkable performance improvement with Wu-Manber. The pseudo-code in [16] has been the source for the implementation of the Wu-Manber algorithm for the 40SEC platform.
We mentioned in the beginning of this paper that fast algorithms such as Wu-Manber need to be redesigned in order to support regular expressions. Nevertheless, this algorithm can be used as it is in email spam detection. It can be considered as an anti-spam content based technique, and utilized to accelerate the emails analysis.

D. Parallalizing Wu-Manber
The Wu-Manber algorithm comprises of two stages -a preprocessing phase. The control flow and the dataflow are serialized in this algorithm. The preprocessing phase is computed for the given set of keywords/patterns only once and doesn't add to the overall computation time period. We decided to exploit data level parallelism in the scanning phase algorithm using an asynchronous mode of execution. Correspondingly, the SIMD [28] architecture is implemented. Let L be the length of the input data stored in the processor memory. Using the AXI4 burst transfer mode, the input data is double buffered asynchronously into the FPGA BRAM with buffers Bn, where B is the buffer of length N (0 < N ≤ L) and n is the number of buffers (n > 1). Let h be the number of identical hardware instances of the scanning phase. The buffered input data is accordingly sliced into N/h slices.
This belonging FPGA design is done via Vivado HLS which offers the flexibility for RTL synthesis from high level programming language (C/C++) and generates the bit stream for the IP cores. By utilizing the asynchronous mode of operation, the h hardware instances operate on their corresponding buffer slice. The goal is to improve the performance by 2x at the maximum.

VI. TESTING AND EXPERIMENTS
In order to test the 40SEC and each of its subcomponents (Firewall, IDS, RESTApi, etc.) within defined scenarios, a test environment was set.

A. Scenarios
The following table provides the scenarios used in our testing activities. The listed attacks were executed in order to test and validate the current state of the 40SEC implementation.  Figure 3 illustrates our local testbed. One can clearly see the positioning of the vSA as allowing it to control traffic between the LAN and WAN segments towards the Internet. Thereby, the LAN segment can be assumed as representative for the local network of a European SME. Furthermore, a management interface and a belonging management/control network is spanned over all involved components allowing us to control their behavior, initiate different scenarios, execute tests and run experiments evaluating different configuration of the 40SEC vSA. In the following, the selected tools are introduced, which we have deployed in our testbed and utilize for testing and experiments. Figure 3: FOKUS local Testbed Components IPerf (client, server) [26]: IPerf is used to generate TCP and UDP data streams. It provides a client-server application that allows to measure bandwidth, quantity of data that passes a network and belonging time aspects. IPerf creates a report with a timestamp, details of transmitted network packets and measured bandwidth. In the case of the 40SEC vSA, IPerf is used to assess the network data processing performance of the FPGA hardware in conjunction with the ARM part. TCPReplay [27]: TCPreplay contains different open source utilities that can be used to replay a pcap file that has been captured before. It can be easily used as a test tool to check the performance of IDS, IPS or Firewall systems. In our scenarios, we are utilizing it to simulate a big network traffic coming to our network and checking if it gets blocked by our Firewall or reported by our IDS. TCPreplay can take long time to replay all the information included in the pcap file. Web Service: To test the performance of the Virtual Security Appliance, we run a simple web service in our testbed, which offers a REST API for computing a complex function value based on an inputted number over the REST API -we use a complex function for simulating web server load. Then we can measure the availability and performance 2020 Fifth International Conference on Fog and Mobile Edge Computing (FMEC) of the service under different scenarios, from high network load to different attacks. This gives information about the latency, throughput and effectiveness of the 40SEC security device. Performance and Security Testing Tools: Besides tools that are available (e.g. hping3, Metasploit nmap and Wireshark) and preinstalled in Kali Linux (a free Debian Linux System for penetration testing), JMeter is one of the tools that is used to simulate a heavy load to the 40SEC Gateway and to test its performance under different load types. Furthermore, in our scenarios, we have used tools like nmap to achieve port scanning attack and hping3 to achieve SYNflood attack.

C. First Experimental Results
The first experiments we wanted to undertake are related to the Wu-Manber algorithm. The idea was to run this algorithm on ARM and also on FPGA and compare between the corresponding performances. As mentioned earlier, this algorithm can directly be used for email spam content analysis, however as we could not find a suitable email spam database for testing purposes, we have chosen to apply this algorithm on available books. Table 1 shows the performance results achieved on the 40SEC ARM architecture with respect to string matching.
When conducting the measurements, we took a set of corpora from different sizes ("Word Count"-column) and searched in those for various random patterns. The corpora were given by various books (e.g. adventures of Sherlock Homes, History of United States of America, Manual for Surgery and War and Peace), whilst the patterns were randomly sampled from available lists of common words in the English language. Thereby, during the experiments we pre-loaded the data into the architecture's memory, and the data was correspondingly pre-processed. Afterwards, the matching operations were initiated and their durations inserted in the results in columns "Matches" (number of matches within the corpora) and "Init + Search" (execution durations). Hence, we can observe that there is quite a need for improvement given that some operations took up to 13.87 secs, which would be critical in the edge network operations of the vSA.
An additional observation is that in many cases the FPGA actually performs worse than the ARM processor version. This can be having multiple reasons including poor implementation, the time required to load the large corpora into the belonging memory areas or the specifics of the Wu-Manber algorithm, which potentially make it unsuitable for significant acceleration. However, this observation is a clear sign that the FPGA utilization can often bring none or minimal benefits compared to the complexity it requires for implementation and debugging. Hence, even though a general acceleration is expected through FPGA, the current cases show that its utilization should be carefully considered with regard to performance and additional complexity.   The current paper presented our activities towards implementing IDS in the edge network segment. Indeed, we discussed the 40SEC IDS architecture, which can run both in a virtualized setup and in an FPGA supported mode. In that line of thought, various important aspects related to the key operations and the modeling and design of the 40SEC (firewalls/IDS) were presented, whilst in parallel the most important operational modules (e.g. pattern matching) were identified, which are also key candidates for FPGA acceleration. A set of scenarios simulating network attacks, and a testbed for rapid prototyping of security appliances in ARM and FPGA were described.

Word count
In the near future, we will compare the performance of Wu-Manber when it runs on ARM and FPGA. This step will be 2020 Fifth International Conference on Fog and Mobile Edge Computing (FMEC) followed by redesigning this algorithm to support regular expressions. Further tests using real rules from Snort will be performed. At the end, the above-mentioned statistical algorithms will be implemented, which allows us to evaluate both signature and anomaly based IDS on FPGA. We will also focus on increasing the level of acceleration, which is currently on a very generic level. Thereby, we want to identify more aspects for handling in FPGA and establishing a stable process from the high level design down to the hardware deployment of the required IDS/IPS/firewall mechanisms.
ACKNOWLEDGMENT This work has been undertaken in the context of the European H2020 project FORTIKA [25], Grant agreement no 740690).