A real-time GPU-based approach for alert aggregation

Abstract

Alert correlation is an approach to analyze a huge number of security alerts received from network sensors. An alert correlation engine normalizes, fuses and clusters incoming alerts; then identifies relationships among them. Limitation of computing resources, like CPUs, makes such systems not satisfactory. In recent years, GPUs have been used in various fields, however, due to the dynamic nature of processes and data structures in alert correlation, correlation algorithms have not been implemented on the GPU. This paper presents a novel approach to implement alert correlation on the GPU. It focuses on alert aggregation, which is classified as a similarity-based alert correlation. This approach presents an online cooperative model which utilizes the processing power of CPUs and GPUs to aggregate security alert. This paper also presents the development of a toolkit named GTA2, which works as an assistant tool with Snort and provides online alert aggregation on alerts received. GTA2 takes advantage of unused processing power of existing GPU to aggregate security alerts generated by Snort. Evaluations illustrate the proposed method will improve the processing speed by 15 times.

Keywords

Alert aggregation security alert Graphics Processing Unit (GPU)snort real-time cooperative model

1 Introduction

Alert correlation analysis is one of the core functions of security operations center, which can avoid false and duplicate reports, contribute to find some potential threats and improve the efficiency and security of the network [27]. Similarity-based algorithms are the subcategory of correlation algorithms which are widely used and utilize similarity metrics to correlate alerts. Techniques used in this subcategory are classified as filtering and aggregation. Filtering technique performs a fixed task on each alert and makes a decision according to the acquired result. Alert verification and prioritization are in this class. The goal of aggregation technique is fusing or clustering incoming alerts in order to facilitate decision making. This technique utilizes similarity metrics and puts similar alerts into one category.

The performance of correlation system should be such that it can do real-time processing on incoming alerts. The algorithms that use aggregation techniques require a lot of computing resources and this restriction is as a bottleneck in correlation systems [1]. The time complexity of aggregation algorithms in the worse-case is $O (r^{2})$ in which r is the rate of input alerts. Lack of resources makes the system to process a less number of alerts or reduces the accuracy of the aggregation algorithms.

Graphics processors have been developed very rapidly in recent years. With each new generation, additional features are introduced that move the GPUs one step closer to wider use in general purpose computations [25]. The use of a GPU beside a CPU to perform general-purpose computations is known as General Purpose computing on Graphics Processing Units (GPGPU). To facilitate GPGPUs, an extension to C language called Compute Unified Device Architecture (CUDA) was introduced in 2007 [8]. Since then, programming with GPUs for general applications becomes much broader as it is easier than before.

Much research has been done on GPU to improve the performance of variant algorithms in other fields, such as image processing, cryptography, pattern matching and etc. There are contributions to implement filter-based algorithms like traffic classification and pattern matching on the GPU. However, due to the dynamic nature of process and data in aggregation, there are not any efforts to implement aggregation-based algorithms on the GPU.

This paper presents an architecture and a model for online CPU–GPU cooperative aggregation that can integrate the computing power of CPU and GPU to perform aggregation on alerts more efficiently and presents a real-time engine. In this model, we have used methods that reduce the negative impact of restrictions caused by irregularities of correlation algorithms.

The rest of this paper is organized as follows: First, a brief discussion of related work about correlation and the GPU is given in Section 2. Section 3 describes the serial aggregation algorithm and time complexity of aggregation algorithms in the serial manner. In Section 4, GPU-based parallel aggregation algorithm is presented and Section 5 describes proposed model. In Section 6, a GPU-based toolkit for alert aggregation is presented. Section 7 discusses experimental results and finally, Section 8 draws conclusions and outlines future works.

2 Related work

Over the past few years, much research has been done in the field of alert correlation. Most of these studies, especially those that were initially proposed, have focused on improving the effectiveness of correlation. In these studies, researchers have attempted to provide ways to correlate more alerts in order to improve reduction rate, to recognize more false positive alerts and to detect scenario of attacks accurately.

