Automatic multi-step attack pattern discovering

Transcription

1 nternational Journal of Network Security Vol.xx No.xx PP.xxx xxx xxx Automatic multi-step attack pattern discovering Li Wang Ali Ghorbani Yao Li Faculty of Computer Science University of New Brunswick Fredericton New Brunswick Canada ( Abstract Current techniques employed in security alert correlation area for multi-step attack recognition purpose are intricate to be performed due to the complexity of the methods and huge computing workload generated during alert analysis and processing. n this paper we proposed a new method of alert correlation aiming at providing concentrated security event information and thus finding multi-step attack patterns accordingly. We use a kind of extension time window when aggregate the alerts into high level alerts. We then connect hyper alerts into candidate multistep attack patterns according to their P address association. The final real multi-step attack patterns are discovered from these connected attack patterns with quantitative correlation calculation method. The method is easy to implement and practical to deploy which is proved by the result of our experiments. The experiment also shows our approach can effectively find real multi-step attack behavior patterns and can be used to identify true attack threats. Key words: Extension time window alert correlation multi-step attack pattern correlativity ntroduction The information security industry has been very active in recent years. n order to counterwork security threats to computer systems and networks many technologies have been developed and applied in security operations such as DS firewalls routers. All those security application devices whether aimed at prevention or detection of attacks usually generate huge volumes of security audit data. Deploying information security systems can provide in-depth protection for networks. However large volume of security data which is the output of different security sensors can overwhelm security managers and keep them from performing effective analysis and initiating timely response. Therefore it is important to develop an advanced alert correlation system that can reduce alert redundancy intelligently correlate security alerts and detect attack strategies. Correlating security alerts and discovering attack strategies are important components of such systems.. Related works Up to now there have been several proposed techniques of analyzing attack scenarios from security alerts. However most of these approaches depend on complex correlation rule definition and hard-coded domain knowledge that lead to their difficult implementation and limited capabilities of detecting new attack strategies. n [2-4] Cuppens et al. correlates alerts if the prerequisites of some later alerts are satisfied by the consequences of some earlier alerts in MRADOR correlation method. The attack base was specified in LAMBDA and was analyzed to generate correlation rules to be used to construct attack scenarios. Ning et al. [5-7] use similar method with theirs. They construct attack scenarios through alert correlation using prerequisites and consequences of attacks in

2 Automatic multi-step attack pattern discovering TAA correlation method. Both approaches are based on the observation that in a series of attacks the attacks were usually not isolated but related as different stages with the earlier stages preparing for the later ones. Such methods can potentially uncover the causal relationship between alerts but they need to define the specification of attacks and the attack plan recognition results rely on the precision of the correlation rules. Such limitations make the methods difficult and complex to implement. BM researchers also have made some efforts on the techniques of alert aggregation and alert verification. Araujo et al. [8] presents a method of mining correlation rules from hand-labeled training examples by using rule wizard and rule editor. t is integrated in the BM Tivoli Event Console (TEC). t enables automatic creation of rules which helps operators by providing a simple way to create rules based on observed events but it relies on the expertise knowledge and manual configuration. Julisch et al. [9-0] introduce the concept of root cause and propose an alarm clustering method to support the discovery of root cause which can help remove most of the redundant alarms that can be attributed to a small number of root causes. This method also need expertise knowledge and can not solve the problem of false negative. Valdes et al. [] proposed a probabilisticbased approach to correlate and aggregate security alerts by measuring and evaluating the similarities of alert attributes. They use a similarity metric to fuse alerts into meta-alerts to provide a higher-level view of the security state of the system. Alert aggregation and scenario construction are conducted by enhancing or relaxing the similarity requirements in some attribute fields. But similarity calculation is the only way for them to aggregate the alerts. They have to compare all the alert pairs and have to determine a lot of thresholds with expert knowledge which lead to their huge volume of computing workload. Sheyner and J. W. Wing et al. [2] proposed a model checking based technique to automatically construct attack graphs. Although it helps facilitate the task of defining attack graphs it has the limitation of scalability especially for larger network and systems. n [3-4] Wenke lee and Xinzhou Qin proposed a GCT-based and Bayesian-based correlation approach to identifying new alert relationship without depending on prior knowledge of attack transition patterns. The method originates from the idea that attack steps are directly related because an earlier attack enables or positively affects the later one. But the method can only detect scenario segment by mining related alert pairs and the analysis of alert pairs results in huge computing workload which also leads to the limitation of the final multi-step discovering result. All the existing methods in security alert correlation area have their limitations. They either depend on complex correlation rule definition or depend on hard-coded domain knowledge. Most approaches are lack of flexibilities and adaptability. These drawbacks lead to their difficult implementation and limited capabilities of detecting new attack strategies. n addition most of them are off-line processing. To solve the problems of complex rule definition and fragmentized attack scenario construction we proposed a new method of attack scenario construction []. Our multi-step attack correlation method has two components. We first mine multi-step attack activity patterns with attack sequential pattern mining method from history aggregated high level alerts which we call security event data. We then match the events online to identify the events which accord with certain attack sequential pattern and correlate them using a quantitative method. Therefore attack plans of the attackers can be recognized and the next step the attacker will take can be predicted accordingly. While this method requires good integration of history 2

3 nternational Journal of Network Security Vol.xx No.xx PP.xxx xxx xxx database which should include various multi-step attack instances. This paper focuses on discovering multi-step attack strategies via the analysis of security alerts based on a new alert correlation method. We first aggregate all the alerts into three types of hyperalerts and then connect these hyper-alerts according to their P address attribute associations. With the connected hyper-alert links which are the candidates of multi-step attack patterns we analyze the relationship between contextual nodes of each link to find out all the meaningful multi-step attack patterns..2 Organization of the paper We discover multi-step attack patterns in four phases: i) Aggregation Phase ii) Candidate Attack Link Generation Phase iii) Pattern Correlation Phase iv) Real Attack Discovery Phase. Section 2 introduces the overview of our work. Section 3 gives this problem decomposition. Section4 proposes the algorithm of the problem. Section 5 reports our experiments with the 2000 DARPA intrusion detection scenario specific datasets and live data collected from our test bed. We conclude with a summary and directions for future work in section 6. 2 About Our Work 2. Overview of our work Fig. System architecture. Figure shows an overview of our system architecture. There are four main modules in our system including: alert normalization alert aggregation hyper alert connection multi-step pattern discovery. All the security reports of these four procedures are output through our web user interfaces. Data collection and alert normalization module can be functionally divided into two parts: the agent sub-module which is installed on the sensor-side reading and normalizing reports from log files generated from different security application devices continuously and sending them to the server and the server sub-module which manages all the agents receives the security data and stores them in alert database. Alert aggregation function merges the alerts according to their P address similarities and time attribute associations into three types of hyper alerts. Alert aggregation module thus combines repetitious and redundant alerts in order to provide more synthetic information to security manager and to the following module. After that the hyper alert connection function find out those related hyper alerts with associated destination and source P addresses or same source P addresses and connect them to form candidate multi-step attack patterns (pseudo attack links). The final multi-step pattern discovery module takes the result of hyper alert connection function and further analyzes the correlativity between contextual node pair in these pseudo attack links to find out meaningful multi-step attack patterns. With the attack patterns we can create rules for detecting multi-step attacks and thus recognize the attack plans of the attackers or even predict the next step the attacker will take. 2.2 Terminology We define some time windows used for alert aggregation processing and alert connection processing. They determine the associate time window when processing raw alerts or hyper alerts. We also define three different types of hyper alerts in this section which represent three different kinds of hyper alerts having different synthetical features according to their P address associations besides attack type and timestamp features.

