# A Hierarchical Security Event Correlation Model for Real-Time Threat Detection and Response
## 3 Experiments and Results
### Results and Discussion  
The correlation model developed in this paper firstly aggregates all events into an aggregated events set. The aggregated events are then correlated with different levels of variations forming clusters according to mining rules. The results show that in most cases the shared correlations reduced the data set by smaller percentages, as can be noted by the difference between the number of events and clusters. This is unsurprising because in this data set the flows from the csv data are already aggregated at 1-min intervals. There are no observed VC1 clusters. VC1 would be formed if two flows only differed by the protocol type, for example, if a host sends a packet to port 53 (DNS) using both TCP and UDP. On the other hand, there are VC3 correlations on all flows. Our analysis of the clusters revealed that these contained either traffic to popular and public services such as DNS and HTTP, or scanning attacks. Table 7 summarizes the results of the first ten time slots of the correlation. The minimum support was chosen to be one for this experiment. This was done so that probe attacks were captured, as most probes would not correlate at higher levels of support. The distribution of the correlations is plotted in the pie chart in Figure 8. The pie chart shows that the majority of the traffic was for shared correlations (SC). Benign traffic is expected to exhibit this correlation behavior. Inspecting the cluster distribution allows for visual analytics. This becomes important for analytics applications such as intrusion detection systems as analysts can use the visual clues to perform further detailed investigations into suspicious clusters. Different analytics can be performed on the clusters to uncover interesting patterns of communications contained within the data set. \begin{table}
\begin{tabular}{c c c c} \hline \hline  & **Function** & **Hardware** & **Virtual Machines** \\ \hline \multirow{4}{*}{Client machine} & \multirow{4}{*}{Data collector} & Lenovo IdeaPad S340 & \multirow{4}{*}{None} \\  & & Intel i7 4 Core Processor 8 GB RAM & & \\  & & Windows 10 Pro & & \\ \hline \multirow{4}{*}{Server} & \multirow{4}{*}{Cloud server} & DELL & \multirow{4}{*}{
\begin{tabular}{} \end{tabular} } \\  & & AMD Ryzen 7 PRO 3700 & & \\ \cline{1-1}  & & 64 GB RAM & & \\ \cline{1-1}  & & Ubuntu 22.04 & & \\ \hline \hline \end{tabular}
\end{table} 
Table 6: Platform configuration for the experiment. \begin{table}
\begin{tabular}{c c c c c c c c} \hline \hline
**Time\_Slot** & **Events** & **AES** & **VC1** & **VC2** & **VC3** & **VC4** & **Meta\_Events** & **Graphs** \\ \hline
0 & 258 & 228 & 0 & 0 & 25 & 11 & 82 & 31 \\
1 & 1258 & 1156 & 0 & 0 & 64 & 3 & 206 & 78 \\
2 & 1558 & 1432 & 0 & 0 & 104 & 6 & 314 & 155 \\
3 & 1362 &  
_Ghysper_ interconnects all clusters with the same source and destination IP address pairs. From the clusters described in Table 7, the output of the _Ghysper_ correlation is shown in Figure 9 for time slot 1. Each cluster in the _Gyhper_ graph represents a correlation of all VCx metaevents between source and destination communication pairs within the measurement time window. Zooming into each cluster shows the individual metaevents (VCx) that make up the cluster. In the graph shown, the blue clusters are the shared correlations. The orange and black clusters are VC3 and VC4, respectively. It can be seen from the graph that there are very few VC4 clusters in the data set. VC4 are clusters where the flows have nothing in common except source and destination IP addresses. To investigate the flow of communication between the pairs, the Gflow analytic was used. Gflow shows the communications paths in the data set from each source to various destinations. The graph in Figure 10 shows Gflow for the data in time slot 1. Figure 8: Distribution of clusters in the data set. Figure 9: _Ghysper_. The nodes in Gflow represent different communicating sources, identified by their source IP addresses.