Most of solutions which have been proposed in correlation, are offline approaches run periodically on alerts. In addition, online solutions are only able to process alerts slowly [20]. Studies presented in [3,9,16,22,24,26] concern a number of offline cases that are seeking solutions to reduce both false positive alerts and final alerts reported. However, there are studies that have made efforts to improve the performance and speed of correlation algorithms.

In 2006, Valeur [23] improved performance of his correlation architecture, which was presented initially in 2004. In addition, in 2010, the researchers [19] proposed an agent-based approach to Valeur correlation system. In [15], in addition to present a method for fast access to required data, researchers provided a platform for clustering correlation processes. In this research, by using storage techniques and an extensible platform, researchers improved alert processing performance. In [1], researcher implies to limitations of correlation systems in terms of performance and proposes to pre-filter the generated alerts at the source (i.e. intrusion detection systems). It can reduce the amount of the alerts that received by correlation system.

In the aforementioned studies, in order to increase the speed and quality of the correlation algorithms, researchers have focused on the algorithm itself as well as on software issues. Software approaches can improve performance of correlation; however, they are limited in improvement. None of the studies that have been mentioned above tries to use other processing platform’s capabilities.

The GPU has had significant success in the field of graphics processing, and over the past five years, researchers have made many efforts to use it in the other areas.

There are some efforts in which use the GPU to improve the performance of security algorithms, such as [4,6,10,14,17]. In [4,6] and [14], researchers are seeking to implement the matching algorithm on the GPU. In the matching engine, which is used in intrusion detection system, incoming data are compared with predefined and fixed patterns, and then, according to the result of matching, it decides about incoming data. In [2,5,12,18], researchers are seeking to implement classification algorithms on the GPU. For example, in [5], researchers implemented BitMap-RFC and BPF algorithms in parallel manner on GPU and could achieve up to 13 times improvement in performance. Pattern matching and traffic classification are filter-based algorithms that can match incoming alerts with fixed parameters.

For the first time, in [11] we implemented a prototype of aggregation engine and showed GPUs can improve the speed of correlation algorithms. This study is the base for us in this paper. In previous contribution, we implemented a light engine of aggregation which processes on incoming alerts one after another.

3 Aggregation algorithm

As mentioned above, alert aggregation is a class of alert correlation that uses similarity metrics and includes fusion, session reconstruction, thread reconstruction, focus recognition and multi-step correlation algorithms [23]. Keeping a sliding time window is the main feature of these algorithms. A sliding time window keeps incoming alerts in an alert queue, in order to process them later. An aggregation-based algorithm has three different phases: reconstruction, matching and merging/adding.

In the reconstruction phase, the alerts that have exceeded the time window will be removed from the alert queue and will be sent to next correlation component. The matching phase compares the incoming alert with those in time window and sends results to the merging/adding phase. In the merging/adding phase, if the incoming alert belongs to the queue – i.e. similarity criteria are satisfied –, the selected alert from the queue and incoming alert will be aggregated as an hyper-alert; otherwise, the incoming alert will be added to the end of the alert queue.

The matching operation in aggregation-based algorithms, such as filter-based algorithms, consists of two elements: incoming data and matching parameters. Incoming data is a dynamic element in both aggregation and filtering techniques, i.e. in each time the incoming data is different from previous data. In filtering technique, matching parameters are constant values, including the rules in classification algorithms and the patterns in pattern matching algorithms; but as of aggregation technique, these parameters are dynamic values, including the alerts in the time window. To sum up, due to this difference, unlike filter-based algorithms, aggregation-based algorithms have not been implemented on GPUs.

3.1 Time complexity

When a new alert arrives, the serial algorithm compares it with all alerts in the queue, starting with the first one and moves towards the end of the queue. Since alerts in queue are not sorted by time stamp and it is possible to match more than one alert, the operation must continue to the end of the queue. If no match is found, the alert will be inserted into the queue, to be considered for matching with future alerts.