4 Automatic multi-step attack pattern discovering 2.. Time Window Definition Event time window defines the time interval within which all the alerts aroused by same security event are interspersing. Event time window can be considered as the maximum delay for two alerts aroused by same security event. So when aggregate the alerts together those which fall into the same event time window can be considered to aggregate into a hyper alert. Definition. Security Event time window W. Consider that SE a and a are the first and last k alerts received which are aroused by the same security event SE a i ( < i < k) is any alert between a and a which is also aroused by k SE then we get a. attack _ type = a2. attack _ type =... = ak. attack _ type. For SE and a ai ak SE we define event time window W SE satisfies the following inequation: Min( ai. timestamp a. timestamp) WSE. Max( ak. timestamp a. timestamp) We use inter-event time window term to describe the time interval that between two successively happened security events. This is useful to determine the size and location of event time window when doing alert aggregation. Since different delays exist in event detection and reporting by DS the event time window is flexible in different situations we use event time window appended with inter-event time window to help us group similar alerts together. Definition 2. nter-event time window W. E Suppose SE and SE are two security events 2 associated to two contextual event time window < a... a... a... a > ( i < j ) and i j n n < b... bk... bl... bm> ( k < l m) are the alert sequences corresponding to the two security events respectively. a. stamptime < b. stamptime in this situation SE is considered as occurring earlier than SE. We define 2 W E _ as: Min{( ai a j )( bk bl )} WE _ Max{( ai a j )( bk bl )}. Definition 3 Attack Scenario time window W. Consider that AS h and h are the hyper k alerts generated after aggregation phase and they correspond to the first attack step and the last attack step taken by the attacker in a possible attack scenario AS respectively. h i ( < i < k) is any hyper alert between h and h in AS that is k AS =< h... hi... hk > ( < i < k). Then we define W AS = AS. end _ time AS. begin_ time and for AS and h h 2 hk AS it satisfies following Min( hi. timestamp h. timestamp) WAS inequation:. Max( h. timestamp h. timestamp) k 2..2 Hyper Alert Definition For all the alerts fall into the same security event time window can be merged into hyper alerts according to the similarity of their attack type and P address attribute features. We defined three types of hyper alerts and defined them as follows: Definition 3. Type hyper alert. Suppose the alert sequence A =< a... ai... an > ( i n) locates in a W SE that means an. stamptime a. stamptime SizeofW SE if a. srcp = a2. srcp =... = an. srcp asrcp. ( ) i SP i n a. dstp = a2. dstp =... = an. dstp adstp. ( ) i DP i n and a. attack _ type = a2. attack _ type = at is the attack... = an. attack_ type= at type name defined by the system or simply integer signature D which corresponds to particular attack type. Then we can aggregate the alert set A into a type hyper alert represented as: at( SP DP AD T N ) in which refers to type hyper alert AD = { ai. alert _ D ai A a i n} T = a. timestamp N = AD. According to the definition type hyper alerts have the feature of having same source and 4

