Network specific vulnerability based alert reduction approach

ABSTRACT

Traditional intrusion detection systems are known for triggering large volumes of alerts. An average commercial intrusion detection system reports thousands of alerts on daily basis. A large proportion of these alerts are false alerts. In the field of alert management, alert verification is cited as critical component in determining the success of intrusions. It helps to eliminate any alert that does not have a corresponding vulnerability in a network, hence improving the effectiveness of alert management approaches. Alert verification alone cannot guarantee alerts of high quality because the validated alerts may contain massive number of redundant alerts. The analysts who review alerts are likely to take longer time to understand the complete security incident because it would involve evaluating each single redundant alert. Consequently, the analysts would not only encounter difficulties when taking the correct decision but would also take longer time to respond against the intrusions. Therefore, the unnecessary alerts diminish the value and urgency of the relevant alerts.

This paper seeks to address the aforementioned issue to strengthen the vulnerability-based alert management approaches. Our approach verifies alerts prior to merging them. Central to this approach is the use of two components: verifier and alert merger. The verifier component improves the quality of alerts by validating them with enhanced vulnerability assessment data. The alert merger component reduces huge number of redundant alerts. Experiments conducted in our test bed have demonstrated the success of our approach in reducing most of the unnecessary alerts for a range of attacks with high accuracy yet closely maintaining the detection rate. Copyright © 2012 John Wiley & Sons, Ltd.

1 INTRODUCTION

Organizations are increasingly looking for additional security technologies to counter risks and vulnerabilities. Intrusion detection systems (IDSs) are widely deployed in many organizations to improve the security of network. An IDS provides an extra layer of defense to computer networks by gathering and analyzing information in a network to identify possible security breaches. There are two broad types of IDSs: signature based and anomaly based. The former uses a database of known attack signatures for detection, whereas the latter uses a model of normative system behavior and observes deviations for detection [1]. If an intrusion is detected, an IDS generates a warning called an alert or alarm.

The goal of any IDS is to deliver alerts of high quality to the analysts. However, the traditional IDSs have not lived up to this promise. They trigger overwhelming number of unnecessary alerts that are primarily false alerts resulting from non-existing intrusions. The important alerts are often buried and hidden among huge number of unsorted, unverified, irrelevant, low priority, redundant and misleading alerts. Evaluating and analyzing alerts of this nature not only consumes unnecessary resources but is also laborious and error-prone task [2-6]. There are several reasons that lead IDSs to generate huge number of alerts. The reasons are discussed in the work of Pietraszek and Tanner [5].

Our paper focuses on reduction of unnecessary alerts in signature-based IDSs. The field of alert reduction is a well-explored topic in the literature, and numerous methods have been proposed to manage alerts on the basis of techniques such as modification of signatures, alert filtering, fixing vulnerabilities, alert correlation and false alert reduction. Each technique has its merits and limitations. For example, tuning and reconfiguring the signature database may eliminate some spurious alerts and increase the relevance of alerts. However, it is extremely difficult in large networks to have all IDS sensors extensively tuned to acceptable false positive levels [4]. The tuning process is iterative and requires extensive knowledge on signatures [3, 7, 8]. Indeed, the improper manipulation of signatures could lower the detection rates, thereby putting the important network resources at risk if critical intrusions are missed. Another viable option is to fix all the known vulnerabilities before damaging intrusions take place to reduce the number of alerts. However, this solution may not be effective because of the following limitations [9]: time gap between vulnerability disclosure and the software patch released by software developers; updating hosts from different vendors in a large network takes longer, thus exposing the hosts to intruders; and some vulnerabilities are protocol based, hence an immediate patch may not be available.

Vulnerability-based alert management approaches are extremely promising in delivering quality alerts [1, 7, 10-12]. They improve the quality of alerts by filtering alerts that do not have corresponding vulnerabilities. However, validating alerts cannot guarantee alerts of high quality. The validated alerts may contain huge volumes of redundant alerts. The analysts who review alerts are likely to take longer time to understand the complete security incident because it would involve evaluating each single redundant alert. Consequently, the analysts would not only encounter difficulties when taking the correct decision but also take longer time to respond against the intrusions. Therefore, the unnecessary alerts diminish the value and urgency of the relevant alerts.

Our paper seeks to strengthen the vulnerability-based alert management approaches by addressing the aforementioned limitation without manipulating the default set of signatures for signature-based IDS. The proposed approach improves the quality of alerts by reducing the unnecessary alerts. We use alert verification process to filter out the non-relevant alerts before the merging of the alerts takes place. Central to this approach is the use of two components: verifier and alert merger. The verifier component validates the alerts with enhanced vulnerability assessment (EVA) data, whereas the alert merger component reduces the volumes of redundant alerts. Experiments conducted in our test bed have demonstrated the success of this approach in reducing most of the unnecessary alerts.

The rest of the paper is organized as follows: Section 2 describes the related work. Section 3 describes the proposed approach. Section 4 describes the experiment, results, and discussion. Section 5 concludes this paper.

2 RELATED WORK

In this section, we studied several prominent works on alert reduction. The goal of these approaches is to reduce the unnecessary alerts generated by IDSs. First, we focus on the general alert reduction approaches and later on the vulnerability-based alert management approaches.

Julisch [13] presents a clustering technique for grouping all the alerts sharing the same root causes. Central to this technique is the generalization hierarchies that decompose the attributes of the alerts from the most general values to the most specific ones. These generalization hierarchies are later used for measuring the distance between alerts in clusters. The idea of generalization hierarchies seems promising for the purpose of aggregating but has the drawback of assuming a predetermined size for all clusters.

Valdes and Skinner [14] propose a heuristic approach to group alerts on the basis of their overall similarity. The overall similarity of two alerts is defined on the basis of their similarity on the corresponding features. This approach provides a basic probability model for measuring similarities between alerts. Although this method seems to effectively reduce a number of false alerts, it cannot fully discover the causal relationship between related alerts.

Ning et al. [15] propose an alert correlator on the basis of the observation that most attacks consist of several related stages, with the early stages preparing for the later ones. Hyper-alert correlation graphs are used to represent correlated alerts in an intuitive way. The approach is useful, but it is ineffective when the attackers use either a different or spoofed IP source address at each attack step.

