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.  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  is almost similar to what we have proposed as shown in Figure 1. We have slightly modified the architecture of  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  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  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 , 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 , 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 IPdest 192.168.1.3 on Portdest 1238. Using the IPdest of this alert, the verifier extracts all the potential vulnerabilities in the EVA data in Table 2 that match this IPdest. In this case, the EVA data have only one vulnerability matching the alert's IPdest. 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|
|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.
|9||Ideal relevant alerts (ideal relevance)|
|4–8||Partial relevant alerts (partial relevance)|
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. . 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.
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.createtime)—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.Nbrealerts)—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.updatetime)—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-updatetime)—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.stoptime)—defines the time when meta-alert is assumed to have completely fused the needed alerts.Meta-alert time out (M.Timeout)—measures the time that a meta-alert should continue waiting for additional alert(s). It varies with class of attack.Exploit cycle time (ECtime)—measures the time that an exploit is believed to take (attack period). It varies with class of attack.Additional data include source address (M.IPsrc and M.Portsrc) and destination address (M.IPdest and M.Portdest).
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.IPsrc and Alert.IPdest) of a given validated alert to identify the potential meta-alerts (i.e., M.IPsrc and M.IPdest of meta-alerts that match Alert.IPsrc and Alert.IPdest). 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.IPsrc,M.IPsrc) and (Alert.IPdest,M.IPdest). If IP addresses matched, then IP similarity = 1; else, IP similarity = 0.Port similarity—compare (Alert.Portsrc,M.Portsrc) and (Alert.Portdest,M.Portdest). If Ports matched, then Port similarity = 1; else, Port similarity = 0.Time similarity—If Alert.Time ≥ M.createtime and M.non-updatetime < M.Timeout, 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.Nbrealerts is incremented, M.non-updatetime is reset to 0, and M.updatetime 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.Nbrealerts is set to 1, M.updatetime is updated, M.non-updatetime is reset to 0, the timestamp of the alert becomes M.createtime, 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-updatetime < M.Timeout) 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.Nbrealerts is incremented, M.non-updatetime is reset to 0, and M.updatetime is updated. If the existing meta-alert's non-update time is equal or more than meta-alert time out (M.non-updatetime ≥ M.Timeout), then the meta-alert stop time (M.stoptime) 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.Timeout parameter ensures that the necessary alerts are fused to a given meta-alert, whereas the ECtime parameter ensures that all the meta-alerts of a given attack are generated accordingly. In our approach, the values set for M.Timeout and ECtime vary with class of attack. Therefore, each submerger has its own M.Timeout and ECtime. Both M.Timeout and ECtime of a given meta-alert are not necessary equal. The M.Timeout of a given meta-alert could be lower than ECtime of the same meta-alert because most events forming the different steps of attacks are generated in the early stage of an exploit cycle . 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.Timeout as this could lead to unreasonable delay of meta-alerts. In addition, an ECtime 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.Timeout and ECtime 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.  that is applied in a network address translation environment. Our approach and that of Sourour et al.  share some variables that define the meta-alerts. In fact, most of the correlation systems such as that of Perdisci et al.  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  and  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. . 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  and Perdisci et al.  use only one correlation schema to correlate alerts of different attacks. However, reference  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.  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 (Tout) 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.