GLoP: Enabling Massively Parallel Incident Response Through GPU Log Processing

TL;DR

GLoP leverages GPU parallel processing to significantly enhance the speed and scalability of large-scale log analysis for cybersecurity incident response, outperforming traditional CPU methods.

Contribution

The paper introduces GLoP, a GPU-based log processing library that enables massively parallel analysis, including deep packet inspection, for faster cybersecurity incident detection.

Findings

Achieves 20Gbps throughput in log processing

Demonstrates GPU-based processing outperforms CPU counterparts

Supports single and multi-GPU configurations for scalable analysis

Abstract

Large industrial systems that combine services and applications, have become targets for cyber criminals and are challenging from the security, monitoring and auditing perspectives. Security log analysis is a key step for uncovering anomalies, detecting intrusion, and enabling incident response. The constant increase of link speeds, threats and users, produce large volumes of log data and become increasingly difficult to analyse on a Central Processing Unit (CPU). This paper presents a massively parallel Graphics Processing Unit (GPU) LOg Processing (GLoP) library and can also be used for Deep Packet Inspection (DPI), using a prefix matching technique, harvesting the full power of off-the-shelf technologies. GLoP implements two different algorithm using different GPU memory and is compared against CPU counterpart implementations. The library can be used for processing nodes with single or multiple GPUs as well as GPU cloud farms. The results show throughput of 20Gbps and demonstrate that modern GPUs can be utilised to increase the operational speed of large scale log processing scenarios, saving precious time before and after an intrusion has occurred.

Figures

Equations

$$\frac{8\ast N}{Tim{e}_{gpu}}=Throughput$$

Full text

Information flow controls]

1 Introduction

Incident Response and threat detection play a key role in industrial system security. With the increased dependence of users on information gathering, e-commerce, social networking, and the Internet of Things (IoT), the amount of data to analyse before and after an intrusion has grown exponentially. This large data volume, in combination with the expanding number of malicious exploits from attackers, make it challenging for system administrators and incident response teams to analyse the logs. Existing frameworks and tools utilise modern search algorithms, however, most of these run sequentially on CPUs.

Research in malware detection [1], [2], Intrusion Detection Systems (IDS) [3], [4], and pattern matching [5], [6] demonstrate significant speed increases utilising parallelised hardware architectures such as Field Programmable Gate Arrays (FPGA) and Graphical Processing Units (GPU). These approaches effectively scale processing vertically and maximise speed from a single device. Cloud based research [7], [8], attempts to parallelise log-processing horizontally, by distributing workload to multiple nodes with services such as the Amazon EC2, GPU G2 instances. These two approaches, are by no means competing but rather complementary. Combining GPU processing in the cloud has the potential of massive speed increases.

This paper addresses the analysis of large scale log processing in a fast and cost-effective fashion using a single off-the-shelf GPU. The performance increase is not limited to a single GPU and can be utilised to enhance both multi-GPU nodes as well as GPU Cloud farms.

The typical use case scenario of the library is illustrated in Figure 1. Network equipment record events using the syslog protocol [9] on a server. The incident response team would periodically push the syslog traces for the last period, to a GPU processing server along with rules describing malicious activity. The GPU server will search through the logs and identify patterns that match any of the malicious rules generating alerts containing the number of suspected malicious activities and their location in the logs.

The contributions of the paper are threefold. It proposes and implements a generic log processing library, called GLoP (GPU Log Processing). The library utilises the single-pattern matching algorithm Knut-Morris-Pratt (KMP) and the multi-pattern algorithm of Failureless Tries. Both algorithms are implemented for CPU and GPU and the performance of the implementations is quantified, for various number of search patterns. The library truncates the patterns to 8 characters reducing thread divergance and memory requirments on the GPU; a technique known as prefix or partial matching. Finally, GLoP contains two GPU implementations of Parallel Failureless Aho-Corasick algorithm that use global or texture memory. It is shown, that the implementation using the texture memory achieves double throughput compared to the implementation that uses global memory.

The remainder of this paper is organised as follows: Section 2 presents the related work, Section 3 introduces the GPU architecture and programming model. Sections 4 and 5 describe the Aho-Corasick algorithm and optimisation for its implementation in GLoP. The experimental environment and methodology are presented in Section 6. Section 7 describes and discusses the results obtained from multiple algorithm variants within GLoP. Finally, Section 8 presents the conclusions and future work.