Sourour et al. [16] propose a model to manage the massive number of isolated alerts and include the network address translation information in the IDS analysis. This approach determines the real identities of entities implicated in security issues and correlates alerts of the same intrusion. The model constructs pertinent and reliable alerts, removes the most prevalent and uninteresting false alerts and provides the analyst with a concise high-level description of attack scenarios. Our work is inspired by this work and in particular on how the alert correlation is implemented to correlate the isolated alerts. Our work is different from this approach in several aspects such as how to identify false alerts. Our work uses alert verification to filter out any alert that does not have a corresponding vulnerability.

The traditional IDSs tend to generate too general alerts that are not network specific because of being unaware of network context they monitor [10]. Most of the IDSs are run with default set of signatures, hence generate alerts for most of the intrusions irrespective of success or failure to exploit vulnerabilities in the network under consideration [1]. The use of additional data such as vulnerability data is recommended and advocated as an important tool to improve the quality of alerts [10, 11, 17]. It helps to differentiate between successful and failed intrusion attempts, hence increase the accuracy of alert management approaches.

Valeur et al. [18] propose a general correlation model that includes a comprehensive set of components such as alert fusion, alert verification, multistep correlation, and alert prioritization. Our approach is inspired by logical framework proposed by the authors. Our approach verifies alerts prior to merging the alerts because efforts to improve the quality of alert should start in the early stages of alert management. Generally, if an approach receives false positives as input, the quality of the correlation results can degrade significantly. Failure to exclude the alerts that refer to failed attacks may lead to false positive alerts being misinterpreted or given undue attention.

Gula [7] illustrates how vulnerability information elicits high-quality alerts from huge alerts that are primarily false alerts. The author states that a particular true intrusion targets a particular vulnerability, and therefore, correlating the alert with vulnerability could reveal whether the vulnerability is exploited or not. The author describes a variety of approaches and theories that can be used to correlate alerts with vulnerability data.

A vulnerability-based alert filtering approach is proposed by Porras et al. [19]. It takes into account of the impact of alerts on the overall mission that a network infrastructure supports. This approach uses the knowledge of the network architecture and known vulnerabilities of the protected network to tag alerts with relevance metric and then prioritize them accordingly. Alerts representing attacks against non-existent vulnerabilities are discarded. However, the authors do not propose a formal vulnerability data model to include details such as vulnerability scanners and their interactions with other concepts.

Yu et al. [20] propose a collaborative architecture (TRINETR) for multiple IDSs to work together to detect real-time network intrusions. The approach reduces false positives by integrating network and host system information into the evaluation process. However, the approach has not implemented the alert correlation part that is very crucial in generating condensed alert views.

Massicotte et al. [21] propose a possible correlation approach on the basis of integration of Snort, Nessus, and Bugtraq databases. The approach uses reference numbers (identifiers) found on Snort alerts. The reference numbers link to Common Vulnerability Exposure (CVE), Bugtraq, and Nessus scripts. The authors show a possible correlation on the basis of the reference numbers. However, it is not effective because not all alerts have reference numbers. In addition, there is no guaranty that the lists provided by CVE and Bugtraq contain complete listing of vulnerabilities.

Neelakantan and Rao [22] propose an alert correlation approach comprising of three stages: (i) finding vulnerabilities in the network under consideration; (ii) creating a database of all vulnerabilities having reference numbers (CVE or Bugtraq); and (iii) selecting signatures that correspond to the identified vulnerabilities. This approach requires reconfiguration of the signatures when there is network change (such as hosts being added or removed) leading to downtime of IDS engine. Moreover, it only handles alerts with reference numbers, thus lowering detection rates due to incompleteness of vulnerability reference numbers.

Morin et al. [10] present a data model (M4D4) that formalizes the concepts and relationships of different network elements (such as network topology, network resources, vulnerabilities, and attacks) to analyze and evaluate alerts. The authors observe that many alerts (especially false positives) involve actors that are inside the monitored information system and whose properties are consequently also observable.

Njogu and Jiawei [23] propose a clustering method to reduce unnecessary alerts in IDSs. This approach uses vulnerability data to compute for alert metrics (such as alert relevance, severity, and frequency). The approach determines the similarities of alerts on the basis of their alert metrics, and the alerts that show similarity are grouped together in one cluster. Our new work is different from this old work because the alert verification is based on dynamic vulnerability data. The architecture of the vulnerability data is different too. In the new work, we use network-specific vulnerability generator to generate the vulnerabilities by incorporating information from three sources, that is, network resource data, scan reports produced by multiple vulnerability scanners, and known vulnerability database. In addition, the new work merges alerts on the basis of the alert features and not the alert metrics. We have also introduced the concept of alert prioritization-based alert relevance scores.

A more recent and interesting work that is closer to our work is presented by Hubballi et al. [1]. The authors propose a false positive alert filter to reduce false alerts without manipulating the default signatures of IDS. Central to this approach is the creation of a threat profile of the network that forms the basis of alert correlation. The method correlates the IDS alerts with network-specific threats and filters out false positive alerts. This involves two steps: (i) alerts are correlated with vulnerabilities to generate correlation binary vector generation and (ii) classification of correlation binary vectors using the neural networks. The idea of correlating alerts with vulnerabilities in this work is promising in delivering accurate alerts. However, this method does not reduce the number of redundant alerts generated from the same event and more so in intrusions carried out in different stages. Our work seeks to strengthen and extend this method by introducing several aspects as described Section 3.

With respect to the related work, we noted that alert verification alone cannot guarantee alerts of high quality. In fact, the validated alerts from vulnerability-based approaches may contain huge volumes of redundant alerts. These redundant alerts could be close in time or distant in time. The redundant alerts should be reduced to deliver alerts of high quality to the analysts. The analysts would quickly be able understand the complete security incident and take the correct decision. The major contribution of our work is the reduction of huge number of redundant alerts from the same event and more so in intrusions carried out in different stages.

3 THE PROPOSED APPROACH

In this section, we discuss our approach in details. The proposed approach processes alerts as follows. The raw alerts are collected from signature-based network intrusion detection system sensor. An alert preprocessor unit is used to preprocess the raw alerts. This involves extracting the important alert features such as IP addresses and port numbers (refer to Table 1) and storing them in an alert relational database for further analysis. The preprocessed alerts are then forwarded to IDS Alert-EVA data verifier component for two reasons: validation of alerts and computation of alert relevance score. The most obvious non-relevant alerts, showing little or no match with the EVA data when being validated, are eliminated. The validated alerts are later forwarded to the alert merger component. The alert merger component has six submergers to reduce volumes of redundant alerts from different intrusions. The submergers present the final alerts in form of meta-alerts. Figure 1 depicts the basic architecture of the proposed approach.

Table 1. Preprocessed alert snapshot.

