Rule-based event correlation

SIEMs, the security systems for log collection and correlation (see page 19), gener- ally apply rule-based reasoning [Müller 2009], which is based on the identification of matches between collected events and static correlation rules. The rules represent a set of conditions to be met by a set of events for raising an alert and they are written by security experts. They can be general or adapted to the characteristics of the network where the monitored devices are placed. Many commercial SIEMs base their detection mechanisms on rules furnished by the vendor [Oliver Rochford 2016] in combination with specific rules crafted by the security analysts in the organization.

The set of conditions represented in a rule can follow a specific order or not. For example, imagine a set of three conditions: “find event A”, “find event B” and “find event C”. We can define a rule looking for the fulfillment of the three conditions in any order: “find event A, B and C in a certain time window WT”. This is what we

call a non-ordered rule. But we can also define a rule where the order is important, an ordered rule: “find event A and then event B and then event C in a certain time window WT”. The specification of a time window WT limits the time during which the

search of conditions take place. This is necessary to limit the usage of computational resources in the SIEM. Henceforth, we only consider ordered rules, which better fit the idea of a multi-step attack as a sequence of actions.

In a SIEM applying rule-based reasoning on ordered rules, there is a linear check of each incoming event against the beginning of each rule. If an event matches the first condition of a rule, a new detection thread is opened to wait for other events matching the rest of the conditions in that rule. Different rules have forcibly some points in common. In that case, the search of following events is done concurrently for all the rules whose first conditions are matched so far. This would be the case of the LLDoS 1.0 and LLDoS 2.0.2 attacks, contained in the dataset DARPA 2000 (section 3.2.2, page 31). The second step of LLDoS 2.0.2 is the same as the third step in LLDoS 1.0, and the two last steps also involve the same actions in both attacks.

5.1. From Concrete to Abstract ASG 111 SAO SAO Ad Ad Rsh FTP_Put MSZ MSZ SAO Ad Rsh FTP_Put MSZ

LLDoS 1.0

LLDoS 2.0.2

SAO = Sadmind_Amslverify_Overflow, Ad = Admind, MSZ = MStream_Zombie

Figure 5.4: Combination in a graph of two detection rules for DARPA 2000 The conditions in an ordered rule can be represented in the form of a graph, as a sequence of nodes. In Figure5.4, we represent two sequences of conditions character- izing the steps 3 and 4 of LLDoS 1.0 and the steps 2, 3 and 4 of LLDoS 2.0.2. The conditions are expressed as the search for a RealSecure3_{IDS alert of certain type in the}

set of incoming events. We use only the type of alert in each step to keep it simple and because it serves well to the purpose of the explanation. Nevertheless, rules generally contain other conditions based on other event attributes, such as the IP addresses or the port numbers.

What is interesting is that we can easily merge the two rules together in only one graph, such as the one shown in the right side of the figure. The concurrent search of alerts is then done as follows:

1. If the system finds an alert of type ‘Sadmind_Amslverify_Overflow’, a new de- tection thread is opened to search for alerts matching the subsequent conditions. 2. The system searches for an alert of type ‘Admind’. So far the process for finding

the two attacks is the same.

3. The detection thread looks for an alert of type ‘FTP_Put’ or one of type ‘Rsh’. Depending on which of the two alerts is found the match corresponds to LLDoS 3_{RealSecure is a brand of IDS, used by many authors in the extraction of alerts in DARPA}

2000 [Ning 2004a, Zhu 2006, Yu 2007, Liu 2008, Sadoddin 2009, Farhadi 2011, Anbarestani 2012,

1.0 or LLDoS 2.0.2.

4. Independently of which is the path taken in the graph, both rules finish with a condition referring to the same type of alert (‘MStream_Zombie’).

The SIEM finally triggers an alert if all the conditions in a rule are matched or, in other words, when the end of a graph representing a rule is reached. Again, if a rule is not completely matched within a certain time window WT, the detection

thread in charge of analyzing this rule is closed. This classical method is used by many correlation systems, such as OSSIM4 _{(Open Source SIEM), whose open code has}

helped to widely disseminate the idea of security event correlation [Alien Vault 2014]. The structure of AASGs and the mechanism to use them is directly inspired by ordered rules in rule-based event correlation. There are at least two reasons to take them as a reference. First, the expression of rules in the form of statements ‘if ... then’ is very intuitive for the human security analyst. At the same time, the possibility of arranging the rules in a graph is suitable for their use by automatic algorithms, as it is done in SIEMs. The requirements of simplicity and intuitiveness, and of computation friendliness (numbers 2 and 4, respectively, in the list defined in section5.1.2) are thus met by the graphs for rule-based event correlation. We take therefore this model as the reference on top of which we append additional features to meet the rest of the defined conditions and fully define the AASG.