If the rate of incoming alerts was r and the size of time window was $window_size$ second, the time window has $r \times window_size$ alerts and the system has to operate on $r \times r \times window_size$ alerts per second in the worse-case. Assuming a constant value of $window_size$ , the time complexity is $O (r^{2})$ , while the time complexity in filter-based algorithms is $O (r)$ . With this time complexity, correlation system cannot process alerts at a high rate [23]. Therefore, in these conditions, the system is forced either to reduce the accuracy of the algorithm or to remove alerts exceed input buffer. Reducing the accuracy of the algorithm can be accomplished through reducing the window size.

To conclude, this decreases the quality of the resulting output. Table 1, which is derived from [23], shows the difference between the filter-based and aggregation-based components in term of processing time. The shaded columns show processing time of aggregation-based components and other ones show processing time of filter-based components.

Table 1
Processing time per component (ms/alert)

4 Parallel algorithm

The programming model of GPU is characterized as simultaneous multithreading (SIMT) and presents some relevance with the SIMD category of parallel programming models on vector processors [7]. This feature helps us to remove comparing loop in the serial algorithm.

The operations in correlation engine that have the potential of parallel processing are:

Identifying alerts that have exceeded the time window and sending them to the next step.

Matching incoming alert with alerts in the queue.

Each thread in the GPU is responsible for processing one alert in the alert queue. Once the host (CPU) receives a new alert, after the pre-processing, correlation system transfers control to the device (GPU) and then, the GPU threads simultaneously compare new incoming alert with the alerts that they are responsible for. As a result, time complexity will decrease to $O (r)$ .

The dynamic nature of correlation algorithm causes challenges for parallelism, such as data process dependency and overhead of parallel operation calls. In the former case, the results of processing alert are not totally independent of each other. Thus, while alerts are processed simultaneously, at some stages they have to wait for other results to be processed. In the proposed model, to deal with this problem, the correlation operation was divided into several steps, which transform data dependency into step dependency. At each step, threads perform their operation independently, but the start of each step depends on the previous step.

In the latter case, the revocation of parallel operation has an overhead on the system, thus when many alerts arrive, the overhead of the system increases. In order to solve this problem, three solutions have been presented:

Using a cooperative model in which the efficient platform processes alerts instantaneously. When the size of the alert queue is smaller than a threshold ( $t_{0}$ ), the overhead of revoking parallel operation assigned to an alert is too much. In this case, the performance of the host is better than the ones of the device. When the alert queue size exceeds the $t_{0}$ , the performance of the device will be better than the host performance. Therefore, it is necessary to switch between CPU and GPU when needed.

Sending a block of alerts to the correlation engine instead of one alert. If the incoming alerts are sent to correlation engine as a block, the overhead of revoking parallel operations will be divided among alerts that are within the block and as a result, the overall overhead decreases. The correlation engine in GPU receives the block of alerts and performs correlation process on each alert of the block. In addition, alerts in the block can be processed in parallel by some steps. The following section will explain about detection of best value for the block size.

Executing some parallel operations periodically. The revocation of some parallel operations has overhead and can be executed in certain periods. This idea reduces overall overhead of the system.

Figure 1 shows the architecture of presented model. This figure illustrates the cooperation between a GPU and a CPU. In each component, the module R denotes Reconstruction phase, the module M denotes matching phase and the module M/A denotes merging/adding phase. Each arrow denotes a processing thread that is responsible for a certain task. The numbers next to the arrows indicate the time complexity of each module in an algorithm revoking. For the modules M and R in Parallel Aggregation Component, n threads will be run on the alert queue. It means each thread is responsible for one element of the alert queue; as a result, the number of running threads is n (alert queue size). For the module M/A, m threads will be run on the alert block and each thread is responsible for one element of the alert block array. As a result, time order of the modules R and M decline to m from $n \times m$ and time order of module M/A decline to 1 from m.