5 nternational Journal of Network Security Vol.xx No.xx PP.xxx xxx xxx destination P addresses as well as same attack type. Definition 4. Type hyper alert. For alert sequence B =< b... bi... bn > ( i n) received in a security event time window W if SE b. srcp = b. 2 srcp =... = bn. srcp = SP b. dstp... bi. dstp... bn. dstp and b. attack _ type = b2. attack _ type = at refers to some... = bn. attack _ type = at attack type. Then we can aggregate the alert set B = { b... bi... bn}( i n) into a type hyper alert represented as: at( SP DP AD T N ) in which refers to type hyper alert DP = { bi. dstp bi B i n} AD = { bi. alert _ D bi B i n} T = b. timestamp N = AD. According to the definition type hyper alerts composed of all the alerts in the same security event time window which have same source P address different destination P addresses and same attack type. Definition 5. Type hyper alert. For alert sequence C =< c... ci... cn > ( i n) received in a W if SE c. srcp c2. srcp... c. srcp c. srcp SP c. dstp =... ci. dstp =... cn. dstp = DP and b. attack _ type = b2. attack _ type =. Then we can... = bn. attack _ type = at aggregate the alert set C = { c... ci... cn}( i n) into a type hyper alert represented as: at ( SP DP AD T ) in which refers to type hyper alert SP is the P address set contains all the source P addresses of set C DP is the set with single value of destination P address of all the members in set C n i AD = { ci. alert _ D ci C i n} T is the timestamp attribute of hyper alert at( SP DP AD T N ) T = c. timestamp N = AD. According to the definition 3 type hyper alerts are composed of all the alerts in the same security event time window which have same destination P address and different source P addresses and same attack type. 3 Problem Decomposition After alert normalization phase we get standard alert database. Each alert in the database consists of the following fields: alert-id (id-number sensor-id) signature-id (attack type) timestamp source (source-p source-port) destination (destination-p destination-port) risk (reliability asset and priority) and protocol. 3. Alert aggregation Alert aggregation then merges the alerts into three types of high level alerts. Those who have same attack type and occur in a certain time interval are combined into a hyper alert according to the similarity of P address attributes. 3.. Extension time window technique When aggregating the alerts we use an extension time window technique to decide the size and the location of each event time window. The quantities of the alerts triggered by different security events are different varying from one to thousands. f we use event time window with fixed size to aggregate the alerts the settling of the window size is difficult. f it is set too large alerts aroused by different security events may be merged into one hyper alert. f it is set small the alerts belonging to same security event may be split into at least two parts. Both situations will result in inaccurate alert aggregation. Therefore we use a kind of extension time window for setting event time window when aggregate the alerts. Figure 2 gives the illustration of the idea of this extension time window technique. We apply a base event time window which has the basic size of all event time windows. That means the event time windows can be extended based on the base

