Composition of a DIDS by Integrating Heterogeneous IDSs on Grids Paulo F. Silva and Carlos B. Westphall and Carla M. Westphall Network and Management Laboratory Department of Computer Science and Statistics Federal University of Santa Catarina, Florianópolis, Brazil Marcos D. Assunção Grid Computing and Distributed Systems Laboratory and NICTA Victoria Laboratory Department of Computer Science and Software Engineering The University of Melbourne, Victoria, 3053, Australia {paulo,westphal,assuncao,carla}@lrg.ufsc.br ABSTRACT This paper considers the composition of a DIDS (Distributed Intrusion Detection System) by integrating heterogeneous IDSs (Intrusion Detection Systems). A Grid middleware is used for this integration. In addition, an architecture for this integration is proposed and validated through simulation. Categories and Subject Descriptors C.2.4 [Distributed Systes]: Client/Server, Distributed Applications. 1. INTRODUCTION Solutions for integrating heterogeneous IDSs (Intrusion Detection Systems) have been proposed by several groups [6],[7],[11],[2]. Some reasons for integrating IDSs are described by the IDWG (Intrusion Detection Working Group) from the IETF (Internet Engineering Task Force) [12] as follows: • Many IDSs available in the market have strong and weak points, which generally make necessary the deployment of more than one IDS to provided an adequate solution. • Attacks and intrusions generally originate from multiple networks spanning several administrative domains; these domains usually utilize different IDSs. The integration of IDSs is then needed to correlate information from multiple networks to allow the identification of distributed attacks and or intrusions. • The interoperability/integration of different IDS components would benefit the research on intrusion detection and speed up the deployment of IDSs as commercial products. DIDSs (Distributed Intrusion Detection Systems) therefore started to emerge in early 90s [9] to allow the correlation of intrusion information from multiple hosts, networks or domains to detect distributed attacks. Research on DIDSs has then received much interest, mainly because centralised IDSs are not able to provide the information needed to prevent such attacks [13]. However, the realization of a DIDS requires a high degree of coordination. Computational Grids are appealing as they enable the development of distributed application and coordination in a distributed environment. Grid computing aims to enable coordinate resource sharing in dynamic groups of individuals and/or organizations. Moreover, Grid middleware provides means for secure access, management and allocation of remote resources; resource information services; and protocols and mechanisms for transfer of data [4]. According to Foster et al. [4], Grids can be viewed as a set of aggregate services defined by the resources that they share. OGSA (Open Grid Service Architecture) provides the foundation for this service orientation in computational Grids. The services in OGSA are specified through well-defined, open, extensible and platformindependent interfaces, which enable the development of interoperable applications. This article proposes a model for integration of IDSs by using computational Grids. The proposed model enables heterogeneous IDSs to work in a cooperative way; this integration is termed DIDSoG (Distributed Intrusion Detection System on Grid). Each of the integrated IDSs is viewed by others as a resource accessed through the services that it exposes. A Grid middleware provides several features for the realization of a DIDSoG, including [3]: decentralized coordination of resources; use of standard protocols and interfaces; and the delivery of optimized QoS (Quality of Service). The service oriented architecture followed by Grids (OGSA) allows the definition of interfaces that are adaptable to different platforms. Different implementations can be encapsulated by a service interface; this virtualisation allows the consistent access to resources in heterogeneous environments [3]. The virtualisation of the environment through service interfaces allows the use of services without the knowledge of how they are actually implemented. This characteristic is important for the integration of IDSs as the same service interfaces can be exposed by different IDSs. Grid middleware can thus be used to implement a great variety of services. Some functions provided by Grid middleware are [3]: (i) data management services, including access services, replication, and localisation; (ii) workflow services that implement coordinate execution of multiple applications on multiple resources; (iii) auditing services that perform the detection of frauds or intrusions; (iv) monitoring services which implement the discovery of sensors in a distributed environment and generate alerts under determined conditions; (v) services for identification of problems in a distributed environment, which implement the correlation of information from disparate and distributed logs. These services are important for the implementation of a DIDSoG. A DIDS needs services for the location of and access to distributed data from different IDSs. Auditing and monitoring services take care of the proper needs of the DIDSs such as: secure storage, data analysis to detect intrusions, discovery of distributed sensors, and sending of alerts. The correlation of distributed logs is also relevant because the detection of distributed attacks depends on the correlation of the alert information generated by the different IDSs that compose the DIDSoG. The next sections of this article are organized as follows. Section 2 presents related work. The proposed model is presented in Section 3. Section 4 describes the development and a case study. Results and discussion are presented in Section 5. Conclusions and future work are discussed in Section 6. 2. RELATED WORK DIDMA [5] is a flexible, scalable, reliable, and platformindependent DIDS. DIDMA architecture allows distributed analysis of events and can be easily extended by developing new agents. However, the integration with existing IDSs and the development of security components are presented as future work [5]. The extensibility of DIDS DIDMA and the integration with other IDSs are goals pursued by DIDSoG. The flexibility, scalability, platform independence, reliability and security components discussed in [5] are achieved in DIDSoG by using a Grid platform. More efficient techniques for analysis of great amounts of data in wide scale networks based on clustering and applicable to DIDSs are presented in [13]. The integration of heterogeneous IDSs to increase the variety of intrusion detection techniques in the environment is mentioned as future work [13] DIDSoG thus aims at integrating heterogeneous IDSs [13]. Ref. [10] presents a hierarchical architecture for a DIDS; information is collected, aggregated, correlated and analysed as it is sent up in the hierarchy. The architecture comprises of several components for: monitoring, correlation, intrusion detection by statistics, detection by signatures and answers. Components in the same level of the hierarchy cooperate with one another. The integration proposed by DIDSoG also follows a hierarchical architecture. Each IDS integrated to the DIDSoG offers functionalities at a given level of the hierarchy and requests functionalities from IDSs from another level. The hierarchy presented in [10] integrates homogeneous IDSs whereas the hierarchical architecture of DIDSoG integrates heterogeneous IDSs. There are proposals on integrating computational Grids and IDSs [6],[7],[11],[2]. Ref. [6] and [7] propose the use of Globus Toolkit for intrusion detection, especially for DoS (Denial of Service) and DDoS (Distributed Denial of Service) attacks; Globus is used due to the need to process great amounts of data to detect these kinds of attack. A two-phase processing architecture is presented. The first phase aims at the detection of momentary attacks, while the second phase is concerned with chronic or perennial attacks. Traditional IDSs or DIDSs are generally coordinated by a central point; a characteristic that leaves them prone to attacks. Leu et al. [6] point out that IDSs developed upon Grids platforms are less vulnerable to attacks because of the distribution provided for such platforms. Leu et al. [6],[7] have used tools to generate several types of attacks - including TCP, ICMP and UDP flooding - and have demonstrated through experimental results the advantages of applying computational Grids to IDSs. This work proposes the development of a DIDS upon a Grid platform. However, the resulting DIDS integrates heterogeneous IDSs whereas the DIDSs upon Grids presented by Leu et al. [6][7] do not consider the integration of heterogeneous IDSs. The processing in phases [6][7] is also contemplated by DIDSoG, which is enabled by the specification of several levels of processing allowed by the integration of heterogeneous IDSs. The DIDS GIDA (Grid Intrusion Detection Architecture) targets at the detection of intrusions in a Grid environment [11]. GridSim Grid simulator was used for the validation of DIDS GIDA. Homogeneous resources were used to simplify the development [11]. However, the possibility of applying heterogeneous detection systems is left for future work Another DIDS for Grids is presented by Choon and Samsudim [2]. Scenarios demonstrating how a DIDS can execute on a Grid environment are presented. DIDSoG does not aim at detecting intrusions in a Grid environment. In contrast, DIDSoG uses the Grid to compose a DIDS by integrating specific IDSs; the resulting DIDS could however be used to identify attacks in a Grid environment. Local and distributed attacks can be detected through the integration of traditional IDSs while attacks particular to Grids can be detected through the integration of Grid IDSs. 3. THE PROPOSED MODEL DIDSoG presents a hierarchy of intrusion detection services; this hierarchy is organized through a two-dimensional vector defined by Scope:Complexity. The IDSs composing DIDSoG can be organized in different levels of scope or complexity, depending on its functionalities, the topology of the target environment and expected results. Figure 1 presents a DIDSoG composed by different intrusion detection services (i.e. data gathering, data aggregation, data correlation, analysis, intrusion response and management) provided by different IDSs. The information flow and the relationship between the levels of scope and complexity are presented in this figure. Information about the environment (host, network or application) is collected by Sensors located both in user 1"s and user 2"s computers in domain 1. The information is sent to both simple Analysers that act on the information from a single host (level 1:1), and to aggregation and correlation services that act on information from multiple hosts from the same domain (level 2:1). Simple Analysers in the first scope level send the information to more complex Analysers in the next levels of complexity (level 1: N). When an Analyser detects an intrusion, it communicates with Countermeasure and Monitoring services registered to its scope. An Analyser can invoke a Countermeasure service that replies to a detected attack, or informs a Monitoring service about the ongoing attack, so the administrator can act accordingly. Aggregation and correlation resources in the second scope receive information from Sensors from different users" computers (user 1"s and user 2"s) in the domain 1. These resources process the received information and send it to the analysis resources registered to the first level of complexity in the second scope (level 2:1). The information is also sent to the aggregation and correlation resources registered in the first level of complexity in the next scope (level 3:1). User 1 Domain 1 Analysers Level 1:1 Local Sensors Analysers Level 1:N Aggreg. Correlation Level 2:1 User 2 Domain 1 Local Sensors Analysers Level 2:1 Analysers Level 2:N Aggreg. Correlation Level 3:1 Domain 2 Monitor Level 1 Monitor Level 2 Analysers Level 3:1 Analysers Level 3:N Monitor Level 3 Response Level 1 Response Level 2 Response Level 3 Fig. 1. How DIDSoG works. The analysis resources in the second scope act like the analysis resources in the first scope, directing the information to a more complex analysis resource and putting the Countermeasure and Monitoring resources in action in case of detected attacks. Aggregation and correlation resources in the third scope receive information from domains 1 and 2. These resources then carry out the aggregation and correlation of the information from different domains and send it to the analysis resources in the first level of complexity in the third scope (level 3:1). The information could also be sent to the aggregate service in the next scope in case of any resources registered to such level. The analysis resources in the third scope act similar to the analysis resources in the first and second scopes, except that the analysis resources in the third scope act on information from multiple domains. The functionalities of the registered resources in each of the scopes and complexity level can vary from one environment to another. The model allows the development of N levels of scope and complexity. Figure 2 presents the architecture of a resource participating in the DIDSoG. Initially, the resource registers itself to GIS (Grid Information Service) so other participating resources can query the services provided. After registering itself, the resource requests information about other intrusion detection resources registered to the GIS. A given resource of DIDSoG interacts with other resources, by receiving data from the Source Resources, processing it, and sending the results to the Destination Resources, therefore forming a grid of intrusion detection resources. Grid Resource BaseNative IDS Grid Origin Resources Grid Destination Resources Grid Information Service Descri ptor Connec tor Fig. 2. Architecture of a resource participating of the DIDSoG. A resource is made up of four components: Base, Connector, Descriptor and Native IDS. Native IDS corresponds to the IDS being integrated to the DIDSoG. This component process the data received from the Origin Resources and generates new data to be sent to the Destination Resources. A Native IDS component can be any tool processes information related to intrusion detection, including analysis, data gathering, data aggregation, data correlation, intrusion response or management. The Descriptor is responsible for the information that identifies a resource and its respective Destination Resources in the DIDSoG. Figure 3 presents the class diagram of the stored information by the Descriptor. The ResourceDescriptor class has Feature, Level, DataType and Target Resources type members. Feature class represents the functionalities that a resource has. Type, name and version attributes refer to the functions offered by the Native IDS component, its name and version, respectively. Level class identifies the level of target and complexity in which the resource acts. DataType class represents the data format that the resource accepts to receive. DataType class is specialized by classes Text, XML and Binary. Class XML contains the DTDFile attribute to specify the DTD file that validates the received XML. -ident -version -description ResourceDescriptor -featureType -name -version Feature 1 1 -type -version DataType -escope -complex Level 1 1 Text Binary -DTDFile XML 1 1 TargetResources 1 1 10..* -featureType Resource11 1 1 Fig. 3. Class Diagram of the Descriptor component. TargetResources class represents the features of the Destination Resources of a determined resource. This class aggregates Resource. The Resource class identifies the characteristics of a Destination Resource. This identification is made through the featureType attribute and the Level and DataType classes. A given resource analyses the information from Descriptors from other resources, and compares this information with the information specified in TargetResources to know to which resources to send the results of its processing. The Base component is responsible for the communication of a resource with other resources of the DIDSoG and with the Grid Information Service. It is this component that registers the resource and the queries other resources in the GIS. The Connector component is the link between Base and Native IDS. The information that Base receives from Origin Resources is passed to Connector component. The Connector component performs the necessary changes in the data so that it is understood by Native IDS, and sends this data to Native IDS for processing. The Connector component also has the responsibility of collecting the information processed by Native IDS, and making the necessary changes so the information can pass through the DIDSoG again. After these changes, Connector sends the information to the Base, which in turn sends it to the Destination Resources in accordance with the specifications of the Descriptor component. 4. IMPLEMENTATION We have used GridSim Toolkit 3 [1] for development and evaluation of the proposed model. We have used and extended GridSim features to model and simulate the resources and components of DIDSoG. Figure 4 presents the Class diagram of the simulated DIDSoG. The Simulation_DIDSoG class starts the simulation components. The Simulation_User class represents a user of DIDSoG. This class" function is to initiate the processing of a resource Sensor, from where the gathered information will be sent to other resources. DIDSoG_GIS keeps a registry of the DIDSoG resources.The DIDSoG_BaseResource class implements the Base component (see Figure 2). DIDSoG_BaseResource interacts with DIDSoG_Descriptor class, which represents the Descriptor component. The DIDSoG_Descriptor class is created from an XML file that specifies a resource descriptor (see Figure 3). DIDSoG_BaseResource DIDSoG_Descriptor 11 DIDSoG_GIS Simulation_User Simulation_DIDSoG 1 *1* 1 1 GridInformationService GridSim GridResource Fig. 4. Class Diagram of the simulatated DIDSoG. A Connector component must be developed for each Native IDS integrated to DIDSoG. The Connector component is implemented by creating a class derived from DIDSoG_BaseResource. The new class will implement new functionalities in accordance with the needs of the corresponding Native IDS. In the simulation environment, data collection resources, analysis, aggregation/correlation and generation of answers were integrated. Classes were developed to simulate the processing of each Native IDS components associated to the resources. For each simulated Native IDS a class derived from DIDSoG_BaseResource was developed. This class corresponds to the Connector component of the Native IDS and aims at the integrating the IDS to DIDSoG. A XML file describing each of the integrated resources is chosen by using the Connector component. The resulting relationship between the resources integrated to the DIDSoG, in accordance with the specification of its respective descriptors, is presented in Figure 5. The Sensor_1 and Sensor_2 resources generate simulated data in the TCPDump [8] format. The generated data is directed to Analyser_1 and Aggreg_Corr_1 resources, in the case of Sensor_1, and to Aggreg_Corr_1 in the case of Sensor_2, according to the specification of their descriptors. User_1 Analyser_ 1 Level 1:1 Sensor_1 Aggreg_ Corr_1 Level 2:1 User_2 Sensor_2 Analyser_2 Level 2:1 Analyser_3 Level 2:2 TCPDump TCPDump TCPDumpAg TCPDumpAg IDMEF IDMEF IDMEF TCPDump Countermeasure_1 Level 1 Countermeasure_2 Level 2 Fig. 5. Flow of the execution of the simulation. The Native IDS of Analyser_1 generates alerts for any attempt of connection to port 23. The data received from Analyser_1 had presented such features, generating an IDMEF (Intrusion Detection Message Exchange Format) alert [14]. The generated alert was sent to Countermeasure_1 resource, where a warning was dispatched to the administrator informing him of the alert received. The Aggreg_Corr_1 resource received the information generated by sensors 1 and 2. Its processing activities consist in correlating the source IP addresses with the received data. The resultant information of the processing of Aggreg_Corr_1 was directed to the Analyser_2 resource. The Native IDS component of the Analyser_2 generates alerts when a source tries to connect to the same port number of multiple destinations. This situation is identified by the Analyser_2 in the data received from Aggreg_Corr_1 and an alert in IDMEF format is then sent to the Countermeasures_2 resource. In addition to generating alerts in IDMEF format, Analyser_2 also directs the received data to the Analyser_3, in the level of complexity 2. The Native IDS component of Analyser_3 generates alerts when the transmission of ICMP messages from a given source to multiple destinations is detected. This situation is detected in the data received from Analyser_2, and an IDMEF alert is then sent to the Countermeasure_2 resource. The Countermeasure_2 resource receives the alerts generated by analysers 3 and 2, in accordance with the implementation of its Native IDS component. Warnings on alerts received are dispatched to the administrator. The simulation carried out demonstrates how DIDSoG works. Simulated data was generated to be the input for a grid of intrusion detection systems composed by several distinct resources. The resources carry out tasks such as data collection, aggregation and analysis, and generation of alerts and warnings in an integrated manner. 5. EXPERIMENT RESULTS The hierarchic organization of scope and complexity provides a high degree of flexibility to the model. The DIDSoG can be modelled in accordance with the needs of each environment. The descriptors define data flow desired for the resulting DIDS. Each Native IDS is integrated to the DIDSoG through a Connector component. The Connector component is also flexible in the DIDSoG. Adaptations, conversions of data types and auxiliary processes that Native IDSs need are provided by the Connector. Filters and generation of Specific logs for each Native IDS or environment can also be incorporated to the Connector. If the integration of a new IDS to an environment already configured is desired, it is enough to develop the Connector for the desired IDS and to specify the resource Descriptor. After the specification of the Connector and the Descriptor the new IDS is integrated to the DIDSoG. Through the definition of scopes, resources can act on data of different source groups. For example, scope 1 can be related to a given set of hosts, scope 2 to another set of hosts, while scope 3 can be related to hosts from scopes 1 and 2. Scopes can be defined according to the needs of each environment. The complexity levels allow the distribution of the processing between several resources inside the same scope. In an analysis task, for example, the search for simple attacks can be made by resources of complexity 1, whereas the search for more complex attacks, that demands more time, can be performed by resources of complexity 2. With this, the analysis of the data is made by two resources. The distinction between complexity levels can also be organized in order to integrate different techniques of intrusion detection. The complexity level 1 could be defined for analyses based on signatures, which are simpler techniques; the complexity level 2 for techniques based on behaviour, that require greater computational power; and the complexity level 3 for intrusion detection in applications, where the techniques are more specific and depend on more data. The division of scopes and the complexity levels make the processing of the data to be carried out in phases. No resource has full knowledge about the complete data processing flow. Each resource only knows the results of its processing and the destination to which it sends the results. Resources of higher complexity must be linked to resources of lower complexity. Therefore, the hierarchic structure of the DIDSoG is maintained, facilitating its extension and integration with other domains of intrusion detection. By carrying out a hierarchic relationship between the several chosen analysers for an environment, the sensor resource is not overloaded with the task to send the data to all the analysers. An initial analyser will exist (complexity level 1) to which the sensor will send its data, and this analyser will then direct the data to the next step of the processing flow. Another feature of the hierarchical organization is the easy extension and integration with other domains. If it is necessary to add a new host (sensor) to the DIDSoG, it is enough to plug it to the first hierarchy of resources. If it is necessary to add a new analyser, it will be in the scope of several domains, it is enough to relate it to another resource of same scope. The DIDSoG allows different levels to be managed by different entities. For example, the first scope can be managed by the local user of a host. The second scope, comprising several hosts of a domain can be managed by the administrator of the domain. A third entity can be responsible for managing the security of several domains in a joint way. This entity can act in the scope 3 independently from others. With the proposed model for integration of IDSs in Grids, the different IDSs of an environment (or multiple IDSs integrated) act in a cooperative manner improving the intrusion detection services, mainly in two aspects. First, the information from multiple sources are analysed in an integrated way to search for distributed attacks. This integration can be made under several scopes. Second, there is a great diversity of data aggregation techniques, data correlation and analysis, and intrusion response that can be applied to the same environment; these techniques can be organized under several levels of complexity. 6. CONCLUSION The integration of heterogeneous IDSs is important. However, the incompatibility and diversity of IDS solutions make such integration extremely difficult. This work thus proposed a model for composition of DIDS by integrating existing IDSs on a computational Grid platform (DIDSoG). IDSs in DIDSoG are encapsulated as Grid services for intrusion detection. A computational Grid platform is used for the integration by providing the basic requirements for communication, localization, resource sharing and security mechanisms. The components of the architecture of the DIDSoG were developed and evaluated using the GridSim Grid simulator. Services for communication and localization were used to carry out the integration between components of different resources. Based on the components of the architecture, several resources were modelled forming a grid of intrusion detection. The simulation demonstrated the usefulness of the proposed model. Data from the sensor resources was read and this data was used to feed other resources of DIDSoG. The integration of distinct IDSs could be observed through the simulated environment. Resources providing different intrusion detection services were integrated (e.g. analysis, correlation, aggregation and alert). The communication and localization services provided by GridSim were used to integrate components of different resources. Various resources were modelled following the architecture components forming a grid of intrusion detection. The components of DIDSoG architecture have served as base for the integration of the resources presented in the simulation. During the simulation, the different IDSs cooperated with one another in a distributed manner; however, in a coordinated way with an integrated view of the events, having, thus, the capability to detect distributed attacks. This capability demonstrates that the IDSs integrated have resulted in a DIDS. Related work presents cooperation between components of a specific DIDS. Some work focus on either the development of DIDSs on computational Grids or the application of IDSs to computational Grids. However, none deals with the integration of heterogeneous IDSs. In contrast, the proposed model developed and simulated in this work, can shed some light into the question of integration of heterogeneous IDSs. DIDSoG presents new research opportunities that we would like to pursue, including: deployment of the model in a more realistic environment such as a Grid; incorporation of new security services; parallel analysis of data by Native IDSs in multiple hosts. In addition to the integration of IDSs enabled by a grid middleware, the cooperation of heterogeneous IDSs can be viewed as an economic problem. IDSs from different organizations or administrative domains need incentives for joining a grid of intrusion detection services and for collaborating with other IDSs. The development of distributed strategy proof mechanisms for integration of IDSs is a challenge that we would like to tackle. 7. REFERENCES [1] Sulistio, A.; Poduvaly, G.; Buyya, R; and Tham, CK, Constructing A Grid Simulation with Differentiated Network Service Using GridSim, Proc. of the 6th International Conference on Internet Computing (ICOMP'05), June 27-30, 2005, Las Vegas, USA. [2] Choon, O. T.; Samsudim, A. Grid-based Intrusion Detection System. The 9th IEEE Asia-Pacific Conference Communications, September 2003. [3] Foster, I.; Kesselman, C.; Tuecke, S. The Physiology of the Grid: An Open Grid Service Architecture for Distributed System Integration. Draft June 2002. Available at http://www.globus.org/research/papers/ogsa.pdf. Access Feb. 2006. [4] Foster, Ian; Kesselman, Carl; Tuecke, Steven. The anatomy of the Grid: enabling scalable virtual organizations. International Journal of Supercomputer Applications, 2001. [5] Kannadiga, P.; Zulkernine, M. DIDMA: A Distributed Intrusion Detection System Using Mobile Agents. Proceedings of the IEEE Sixth International Conference on Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing, May 2005. [6] Leu, Fang-Yie, et al. Integrating Grid with Intrusion Detection. Proceedings of 19th IEEE AINA"05, March 2005. [7] Leu, Fang-Yie, et al. A Performance-Based Grid Intrusion Detection System. Proceedings of the 29th IEEE COMPSAC"05, July 2005. [8] McCanne, S.; Leres, C.; Jacobson, V.; TCPdump/Libpcap, http://www.tcpdump.org/, 1994. [9] Snapp, S. R. et al. DIDS (Distributed Intrusion Detection System) - Motivation, Architecture and An Early Prototype. Proceeding of the Fifteenth IEEE National Computer Security Conference. Baltimore, MD, October 1992. [10] Sterne, D.; et al. A General Cooperative Intrusion Detection Architecture for MANETs. Proceedings of the Third IEEE IWIA"05, March 2005. [11] Tolba, M. F. ; et al. GIDA: Toward Enabling Grid Intrusion Detection Systems. 5th IEEE International Symposium on Cluster Computing and the Grid, May 2005. [12] Wood, M. Intrusion Detection message exchange requirements. Draft-ietf-idwg-requirements-10, October 2002. Available at http://www.ietf.org/internet-drafts/draftietf-idwg-requirements-10.txt. Access March 2006. [13] Zhang, Yu-Fang; Xiong, Z.; Wang, X. Distributed Intrusion Detection Based on Clustering. Proceedings of IEEE International Conference Machine Learning and Cybernetics, August 2005. [14] Curry, D.; Debar, H. Intrusion Detection Message exchange format data model and Extensible Markup Language (XML) Document Type Definition. Draft-ietf-idwg-idmef-xml-10, March 2006. Available at http://www.ietf.org/internetdrafts/draft-ietf-idwg-idmef-xml-16.txt.
distributed intrusion detection system grid middleware open grid service architecture computational grid grid intrusion detection architecture gridsim grid simulator intrusion detection system grid system integration
heterogeneous intrusion detection system intrusion detection service integration of ids ids integration grid service for intrusion detection