*Reference Id	*Name	*IPdest	*Portdest	IPsrc	Portsrc	*Priority (Severity)	*Protocol	*Class	*Time	*Application
* Keyused in alert verification, TCP, transmission control protocol.
CVE-1999-0001	Teardrop	192.168.1.3	1238	192.168.1.1	1238	High	TCP	DoS	9:9:2011:10:12:05	Windows
CVE-1999-0527	Telnet Resolv Host Conf	192.168.1.2	1026	192.168.1.1	1026	Medium	TCP	U2R (Telnet)	9:9:2011:10:12:06	Telnet, Windows

Figure 1. Proposed architecture. IDS, Intrusion Detection System; NIDS, Network IDS.

Our work is twofold. First, we describe how alerts are validated and highlight the added value on alert validation brought by the proposed approach. Second, we focus on reduction of redundant alerts contained in the validated alerts using the alert merger component.

3.1 Alert verification

Threats in a network are due to vulnerabilities in a network. It is believed that each attack exploits a particular vulnerability on a specific application, service, port, or protocol. Generally, the traditional IDSs run with their default signature database and do not check the relevance of an intrusion to the local network context. Thus, IDSs generate huge volumes of raw alerts, majority of which are not useful in the context of the network.

As previously mentioned in Section 2, we seek to extend and strengthen the work of Hubballi et al. [1] by incorporating the concept of reducing the redundant alerts. Before we implement this concept, we have introduced several aspects that could add value on how alerts are validated. The purpose of this subsection is to illustrate and describe how alerts are validated.

Enhanced vulnerability assessment datum is a dynamic threat profile of the network under consideration. It represents vulnerabilities of the network that are likely to be exploited by attackers. It lists all the vulnerabilities by their reference ids, names, priority, IP addresses, ports, protocols, classes, time, and applications. Figure 1 illustrates how the EVA data are constructed. The network-specific vulnerability generator is the engine that constructs the EVA data. It does this by establishing a relationship in all the elements of vulnerabilities drawn from three sources. The sources are as follows: The known vulnerability database comes from various sources such as CVE database to provide additional details of vulnerabilities. Vulnerability scanners generate threats, exploits, and vulnerabilities existing in the network under consideration in the form of scan reports. The reports indicate the network assets likely to be exploited including information such as severity and time of reporting the vulnerabilities. Different vulnerability scanners such as Nessus and Protector plus can help to populate the aforementioned information. Scripting languages such as Perl scripts can easily process the reports from different scanners. Network resource database contains the network context information such as hosts in the network, their applications, IP addresses, and ports.

The architecture of building the threat profile in [1] is almost similar to what we have proposed as shown in Figure 1. We have slightly modified the architecture of [1] to enhance it in terms of efficiency and scalability. In addition, we have applied a different technique to validate alerts. Specifically, we introduced the following aspects:Threat profile of [1] is drawn from two major sources, that is, known vulnerability database and scan reports. In our work, the EVA data are drawn from three sources as illustrated previously. We introduced a database for network resources to improve the management of network resources. Our approach has incorporated a mechanism to eliminate vulnerabilities that appear outdated, old, and have not been used for validation in a relatively longer time (time varies with different network environment). This is very important for the purpose of having efficient and scalable EVA data.We noted that it is difficult to maintain a dynamic threat profile in [1] because updating the threat profile is performed offline. In our approach, we use host agents to track changes in a network and later relay the necessary information to the network-specific vulnerability generator so that the EVA data are updated accordingly, thus leading to better validation results. In [1], correlation binary vectors are generated by neural network-based engine to represent the match and mismatch of the corresponding features between alert and vulnerability. An example of the binary vector is (1000001001), where “1” represents a match whereas “0” represents a mismatch. Our approach uses IDS Alert-EVA data verifier engine to validate alerts and compute the alert relevance score. The verifier computes the alert relevance score for a given alert and the corresponding vulnerability on the basis of match or mismatch of the common parameters. Our approach uses direct comparison of values of the parameters because it is easy, fast, and does not require extensive training. The alert relevance score represents the likelihood of an attack being successful with respect to the network being considered—the higher the number of matching parameters, the higher the relevance of an alert is. In addition, it would be more convenient for us to use the alert relevance score when addressing the alerts in the later stage (merging of alerts), which forms the critical part of this work. The quality of alert verification is highly dependent on various elements of information from IDS alerts and their corresponding vulnerabilities. As noted in [1], the threat profile and an IDS product may use different attack details such as reference ids when referring to the same attack. In fact, there are no unique (standard) attack details such as reference ids to reference all types of attacks. To have a comprehensive EVA data, we have introduced additional attack reference information from IDS product. This involves setting up additional mappings based on IDS into EVA data. We use this information to play a complementary role when determining the relevance of alerts. This helps to ensure the completeness of attack details in the EVA data because if attack details are missed, then the computation of alert relevance score is negatively affected. It improves the accuracy of alert relevance score and increases the speed of validation process too.

The verifier uses an IP address of a given alert to search for the potential vulnerabilities in the EVA data. The verifier chooses the vulnerability that best represents the alert from the potential vulnerabilities, that is the chosen vulnerability has the highest alert relevance score. For simplicity reason, any match is awarded a value of 1, whereas a mismatch is awarded a value of 0. The alert relevance score is the total number of matches of the common parameters between the alert and the corresponding vulnerability.

To illustrate the concept of alert verification, consider the following example. Table 1 shows a snapshot of preprocessed alerts. Table 2 shows a section of EVA data. In Table 1, the first alert reports teardrop attack targeting a host with IP_dest 192.168.1.3 on Port_dest 1238. Using the IP_dest of this alert, the verifier extracts all the potential vulnerabilities in the EVA data in Table 2 that match this IP_dest. In this case, the EVA data have only one vulnerability matching the alert's IP_dest. The verifier then matches other features (reference id, port, priority, protocol, class, time, name, and application) of alert against the said vulnerability. The alert relevance score is computed as follows: IP_Score = 1 because IP addresses are matching and so is the rest of features; ReferenceId_Score = 1; Port_Score = 1; Time_Score = 1 (Alert.Time ≥ EVAdata.Time); Application_Score = 1; Protocol_Score = 1; Class_Score = 1; Name_Score = 1; Priority_Score = 1. Thus, the alert relevance score is 9.

Table 2. Enhanced vulnerability assessment data snapshot.