2 Related Work

Large scale log processing research has extensively studied the use of large scale data mining and big data scenarios using distributed frameworks analysis. Shu et al. have proposed a lightweight framework based on the Amazon Cloud Environment (EC2 and S3), using multiple nodes to speed up the log analysis processing, and harvesting the results using a map reduce implementation [7]. Yang et al. demonstrated that by using Hadoop MapReduce, it was possible to decrease the processing time of log files by 89% for intrusion detection purposes [8]. Marty et al. proposed a theoretical logging framework dedicated to cloud infrastructures and software as a service (SaaS) running on a third party public cloud service [10].

Cheng et al. described a fast filter virus detection engine running on GPUs based on eigenvalues with good performances [1]. Our previous work [11] has shown that a massively parallel pattern matching algorithm based on the Knuth-Morris-Pratt algorithm [12] can achieve a 29 fold increase in processing speed over CPU counterparts. From the output of these works, it is clear that the processing capabilities of off-the-shelf hardware have a great potential not only to increase the speed on a single stand-alone processing server but also on GPU cloud deployments [13].

String searching algorithms can be classified to single-pattern and multi-pattern matching. Single pattern matching algorithms search the complete string for a single pattern sequentially. The naive approach to search for a single pattern is to iteratively walk through the text string and every time there is a mismatch or a complete match, the algorithm rewinds back. Optimised algorithms such as the Knuth-Morris-Pratt (KMP) and Boyer-Moore (BM) avoid rewinding by introducing failure and backtracking tables respectively [14].

On the other hand multi-pattern matching algorithms search simultaneously for multiple patterns in the text string. The most common multi-pattern algorithm is the Aho-Corasick (AC) [15], [16] which has been implemented in a variety of hardware architectures such as FPGAs [4][17] and GPUs [18].

For cases where the cross-correlation between pattern prefixes is low, a two staged searching approach can be utilised to improve parsing speeds. In these scenarios, the patterns are truncated to create a set of prefixes. The first searching stage filters the text locations where the prefixes match. Subsequently the identified locations are passed to a secondary process where the patterns beyond the prefix are searched. This completes the searching for the full pattern. Such techniques are known as prefix or partial pattern matching [19, 20]. In this work, only the first searching stage is considered as the prefix cross-correlation is low and patterns share the same prefix for 0.0001% of the time [21]. Therefore the additional overhead to complete the full pattern search is negligible.

3 CUDA Programming Model

The Compute Unified Device Architecture (CUDA) framework offers the possibility to researchers to use GPUs for General Purpose Graphics Processing. The framework allows researchers to access hardware features using an extension of the C99/C++ language from the host.

The present implementation of the library is implemented for the Tesla graphics card. The device consists of different multiprocessors each one of them containing streaming processors (SP). Each SP executing thousands of threads. Threads running on the GPU are organised in thread blocks. Within each block, the threads are organised in warps, each warp contains the same number of threads (32 for the Tesla K20 GPU). Each wrap executes in a Single Instruction Multiple Thread (SIMT) fashion and the multiprocessor periodically switches between warps maximising the resources, and hiding latencies [22].

The GPU contains different types of memory, Global, Texture, Constant, Shared which need to be managed explicitly at compilation time, by the programmer. The global memory is the largest memory on the device, and requires the more clock cycles to be accessed. The texture and constant memories are cached, and require less clock cycles to be accessed. Finally the shared memory is shared between threads within a block and requires even fewer clock cycles but is a very scarce resource [23].

4 Aho-Corasick

The AC algorithm is a multi-pattern matching algorithm and is able to identify multiple patterns in the text string on a single pass. The AC algorithm consists of two phases: the first phase constructs a state machine from a set of patterns, while the second phase searches for the patterns in the text.

A typical state machine diagram constructed during the first phase of the algorithm is shown in Figure 2. The state machine shown, consists of two patterns $P$ = $\{HIS,SHE\}$. The straight arrows represent the “regular” transitions which occur when the text is matching, while the dashed arrows represent the “failure” transitions, when a mismatch occurs but the prefix of another pattern is matched. This allows single threaded implementation of the AC algorithm to avoid rewinding and back-track matches of multiple patterns on a single pass.