Fig. 1.

The architecture of presented model.

5 Cooperative model

With the arrival of a new alert, the host will pre-process it and puts it on an alert block. In pre-processing operation, the host aggregates incoming alert; indeed, in this step, the alert block is considered as a small instance of the alert queue and the operation performed on the alert block is considered as a primary correlation operation. When the alert block is full, it will sent to main correlation engine and according to predefined thresholds, the host or the device processes the alerts that are in the alert block. When the device is responsible for the alert block, the host creates a kernel code – a code executed on device – and transfers control to the device. When the code is completely executed, control returns to the host.

When the queue size is close to $t_{0}$ , it is likely that control continuously changes between the host and the device. Since control switching between the host and the device imposes overhead on the system, it can reduce overall performance. As shown in Fig. 2, to address this problem, two thresholds ( $t_{1}$ and $t_{2}$ ) were defined such that: $\{\begin{matrix} t_{1} < t_{0} < t_{2}, \\ t_{0} \approx \frac{(t_{1} + t_{2})}{2} . \end{matrix}$

If the queue size is smaller than $t_{1}$ , the CPU will be responsible for processing, and if the queue size is greater than $t_{2}$ , the GPU will be responsible for processing. The range of $[t_{1}, t_{2}]$ is named “stable area”. In this area the processing state will be maintained; i.e. when the alert queue size reaches to stable area, if the CPU is responsible for processing, it will continue to process alert.

Fig. 2.

The model of cooperative alert aggregation.

The flowchart presented in Fig. 2 has two main components: CPU Processing Component (CPC) and GPU Processing Component (GPC). The CPC is a component with serial processing algorithm and the GPC is a component with parallel processing algorithm. Figure 3 shows the flowchart of CPC, which has been described in Section 3.

Fig. 3.

CPU Processing Component flowchart.

Figure 4 shows the GPC in details. As discussed in Section 4, the kernel code must be divided into three parts. But there are no peer-to-peer mapping between three phases of the aggregation algorithm and three parts of the kernel code.

Fig. 4.

GPU Processing Component flowchart.

In order to map aggregation phases into kernel code parts, the aggregation phases were divided to sub-phases and each sub-phases were mapped into a kernel code (Table 2).

Table 2

Mapping aggregation phases to kernel parts

Phases	Sub-phase ID	Sub-phase task	Kernels
Reconstruction phase	RP-1	Identifying alerts exceed the time window, sending them to the next step, and marking them as Inoperative Alerts.	Kernel 2
Reconstruction phase	RP-2	Removing Inoperative Alerts from the alert queue, and reconstructing it.	Kernel 1

Matching phase	MP-1	Identifying alerts that match with the incoming alert, and marking them as a candidate.	Kernel 2
Matching phase	MP-2	Selecting one alert from the candidate alerts.	Kernel 3

Merging/adding phase	AP-1	Merging the incoming alert with the candidate alert.	Kernel 3
Merging/adding phase	AP-2	Adding the incoming alert at the end of the queue.	Kernel 3

The kernel 1 uses Thrust library [13], which executes serial function by GPU’s threads. Thrust is a CUDA library of parallel algorithms which provides many fundamental programming logic like sorting, prefix-sums, reductions, transformations. Since the revoking of a function of Thrust library causes overhead to the system, the kernel 1 is periodically executed under predefined conditions. These conditions are: $\{\begin{matrix} the alert queue size ⩽ 2 * Inoperative Alerts count, \\ the alert queue size - Inoperative Alerts count ⩽ t_{1} . \end{matrix}$

The pseudo code (see Fig. 5) shows the kernel functions of the proposed model.

Fig. 5.

Pseudo code.

6 Implementation

In order to test the presented approach, a toolkit were developed, called GTA2 (GPU-based Toolkit for Alert Aggregation). GTA2 works together with Snort and processes the alerts generated by such software. Figure 6 gives a graphical representation of GTA2 operations along with Snort. As shown in this figure, when Snort sends an alert out, GTA2 receives that alert and after the aggregation process, sends result to Syslog.

Fig. 6.

The architecture of GTA2.

7 Experimental results

In this evaluation, the performance of alert processing is calculated with respect to serial, parallel and mixed modes. The experiments were executed locally on an Intel CPU with a 2.93 GHz clock speed and on the NVIDIA GTX 580 GPU with 512 cores. The operating system used is Ubuntu 11.10 and the programming toolkit is CUDA 5.0. In all scenarios of this experiment, the argument of “block_size”, which shows the number of threads per block, for kernel 2 and kernel 3 is 512. Also the number of blocks per kernel for kernel 2 is calculated as follows: $blocks_per_kernel_2 = alert_queue_size / block_size .$

And the number of blocks per kernel for kernel 3 is calculated as follows: $blocks_per_kernel_3 = alert_block_size / block_size .$

Since the goal of this study is to improve the performance of correlation system, it is important to have a great number of alerts that cover all possible states for processing. So, we used three different datasets, including similar alerts, dissimilar alerts and real alerts. The first two datasets consist of 600,000 alerts and the other one consists of 200,000 alerts. In the first case, the incoming alerts always merge with an alert or hyper-alert in the queue. In the second case, the incoming alerts do not merge with any alerts in the alert queue; instead, they are added at the end of the queue. The real alert dataset is collected by DefCon 9 [21] which simulates a real condition.

For each alert type, two scenarios are considered:

Scenario with the block size of one.

Scenario with the best value for block size.

As a result, six evaluation scenario were developed (Table 3).

As shown in Table 3, for Scenarios 5 and 6, the time window size is variable and for the others, the queue size is variable. If the queue size is used as a variable parameter, the time window will be disabled; i.e. the size of it is considered as maximum value as possible. With these scenarios, we can evaluate all states of processing.

Table 3
Experimental scenarios

Case	Scenario	Alert type	Alert block size	Queue size	Time window state
1	1	Similar	1	Variable	Disable
1	2	Similar	Best value	Variable	Disable

2	3	Dissimilar	1	Variable	Disable
2	4	Dissimilar	Best value	Variable	Disable

3	5	Real	1	Unknown	Variable
3	6	Real	Best value	Unknown	Variable

In order to acquire best value for the alert block size, an experiment was implemented. In this experiment, six timers were utilized to measure processing time of every component of parallel operation. The experiment was repeated for the real alert dataset with the block size of 1 to 23,750. The best alert queue size is achieved when the total time of processing is minimum. Results shown in Fig. 7 represent the time of one execution of parallel correlation.

The dotted curve represents the GPU processing time, the dashed curve represents the pre-processing time required by the CPU and the solid one is the sum of both. The pre-processing function, which is required for creating the alert block and performing primary correlation on it, causes a distance between tow continuous GPU processes. As shown in Fig. 7, the longer the alert block, the pre-processing time of CPU is greater. When the size of alert blocks is in the range of 50 to 1,000, the processing time of parallel operation – solid curve – will be minimum. Accurate tests show that the number of 250 is the best value for the incoming alert block.

Fig. 7.

Processing time of parallel operation with respect to different block size. (Colors are visible in the online version of the article; http://dx.doi.org/10.3233/JHS-150509.)

Figure 8 shows the result of case 1 as similar alert scenarios. Part (a) is the speed of aggregation operation of the serial algorithm with alert block size of one (CPU), the serial algorithm with alert block size of 250 (CPU250), the parallel algorithm with alert block size of one (GPU) and the parallel algorithm with alert block size of 250 (GPU250). Part (b) is improvement of CPU250, GPU and GPU250 algorithms in comparing to CPU algorithm.

Fig. 8.

Experimental results of similar alert. (a) Speed of the aggregation operation; (b) Improvement of proposed algorithms. (Colors are visible in the online version of the article; http://dx.doi.org/10.3233/JHS-150509.)

Figure 9 shows the result of case 2 as dissimilar alert scenarios and Fig. 10 shows the result of case 3 as real alert scenarios.

Fig. 9.

Experimental results of dissimilar alert. (a) Speed of the aggregation operation; (b) Improvement of proposed algorithms. (Colors are visible in the online version of the article; http://dx.doi.org/10.3233/JHS-150509.)

Fig. 10.

Experimental results of real alert. (a) Speed of the aggregation operation; (b) Improvement of proposed algorithms. (Colors are visible in the online version of the article; http://dx.doi.org/10.3233/JHS-150509.)

In evaluation cases 1 and 2, the horizontal axis are alert queue size and in evaluation case 3, the horizontal axis is the time window.

Experiments illustrate that proposed model improves the speed of aggregation algorithms. Improvement is variable with respect to the time window and the alert queue size. In real condition, if the time window is 100 s, improvement will be achieved up to 20 times and for time window 2,000 s, up to 50 times. We can illustrate the improved GPU-based approach (GPU-250) aggregate security alerts 6.5× faster than improved CPU-based approach (CPU-250) when the time window is 100 s, and 15× faster when the time window is 1,000 s. Reduced rate for time window 100 s and 2,000 s is 64.50% and 75.50%, respectively. The processing speed of mixed approach is calculated as follows: ${Speed}_{MIX} = MAX ({Speed}_{GPU}, {Speed}_{CPU}) .$

8 Conclusion and future work

This paper presented a real-time cooperative model to aggregate alerts, which increase the performance of correlation system. As a result, we developed GTA2 that use the processing power of GPUs beside CPUs for aggregating security alerts that generate by Snort. By experimentations, we can find that the model proposed is effective and is able to correlate alerts rapidly. However, there are some issues worthy of future research. In the future, we expect to improve the above model and algorithm to reach better performance and extend it to all aspects of correlation system. Also, issues such as memory bandwidth and allocation of the resource must be considered with more details in future work.

References

[1]

Bidou, Security operation center concepts and implementation, August 2005, available at: http://iv2-technologies.com/SOCConceptAndImplementation.pdf.

[2]

K.-W.

Chang,

Deka,

W.-M.W.

Hwu and

Roth, Efficient pattern-based time series classification on GPU, in: 2012 IEEE 12th International Conference on Data Mining, December 2012, 2012, pp. 131–140.

[3]

H.T.

Elshoush and

I.M.

Osman, Reducing false positives through fuzzy alert correlation in collaborative intelligent intrusion detection systems – A review, in: International Conference on Fuzzy Systems, 2010.

[4]

N.-F.

Huang,

H.-W.

Hung,

S.-H.

Lai,

Y.-M.

Chu and

W.-Y.

Tsai, A GPU-based multiple-pattern matching algorithm for network intrusion detection systems, in: 22nd International Conference on Advanced Information Networking and Applications – Workshops (AINA Workshops 2008), 2008.

[5]

Hung,

Lin,

Li,

Wang and

Guo, Efficient GPGPU-based parallel packet classification, in: 2011 IEEE 10th International Conference on Trust, Security and Privacy in Computing and Communications (TrustCom), 2011, pp. 1367–1374.

[6]

Jacob,

Ave and

Brodley, Offloading IDS computation to the GPU, in: 22nd Annual Computer Security Applications Conference, ACSAC’06, 2006, pp. 371–380.

[7]

K.I.

Karantasis,

E.D.

Polychronopoulos and

G.N.

Dimitrakopoulos, Accelerating data clustering on GPU-based clusters under shared memory abstraction, in: 2010 IEEE International Conference on Cluster Computing Workshops and Posters (CLUSTER WORKSHOPS), September 2010, 2010, pp. 1–5.

[8]

Kijsipongse,

U-ruekolan,

Ngamphiw and

Tongsima, Efficient large Pearson correlation matrix computing using hybrid MPI/CUDA, in: 2011 Eighth International Joint Conference on Computer Science and Software Engineering, May 2011, 2011, pp. 237–241.

[9]

Li,

Wang and

Roesch, Reducing false positives based on time sequence analysis, in: Fourth International Conference on Fuzzy Systems and Knowledge Discovery (FSKD), 2007, pp. 67–71.

10.

[10]

Mei,

Jiang and

Jenness, CUDA-based AES parallelization with fine-tuned GPU memory utilization, in: 2010 IEEE International Symposium on Parallel & Distributed Processing, Workshops and PhD Forum (IPDPSW), 2010, pp. 1–7.

11.

[11]

Narimani,

Nowroozi and

Mahdinia, A cooperative GPU-based approach for alert aggregation, International Journal of Computer and Information Technologies (IJOCIT) 2(2) (2014), 416–425.

12.

[12]

Nottingham, GPF: A framework for general packet classification on GPU co-processors, Master’s thesis, Rhodes University, 2012.

13.

[13]NVIDIA, CUDA C Best Practices Guide, 2010, available at: www.nvidia.com.

14.

[14]

Platos,

Kromer,

Snasel and

Abraham, Scaling IDS construction based on non-negative matrix factorization using GPU computing, in: Sixth International Conference on Information Assurance and Security Scaling, 2010, pp. 86–91.

15.

[15]

Roschke,

Cheng and

Meinel, A flexible and efficient alert correlation platform for distributed IDS, in: Fourth International Conference on Network and System Security, 2010.

16.

[16]

Roschke,

Cheng and

Meinel, A new alert correlation algorithm based on attack graph, in: Proceedings of the 4th International Conference on Computational Intelligence in Security for Information Systems (CISIS), June 2011, 2011, pp. 58–67.

17.

[17]

Smith,

Goyal,

Ormont,

Sankaralingam and

Estan, Evaluating GPUs for network packet signature matching, in: 2009 IEEE International Symposium on Performance Analysis of Systems and Software, April 2009, 2009, pp. 175–184.

18.

[18]

Sun and

Ricci, Fast and flexible: Parallel packet processing with GPUs and click, in: ACM/IEEE Symposium on Architectures for Networking and Communications Systems (ANCS), 2013.

19.

[19]

A.E.

Taha and

I.A.

Ghaffar, Agent based correlation model for intrusion detection alerts, in: 2010 IEEE International Conference on Intelligence and Security Informatics (ISI), 2010, pp. 89–94.

20.

[20]

Tedesco and

Aickelin, Real-time alert correlation with type graphs, in: Proceedings of the 4th International Conference on Information Systems Security (ICISS), 2008, pp. 173–187.

21.

[21]The Shmoo Group, DefCon, available at: http://cctf.shmoo.com.

22.

[22]

Valdes and

Skinner, Probabilistic alert correlation, in: SRI International, 2001, pp. 54–68.

23.

[23]

Valeur, Real-time intrusion detection alert correlation, PhD dissertation, University of California, Santa Barbara, 2006.

24.

[24]

Waita Njogu, Using alert cluster to reduce IDS alerts, in: 2010 3rd International Conference on Computer Science and Information Technology, July 2010, 2010.

25.

[25]

Wu,

Zhang and

Hsu, Clustering billions of data points using GPUs, in: UCHPC-MAW’09, 2009, pp. 1–5.

26.

[26]

Xiao,

Zhang,

Liu and

Gao, Alert fusion based on cluster and correlation analysis, in: 2008 International Conference on Convergence and Hybrid Information Technology, 2008, pp. 163–168.

27.

[27]

Yuan and

Zou, The security operations center based on correlation analysis, in: 2011 IEEE 3rd International Conference on Communication Software and Networks, May 2011, 2011, pp. 334–337.