6 Automatic multi-step attack pattern discovering event time window according to the particular situations. Fig. 2 llustration for alert aggregation processing. n figure 2 from left to right are the hyper alerts received one after the other. Hyper alert h to hyper alert h fall into the first base event time k window W. Then we examine the time SE _ interval between the last alert h k in W and the SE _ first alert h following the window if it is less k+ than or equal to the inter event time window size ε defined in advance we think alert h k and h k+ have close time association the event time window W expands to contain alert SE _ h. f the k+ time interval between h k+ and h is still less k+ 2 than ε repeat the same operation until the time interval between the last alert in current time window and the next following alert is larger than ε or until the times of window expanding operation exceed a certain predefined threshold number for example 500 times then the window stops extension and the next event window is supposed to begin. Compared with general sliding associated time window the extension time window is more flexible which can operate in different situations. t is also more efficient than the way of simply moving the window one by one alert thus it avoids the complexity of solving the overlap parts and also solves the efficiency problem caused by too many timers generated during window sliding. Figure 3 shows the algorithm of extension event time window used in generating event time windows during alert aggregation processing. From the algorithm we can see there are two criteria for event time window to be expanded. One is the time interval between the last alert in current event window and the first following alert exceeds the size of inter-event window. The other criteria is the extension for the number of extra alerts to be contained in one event window is no more than a certain predefined figure which means the window will not extend unlimitedly in busy network flow situation after collecting enough number of alerts the window will stop extension in case the event window expanding to an unreasonable size. input W =ε ex_alert_no=δ ; E W _ =α alert sequence from id 0 to id last_alert_id ( sorted by timestamp) begin i=0; j=0; n=0; while (j last_alert_id) do { if (alert(j).timestamp-alert(i).timestamp α ) j++; else if (alert(j).timestamp-alert(i).timestamp ε && n δ ) {j++; n++;} else { AggregatenEw(i j); j++; i=j; n=0; } } end while end SE base Fig. 3 Algorithm of extension event time window Alert aggregation method Figure 4 gives the algorithm of alert aggregation in one generated event time window. n alert aggregation processing we consider aggregate the alerts fall into an event time window into hyper alerts. We study the association between the alert attributes of attack type source P address and destination P address in a same event time window and aggregate the alerts into 3 types of hyper alerts as defined in section 2. After alert aggregation we keep the information of hyper alert type source P address set destination P address set alert D set timestamp number of raw alerts and window 6

