You are currently viewing Processing of IDS alerts in multi-step attacks

Processing of IDS alerts in multi-step attacks

Article
Link to Science Direct

Authors: Tomáš Bajtoš, Pavol Sokol, František Kurimský

Abstract

In this information age, we notice an increase in the quality of security threats. Organizations are forced to defend themselves against attacks in several steps. To identify the individual steps of attackers, we use several security technologies, among which we can include attack detection systems. Researchers or members of security teams have to deal with a large number of security events and alerts. A tool can help with this, which allows filtering relevant alerts and combining them into larger units without significant loss of information. 

Introduction

Information and cyber security have been becoming a standard part of the lives of state and private organizations. In addition to the increase in the number of attacks, it is also possible to observe a greater sophistication of these attacks. At the same time, attacks consist of several phases, which the attacker or group of attackers must perform to achieve their result. Their sophistication can be observed mainly in the fact that security systems can overlook individual steps, but as a whole, they represent a significant risk for the organization. Attacks consisting of multiple stages are referred to as multi-step attacks. Multi-step attack can be defined as an aggregate of steps containing at least two actions taken by one or more attackers with one specific target within a network [1]. Other names for these attacks include multi-stage [2] and attack scenarios [3].
When using conventional security tools for intrusion detection, the course of multi-stage attacks remains undetected, or its detection is time-consuming. It is mainly due to the growing volume of network communication, which also increases the number of security alerts generated by security mechanisms and devices. Intrusion detection systems (IDS) are the primary tools for detecting attacks in organizations’ computer networks. These tools recognize known signatures or detect anomalies in network traffic behavior. As the volume of network traffic grows, so does the number of security alerts generated by these systems. A security alert can be defined as an event generated by the security system in response to the detection of alleged malicious activities or malfunctions [4]. A security event is “an identified occurrence of a system, service or network state indicating a possible breach of information security policy or failure of safeguards, or a previously unknown situation that may be security relevant” [5] and event is “any observable occurrence in a system or network” [6].
The problem then manifests itself in several ways. This data must be stored, accessed, and analyzed reasonably. At the same time, there is a problem with benign network communication, which, in most cases, increases the amount of data without added information. Last, security systems (e.g., SIEM) generate many security alerts that security analysts must evaluate. Rapid and adequate evaluation of network traffic and security alerts is essential to the organization’s security, especially its security teams (e.g., SOC and CSIRT teams). Based on the analysis of security alerts, it is possible to detect security incidents, analyze them and adopt an adequate reaction to them, and adopt security measures within the organization as prevention against specific types of attacks.
For the above reasons, it is necessary to reduce the amount of stored data and increase the number of relevant data, thus facilitating the process of obtaining useful information and knowledge that is important for the response mentioned above to security incidents and making decisions about security measures. Network communication processing with minimal loss of information value can help in this direction.
The processing of security alerts consists of several phases. Several works describe these phases [7], [8]. For this paper, we will distinguish the following stages. The first phase is alert preprocessing. This stage includes normalization and verification procedures to clean and transform raw alerts into the formats expected by the aggregation and correlation modules. Normalization is also part of this phase. It converts heterogeneous alerts from multiple sources into a standard format acceptable by correlation modules [4].
The next phase is the aggregation of security alerts (aggregation phase). The primary role of this phase is to combine similar alerts or security events clustering and grouping to reduce the number of low-level alerts [8]. The output of the phase is aggregated alerts. In addition to the usual attributes, the aggregated alerts can contain other statistical information, such as the number of events, their size, or a list of individual events.
The correlation phase of aggregated security alerts follows the aggregation phase. Correlation extracts useful and high-level information from the security alerts. It aims to provide an understanding of the logical relationships between them [9].
Reconstruction of attack scenarios is the next phase. It is a process complicated by false negatives and false positives resulting from IDS limitations. False positives lead to incorrect attack scenarios, while false negatives (i.e., attacks missed by the IDS) either make it impossible to reconstruct the attack or lead to an incomplete scenario.
Alert post-processing are procedures aimed at helping security analysts determine how to behave during a security incident identified as a multi-step attack, predict the attacker’s next steps, and what the probability of each possible step is according to current contextual information [8].
Functionalities and key features
Above, we listed the individual steps of alert processing. For this purpose, we designed software that covers preprocessing and aggregation phases and is composed of three parts:

  • Preprocessing;
  • Alert filtration;
  • Aggregation.

The scheme of the software flow is displayed in Fig. 1.



Fig. 1

As mentioned above, IDS (e.g., SNORT, Suricata) represent primary tools for network security monitoring. These tools use various rules to process network traffic through packets (pcaps). To prepare input data, we used SNORT IDS. We used three types of rules for our software: (I.) Snort community rules (v3.0) [10]; (II.) Proofpoint Emerging Threats Rules [11], (III.) Network forensic Snort IDS rules  [12]. At the output of the IDS, we receive alerts that we further process within our software. The software can process alerts that are stored in files in CSV format.