Reference Id	Name	IP address	Port	Priority (severity)	Protocol	Class	Time	Application
TCP, transmission control protocol.
CVE-1999-0001	Teardrop	192.168.1.3	1238	High	TCP	DoS	8:9:2011:14:16:02	Windows
CVE-1999-0527	Telnet Resolv Host Conf	192.168.1.2	1026	Medium	TCP	U2R (Telnet)	8:9:2011:14:16:02	Telnet, Windows

With the help of the scale shown in Table 3, alerts are tagged with appropriate alert relevance. The scale helps in tagging alerts with their respective alert relevance. Alerts with score of 9 are tagged with ideal relevance. Alerts with score of between 4 and 8 are tagged with partial relevance, whereas alerts with score of between 0 and 3 are considered as non-relevant alerts (the most obvious false alerts). We used a score of between 0 and 3 to include alerts reporting attempted but failed attack. Most of the alerts in this category are system immune meaning they report real attacks but are not harmful to the target(s). A high percentage of the alerts reporting these attacks could match with the EVA data on IP address, port, or time.

Table 3. Alert relevance score scale.

Threshold	Alert relevance
9	Ideal relevant alerts (ideal relevance)
4–8	Partial relevant alerts (partial relevance)
0–3	Non-relevant alerts

Alerts tagged with ideal relevance and partial relevance are forwarded to the alert merger, whereas those considered as non-relevant alerts are eliminated. This helps the alert merger to focus on the real threatening alerts. Finally, to achieve better thresholds as indicated in the Table 3, a number of verifications were run using different scores to search for the best thresholds for the alerts. However, the threshold values can be adjusted depending on network environment.

3.2 Merging of alerts

In this subsection, we discuss the details of the alert merger component. Our main objective is to reduce the redundant alerts in vulnerability-based approaches. As previously noted, the validated alerts of most vulnerability-based approaches may contain huge number of redundant alerts that need to be reduced.

Different types of intrusions may cause IDSs to generate volumes of redundant alerts. In recent years, the trend of the multistep intrusions is on the rise, leading to overwhelming number of redundant alerts. A single attack such as port scan is enough to generate huge number of redundant alerts. In addition, some attacks may trigger alerts that appear independent but may have some logical connections with each other when correlated; that is, correlation helps to show interrelatedness and logical connections of alerts.

The analysts are likely to take longer time to understand the complete security incident because it would involve evaluating each single redundant alert. Consequently, the analysts would not only encounter difficulties when taking the correct decision but would also take longer time to respond against the intrusions. The analysis of individual alerts provides partial information on the attack, hence not effective to uncover the real patterns of the attacks. Therefore, we conclude that the unnecessary alerts diminish the value and urgency of relevant alerts.

In this work, we use the alert merger component to reduce the redundancy of validated alerts and present them in the form of single-summarized alert known as meta-alert. A meta-alert contains summarized information of related alerts of a given intrusion. The component merges the single redundant alerts representing every step of attack to have a big picture of attack. Thus, the alert merger reduces the volume of redundant alerts belonging to the same attack activity within a particular time window. In our alert merging procedure, the attributes of new alerts are compared with those of the previous alerts before merging takes place. Our alert merging technique is inspired by Sourour et al. [16]. The differences between our work and other related works are highlighted later in this subsection.

The alert merger handles six different classes of attacks, namely DoS, FTP, Telnet, MySql, SQL, and undefined attacks. To be more efficient, the alert merger has six submergers to handle the validated alerts representing the six different classes of attacks as illustrated in Figure 2. For example, DoS submerger handles all alerts reporting DoS attacks. Undefined attack submerger is slightly different from the other five submergers. It handles alerts reporting new attacks that have not been defined during the design of the alert merger or any alert that has a mismatch in the field of class of attack during alert verification. The final processed alerts from this submerger are further analyzed by the analysts to update the EVA data and the alert merger with new attack information.

Figure 2. Alert merging schema.

The alert merger component receives the validated alerts from the verifier component. As noted earlier, the validated alerts are unrelated, isolated, and redundant. Before going into fine details of how alerts are merged, we define the variables of each meta-alert M:Meta-alert attack class (M.Class)—indicates the class of attack as reflected in alerts.Meta-alert relevance (M.Relevance)—indicates the relevance of alerts contained in alerts.Meta-alert create time (M.create_time)—defines the create time of meta-alert. It is derived from the timestamp of the first alert that created the meta-alert.Number of alerts (M.Nbre_alerts)—defines the number of alerts contained in the meta-alert. Each time a new alert is fused to meta-alert, this number is increased.Meta-alert update time (M.update_time)—defines the time of the last update in meta-alert. This variable represents the time of the most recent alert fused to the meta-alert.Meta-alert non-update time (M.non-update_time)—counts the time since the last update made on the meta-alert. This time is reset to 0 each time a new alert is fused to the meta-alert.Meta-alert stop time(M.stop_time)—defines the time when meta-alert is assumed to have completely fused the needed alerts.Meta-alert time out (M.Time_out)—measures the time that a meta-alert should continue waiting for additional alert(s). It varies with class of attack.Exploit cycle time (EC_time)—measures the time that an exploit is believed to take (attack period). It varies with class of attack.Additional data include source address (M.IP_src and M.Port_src) and destination address (M.IP_dest and M.Port_dest).

