Data Reduction in Intrusion Alert Correlation

Data Reduction in Intrusion Alert Correlation Gianni T edesco and Uw e Aick elin The School of Computer Science & IT The U niv ersity of No ttingham Jubilee Campus, W ollaton R oad, No ttingham U nited Kingdom {gxt,uxa}@cs.nott.ac.uk Abstr act : - Ne tw ork intr usion detection sensors are usuall y built around lo w le v el models of netw or k traff ic. This m eans that t heir output i s of a similarl y low le v el and as a consequence, is difficult to anal yze. Intrusion aler t cor relation is the t ask of a utomating some of this analy si s b y grouping related aler ts toge ther . Attac k graphs pro vide an intuitiv e model f or such analy sis. U nfortunately aler t f looding attacks can still cause a loss of servi ce on s ensors, and when per f or ming atta c k graph cor relation, there c an be a large number of e xtraneous alerts included in the output g raph. This obscures t he fine struc ture of g enuine attacks and makes them more dif ficult f or human operators to discer n. This paper e xplores m odified cor relation algor ithms which attemp t to minimize the impact of this attack. Key- W ords : - Intrusion Detection Sy stems, Aler t C orrelation, Attack Graphs, De nial of Servi ce A t tacks, T oken Buc ket F i lter 1 Introduct ion As global a w areness of inf or mation securi ty issues has increased, so has the prolif eration of intr usion detection technology . Netw ork i ntrusion detection sy stems (NIDSs or simpl y I DSs) are qui ckl y becoming a cr ucial par t of the Internet secur ity infrastructure. Back in March 200 1 , there w as a media furore[1] when the FBI Internet cr ime division issued a wa r ning concer ning the then unreleased Stick[2] program which “essentially di sarms intr usion detection sys tems. ” The tool automated what we shall call the aler t f lood att ac k. The attack w orks because eac h time an intr usion detection sys te m raises an aler t it must m ak e some attempt to com municate the i nf orm ation to an operator . T his com munication channel can t heref ore become t he t arg et of a de nial of ser vice att ack because, like all communication channels, it has a finite capacity . If this channel can become o v er whelmed with bogus data , an attack er can quic kly achie v e comple te ne utralization of intrusion detection capability . There are, i n f act, numerous possible types of denial of servi ce attack ag ainst a netw ork IDS[3], but we will f ocus on this particular att ac k t ype. A g reat deal of research has gone in to techniques f or reducing f alse positiv e alarms generall y . One such technique is aler t cor relation. The aim of aler t cor relation is to anal yse the a l ert s tream and disco ve r strategies or att ac k scenar ios using some kind of model of possible atta c ker strategies[4]. One quite intuitive type of model is an a ttack graph[5,6,7]. The advantage of this kind of cor relation is that aler ts which do not (ye t) c onf orm to a threatening attack s trategy are not displa y e d. W e propose a no vel algorit hm to protect NIDSs from aler t-f looding attacks. The algor ithm combines a throttling algor ithm, nam el y a token buck et f ilter , with an exis ting real-time aler t cor relation al gorit hm. The aim is to reduce al erting throughput in t he f ace of an aler t f lood attack, while minimising the chances of missing import ant alerts. The key to our approach is using the a ttack graph to inf or m the t hrottling algor ithm so that t he y key aler ts whic h make up threatening strategies a re not dropped b y the sensor . The ne xt section of this paper will present t he rele v a nt background f or t he propos ed tec hniques. The aler t f lood attack is defined and cur rent approaches are ex a mined. The real-time correlation algor ithm our solution i s based on is also introduced. I n section 3, a modified cor relation algor ithithm is presented whic h uses throt tling techniq ues to curb alert f lood att ac ks. In section 4 some experimental dat a i s presented in order to demonstrate t he e ff ectiv eness of our t echni que. W e finish b y presenting a summar y and some concluding remarks. 2 Bac kground The patter n matc hing[8] model is cur rentl y the most commonl y used methodology f or detecting intr usion attempts. In t his model t he NIDS is conf igured with a dat abase of known attack patter ns ( also called signatures). An e xample of a signature is shown in Listing 1 . This signature a lerts on traffic generated b y the wel l-kno wn “BackOrif ice” trojan horse program and detects any incoming packe ts destined to use r dat agram protocol (UDP) por t 3 133 7 , containing a specific sequence of b yt es an ywhere within its pa y l oad. alert udp $EXTERNAL_NET any -> $HOME_NET 31337 (msg:"BACKDOOR BackOrifice access"; content: "|ce63 d1d2 16e7 13cf39a5 a586|";) Listing 1: A Sam ple Rul e as used e.g. b y Snor t 2.1 Alert Flooding Aler t f looding att acks are achie v ed b y transmitting pac ke ts that simulate intr usion a ttempt s and which the I DS will recognise as t rue attacks. T aking the e xample signature in Listing 1 , an attacker must craft a UDP packe t, set t he destination por t to 3 133 7 , include the se q uence of bytes gi v en in t he signature and f lood the t arg et netw ork with t hese pac kets. The possible ramific ations of t his type of attack agains t an IDS are t hreef old: 1 . Sensor s torag e becomes full, pre v enting fur ther logging. 2. Sensor e xc eeds maximum aler t throughput, causing alerts to be los t, or the sensor to cease functioning. 3. The analy st becom es deluged with fal se inf or mation and becomes unable to distinguish re al attacks from the fa lse ones. Because of t his, attackers ma y use the aler t f lood attack as a wa y to conceal g enuine malicious activities. The aler t f l ooding technique has been automated, and hence popularised, b y tools such as St ick and Snot [9] w hich read in signatures di rectl y from the freel y av ailable Snort [1 0] I DS. Each pack et se nt could also ha ve cr ucial fi elds such as source and destination address modulated b y adding random data into t hem. This random noise makes it difficult to block t he atta c k using a simple pack et filter or firew all. Aler t f loods can also be e xacerbated b y the poor aler ting per f or mance of IDS sy stems in general. A quic k e xamination of the Snor t sys t em rev eals t hat, in i ts preferred output mode (called “unified”), Snor t f lushes its buff ers nee dlessl y i n at least tw o places. This caus es a reduction in the eff ectiv eness of the buf f er ing and on UNIX like sys t ems results in added sys tem call ov e rhead f or ev ery l ogg ed aler t. Perf or mance in this area can be understandabl y o v erlook ed by t he IDS sy stem designer . After all, good engineering practice tells us to optimise f or the common case, and, in the w orld of intr usion detection, an alert is not us uall y the common case. In fact, on a high-speed netw ork it should be a very rare e vent indeed. Per haps t he simplest wa y to reduce data output while maint aining the same intrusion detection capability is to make minor modif ications to the signatures to mak e sure that the IDS is as terse as possible. Suc h modifications are of ten used t o reduce t he number of f alse positive alerts ge ner ated. In fact ge nerally speaking, signatures are usuall y a subtle com promise betwe en allo wing f alse neg ative and fa lse positiv e aler ts. One wa y to make the IDS less verbose i s to fine- tune s ignatures to e xamine only those pack ets destined f or the relev ant hosts. Let us c onsider BIND, D NS ser v er software infa mous for its secur ity vulnerabilities. In this s ituation, the signatures ma y be modified to only look f or BIND e xploits if the destination address on the packe t matches a pre-def ined list of DNS ser v er s. Of course, t he oper ator may actuall y be interested to kno w that someone is attempting a BIND exploit on a wor kstation or a web server . That is to sa y , t his approach tips the fal se alar m compromi se to wa rds the f alse neg ative side. Interes tingl y this problem also comes up when designing attack gra ph for cor relation algorithm s. The S nort team addressed the problems of wide spread prolif eration of automated alert f looding tools like S tick and Snot in t heir 1 .8 release. Their solution w as to implement a T ra nsmission Control Protoc ol (TCP) state tracking s y stem which t he y called “stre am4”. By keeping track of TCP connection states, stream4 is able to ignore an y segments which are not part of such a conv ersation. In order to mak e the IDS raise an aler t the atta c ker is no w f orced to transmit at least three segments, rather t han just one. More import antl y , because the t hree-w a y handshake requir es tw o hosts to be communicating, the exte r nal attack er must f ind a host on the monitored netw ork willing t o participate. This m ight be pre vented by a firew all blocking connections. Cur rentl y mos t s y stems k eep track of TCP states. This is mainly to protect ag ainst desync hronisation attacks such as t hose described by Pt acek and Ne wsham[3], but t here is also the additional benef it of making s ure that there is no such short c ut in car rying out an aler t f looding att ac k. Fur ther to performing TCP state tr ac ki ng, it is a lso possible to track an y appl ication lay er state, e nabling us to remo v e shor tcuts e v en f or protocols r unning o v er stateless transports such as UDP . While this is a defi nite impro vem ent, it cannot co ve r all cases: For e xample, some signatures must ignore state information as some e xploits can exis t as a single packe t (i.e. statelessly); or because in other cases, the y w ork o v e r inherentl y stateless pro tocols. As w e describe in t he ne xt section, token buck et filters combined with attack g raph cor relation c an impro v e the si tuation. 2.2 T ok en Buck et Filter A token buc ket filter is an algor ithm for controlling the rate of f lo w of data. T oken bucke t f ilters hav e traditionall y been used in a number of applications where rate limiting has been needed. S ome good e xamples are: 1 . Ne t w ork bandwidth management sy stems[1 1]. 2. Flood pro t ection in netw ork chat / te xt conf erencing sy stems such as Internet Rel a y Chat. 3. Flo w control in netw ork transport protocols [1 2]. 4. Flood protection f or programs t hat log e xter nally ge nerated ev ents s uc h as UNIX sy slog. A tok en bucke t f ilter has tw o parameters, bucke t size, and tok en rate [1 3]. T okens are g ener ated at the tok en rate and s tored in a buff er called the “buck et'” If t he buc ket becomes full, the extra tokens are just discar ded. Eac h alert that ar r iv es must hav e a tok en to pa ss t hrough the filter . An y al ert tha t does not ha v e a token is called “o ver -limit” and does not pa ss the filter . If the aler t rate is less t han the token- rate then credit is allo wed to accumulate in the bucke t. This stor ed credit allo ws f or t he aler t-rate to temporar il y ex ceed t he tok en rate (or “burst”). 2.3 A ttack Graph Corr elation Net w ork intr usion detection sy stems are t ypicall y built based on a lo w le v el m odel of netw ork traf fic and the output of these systems are understood on a similarl y low le ve l. This makes analy sis of t he dat a diff icult by an y one other t han a highly experienced netw orking and s ecurity specialist. Intrusion aler t cor relation aims to make t his tas k easier b y someho w g rouping related alerts tog ether . Attack graphs hav e long been used inf or mall y b y netw ork secur ity staff as a wa y of com municating inf or mation about t hreatening at tack strategies to other specialists. The basic idea is t hat v er tices i n the graph represent some vulnerability and edg es represent orderi ng constraints betw ee n the vulnerabilities. An inf or mal att ac k g raph for breaking in to a house is presented in F i gure 1 . Figure 1: Sam pl e attack graph. Attac k graph cor relation algori thms aim to cor relate intrusion alerts tog ether, based on the s trategic relationship betwe e n t he alerts. In order to do this intrusion aler ts must be related to ve r tices in the attack graphs. In this wa y t he role of the NIDS sensor is re-stated as bei ng to map pack ets on to vulnerabilities in the attack graph. W ang et al pro vide a unified approac h to cor relating, predicting a nd reasoning about missed aler ts in [1 4]. W e f ocus on this approac h as it r uns in real-time, this i s necessar y s ince our approach relies on accessing the inter nal data structures of the cor relator befor e aler ts ha v e been logg ed. Like other cor relation algorit hms[6], it is robust in t he face of missing alert s from the under lyi ng IDS. An in-memor y data str ucture called a “queue graph” (QG) is introduced. In order t o a v oid keeping unnessecary aler ts in memory , only the latest alert seen for a giv e n e xploit verte x is stor ed in this structure. That is to sa y that the cor relation between such matchi ng aler ts is left as implicit. This limits the amount of data tha t needs to be kept in main memory and allo ws the algorit hm to be r un wit h a finite amount of memor y while a v oiding the naiv e sliding cor relation windo w approach which would allo w an attacker to use an aler t f lood attack to introduce f alse negativ e cor relations. In this sy stem, attack graphs are defined as directed acy clic graphs (D A Gs) ha ving tw o dist inct types of v er tices, secur ity conditions a nd e xploits (see Figure 2). Exploit vertices are (vuln,src,dst) tuples. The src and dst fields are used to tie the exploit to specific combinations of vulnerable and at tacki ng hosts, wildcards may be used. These v er tices ma y represent one or more possi ble alert types. A function “f” is introduced which maps alerts to an e xploit vertices in the att ack graph. Secur ity c onditions vertices ref er to prereq uisites and consequences of e xploits. Thus edg es connecting a condition to an expl oit are prerequisite relations and t hose connecting an e xploit to a condition are conseq ue nce rel ations. All prerequi sites for an alert m ust be satisfied bef ore the exploit is considered possible. The addition of secur ity cons traints in to the attack graph allo ws e xploits to ha v e eithe r disjunctive or conjunctiv e relationships depending on the construction of the attack graph. This proper ty is illustrated in Figure 3, in which a successful exploit a g ainst t he sadmind ser v er leads to the same consequence as an equiv alent attack against the sendmail ser v er , namel y a compromise of roo t privil eg es. Figure 2. An attack g raph f eatur ing e xploits (circles) and security conditions (squares). Attack graphs a re generated automatically with TV A, the topological vulnerability assessment tool[1 5] whic h links t ogether the out put of Nessus, IDS rul es and a vulnerability dat abase. In order to do this a function which maps aler ts to expl oi ts is introduced. In t his wa y the correlation algorithm is vulnerability - centric. That is to sa y i t will not cor relate e xploits aga i nst mac hines which are not defined as being vulnerable to them. These g raphs are distinct from those used by Ning et al in that they contain not just the causal relationships betw een a ttacks but also a database of vulnerable hosts on the netw ork. An IDS (in this case Snor t) is set up to send its alerts directl y to the correlation component. The wa y the attack graph i s used by t he cor relation component is to treat each e xploi t verte x in the graph as a queue. Aler ts are placed in thei r requisite queue and a breadth first searc h is performed in t he g raph to f ind pre vious exploits which w ould cor relate with the cur rent one. If a queue is f ound and is non- empt y then a cor relation is ge ne rated. If a queue is empty , the algor ithm can either s top or h ypothesise a missing attack and carr y on. Figure 3: Attack g raph sho wing disjunctive relations betw een expl oits. If the edg es in the graph are directed f or wa rds in time, rather than bac kwards, predictions can be ge nerated in much the same w ay as correlations. The QG structure is actuall y an enhanced v ersion of the att ack graph which av oids t he need f or per f orm ing a costly breadth-fi rst search o v er t he graph f or e v er y aler t ge nerated. For each e xploit v er te x in t he graph, an breadth-f irst search tree is created, and t he pointers of this tree are store d in t he QG str ucture in what are ref er red to as “pointer lay ers”. This ef f ectiv el y means that cor relation and prediction can be done in li near time b y searching in a tre e rather than in t he attack graph and this is what makes the algorit hm suitable f or real-time application. The output of t he algorithm is a correlation graph which can contain a m ix of real and hypo the sised aler ts and security conditions. R eaders are urg ed to consult the or iginal paper f or t he full details[1 4]. 3 Strategic Data R educt ion W e ha v e descr ibed t he a lert f l ood atta c k in t he pre vious s ections as f undamentall y a resource e xhaustion attack. In thi s section we will outline an approach to reduce e xpos ure to the attack b y combining aler t t hrottling with att ack g raph cor relation. Consider t he case of a human IDS operator as a resource t hat cannot cope withhaving to e xamine man y thousa nds of bogus aler ts at t he rate at whic h a sustained attack can produce them. There are t w o appr oaches to s ol ving t his type of problem: one is to increase the amount of resources at y our disposal, the other is to reduce the amount of resources required. While i t is conceiv able that one could scale the sensor hardware to be full y able to cope with a lert f loods at a given r ate f or a giv en length of time it seems rather more comple x to scale the human operator . T aking the approach of minimising the resources require d, alert data could be reduced b y throttling the aler t stre am to a f ix e d rate. This could be achie v ed b y applying a token buck et f ilter either per signature, per attack type, globall y , or ev en i n to comple x hierarc hies as in HTB3[1 5]. The burstiness f eat ure of the TBF algorithm means that aler ts are onl y discarded under sustained high rate of aler ts. Ho we v er such approaches run the r isk of dropping import ant aler ts which can ev en assis t an att ac ker in concealing their malicious activities. The k ey to our approach i s to a llo w the correlation algor ithm to i nterpose betwe e n t he signature matching, and output components of the IDS. By doing t his, a token buck et filter can be placed at each queue in the QG structure and o v erlimit alerts can be discarded. In orde r that the user ma y be inf ormed of dropped alert s w e can use a kind of “r un length encoding” (RLE) to represent a s tr ing of aler ts. RLE is a simple compression techniq ue w hic h replaces recurr ing sequences of symbols (called r uns) with a single symbol and a r un count N . T o decompress, one simpl y copies the symbol into t he output stream N times. This is an a pproac h familiar to UNIX users who ha ve ev er tr ied to f lood the sy slog program and seen its “last messag e repeated N times” warning. T o implement RLE compression in our case, we first assume that all aler ts goi ng through t he s ame token buck et filter are identica l. Then all that is required is to add a counter to t he queues in t he QG dat a structure and increment t hat counter f or all ov er - limit aler ts. When t here is enough credit in the token buck et to perm it ne w aler ts, w e dequeue the aler t and the count er , allo w ing them to add a node in t he output graph and to be l ogg ed to permane nt st orage. Although the assumption that pack ets are identical is unrealist ic, it is taken that the att ack graph itself i s already defining w hat is relev ant to identifying a threatening strategy and so the loss is acceptable, if not alw ay s desirable. T w o q uestions then arise. Firs tly what to do with alert s not mapping to v er tices in the queue g raph; and secondl y what parameters to use f or the token buck et filters. For t hose alert s which do not map in to e xploit nodes, we cannot be sure that w e are missing alerts vital to some, as y et undef ined strategy . Since the QG algor ithm assumes a complete atta c k gra ph an ywa y w e could discard all suc h aler ts. A more prudent approach is taken in our case, and t hat is to apply a token buck et f ilter to such aler ts on a per - signature basis. As for the pa rameters of t he TBFs, f or those aler ts which map to vertices in the att ack graph, we could drop all implicitly cor relating alert s and keep the same strategies. H o w e v er it is seen as a benef it to kee p alerts where possible, here we envisag e that tok en rates of greater t han one or tw o alerts per second need not be used. For other alerts ho we v er , there is, of course, a trade-off betw een data fidelity and eff iciency . 4 Empirical Data W e can per f or m a simple test with t he Fires tor m[1 6] sy stem running off-line agains t a tcpdump[1 7] capture file cont aining an aler t f lood att ac k captured by Shmoo Group at a defcon CTF e v ent[1 8]. The attack consists of a repeated ICMP f lood at a rate of around 7 ,343 pack ets per second. The dat a set contains no scenar ios although ea c h of the al erts in the f ile ma y f or m the initial step in possible scenar ios. T o capture this feature of the data we create e xploit v er tices for eac h host attack ed. Some sensible consequences are added based on expert know l edg e so that the cor relation algor ithm can be more full y e xer cised. W e perf or m 2 tests and in both, we hav e a full signature database loaded containing around 1 ,600 signatures, with t he netw ork data read di rectl y from the hard disk. The test machine was a 3.2GHz Pent ium-IV runni ng Linux 2.6 wit h 1GB of RAM. The results show n are an av erage of t hree iterations f or both runs to factor out any random f luctuations such as ma y be caused b y disk seek latency . The first run (#1) is a control r un using f irestorm + QG algor ithm. The second r un (#2) i s identical e xcept f or the addition of token bucket filter ing. T w o sets of filters are used: 1 . The set of f ilters f or each e xploit v er te x in the attack graph. 2. The se t of filters f or each rule which does not map to a v er te x in the att ack graph. Each of t hese filters is set to 2 aler ts per second and a burst of 20 al erts. These parameters are rather arbitrar y but are probabl y best set based on the operators experience of the baseline aler t rate for the netw ork. # Data Size (KB) Alerts CPU Time Elapsed Time 1 4 7 5,229 300,7 4 1 1 3. 1 3 1 1 8.4 7 6 2 1 ,092 696 1 2. 153 1 2.8 1 7 T able 1 : Exper imental R esults. As we can see i n T able 1 , t he amount of data logg ed was reduced b y se veral orders of magnitude and t he run time decreased di sproportionately to the CPU time. While t he r un time was reduced b y around 30%, the C PU time only reduced by around 1 0% . This indicates t hat the Firest or m process is not wa sting as muc h time w aiting f or I/O completion when the token buc ket filter is enabled, The number of aler ts output is reduced b y orders of magnitude. In the e xper iment t he communication channel betwee n t he IDS and the operator is s imply an on-disk alert spool so the a vailable bandwitdth is high. In a real w orld deplo yment, on the other hand, it is lik ely t hat alerts w oul d be transmitted acros s a netw ork adding fur ther latency and bandwidth constraints. In these deplo yments w e e xpect ev en greater gains in perf ormance. From these results it is sho w n that we can eff ective ly boost per f or mance and t heref ore sensor capacity , allo wing t he IDS to car r y on w orking dur ing an aler t f lood rat her than becoming ov er whelmed and possibl y e xhausting the storag e on the sensor . E v en if the attac k cont ained twice as many pac ke ts in t he same spac e of time, it would not double t he amount of data logged as the tok en rate is f ix ed. 5 Summary and Conclusions Aler t f looding i s a problem that will probabl y alw a ys e xist with intrusion detection sy stems and one that cannot be eliminated entirel y . Ho w ev er , w e ha v e shown that it is possible to drast ically reduce the effects by recognising an attack and throttling e xcess aler ts. W e hav e fur ther sho wn t hat real-time aler t cor relation algorit hms can be used to pro vide a useful context f or throtting aler ts such t hat ke y attacks are not missed, such an approach sol v es problems with either technique used in isolation. Without the cor relation sys tem inter cedi ng betw een the signature matching and aler ting components of the IDS it is not possible for it to decide if aler ts ma y be logged or not and without ha ving strategic inf or mation av ailable to the throttling algor ithm, it could drop crucial aler ts. While our approach has been successful in reducing the impact of alert f looding on t he computer sy stem. There is still t he problem of e xtraneous aler ts w hic h ma y cause out put graphs to be very confusing. This is surel y a problem which merits closer attention. Furt her inv estig ation is also required in to producing optimal tok en bucke t filter configurations and ho w best to handle those a lerts whic h do not map on to an y exploit v e rtices in t he attack graph. Ref er ences: [1] ZDNe t UK Ne ws. http://news.zdnet.co.uk/internet/s ecurity/0,39020375,2085099,00.htm [2] G. Corete x. “Fun W i th P ackets : Designing a Stic k.” Endeavor Sy stems Inc., 2002. [3] T . H. Ptacek and N. N . Ne wsham. "Inser tion, Evasion and Denial of Service: Eluding Ne tw ork Intrusi on Detection. ” Secur e Ne tw orks Inc., 1 998. [4] Xinzhou Qin. W enke Lee. “ Attack Plan Recogni tion and Prediction Using Causal Net w orks”. Pr oceedings of Annual Computer Security Applications Conf er ence , 2004. [5] Peng Ning. Y en Cui, and Douglas S Ree v es. “Constructing Attack Scenar ios through Cor relation of Intrus ion Aler ts.” Proceedings of the 9th A C M Conf er ence on Computer & Com munications Security. 2002. pp. 245-25 4. [6] Peng Ning, Dingbang X, Christopher G. Healey , R ober t and St. Amant. “Building Attack Scenar ios through Integ ration of Complementar y Aler t Methods. ” Proc eedings of the 1 1th Annual N etw ork and Distributed Sys tem Security Symposium, 200 4, pp. 97-1 1 1 . [7] Oleg She yner , Joshua Haines and Somesh Jha. “ Automated Generation a nd Analy sis of Attack Graphs. ” Proceedings of the IEE E Symposium on Security and Pri v ac,. 2002. pp. 27 3. [8] "The Science of Intr usion Detection Sys tem Attack Identification." Cisco Syst ems.2002, http://www.cisco.com/warp/public/c c/pd/sqsw/sqidsz/prodlit/idssa_wp. htm [9] Sniph. “snot “. 200 1 . [1 0] Marty R oesch. "Snor t - Lightw eight Intrusion Detection f or Netw orks". U SENIX 1 3 th Sys tems Administr ation Confer ence, 1 999. [1 1] G. W oodruf f, R. R ogers and P . Richar ds . "A cong estion control framew ork f or hi gh-speed integrated pack etized transport." IEEE Globecomm, 88. 1 9988. [1 2] R. W ade, M. Kara and P .M. Dew . "Study of a T ranspor t Protocol E mplo ying Bottlene ck Probing and T ok en Buc ke t Flo w Contr ol ." Fifth IEEE Symposium on Computer s and C ommunications, 2002. [1 3] J. T ur ner . "N e w directions in communications (or which wa y to the inf or mation age?)" IEEE Communications Mag azine ,V ol.24, N o. 1 0, pp. 8-15. [1 4] Lingyu W ang, An yi Liu and Sushil Jajoda. “ An Eff icient Uni fied Approach to Correlating Hypothesising, and Predicting Intr usion Aler ts.” Pr oc eedings of European Symposium on Computer Security, 2005. pp. 24 7-266. [1 5] Sushil Jajodia, Ste ve Noel and Br ian O’Berr y . “T opological analy sis of netw ork attack vulnerability . ” Managing Cyber Threats: Issues, Approac hes and Challeng es , 2005. Spr ing er . pp. 248-266. [1 6] Mart in De v er a. "Hierarchical tok en buck et theor y ." 2002. http://luxik.cdi.cz/~devik/qos/htb/ manual/theory.htm [1 7] Gianni T edesco. 2005. Fires torm IDS. http://www.scaramanga.co.uk/firesto rm/ [1 8] Leres V an Jacobson, Craig M c Canne and St e v en McCanne. “tcpdump”. Lawrence Berkele y Na t ional Laboratory . [1 9] Shmoo Group. “CCTF Defcon Data”. 200 1 . http://www.shmoo.com/cctf/