7 nternational Journal of Network Security Vol.xx No.xx PP.xxx xxx xxx D. This information facilitates the following hyper alert connection and correlation processing. We can also study the similarity or other features between the alert sets hyper alert type or attack type frequency or the regularity of the timestamp for each similar pattern group to figure out if there exists any pattern which is caused by some system configuration error or some failure operations. input EW(i j) // alert sequence in a Event Time Window (start from alert id i and end with alert id j k is the current hyper alert id) begin H = H H H = ; //h_yper alert set for current EW k=i; while (i j) do { if ((alert(i).attacktype is new ) ((alert(i).srcp and alert(i).dstp are new) && alert(i).attacktype H )) { k++; create h_alert(k) in H ; add i to h_alert(k).ad; h_alert(k).n++; i++; } else if ((alert(i).srcp and alert(i).dstp are new) && alert(i).attacktype H ) { take h_alert(d) with attacktype alert(i).attacktype in H ; //d is h_alert id add i to h_alert(d).ad; h_alert(d).n++; i++; } else if (alert(i).srcp is new && alert(i).attacktype H H ) { take h_alert_id with same dstp in H H ; d= h_alert_id; remove alert(i).dstp from h_alert(d).dp; if h_alert(d).dp = { move h_alert(d) to H ; add i to h_alert(k).ad; h_alert(k).n++; i++; } else{ remove alert(l) with same dstp from H H ; k++; create h_alert(k); add alert(l) to h_alert(k) add alert(i) to h_alert(k); add h_alert(k) to H ; i++; } } //end of if (alert(i).srcp is new && if (alert(i).srcp is new && alert(i).attacktype H { take h_alert_id with same dstp in H ; d= h_alert_id; add alert(i) to h_alert(k); i++; } else if (alert(i).attacktype H H ) { take h_alert_id with same srcp in H H ; d= h_alert_id; remove alert(i).srcp from h_alert(d).sp; if h_alert(d).sp = { move h_alert(d) to H ; add i to h_alert(k).ad; h_alert(k).n++; i++; } else{ remove alert(l) with same srcp from H H ; k++; create h_alert(k); add alert(l) to h_alert(k) add alert(i) to h_alert(k); add h_alert(k) to H ; i++; } } //end of if (alert(i). attacktype H H else { take h_alert_id with same srcp in H ; d= h_alert_id; add alert(i) to h_alert(k); i++; } // end of if ((alert(i).attacktype is new ) } end while end output H. Fig. 3 Algorithm of alert aggregation. 3.2 Multi-step attack pattern recognition 3.2. Candidate attack link After alert aggregation we merged low level alerts into three types of hyper alerts. A ( SP DP { 2} T 2 W ) is an examples of hyper alert after aggregation processing. A refers to attack type. means hyper alert type. SP and DP are source P address set and destination P address set respectively. t also contains raw alert D set timestamp number of corresponding raw alerts and event time window D. We sort all the hyper alerts according to their timestamp attribute and connect them according to their P address associations. The condition of connecting two hyper alerts together to form candidate attack link is that h and h 2 can be connected is they satisfy: ( h. SP h 2. SP or h. DP h2. SP ) and h2. timestamp h. timestamp W. AS

8 Automatic multi-step attack pattern discovering For contextual attack steps involved in the same multi-step attack their source P always have associations or the destination P of the previous step and the source P of the next step usually have similarities or associations. So if two hyper alerts meet such condition we consider connect them to form candidate attack links. The final real multi-step patterns can be further detected from these candidate attack links. The foundation of doing so bases on the observations that in multi-step attack aroused by certain attacker the source P and destination P address always have some association or are the same. For example the attacker first scan the target network then select a target host from the result of the first step to exploit it. The source P address should be the same. n another case the attacker installed a daemon program on the victim host then victim host attack the target. The destination P address of the former step contains the source P of the latter step Filtering phase n this phase we filter out segment attack links from the result of hyper alert connection processing. We fist remove all the short links which are contained by other longer links to remove attack scenario segment. We also study the similar links with periodical features to remove them. Because periodically happened attack links are caused by some system configuration error or some normal network activities they are not the real attack we are looking for. After filtering we get pseudo-attack-link in the form of connected hyper alert links. We correlate the contextual nodes in pseudo-attacklink to determine whether they have real correlationship or just happen to be connected together Correlation phase For the same intension of attack steps in an attack scenario there is relationship existing between two attack steps except their time association. For example the attacker takes an PSweep action first and then inquires about the vulnerability. The source P or other attributes of the two steps maybe similar or may have relationship more or less. The alert association describes the correlation-ship of the two alerts. The larger the alert correlativity is the more possible they belong to the same scenarios. The alert correlativity measures the relationship between two hyper alerts. The correlativity between hyper alerts h i and h is j determined by the formula: p HC( h h ) w HAC( x y )/ w = i j ij i j ij i j= i j= h and i h are described by p attributes x j x 2 x p and y y 2 y p respectively. The correlativity between h i and h is described j as the weighted sum of their attribute correlativity HAC( xi y j). Currently we only consider four attributes of hyper alert which contribute the value of HC( hi h j) they are source P address destination P address source port number destination port number. Table gives the weight matrix. For the sake of standard normalization computation the sum of all weights in the table is. n addition since h is earlier than i h the matrix is not symmetrical. j The weight values are set empirically and can be tuned in practice. Small deviation of weight setting will not affect the accuracy of final correlation result since we only calculate the correlativity between two alerts which accord with certain pattern already. They either have strong relationship or not depending on they either belong to the same attack scenario or not. Table : W ij weigh matrix i\j SrcP DstP SrcPort DstPort SrcP DstP SrcPort DstPort p 8