In this solution, each of the submergers uses an exploit cycle time parameter to determine the extent of an attack. A submerger generates meta-alerts regarding a particular attack within an exploit cycle time. Generally, a multistep attack is likely to generate several meta-alerts in a given exploit cycle time, whereas a single-step attack is likely to generate one meta-alert within a given exploit cycle time. However, one meta-alert could also represent multistep attack especially if the intruder knows the network resources to exploit. The procedure to merge alerts is illustrated as follows: To determine which submerger handles a given alert, the alert merger component makes this decision on the basis of the attack identifier (class) field in the alert and forwards the alert to the corresponding submerger. For example, an alert reporting a DoS attack is forwarded to the DoS submerger. The submerger uses the IP addresses (Alert.IP_src and Alert.IP_dest) of a given validated alert to identify the potential meta-alerts (i.e., M.IP_src and M.IP_dest of meta-alerts that match Alert.IP_src and Alert.IP_dest). To identify the best meta-alert representing the alert under consideration, the submerger measures the similarity between the alert and the existing meta-alerts as follows: IP similarity—compare (Alert.IP_src,M.IP_src) and (Alert.IP_dest,M.IP_dest). If IP addresses matched, then IP similarity = 1; else, IP similarity = 0.Port similarity—compare (Alert.Port_src,M.Port_src) and (Alert.Port_dest,M.Port_dest). If Ports matched, then Port similarity = 1; else, Port similarity = 0.Time similarity—If Alert.Time ≥ M.create_time and M.non-update_time < M.Time_out, then Time similarity = 1 (time is within close range); else, Time similarity = 0 (time not within close range). Relevance similarity—if Alert.Relevance = M.Relevance, then Relevance similarity = 1 (match); else, Relevance similarity = 0 (mismatch). Choose the meta-alert with a perfect match with alert (only one meta-alert can be chosen). If a meta-alert that fully corresponds to the alert is found (in step 3), then details of that meta-alert are updated, that is, M.Nbre_alerts is incremented, M.non-update_time is reset to 0, and M.update_time is updated.However, if a meta-alert does not exist corresponding to the alert being considered, a new meta-alert is created. Details of this alert form the new meta-alert. For example, M.Nbre_alerts is set to 1, M.update_time is updated, M.non-update_time is reset to 0, the timestamp of the alert becomes M.create_time, and M.Class is updated. The new meta-alert starts waiting for the related alerts. If the existing meta-alert's non-update time is less than meta-alert time out (M.non-update_time < M.Time_out) then the meta-alert continues waiting for additional related alerts. If the related alerts are received, the meta-alert updates its contents; that is, M.Nbre_alerts is incremented, M.non-update_time is reset to 0, and M.update_time is updated. If the existing meta-alert's non-update time is equal or more than meta-alert time out (M.non-update_time ≥ M.Time_out), then the meta-alert stop time (M.stop_time) is updated and stops waiting for additional related alerts. Finally, the meta-alerts are forwarded to the analyst who takes the adequate decision on the basis of the forwarded information.

The M.Time_out parameter ensures that the necessary alerts are fused to a given meta-alert, whereas the EC_time parameter ensures that all the meta-alerts of a given attack are generated accordingly. In our approach, the values set for M.Time_out and EC_time vary with class of attack. Therefore, each submerger has its own M.Time_out and EC_time. Both M.Time_out and EC_time of a given meta-alert are not necessary equal. The M.Time_out of a given meta-alert could be lower than EC_time of the same meta-alert because most events forming the different steps of attacks are generated in the early stage of an exploit cycle [24]. Therefore, there is no need to wait for the complete exploit cycle timeframe of an intrusion. Moreover, in environments prone to both single-step and multistep attacks, it would be inappropriate for single-step attacks to have longer M.Time_out as this could lead to unreasonable delay of meta-alerts. In addition, an EC_time of a given attack may expire before all steps of the corresponding attack scenario are executed. This is not a major disadvantage as such because the information collected on meta-alert(s) at that time could show the analyst what the intruder has performed and obtained; hence, the analyst can predict how intruder will perform in future. More so, the values for M.Time_out and EC_time of a given attack can be adjusted to optimize the detection of all steps of the attack.

It is worth noting that alerts can be merged using source address, target address, or both depending on the nature of attack. We have used source and target addresses on steps 2 and 3 for illustration purposes. To produce better results, we assume that the alerts are forwarded to the alert merger without unnecessary delay by the verifier.

Our solution is an extension of vulnerability-based alert management approach. It is inspired by the correlation system proposed by Sourour et al. [16] that is applied in a network address translation environment. Our approach and that of Sourour et al. [16] share some variables that define the meta-alerts. In fact, most of the correlation systems such as that of Perdisci et al. [25] use such similar variables when defining meta-alerts. To define meta-alerts better, we included additional variables such as meta-alert attack class and meta-alert relevance. Other distinctive characteristics that describe our work are as follows:Our alert merger is fed with validated alerts as input. As discussed earlier in Section 3, the alert verification process helps to filter out any alert without a corresponding vulnerability. This means that the alert merger processes alerts of high quality, thus giving better results unlike other correlation methods proposed by Valdes and Skinner [14] and [16] Sourour et al. that are fed with unverified alerts. Generally, if a correlation system receives unverified alerts (containing false positives) as input, the quality of the correlation results may degrade significantly leading to false positive alerts being misinterpreted or given undue attention. [18]. In addition, our approach drastically reduces the overhead (such as processing time and storage) associated with unverified and unnecessary alerts. Most of the previous correlation methods such as Valdes and Skinner [14] and Perdisci et al. [25] use only one correlation schema to correlate alerts of different attacks. However, reference [16] uses four subcorrelators that are based on characteristics of attacks (such as one-to-many attacks subcorrelator, many-to-one attacks subcorrelator, many-to-many attacks subcorrelator, and undefined attacks subcorrelator). In contrast to the previous works, our work has six submergers where each of the submergers is designed or based on a specific class of attack. Handling a specific class of attack in each submerger definitely simplifies the process of merging alerts; that is attacks from different classes are separated appropriately hence contributing to better results. Sourour et al. [16] use an implicit correlation method to define false positives that is based on the following claim: “If the number of alerts in an alert cluster is one and nothing else has been added to that meta-alert in a long enough timeframe, so the meta-alert is considered as false positive.” The solution generates random values for meta-alert time out (T_out) periodically to avoid attackers who may know and wish to exploit the property of this system. However, with the advanced attacking tools, this solution can easily be bypassed, hence producing unreliable results. This makes the system not very effective in handling attacks represented by single alerts. Our approach identifies the false positives by comparing the alerts with their corresponding vulnerabilities. Any alert without a corresponding vulnerability is regarded as false positive. Filtering alerts based on the vulnerabilities is a very promising way of identifying false positive alerts [1, 7, 10-12]. In addition, our approach is able to detect a wide range of attacks in early stages including single-step and multi-step attacks and deliver realistic results. More so, our solution is able to find the new attacks using the undefined attack submerger. Finally, our solution is able to prioritize alerts accordingly. The alert merger separates alerts according to their alert relevance, that is, ideal relevant alerts and partial relevant alerts. This is possible because each meta-alert has M.Relevance variable that indicates the relevance of alerts contained in the meta-alert.

4 EXPERIMENT AND DISCUSSION

4.1 Overview