For example, for the text $T=``SHIS^{\prime\prime}$ and the state machine of Figure 2, the algorithm will start with two consecutive regular transitions from the initial state $to$S$and from$S$to$H$when comparing the first two characters of the text$T$. On the third comparison, the character$I$from the text string$T$does not result to a regular transition and consequently the failure transition is activated followed by a regular transition from$H$to$I$. Finally, for the last comparison results to a regular transition from$I$to$S$.

The most common modification to adopt the AC algorithm in a multi-threaded environment is to split the text $T$ in multiple chunks and assign one chunk per thread. However, this creates problems when the text contains patterns across two chunks. For example, when the state machine of Figure 2 is considered, for the text string shown in Figure 3, it is clear that the character sequence $``HIS\textrm{'}\textrm{'}$ exists on the boundary between the chunks assigned to Thread 0 and Thread 1 and neither of these threads will match it. That can be avoided if the text string is split in chunks that overlap each other by at least the length of the longest pattern minus 1. The implication of the minimum chunk overlap is that it limits the number of chunks especially for scenarios where the maximum pattern length is long. Consequently the number of threads used to process the input text are also limited and this could become a bottleneck considering the massive number of threads that can be launched in the GPU (tens of thousands) [24].

Another drawback of the AC algorithm in a multi-threaded environment is that the failure links create thread divergence. Thread divergence occurs when threads of the same wrap branch to different sections of the code. As described in Section 3, the GPU executes the wraps in a Single Instruction Multiple Thread manner and the GPU scheduler will allocate an execution slice to every branch. Threads on the same branch execute concurrently, while all the threads on a different branch are waiting for an execution slice. The scheduling within the wrap occurs in a Round Robin fashion. Thread divergence does not only consume more execution slices, but also increases memory access time as each branch makes memory transfers at different execution slices making access non-coalesced.

5 Parallel Failureless Trie and

Prefix Matching

An alternative method to parallelise the AC algorithm that avoids the problem of patterns splitting over boundaries and reduces thread divergence is the Parallel Failureless Aho-Corasick (PFAC) [25]. With this method, “failure” transitions are removed from the state machine and one thread is instantiated for every character in the text string as shown in Figure 5. In the case of a match, the current thread will overlap the succeeding thread, allowing the state machine to change state. In the case of a mismatch, the current thread will terminate, releasing the resources and reducing divergence.

The failureless trie mechanism exploits effectively the large number of threads that are available in massively parallelised off-the-shelve GPU devices, however further optimisation can be achieved.

Observe that the first memory transfer of text string to the threads occurs in a coalesced manner. Subsequently, each thread will transition to separate branches of the trie, leading to non-coalesced memory access and thread divergence. As the algorithm progresses deeper in the trie more threads will terminate due to mismatches leaving only a small number of threads continuing to match while the bulk of the threads terminate. This reduces the throughput significantly and can be avoided if the trie is truncated and all the threads terminate beyond a certain trie depth. The approach of truncating the trie is known as prefix or partial pattern matching [26, 21] and assumes that a secondary process takes over to complete the search; for example a CPU thread is lunched to complete the search.

In practise this approach is effective as the prefix length of a malicious activity pattern has a low probability being a false positive (i.e. the prefix exist in the text followed by a suffix that does not match that pattern). Vasiliadis et al. [21] has shown that a prefix length of 8 is adequate to achieve a false positive rate below 0.0001%. In this work this has been verified independently.

The prefix matching does not only reduce divergence, but also reduces memory footprint due to the reduced number of states in the trie. Memory reduction in itself may not be of significant benefit, but when texture memory is used the caching hit rate is increases leading to significantly reduced memory access times.

6 Experimental Environment

GLoP was implemented on a Nvidia Tesla K20m graphic card. The card consists of a single Printed Circuit Board (PCB), composed of 192 CUDA Cores distributed over 19 multiprocessors. The card is also composed 5 GB of global memory,and permits up to 26,624 active threads.

The base systems, is supplied with two Intel Xeon E5-2620 six core CPUs running at 2.0 GHz. The rig has a total of 64 GB ram. The server is running Ubuntu Server 11.10 (kernel version 3.0.0-12-server). The algorithm has been compiled with the optimisation brought by the latest version of CUDA 6.0, using C99.