9 nternational Journal of Network Security Vol.xx No.xx PP.xxx xxx xxx Hyper alert is composed of more than one raw alert. Therefore attribute values of every alert are sets with various data type elements. For example an P address type attribute of a hyper alert is an P address set instead of a single P address. t can be represented as: {P P 2 P n- P n } (n>=). Since the hyper alert attribute values are set values instead of single value types. We need to determine the calculation of correlativity between set values. For the problem of computing the distance between two sets we need to classify the set first and then do the computation. The existing classification algorithms are complicated and are not suitable for online processing especially for this particular question. We use our CTG (correlation tree graph) method here to define the alert attribute value classification and correlativity. According to alert correlativity definition we should determine the following alert attribute correlativity functions shown in table 2. We need to determine the method of evaluating the correlation-ship between P address sets port number sets. Table 2: Alert attribute correlativity involved in alert correlativity definition Alert Attribute Correlativity HAC(SrcP i SrcP j ) HAC(SrcPort i SrcPort j ) HAC(DstPort i DstPort j ) HAC(DstP i SrcP j ) HAC(DstP i DstP j ) HAC(SrcP i DstP j ) Function type between P address sets between port number sets between port number sets between P address sets between P address sets between P address sets Before determine the correlativity between two sets we should first classify the set value to a designated class. The classification threshold is 80%. P address data type parameter is very important reference of measuring the level of final alert correlativity. Figure 5 shows the CTG for P address type alert attribute value. The classification and correlativity of P address sets are defined by a correlation tree graph structure. We use this CTG definition to get the value of alert attribute correlativity especially with P address data type. First we use the CTG in figure 5 to classify the P address type alert attribute value. Situation : Suppose we need to determine the value of HAC(S S 2 ) which is the correlativity between two sets S and S 2 with P address data type S ={ } and S 2 ={ }. We first determine each set belongs to which node of the CTG in figure. The classification threshold is 80%. t is not hard to figure out that S and S 2 all belongs to node since more than 80% elements of both sets belong to this node. According to the definition given in figure 5 we get the correlativity between S and S 2 is that is HAC(S S 2 ) = which means there is maximum correlation-ship existing between S and S server 0.3 nside Station All P A Class 0 Outside 0.2 B Class P in P in P in P in P in A B C D Other Fig. 5 CTG for P address type attribute correlativity definition Situation 2: To determine the value of HAC(S 3 S 4 ). S 3 = { } belonging to server node in CTG and S 4 = { } belonging to station class by searching the CTG in figure 5 we get the result: HAC(S 3 S 4 ) = 0.3. Situation 3: Consider the correlativity between S 3 and S 5 (S 3 belongs to server class and S 5 belongs to outside class) then the result according to the definition in figure is 0. 0 is C Class 0.2 D Class Other 0.6