The proposed approach takes IDS alerts as input and processes and outputs them in the form of meta-alerts. To validate the proposed solution, a heterogeneous test bed was set up with different operating systems such as windows 98, windows server 2003 and 2000, windows XP, Redhat 4.2, Fedora 9, and Ubuntu. Different applications such as FTP server, Telnet, MySql server, and SQL server are installed. Target machines host the operating systems and applications. Snort [26] is chosen as network intrusion detection system with default set of rules. One of the machines stores the alerts and EVA data. The machines are equipped with Intel core duo processor (P8400) running at 2.26 MHz and have 2 GB of RAM. The attacking machines are loaded with widely known attacking tools such as Metasploit tool [27], among others, in order to generate exploits. Attacks are divided into two: relevant attacks and non-relevant attacks. Relevant attacks are capable of exploiting the vulnerabilities of the test bed. The relevant attacks consist of two types: (i) attacks that fully exploit the vulnerabilities and (ii) attacks that partially exploit the vulnerabilities. The non-relevant attacks cannot exploit any vulnerability in the test bed.

To generate the required alert sets, this experiment used the attacking machines to execute attacks using known techniques and exploits on the applications, operating systems, ports, and protocols. The attacks are grouped into five classes, namely DoS, FTP, SQL, MySql, and Telnet. Some attacks involve one step and others multistep. The following are examples of specific scenarios for multistep attacks based on known techniques and exploits. The first scenario is multistep attack that exploits the vulnerabilities of FTP server in the test bed. The attacking machine uses Nmap [28] to try to detect whether an FTP service is running on the target machines (FTP attack). The second scenario is multistep attack that involves attacking machines to interrupt the Transmission Control Protocol (TCP) service running in target machines. This attack is emulated with the aid of an Internet Control Message Protocol (ICMP) Flooder because it can continuously transfer large packets to the target of the attack, hence disrupting TCP service (DoS attack). This attack originates from many sources to multiple destinations. A list of other specific attacks includes the following: DoS attacks (Teardrop, Land, Winnuke, Ping of death, and Syndrop), FTP attacks (Finger redirect, FreeFTPd username overflow, and FTP format string), Telnet attacks (Telnet username buffer overflow and Resolve host conf), SQL attacks (SQL server buffer overflow and SQL injection), and MySql (SSL hello message overflow).

We designed a JAVA program to implement the components of the proposed solution.

4.2 Enhanced vulnerability assessment data

Enhanced vulnerability assessment data are a comprehensive database implemented on MySql platform. It represents the threat profile of the test bed, and it lists all vulnerabilities by their reference ids, names, priority, IP addresses, ports, protocols, classes, time, and applications as discussed in Section 3. The network-specific vulnerability generator establishes relationships in all elements of vulnerabilities from three sources. The information of three sources is populated as follows: Use of various up-to-date vulnerability scanners such as Nessus [29], Nmap, and GFI Languard [30] to capture and report threats and vulnerabilities (in ports, applications, etc.) of the test bed. They use different techniques to detect vulnerabilities and are set to run periodically to look for the new vulnerabilities. Perl scripts are used to process the reports from the scanners.The known vulnerability database is populated from widely known databases such as CVE database to provide additional details of vulnerabilities. Network Resource database is populated and contains the network context information such as hosts present in the network, their applications, IP addresses, and ports within our test bed.

The network vulnerabilities are known to be dynamic in nature. Special agents (in form of Perl scripts) are installed in the hosts to track changes in applications, services, and configuration and then update the EVA data accordingly.

As noted earlier in Section 3, the EVA data and IDS product (in this case, we use Snort) may use different attack details such as reference ids when referring to the same attack. Actually, standardization of attack details is a global issue affecting the management of alerts. Standardized schemes such as CVE have been developed to uniquely reference and directly map attack information to vulnerabilities. Snort refers its signatures to standard CVE. However, not all attacks have assigned CVE ids as reference ids. For example, 33–42% of attack signatures in Snort (since 2003) have CVE ids [16, 21]. Missing CVE details could have an impact on alert validation. The most appropriate solution is to establish a mechanism to map identifiers for attacks and vulnerabilities. We have proposed a mapping facility to help in setting up additional mappings based on Snort-specific identifiers into EVA data. This involves the following: Examining the attack reference details contained in the EVA data and Snort. Determining the coverage overlap of standardized attack reference details between EVA data and Snort. Setting up additional attack reference details based on Snort into EVA data with help of the Open Source Vulnerability Database (OSVDB) [31], which is an open source database for vulnerabilities that references CVE, Snort, Nessus, and other leading network security products. That is, the EVA data use other Snort's references such as Bugtraq ids and OSVDB ids when CVE ids are not applicable (complement CVE when referring to attacks).

We limited the coverage of this exercise to the attacks used in the test bed. We added the attack information into EVA data to ensure that the details derived are appropriate and would positively influence the alert validation and computation of alert relevance score as well.

4.3 Performance of the system

The time taken to generate the EVA data is influenced by factors such as the number of applications installed in each host, the type of scanners used, the number of hosts to be scanned, and the number of scanners used in the network. On average, it took 2–6 min to scan one host. After building the EVA data, the vulnerability scanners are configured properly to minimize overhead by focusing on the new vulnerabilities. It is important to note that EVA data may require some adjustments such as when network changes and when eliminating the obsolete vulnerabilities. Even though this is performed by agents, time taken to do this may play secondary role.

The period of test was about 60 min for each class of attack (containing different intrusions). We generated a total of 904 alerts. These alerts were collected and preprocessed in terms of extracting the important features using Perl scripts as discussed earlier in Section 3. The preprocessed alerts were fed as input into the verifier component for validation and computation of alert relevance scores. The validated alerts were forwarded to the alert merger to reduce the redundant alerts. The following parameters were set for alert merger component: M.Time_out = 1–2 min and EC_time = 3–15 min, depending on the class of attack.

Table 4 shows the alerts generated by Snort per class of attack. The alerts shown conforms to the number of attacks, where about 20% of the alerts represents attacks that exploited the vulnerabilities (relevant attacks) of the test bed whereas 80% of the alerts represents attacks that did not exploit the vulnerability (non-relevant attacks).

Table 4. Accuracy and detection rate of raw alerts (Snort).

Alerts /Class	DoS	Telnet	FTP	MySql	SQL
TP, true positive; FP, false positive; FN, false negative.
Attacks	83	135	352	189	164
Relevant attacks	17	23	63	68	31
Non-relevant attacks	66	112	289	121	133
Snort alerts collected (unverified)	77	135	342	179	171
TP	15	22	63	66	31
FP	60	112	279	111	140
FN	2	1	0	2	0
Accuracy (%)	20	16	18.4	37.2	18.1
Detection rate (%)	88.2	95.6	100	97	100

4.3.1 Performance evaluation of the verifier component

