INTERNET-DRAFT Yixian Yang Expires: April 2006 Jian Li Xu Zhu Beijing University of Posts and Telecom. October 2005 Alert Filtration and Fusion(AFF) in Intrusion Management System draft-yang-aff-00.txt Intellectual Property Rights (IPR) statement: By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract Alert Filtration and Fusion (AFF) is proposed to solve the problems of existing IMS(Intrusion Management System). The Alert Filtration is used to filtrate original alerts and reduce the alerts which are obviously unavailable. The Alert Fusion is used to reduce redundant alerts and find the relationships of alerts. The false positive Yixian Yang, et al. Expires March, 2006 [Page 1] INTERNET-DRAFT Alert Filtration and Fusion September,2005 rate and false negative rate can be reduced by Alert Filtration and Fusion. Table of contents Status of This Memo ......................................... 1 Abstract .................................................... 1 1. Introduction ............................................ 3 2. AFF Location ............................................ 4 3. Alert Filtration Model .................................. 6 3.1 Alert Filtration structure ............................ 6 3.2 Alert Filtration Process .............................. 6 3.2.1 Local Alert Filtration Process ........................ 7 3.2.2 Intranet Alert Filtration Process ..................... 10 4. Alert Fusion Model ...................................... 11 4.1 Alert Fusion structure ................................ 11 4.2 Concept of Alert Class ................................ 12 4.3 Alert Fusion Process .................................. 12 4.3.1 Alert Classification .................................. 13 4.3.2 Alert Corelation ...................................... 17 4.3.3 Situation Assessment .................................. 21 5. References ............................................. 22 6. Acknowledgements ....................................... 24 7. Authors' Addresses ..................................... 24 Full Copyright Statement .................................... 25 Yixian Yang, et al. Expires March, 2006 [Page 2] INTERNET-DRAFT Alert Filtration and Fusion September,2005 1. Introduction This document addresses the Alert Filtration and Fusion mechanism and the structure of AFF. There are millions of alerts created by IMS everyday, and the huge amount of alerts can't be processed by administrators efficiently. So Alert Filtration and Fusion is proposed to be added in IMS. In this document, the structure of Alert Filtration and Fusion is presented. There are different functional modules in Alert Filtration and Fusion. The two parts can cooperate with each other to reduce the false positive and false negative rate. Yixian Yang, et al. Expires March, 2006 [Page 3] INTERNET-DRAFT Alert Filtration and Fusion September,2005 2. AFF Location Large scale distributed intrusion management system should has a four-layer structure. The raw data which is prepared for detecting is collected by Collection Layer. The raw data is analyzed in Analysis Layer. In Fusion Layer, alerts are sorted, merged and corelated. In the end, The senior alerts are sent to Harmonization and Management Layer. +------------------------------------+ | Harmonization and Management Layer | +------------------------------------+ ^ | Senior alert +------------------------------------+ | Fusion Layer | +------------------------------------+ ^ | Junior alert +------------------------------------+ | Analysis Layer | +------------------------------------+ ^ | Raw data +------------------------------------+ | Collection Layer | +------------------------------------+ Figure 1: IMS Four-Layer Structure Generally, the detecting engine of Analysis Layer is based on rule database. Although the attack can be detected, it can't be corelated with local information. So attacks which is unavailable (Such as RedCode attacks Linux host) can also produce alerts. These are false positive alerts. To solve the problem, Alert Filtration is added between Analysis Layer and Fusion Layer. The original alerts created by Analysis Layer are first sent to Alert Filtration and then flow to Fusion Layer. The unavailable attacks are filtrated, so alerts in Fusion Layer are fewer and more reliable. It also reduces some burden for Fusion Layer. Yixian Yang, et al. Expires March, 2006 [Page 4] INTERNET-DRAFT Alert Filtration and Fusion September,2005 +------------------------------------+ | Harmonization and Management Layer | +------------------------------------+ ^ | Senior alert +------------------------------------+----+ | Alert Fusion | | +------------------------------------+ | ^ | | Junior alert > AFF +----------------------------------------+ | | +------------------------------------+ | | | | Alert Filtration | | | | +------------------------------------+-|--+ | ^ | | | Original alert | | +------------------------------------+ | | | Detecting Engine | | | +------------------------------------+ | | Analysis Layer | +----------------------------------------+ ^ | Raw data +------------------------------------+ | Collection Layer | +------------------------------------+ Figure 2: Alert Filtration and Fusion Location Yixian Yang, et al. Expires March, 2006 [Page 5] INTERNET-DRAFT Alert Filtration and Fusion September,2005 3. Alert Filtration Model Alert Filtration is based on expert system. It contains Knowledge Base, Filtrating Engine and Management System. 3.1 Alert Filtration Structure Original Alert +------------------+ | +--------| Admining System | | | +------------------+ | | | v v v +-------------------+ +----------------+ | Filtrating Engine |<----| Knowledge Base | +-------------------+ +----------------+ | v Junior Alert Figure 3: Alert Filtration Structure Compared with common expert base, Alert Filtration doesn't have explaining module. Since there are more works for Alert Fusion, explaining module is unnecessary here. Filtrating Engine works as reasoning machine. The main part of it is a Filtrating Tree. This structure is better for extension. And it is also independent of Knowledge Base. The Knowledge of Filtrating Engine is from Knowledge Base. Knowledge Base locates in each host. It contains the information of the host, such as security grade, operating system, open service, open port, fixed vulnerability, hardware inform and Agent Location. Filtrating Engine filtrates alerts by matching the information from Knowledge Base. Knowledge Base and Filtrating Engine are both controlled by Admining System. 3.2 Alert Filtration Process The original alerts are divided into two kinds. One is created by the data which flows in the local machine, the other one is created by the data which flows out of the local machine. The flow-in alerts are sent to Local Alert Filtration Module. Some of the flow-in alerts are dumped, some are turned into the Junior Alerts. The dumped alerts will be archived. The flow-out alerts (May be caused by Trojan or worm) have different targets. They may be in intranet or extranet. So the flow-out alerts whose target is intranet will be sent to Intranet Alert Filtration Module. The others are turned into the Junior Alerts directly. Yixian Yang, et al. Expires March, 2006 [Page 6] INTERNET-DRAFT Alert Filtration and Fusion September,2005 Original Alerts | v flow-in +-------------------------+ flow-out +--| Source Address Judgment |--+ | +-------------------------+ | | | v v dump +-------------+ Intranet +----------------+ Extranet <----| Local Alert | +----| Target Address |------+ | Filtration | | | Judgment | | +-------------+ | +----------------+ | | | | | | | | | | | | | | v v | dump +---------------+ inform +------------+ | <-----| Intranet Alert|-------> | Alert | | | Filtration | coordination | Generation | | +---------------+ agent +------------+ | | | v v v Junior Alert Junior Alert Junior Alert Figure 4: Alert Filtration General Process 3.2.1 Local Alert Filtration Process Local Alert Filtration is an important module, Most of the filtration work is done by it. The alerts which flow in must be processed. The alerts which flow to extranet can't be filtrated because it is difficult to get the information of hosts in extranet. Local Alert Filtration has a structure of Filtration Tree. Original Alerts first pass the Security Grade, then pass the other five tests one by one. If the alert passes all the tests, then it will become Junior alert, or it will be dumped. Yixian Yang, et al. Expires March, 2006 [Page 7] INTERNET-DRAFT Alert Filtration and Fusion September,2005 Original Alert | v +----------------+ | Security Grade | +----------------+ . . . . . . . . . . . . . . . . . . . . .-----.-----.-----.---->. Ordinal And . . . . . . . . . . . . . . . . . . . . v v v v v +----+ +-------+ +------+ +-------------+ +----------+ | OS | | Open | | Open | | Fixed | | Hardware | +----+ |Service| | Port | |Vulnerability| | Inform | +-------+ +------+ +-------------+ +----------+ Figure 5: Filtration Tree Structure o Security Grade Security Grade is dynamically set by IMS and Loading the five following modules is decided by security Grade. If the traffic is so heavy that system can't afford and the system isn't important, the Security Grade should be reset, the too much alerts will be dumped directly and the heavy pressure of system is eased. When the alert comes, Knowledge Base is checked to get Security Grade. If the grade is low, load the modules following the grade, or load all the modules directly. If the grade is "Ignore", then all the modules are skipped, all the alerts are dumped. o Operating System Local operating system and operating system which is influenced are checked in this module. If Local OS is influenced, go to the next module, or the alert will be dumped. This module can identify incidents such as Red Code attacks Linux host. This module mainly deals with the attack which uses the vulnerabilities of OS. There are much more vulnerabilities than OS. So matching OS is more efficient than matching vulnerability. Since alert should contains the influenced OS, the Detecting Engine needs to be rebuilt. CVE vulnerability list will be helpful. All the information of vulnerability can be found there. Yixian Yang, et al. Expires March, 2006 [Page 8] INTERNET-DRAFT Alert Filtration and Fusion September,2005 o Open Service The attacked service in alert and local open service are checked in this module. If the attacked service is not open in local host, then the alert is dumped, or the next module is launched. o Open Port The attacked port in alert and local open port are checked in this module. If the attacked port is not open in local host, then dump the alert, or go to the next module. o Fixed Vulnerability The attacked vulnerability and the fixed vulnerability of local host are checked in this module. If the attacked vulnerability is in the fixed vulnerability list of local host, the attack is unavailable, the alert will be dumped. o Hardware Inform Some hardware may has special protecting effect, so this module is for these hardware. Original Alert | v +----------------+ Unmatched +---------| Security Grade |---------->dump | +----------------+ | | | v | Control +----------------+ Unmatched +---------| OS |---------->dump | Message +----------------+ | | | v | Control +----------------+ Unmatched +---------| Open Service |---------->dump | Message +----------------+ | | | v | Control +----------------+ Unmatched +---------| Open Port |---------->dump | Message +----------------+ | | | v Yixian Yang, et al. Expires March, 2006 [Page 9] INTERNET-DRAFT Alert Filtration and Fusion September,2005 | Control +----------------+ Unmatched +---------| Fixed |---------->dump | Message | Vulnerability | | +----------------+ | | | v | Control +----------------+ Unmatched +---------| Hardware Inform|---------->dump Message +----------------+ | v +----------------+ | Alert | | Generation | +----------------+ | v Junior Alert Figure 6: Local Alert Filtration Process 3.2.2 Intranet Alert Filtration Process The alert created by the data which flows to Intranet is processed in this module. First, the Knowledge Base is checked to find whether the target host has an agent. If the target host has an agent, the local host dumps the alert. The target host will create the alert. It can reduce redundant alerts. It's also a preparation for Alert Fusion. Original Alert | v +--------------+ Yes | Target Agent |------> dump | Judgment | +--------------+ | No v +------------------+ | Agent Generation |---->Inform +------------------+ Coordination Agent | v Junior Alert Figure 7: Intranet Alert Filtration Process Yixian Yang, et al. Expires March, 2006 [Page 10] INTERNET-DRAFT Alert Filtration and Fusion September,2005 4. Alert Fusion Model The Alert Fusion composes of Alert Classification, Alert Corelation and Situation Assessment. 4.1 Alert Fusion structure ^ senior Alert | +------------------------------+-----------------------------+ | | Alert Fusion | | +--------+--------+ | | | Assessing | | | +-----------------+ | | ^ ^ | | Corelated Alert | | | | | | | | +--------+---+ +-+----------+ | | | Corelating | ... | Corelating | | | +------------+ +------------+ | | ^ ^ ^ | | Alert Class | | | | | | | | | | +----------+--+ +--+----------+ +-+-----------+ | | | Classifying | | Classifying | ... | Classifying | | | +-------------+ +-------------+ +-------------+ | | ^ ^ ^ | | | | | | +-----------+----------------+--------------------+----------+ Junior Alert | | | +------+------+---------+----------+---------+-----+ | | | | +--------+ +--------+ +--------+ +--------+ |Analysis| |Analysis| ... |Analysis| |Analysis| +--------+ +--------+ +--------+ +--------+ Figure 8: The Alert Fusion Structure in Large-scale Distribute IMS The Junior Alert was sent to Alert Classification module by Alert Filtration in Analysis Layer. The alerts are classified there. Then the Alert Class is sent to Alert Corelation module. The Alert Classes are corelated with each other. Then the corelated alerts are sent to Alert Assessment module. The reliability is given to each alert. The alert with low reliability could be dumped or kept as reference information for administrators. Yixian Yang, et al. Expires March, 2006 [Page 11] INTERNET-DRAFT Alert Filtration and Fusion September,2005 4.2 Concept of Alert Class Alerts are used to be classified by methods of attack, such as the class of Trojan, Worm, and so on. In this way of classifying, each attack has to be arranged to build the attacking scene for alert fusion. When another scene is needed, attacks must be rearranged. Even in the same attacking scene, if one or more attacks can be replaced by some others, the scene must be rebuilt along with the changing of attacks. So it's a hard way of building attacking scene, and when the sequence of attacks changes, it can't be recognized. To solve the problem above, a new classifying way is proposed in this document. Alerts can be classified into three classes: Invalidation, Scan and Penetrate by intensions of attacks. Class of Invalidation: Land, Smurf, Syn-Flood, some other vulnerabilities of buffer overflow and so on are in this class. The intention of these attacks is paralyzing the system and making it invalid. Class of Scan: nmap and some other scanning tools are usually used to detect the active hosts ,get information of hosts, such as operating system type, username, password and so on. The intention of attacks is getting the information and preparing for the real attack following. Class of Penetrate: Breaking into others' computers is the final intention of all attacks. Attacks of this class are to finish the final work. They are mainly Trojans and some vulnerabilities of getting privileges. Nearly all the attacks can be classified into these three classes. Through finding the corelation of the classes, we can find out the complicated attacks from millions of alerts. 4.3 Alert Fusion Process Junior Alert | v +----------------------+ | Alert Classification | +----------------------+ | v +------------------+ | Alert Corelation | +------------------+ | v Yixian Yang, et al. Expires March, 2006 [Page 12] INTERNET-DRAFT Alert Filtration and Fusion September,2005 +----------------------+ | Situation Assessment | +----------------------+ | v Senior Alert Figure 9: Alert Fusion Process There are three modules in Alert Classification. Alert Fusion Time, Alert Property Classification and Alert Class Clustering. There are two modules in Alert Corelation. Basic Corelation and Advanced Corelation. Situation Assessment is an independent part. It is removable. 4.3.1 Alert Classification 1) Alert Fusion Time Createtime is a property of alert. It describes the time when the alert is created. Alert Fusion Time is a scope. The alerts are picked up in this scope based on createtime. 2) Alert Property Classification Classification is a property of a alert. The alerts are classified into Invalidation Class, Scan Class or Penetrate Class by this property. 3) Alert Class Clustering There are different alerts in Alert Class. It is necessary to cluster the alerts. a) Repeated Alerts Merging Many of alerts are repeated, such as a hacker attacks a host with Syn-Flood. Host will get many Syn-Flood alerts with the same source and target address. These are redundant alerts. They will be merged as one alert and the amount will be recorded as the parameter of the alert priority. b) Same Target Alerts Merging After the merging of redundant alerts, there are still some alerts with the same source address or target address. The reason why merging the alerts that have the same target address is that target of attack is the key of corelation, and attack sources are usually much more than targets. So the alerts in the class are clustered by target addresses. Yixian Yang, et al. Expires March, 2006 [Page 13] INTERNET-DRAFT Alert Filtration and Fusion September,2005 In the end, the alerts are rearranged from high to low by priority. This can improve the efficiency of the corelation. The Process: Input: Junior Alert Output: Alert Class (Invalidation, Scan, Penetrate) Step1 Search for the alerts with the same source and target address, the alert priority adds the times which is repeated. Step2 Merge the redundant alerts and delete the redundancies. Step3 Search for alerts with the same target address, merge them as a cluster. The cluster is treated as an alert, but it keeps all its source addresses. Step4 After the merging, delete the single alerts that have been merged. Step5 Rearrange the alerts in the cluster from high to low by priority. Compute the cluster priority. Step6 Rearrange the clusters and alerts in the alert class. Step7 Output the alert class. The process in C code: Repeated Alerts Merging Step1: for (i=1;i<=m;i++) { if( Alert[i].mark==0) // repeat mark is 0, it's not repeated { for(k=i+1;k<=m;k++) { if(Alert[i].source_address==Alert[k].source_address&& Alert[i].target_address==Alert[k].target_address) // find repeated alert { Alert[k].mark=1; // mark repeated alert, prepare for deleting Yixian Yang, et al. Expires March, 2006 [Page 14] INTERNET-DRAFT Alert Filtration and Fusion September,2005 repeat_num++; // counter of repeated alert adds 1 Alert[i].priority++; // priority adds 1 } } } } Step2: for(i=1;i<=m;i++) // delete repeated alerts { if(Alert[i].mark==1) // find a repeated alert { for(k=i+1;k<=m;k++) // search for the unrepeated alert // following the repeated one { if(Alert[k].mark==0) // find unrepeated alert { Alert[i]=Alert[k]; // copy unrepeated one to the repeated Alert[k].mark=1; // mark it after copying } } } } for(i=m-repeat_num+1;i<=m) // delete repeated alerts behind { delete(Alert[i]); } The unrepeated alerts are picked out, the number is m-repeat_num Same Target Alerts Merging Step3: n=m-repeat_num; repeat_num=0; // counter resets for(i=1;i<=n;i++) { if(Alert[i].mark==0) // work on unmerged alerts { for(k=i+1;k<=n;k++) { Yixian Yang, et al. Expires March, 2006 [Page 15] INTERNET-DRAFT Alert Filtration and Fusion September,2005 if(Alert[i].target_address==Alert[k].target_address) // find an alert with the same target { Alert[i]=combine(Alert[i],Alert[k]); // merge the alerts // keep the source addresses Alert[i].combine_num++; // record the number of alerts in cluster Alert[k].mark=1; // mark the alerts repeat_num++; // counter adds 1 Alert[i].combine_flag=1; // mark merged alert } } } } Step4: for(i=1;i<=n;i++) // delete merged alert { if(Alert[i].mark==1) // find a merged alert { for(k=i+1;k<=n;k++) // search for unmerged alert behind { if(Alert[k].mark==0) // find unmerged alert { Alert[i]=Alert[k]; // copy unmerged one to the merged Alert[k].mark=1; // mark it after copying } } } } for(i=n-repeat_num+1;i<=n) // delete merged alerts behind { delete(Alert[i]); } Step5: for(i=1;i<=n-repeat_num;i++) { if(Alert[i].combine_flag==1) //find cluster { for(k=1;k<=Alert[i].combine_num;k++) // arrange the high priority alert before Yixian Yang, et al. Expires March, 2006 [Page 16] INTERNET-DRAFT Alert Filtration and Fusion September,2005 { Alert[i].priority=Alert[i].priority+Alert[i][k].priority; // compute cluster priority for(j=k+1;j<=Alert[i].combine_num;j++) { if(Alert[i][k].priorityB, Invalidation Class. b. A->C, Scan Class. c. B->C, Penetrate Class. These attacks can't be corelated by basic corelation. So the Advanced Corelation is needed. Yixian Yang, et al. Expires March, 2006 [Page 19] INTERNET-DRAFT Alert Filtration and Fusion September,2005 The process of Advanced Corelation: Input: Alert Class(Invalidation, Scan, Penetrate) and the single alerts. Output: Senior Alerts Step1: Traverse invalidation class. The target address is called B. Step2: Traverse source addresses of B, the source is called A. Step3: Search for source A in scan class. Step4: Traverse scan class. Search for the alert with source A, Its target is called C. Step5: Traverse penetrate class. Search for target C. Step6: Find the alert with target C. Step7: Traverse sources of the alert with target C in penetrate class. Search for source B. Step8: Find B, A->B, A->C, B->C can be corelated. Senior alert is created. The process in C code: for(i=1;i<=invalidation.target_num;i++) { for(j=1;j<=invalidation[i].source_num;j++) { for(k=1;k<=scan.source_num;k++) { if(scan[k].source_address==invalidation[i][j].source_address) { for(l=1;l<=penetrate.target_num;l++) { if(scan[k].target_address==penetrate[l].target_address) { for(a=1;a<=penetrate.source_num) { if(penetrate[l][a].source_address== invalidation[i].target_address) connect(invalidation[i][j],scan[k],penetrate[l][a]); } } } } } Yixian Yang, et al. Expires March, 2006 [Page 20] INTERNET-DRAFT Alert Filtration and Fusion September,2005 } } 4.3.3 Situation Assessment The Dempster-Shafer decision theory is considered a generalized Bayesian theory. It is proposed here to calculate the belief of senior alerts. The alerts will be judged by expert system based on the belief. This is the example of IPspoofing: Assume situations of the senior alert is A1(IPspoofing) and A2. On t1, there is an alert in invalidation class(A->B). This is state S1. Based on expert experience, probability mass function m1(A1,A2)=(0.4,0.6). On t2, there is an alert in scan class(A->C). This is state S2. Based on expert experience, probability mass function m2(A1,A2)=(0.5,0.5). On t3, there is an alert in penetrate class(B->C). This is state S3. Based on expert experience, probability mass function m3(A1,A2)=(0.8,0.2). On t3, there is an alert in penetrate class(B->C). This is state S4. Based on expert experience, probability mass function m4(A1,A2)=(0.8,0.2). Combine the data: m=m1¨’m2=(0.4,0.6) m=m¨’m3=(0.73,0.26) m=m¨’m4=(0.92,0.08) Yixian Yang, et al. Expires March, 2006 [Page 21] INTERNET-DRAFT Alert Flitration and Fusion September,2005 5. References [1] Denning, D.E. An intrusion detection model[J], IEEE Transactions on Software Engineering, 1987, 13(2):222-23. [2] Bass-Intrusion detection systems and multisensor data fusion [J], Communications of the ACM, 2000, 43(4):99-105. [3] H.Debar, A.Wespi, "Aggregation and Correlation of Intrusion- Detection Alerts", In Proceedings of the Fourth International Symposium on the Recent Advanced in Intrusion Detection (RAID'2001), LNCS2 212, pp.85-1032001. [4] F.Cuppens, Managing Alerts in a Multi-Intrusion Detection Environment, In 17th Annual Computer Security Applications Conference New-Orleans, New-Orleans, USA, December 2001. [5] Stuart Staniford etc. Practical Automated Detection of Stealthy Portscans. Silicon Defense, http://www.silicondefense.corn/software/spice/index.htm. [6] S.Kumar and E.Spaford. An Application of Patern Matchingin Intrusion Detection. Department of Computer Sciences, Purdue University, CSD-TR-94-013, Coast TR 94-07, 1994. [7] S.Kumar. Classification and Detection of Computer Intrusions. PhD thesis, Department of Computer Sciences, Purdue University, August 1995. [8] Slagell,M. The Design and Implementation of MAIDS (Mobile Agent Intrusion Detection System) . Master's thesis, Computer Science Department, Iowa State University, 2001. [9] G.Helmer, J.Wong, M.Slagell, V.Honavar, L.Miller and R.Lutz. Software Fault Tree and Colored Petri Net Based Specification, Design and Implementation of Agent-Based Intrusion Detection Systems. Submited to ACM Transactions on Information and System Security (TISSEC). [10] Jain, K. and Sekar, R. User-Level Infrastructure for System Call Interposition: A Platform for Intrusion Detection and Confinement. In Proceedings of the Year 2000 Network and Distributed Systems Security Symposium (NDSS 2000). [11] Warrender, C., Forrest, S., and Pearlmutter, B.Detecting Intrusions Using System Calls: Alternative Data Models. In Proceedings of the 1999 IEEE Symposium on Security and Privacy. [12] Helmer, G., Wong, J., Honavar, V., and Miller, L. Automated Discovery of Concise Predictive Rules for Intrusion Detection. Technical Report TR99-01, Department of Computer Science, Iowa State University. Yixian Yang, et al. Expires March, 2006 [Page 22] INTERNET-DRAFT Alert Filtration and Fusion September,2005 [13] Hofmeyr, S.A.,Forrest, S., and Somayaji, A. Intrusion Detection Using Sequences of System Calls. Journal of Computer Security, 6(3):151180,1998. [14] T.Tidwell, R.Larson, K.Fitch and J.Hale. "Modeling Internet Attacks". Proceedings of System Calls. Journal of Computer Security, 6(3):151180,1998. the 2001 IEEE Workshop on Information Assurance and Security, pp .54-59,2001. [15] Ming-Yuh Huang, Thomas M.Wicks. A Large-scale Distributed Intrusion Detection Framework Based on Attack Strategy Analysis. Technical Report, Boeing Company, Seattle, WA,U.S.A. [16] C.Geib and R.Goldman. Plan Recognitionin Intrusion Detection Systems. In DARPA Information Survivability Conference and Exposition(DISCEX), June 2001. [17] C.Geib and R.Goldman. Probabilistic Plan Recognition for Hostile Agents. In Florida 115 AI Research Symposium (FLAIR), Key-West, USA, 2001. [18] Ulf Lindquist and Philip Porras. Detecting Computer and Network Misuse Through the Production-Based Expert System Toolset (P- Best). In IEEE Symposium on Security and Privacy, Oakland, USA, 1999. [19] A.Mounji and B.Le Charlier. Continuous Assessment of a Unix Configuration: Integrating Intrusion Detection and Configuration Analysis. In ISOC'97 Symposium on Network and Distributed System Security, San Diego, USA, February1997. [20] DEMPSTER A P. Upper and lower probabilities induced by a multivalued mapping [J]. Annals of Mathematical Statistics, 1967(38): 77-87. [21] SHAFER G. A mathematical theory of evidence [M].Princeton: Princeton University Press, 1976. Yixian Yang, et al. Expires March, 2006 [Page 23] INTERNET-DRAFT Alert Filtration and Fusion September,2005 6. Acknowledgement The authors gratefully acknowledge the contributions of Ming Cao, Xiuling Zhu, Huayi Rao, Xinliu Wang and Shuai Zeng. 7. Authors' Addresses Yixian Yang Information Security Center, Beijing University of posts and telecom.(BUPT), Beijing, China,100876 Phone:8610-62283366 Email:yxyang@bupt.edu.cn Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Yixian Yang, et al. Expires March, 2006 [Page 24]