10 Automatic multi-step attack pattern discovering the minimum of correlativity which means the two sets representing two alert P address attribute values have no relationship. That is they have the least possibility of belonging to the same attack scenario. Correlativity between Port address data type sets is another important factor for the degree of alert correlativity. Figure 6 shows the CTG for Port address type alert attribute correlativity. Each node of CTG represent different class of Port address set and the figure besides the node represents the correlativity between two child nodes of this node. For each port address type alert attribute value it can be represented as: {p p 2 p n- p n } (n>=). The classification threshold is 80% if more than 80% elements of the set belong to one node then the set is classified to the class represented by the node. For example: Privileg ed All Ports NonePr eviliged Fig. 6 CTG for Port address type attribute correlativity definition Situation : Given HAC(P P 2 ) P = {80} P 2 = { }. Both P and P 2 belong to the class 80 the node with port number 80. From figure 6 we get the correlativity of the two sets is that is HAC(P P 2 ) =. Situation 2: Given HAC(P 3 P 4 ) P 3 belongs to node 2 P 4 belongs to node Privileged their parent node is Privileged. Therefore according to the port address CTG definition in figure 6 HAC(P 3 P 4 )=0.5. Situation 3: Given HAC(P 3 P 5 ) P 3 is classified to node 2 and P 5 belongs to the class None Privileged. By querying the CTG in figure 6 we get the correlativity of the two sets is 0 that means P 3 and P 5 have no relationship with each other. They have the minimum possibility of contributing to the degree of alert correlativity Recognition phase We calculate the correlativity of each contextual pair nodes in each pseudo attack link. Remove those attack links with low correlativities. We also split a link into two parts if a low correlativity result is found between two nodes to remove any meaningless segment attached to a real attack link. After this recognition phase all the attack links which have real relationship between all their contextual pair nodes are kept. The links with low correlativities are considered having no real associations between neighbor nodes and are dropped after processing. 4 Experiment To evaluate the effectiveness of our method we applied our algorithm to DARPA 2000 benchmark repository scenario-specific datasets [5] and live data collected from our honey-net test platform. DARPA 2000 datasets consist of two intrusion scenarios LLDDOS.0 and LLDDOS2.0.2 [MT Lincoln Lab 2000]. LLDOS.0 contains a series of attacks in which an attacker probes breaks in installs the components necessary to launch a DDoS attack and actually launches a DDoS attack against an off-site server. We use playback technique (Open source tool Tcpreplay32 [6]) to induct the workflow to the DS sensors integrated in the system. We then use the alerts reported by RealSecure and Snort as the input of our approach. Table 3 shows the aggregation and correlation result of our method with Event time window and Attack scenario time window setting to 5 minutes and 60 minutes respectively. Aggregation rate is defined as: # of _ raw _ alerts # of _ hyper _ alerts. C_AL means the # of _ raw _ alerts number of candidate multi-step attack links after 0

11 nternational Journal of Network Security Vol.xx No.xx PP.xxx xxx xxx hyper alert connection process. P_AL means the number of pseudo-attack-links after subset filtering process. F_AL means the number of final meaningful attack patterns discovered from pseudo-attack-links with hyper alert correlativity verification process. Drop rate is defined as: # of _ P _ AL # of _ F _ AL. We set correlativity # of _ P _ AL threshold as 0.4. The attack links which contain correlativities lower than 0.4 are dropped from the final attack patterns. n our DARPA test all the dropped attack links are meaningless multistep attack patterns. They happened to be connected together when using P address associations to connect them. Correlativity calculation can reduce this part of attack links and keep those meaningful attack patterns which correspond to real multi-step attacks. Figure 7 shows some examples of dropped patterns after correlativity checking. They are dropped for their low correlativities between contextual nodes in connected attack links. From the example of figure 7 (b) we can see that althought the involved contextual attack types are the same the correlativity is not always high. This demonstrates that correlativity is a good way to evaluate the relationship between contextual two steps in a multi-stage attack other than the similarity of two alerts. Fig. 7 Examples of dropped attack links after correlativity checking Figure 8 shows the real attack patterns we got from the final correlation result. The correlativities of neighboring node pairs reflect strong relationship residing in contextual steps of a real multi-step attack specifically Sadmind DDoS attack in this experiment. Table 3: Test result with DARPA 2000 LLDOS.0 dataset Raw alert # H # H # H # Aggregation Rate C_AL P_AL F_AL Drop Rate 937 (Snort) % % 922 (RS) % % Fig. 8 Examples of final attack patterns in DARPA test