The GLoP library is executed using unified memory, allowing the users to access variables stored in global memory from the CPU and the GPU at any given time, and to facilitate the execution of streamed kernels. Each stream sends logs to GPU to be analysed, and matched against the failureless trie. During the launch of a kernel, the CPU is free to stream the next batch of logs to the GPU.

Two implementations of the algorithm are evaluated using global and texture memory. For the texture memory versions, the trie must be represented in memory using int types which are subsequently matched to ASCII values (e.g. “A”=65). The texture memory allows transactions to be cached, requiring fewer clock cycles to complete transfers compared to global memory accesses. The caching procedure is illustrated in Figure 4 where CUDA Cores (within a Streaming Multiprocessor) have access to texture memory via the cache, potentially speeding up significantly memory access.

During the evaluation, the algorithm is run 100 times and the results presented are the average of the total runs. This allows to mitigate the sources of jitter; such as background processes running competing for resources available. The patterns searched are also generated randomly against each log files.

The log files used during the trials have been automatically generated, using the Mersenne Twister (MT) uniform pseudo-random number generator [27]. Each synthetic log has an exact file size of 100 MB, and its uniqueness is ensured by computing the SHA256 hash.

In all comparison the throughput is calculated as follows:

• •

Let $N$ be the size of the log data sent to the GPU.

• •

Let $Time_{gpu}$ be the time elapsed during with the algorithm is running.

[TABLE]

7 Evaluation

GLoP implements the multi-pattern failureless trie algorithm using global and texture memory as well as the single pattern algorithm Knuth-Morris-Pratt for comparison purposes. The KMP algorithm performance on CPU and GPU for varying number of patterns is shown in Figure 6. As the number of pattern increase, the throughput decreases linearly as the algorithm performs a single pattern search at time. The single threaded CPU version of the KMP algorithm achieves throughput of 50 Mbps when matching a log file of 5 MB against 10 patterns. On the CPU, the throughput is 10 times less when matching the same log file against 100 patterns. Despite the fact that the GPU version of the algorithm achieves throughput nearly 2,000 Mbps when 10 patterns at searched while the throughput decrease linearly to 15 Mbps for 1,000 patterns.

The KMP algorithm does not have sufficient throughput to cope with large scale log analysis, even with the boosted performance on the GPU. Its main shortcoming is that the single pattern searching does not scale well for multiple patterns. GLoP shows that the multi-pattern algorithms such as the failureless trie are able to maintain a constant throughput independent of the number of patterns. This is demonstrated on Figure 7 where the performance of the Parallel Failureless Aho-Corasick algorithm is shown to sustain throughput for both the CPU and GPU. The performance of the failureless trie algorithm on the GPU when global memory is used is 11 Gbps for the 10 patterns and 100 MB file, while the corresponding CPU version achieves throughput of 1.7 Mbps.

Implementation of the failureless trie can be further improved when texture memory is used. The operation of the algorithm in this case is identical with the only different being that the state transition table being stored in texture memory. The performance comparison between the two algorithm using the global and texture memory respectively is shown in Figure 8. The texture implementation is shown to achieve double the throughput and this can be attributed to the caching capabilities which significantly reduce the cycles required to retrieve data from memory. The global memory implementation culminates at 11 Gbps for a 100 MB log file whereas the texture implementation reaches an overall throughput of 20 Gbps.

8 Conclusion and Future Work

This paper presented GLoP, a massively parallel incident response engine offloading the large scale log processing, and pattern matching to the GPU allowing the CPU to concentrate on other tasks.

In this work GLoP has been evaluated against the single pattern matching algorithm Knuth-Morris-Pratt, and has demonstrated a throughput of 11 Gbps with the failure-less global memory implementation and an overall throughput of 20 Gbps for the failure-less texture memory implementation. Various synthetic log files have been used proving its efficacy, and in particular its ability to considerably speed up incident response processes, while remaining cost-effective. This work also highlighted the high performances demonstrated by the engine, as a single node, but also its possible and complementary use to cloud based log processing frameworks, such as Hadoop, to increase the processing power.

In future work, it is planned to reduce the memory footprint of the failure-less trie when using larger state machines, and improve the library by using Message Passing Interface (MPI) technique to allow the library to run on an HPC as well as investigating real-time operations.

Acknowledgment

The authors would like to thank Agilent Technologies for their insightful comments and feedback as well as their support.