To evaluate the effectiveness of the verifier component, we employed two parameters: detection rate and accuracy. Detection rate represents the number of attacks that are detected by IDS among all relevant attacks that are generated. Accuracy represents the percentage of relevant attacks detected versus all cases detected as attacks by IDS. We used the following abbreviations: true positive (TP) represents the attacks that are correctly detected, false positive (FP) represents the attacks that are incorrectly detected, and false negative (FN) represents the attacks that are not detected. The equations of the parameters are listed as follows:

• 

To find how much improvement is achieved by using the verifier component, we used these parameters before and after deploying the verifier component. Table 4 shows the detection rates and accuracy of IDS without the verifier component. The tabulated result indicates that most of the alerts are generated because of the ineffectiveness of IDS. The IDS detected most of the relevant attacks, but it did not perform well on non-relevant attacks, hence generating high numbers of alerts. The accuracy of Snort alerts is between 16% and 37% as reflected in the same table. The low accuracy justifies the need to use alert verification to further improve the accuracy of the alerts.

Table 5 displays the results of accuracy and detection rates after employing the verifier component. This table shows how alerts are further eliminated by the verifier because they are correlated with the threat profile of the test bed. We noted that most of the relevant attacks are accurately detected. The first row of Table 5 shows the raw alerts from Snort. The second row shows the number of alerts retained after alert verification. The third, fourth, and fifth rows represent TP, FP, and FN, respectively, after alert verification. In addition, the table shows how the verifier increases the accuracy of Snort alerts. For example, the accuracy of DoS attacks increased from 20% (Table 4) to 93.3% (Table 5). Accuracy for Telnet, FTP, MySql, and SQL attacks is improved to above 95%. This is because of the use of network-specific vulnerabilities to validate the alerts.

Table 5. Accuracy and detection rate of validated alerts (verifier component).

Alerts/Class	DoS	Telnet	FTP	MySql	SQL
TP, true positive; FP, false positive; FN, false negative.
Snort alerts collected (unverified)	77	135	342	179	171
Validated alerts (alerts retained)	15	22	63	66	31
TP	14	21	62	64	30
FP	1	1	1	2	1
FN	3	2	1	4	1
Accuracy (%)	93.3	95.4	98.4	96.9	96.7
Detection rate (%)	82.3	91.3	98.4	94.1	96.7

It is also noted that the verifier has minimally influenced the detection rates of Snort. From Table 5, the detection rates of Snort are slightly affected because the verifier component eliminated some alerts involving cases such as follows: IDS issues an alert for relevant attack, but the EVA data have not registered a corresponding vulnerability for this attack. We formulated a policy to address the aforementioned case and other similar cases where relevant alerts are ignored or considered as false alerts simply because they fail to match the vulnerabilities in the EVA data when being validated. The policy covers the following four cases:Case 1: IDS issues an alert on non-relevant attack, but the EVA data contain outdated vulnerabilities. As expected, the verifier identifies the corresponding vulnerability (that is outdated) in the EVA data that matches the alert (and yet the network is not vulnerable at all). This issue is difficult to address but can be minimized by frequently updating both IDS and the EVA data as well as removing the outdated vulnerabilities. Alerts in this case are considered as non-relevant alerts. Case 2: IDS issues an alert on non-relevant attack, and the EVA data do not contain a corresponding vulnerability because the network is not vulnerable to the non-relevant attack. For example, an IDS issues an alert in response to an attack that exploits a well-known vulnerability of a Windows operating system, but the system that the IDS is monitoring is a Linux operating system. This is a desired case; hence, alerts in this case are considered as non-relevant alerts. Case 3: IDS does not produce alert (false negative) on a relevant attack, and the EVA data have not registered a vulnerability corresponding to the relevant attack. This case is very difficult to address because IDS and the EVA data have no idea of the relevant attack. However, this is minimized by frequently updating both IDS and the EVA data. Case 4: IDS issues an alert on relevant attacks, but the EVA data have not registered a vulnerability corresponding to the relevant attack. This is a worse-case scenario, and such alerts are considered as non-relevant alerts. This is minimized by frequently updating the EVA data.

The validated alerts are tagged with the appropriate alert relevance depending on their alert relevance scores. Table 6 displays different categories of alerts based on their alert relevance. The ideal relevant alerts represent the ideal relevant attacks that fully exploited the vulnerabilities of the test bed, whereas partial relevant alerts represent the partial relevant attacks that partially exploited the vulnerabilities. The non-relevant alerts represent attacks that are not able to exploit the vulnerabilities. To tag the validated alerts with their respective relevance correctly, we performed a series of regrouping of alerts as mentioned in Section 3.

Table 6. Alert reduction on validated alerts.

Meta-alert type	Number of validated alerts (after being verified by verifier component)	Reduced alerts after using alert merger (in form of meta-alerts)	Reduction rate (%)
DoS	15 (5 ideal, 10 partial)	8 (2 ideal, 6 partial)	46.7
Telnet	22 (9 ideal, 13 partial)	10 (4 ideal, 6 partial)	54.5
FTP	63 (18 ideal, 45 partial)	29 (10 ideal, 19 partial)	54.0
MySql	66 (22 ideal, 44 partial)	34 ( 13 ideal, 21 partial)	48.5
SQL	31 (13 ideal, 18 partial)	13 ( 4 ideal, 9 partial)	58.1

We noted that not all vulnerabilities have CVE ids and not all Snort alerts have CVE ids. In fact, we noted that Snort generated the highest numbers of alerts with CVE ids on SQL and MySql attacks, whereas DoS attacks had the least. To improve the accuracy of alert relevance score as mentioned earlier, we included additional attack references that are comparable to Snort such as OSVDB ids and Bugtraq ids. We experienced a challenge when drawing a line between partial relevant alert and non-relevant alert. As indicated in Table 3, we chose a score of 0–3 to represent non-relevant alerts. This is based on an observation we made that some non-relevant alerts had a match on IP address, port or time and rarely recorded a match in all three features.

The verifier component appears effective in eliminating most of the non-relevant alerts generated by IDS. In particular, the ICMP traffic (due to ICMP flooder) contributed the highest number of alerts in DoS class. The ICMP traffic interrupted TCP services running in the target machine. The IDS generated high number of non-relevant alerts on ICMP traffic, and most of these alerts did not imply the occurrence of probing activities but were mere information events indicating the occurrence of network outage. ICMP traffic represents 25% of the non-relevant attack of DoS class. Other leading contributors of non-relevant alerts include the following: INFO telnet login incorrect (telnet class), INFO FTP bad login (FTP class), SQL injection (SQL class), and SSL hello message overflow (MySql class).