12 nternational Journal of Network Security Vol.xx No.xx PP.xxx xxx xxx Figure 8 (a) shows the attack patterns we found from snort alerts. Figure 8 (b) to 8 (d) are the examples of attack patterns we found from RealSecure alerts. We can see that in figure 8 (b) and figure 8 (c) there exists repeated attack types in a particular attack link. This is due to the particularity of hyper alert generating and connection mechanisms and can be easily combined into one step to reduce the redundancy of the attack pattern. That is also the reason why there is only one main multi-step attack scenario in DARPA test but we got more than one attack patterns. After manually checking the result patterns they are all meaningful and can be related back to the original alert distribution condition. We also used real data to test our method. Figure 9 shows a real Trinoo multi-step attack pattern built by our correlation method. We can thus build corresponding correlation rules according to these patterns to realize the goal of real-time multi-step attack detection. Fig. 9 A real Trinoo DDoS attack pattern 5 Conclusion n this paper we proposed a new multi-step attack pattern discovering method which aims at solving the problems of new attack pattern discovering and difficulty in complex attack association rule definition and maintenance. We classified the raw alerts into three types of hyper alerts and connected the hyper alerts to form candidate attack links according to their P address attribute associations. We then apply hyper alert correlativity calculation method to candidate attack links to filter out the attack links which have no real relationship. Experiment shows our method can find real multi-step attack patterns from network security alert data successfully. The hyper alert generation method can provide a concentrated perspective of network security event information and provide favorable prerequisites for further multi-step attack pattern discovering processing. The correlation method can effectively differentiate real attacks and fake attack links. The final attack patterns we got can easily help us build the association rules which can help us detect possible upcoming multi-step attacks in real-time system. As to future work we currently use correlativity to measure the correlation-ship between pair nodes in pseudo-attack-link to determine if the link is real attack pattern or not. We only consider four attributes of hyper alert in the calculation of correlativity. We can add more attributes in the formula to further ensure the accuracy of the result in future. Besides how to build the precise rules based on the attack patterns found by our method and how to predict the future attack behaviors are also the research directions we are interested in. References [] Wang Li Li Zhi-tang Lei Jie Li Dong. Attack scenario construction with a new sequential mining technique. 8th ACS nternational Conference on Software Engineering Artificial ntelligence Networking and Parallel/Distributed Computing SNPD [2] Fre de ric Cuppens. Managing alerts in multi-intrusion detection environment. n: Proceedings 7th annual computer security applications conference. New Orleans; 200. p. 22e3. [3] Fre de ric Cuppens Alexandre Mie`ge. Alert correlation in a cooperative intrusion detection framework. n: Proceedings of the 2002 EEE symposium on security and

13 nternational Journal of Network Security Vol.xx No.xx PP.xxx xxx xxx privacy; p. 202e5. [4] Fre de ric Cuppens Fabien Autrel Alexandre Mie`ge Salem Benferhat. Correlation in an intrusion detection process. n: Proceedings SE curite des communications sur internet (SEC02); p. 53e7. [5] P. Ning Y. Cui and D. S. Reeves "Constructing attack scenarios through correlation of intrusion alerts" presented at Proceedings of the 9th ACM Conference on Computer and Communications Security Nov Washington DC United States [6] P. Ning Y. Cui D. S. Reeves and D. Xu "Techniques and tools for analyzing intrusion alerts" ACM Transactions on nformation and System Security vol. 7 pp [7] P. Ning and D. Xu "Alert correlation through triggering events and common resources" Tucson AZ USA 2004 [8] C. Araujo A. Biazetti A. Bussani J. Dinger M. Feridun and A. Tanner "Simplifying correlation rule creation for effective systems monitoring" presented at Utility Computing. 5th FP/EEE nternational Workshop on Distributed Systems: Operations and Management DSOM Proceedings 5-7 Nov Davis CA USA [9] K. Julisch "Clustering intrusion detection alarms to support root cause analysis" Edmonton Alta Canada [0] K. Julisch "Mining alarm clusters to improve alarm handling efficiency" New Orleans LA USA 200. [] Valdes A. and Skinner K. Probabilistic alert correlation in Proceedings of the 4th nternational Symposium on Recent Advances in ntrusion Detection (RAD) October 200. [2] Sheyner O. Haines J. Jha S. Lippmann R. and Wing J. M. Automated generation and analysis of attack graphs in Proceedings of the 2002 EEE Symposium on Security and Privacy (Oakland CA) May [3] W. Lee and X. Qin "Statistical Causality Analysis of NFOSEC Alert Data" presented at RAD2003. [4] Q. Xinzhou and L. Wenke "Discovering novel attack strategies from NFOSEC alerts" Sophia Antipolis France [5] MT Lincoln Lab DARPA ntrusion Detection Scenario Specific Data Sets _data_index.html Li Wang is currently a post-doc Researcher at the nformation Security Centre of Computer Science University of New Brunswick. She received her Ph.D. degree from Computer Science Department of Huazhong University of Science and Technology in 2007.