4.3.2 Evaluation of the alert merger component

We noted that validated alerts from different classes of attacks contain massive number of redundant alerts. These redundant alerts are close in time or distant in time. We observed that volumes of related alerts for multistep attacks are generated by IDS within a short period. To illustrate this, we refer to a specific scenario of multistep attack exploiting the vulnerabilities of FTP server. The IDS generated numerous alerts on this scenario for the first 3 min as compared with the rest of test period. However, the IDS failed to establish the relationships among these alerts. The redundant alerts may overwhelm the analysts when analyzing the attack trends, hence the need to eliminate the redundant alerts.

To evaluate the effectiveness of the alert merger component, we employed Alert Reduction Rate parameter. It represents the percentage of filtered alerts by the system. We used the following abbreviations: N represents the total number of alerts, and N_f represents the number of alerts filtered by the system. The equation of the parameter is listed as follows:

• 

Table 6 contains data of unmerged and merged alerts in each class of attack. The table shows the reduction rates after employing the alert merger component. In this table, we can see that validated alerts are further reduced and presented in the form of meta-alerts. Alerts are significantly reduced by rates of between 46.7% and 58.1%. It is important to note that these rates do not take into account of 707 non-relevant alerts that are eliminated by the verifier component.

The alert merger component is able to forward the alerts to their corresponding submergers accurately. We remark that the alert merger runs the suitable merging procedure for each submerger. To optimize the detection of unknown attacks, the undefined attack submerger handles any alert with a mismatch in class of attack or any other attack that have not been defined during the design of the alert merger. These alerts are further analyzed by analysts and later used to make the necessary updates as well as the removal of inconsistencies in the EVA data.

When evaluating the meta-alerts, we noted that long attacks generate more than one meta-alert, whereas shorter attacks generate one meta-alert. The alert merger component successfully reduces the redundant alerts of different attacks as illustrated in Table 6. However, our alert merger may not be able to completely reveal attack patterns especially when real attack period is longer than the expected exploit cycle time. This is explained by the fact that our approach only considers meta-alerts within the set EC_time value.

4.4 Processing time of the proposed approach

To measure the efficiency of the proposed system, we recorded the maximum time to process the alerts. An alert in the verifier component takes 0.033 s (including alert preprocessing time), and 0.192 s in the alert merger. This means that an alert can be processed completely in the two components within 0.218 s. Our approach does not introduce sensible delays; hence, the analysts are able to react early enough against the attacks. The processing speed can be improved by incorporating better searching algorithm and representation of vulnerabilities in the EVA data.

4.5 Comparison with other alert management approaches

The proposed approach offers superior performance. It reduces the redundancies in validated alerts, thus helping the analysts to make the right decision about the final alerts. More so, alerts are grouped according to their relevance, thereby enabling the analysts to focus on the most important alerts. No extensive training is needed for the proposed system. In terms of configuration, this approach is very efficient and easy to use. It can be applied to other signature-based IDSs without configuring their default signatures. EVA data have to be updated with the attack reference details of those IDS products. However, our approach experienced some challenges that affected its performance. The verifier encountered situations such as follows: IDS issues an alert for relevant attack, but the EVA data do not have a corresponding vulnerability for this attack. Although we formulated a policy to guide the alert verification, our approach does not offer an effective solution regarding the unknown vulnerabilities and attacks. Generally, the vulnerability-based alert management approaches are not very effective in dealing with unknown vulnerabilities and attacks [7]. Another challenge is when drawing a line between partial relevant alerts and non-relevant alerts. Other challenges are mentioned in the Section 5 as part of our future work.

Table 7 shows the comparison of the proposed approach with that of [1] and [16]. We computed the comparison rates (reduction rates, accuracy, and detection rates) using the functions discussed earlier in this section. The table shows that the proposed approach has the best reduction rates of redundant true positive alerts. This is because our system has six submergers dedicated to different classes of attacks that are well configured to reduce the redundant alerts. The submergers deliver their output in the form of meta-alerts. Our system has a minimum negative impact on the detection rate of IDS. In terms of accuracy, the work in [1] exhibits a slightly higher accuracy than our approach because of the use of neural network that is trained to process the raw alerts. In addition, we remark that the alert verification process improves the accuracy of alerts as shown in the proposed solution and in [1]. Finally, the proposed solution has additional features such as alert prioritization that assist the analysts to manage alerts.

Table 7. Comparison with other approaches.

Approaches		Hubballi et al. [1]	Sourour et al. [16]	Our approach
Techniques		Vulnerability-based alert filter	Alert correlation	Vulnerability-based alert reduction
Initial alerts (input)		1756	753	904
Reduction rate of false positives (%)		78.5 (after filtering)	30.9	78.2 (after verification)
Reduction rate of redundant positive alerts (%)		—	33.0	52.4
Parameters	Accuracy (%)	97.0	10.9	96.1
	Detection rate (%)	95.5	95.3	92.6

5 CONCLUSION

This paper proposes a fast and efficient approach to reduce volumes of redundant alerts generated by signature-based IDS. The proposed approach has two major components: verifier and alert merger. The verifier component improves the quality of alerts by validating them with vulnerabilities contained in the EVA data. The alert merger component reduces the redundancy in validated alerts. The final alerts are presented in the form of meta-alerts. We conducted experiment to demonstrate the effectiveness of this approach by processing alerts from five different classes of attacks. We recorded impressive results in terms of reduction of redundant alerts while closely maintaining the detection rate of IDS.

As part of our future work, we are planning to address several challenges. The way IDS products and vulnerabilities reference each other does not allow efficient correlation of alerts and their corresponding vulnerabilities. We designed a mapping facility, which is not as flexible and scalable as we wanted because it is manual based, that maps attack reference details into EVA data. However, this is the first step towards realizing our desired goal of having an automated facility that maps attack details into EVA data. In addition, there is a trade-off concerning accuracy and detection rate. Hubballi et al. [1] note that the trade-off can be exploited by taking into consideration the criticality of network resources. For critical resources, false negatives should be kept at minimum (detection rate should be high) at the cost of some false positives (lower accuracy), whereas less critical resources (higher accuracy) should be maintained at the cost of some false negatives. Finally, there is a need to include a mechanism to explore relationships among meta-alerts to gain deeper understanding regarding the different classes of attacks.

ACKNOWLEDGMENT

This work is partially supported by Hunan University—College of Information Science and Engineering. We are grateful to the anonymous reviewers for their thoughtful comments and suggestions to improve this paper.