An Open Architecture of Intrusion Detection and Response System 1. Introduction Existing intrusion detection systems (IDSs) are static, with hard-coded detection algorithms and detection models. Therefore, it is difficult for existing IDSs to adapt to new algorithms and models. Such IDSs aim to protect a single computer system or a small local network, and are tightly tied to their underlying monitored computer systems and networks. They are incapable of adapting dynamically to a changing environment. Existing IDSs are also centralized and closed. They are not extensible and scalable to arbitrarily large systems. They do not interact with other domains' IDSs and do not rely on the information from other domains' IDSs. They follow the paradigm of a single locally-omniscient observer. They lack mechanisms to enable cooperative detection with other policy domains in wide-area networks, and they cannot reasonably monitor wide-area dynamic distributed applications that span organizational boundaries. Furthermore, the lack of significant automated support of IDSs makes them vulnerable to attack from foes with high computational power. It is clear that existing IDSs are not suitable for emerging software-intensive open active network architectures. New alternative approaches are required. In this paper we present an open architecture of intrusion detection and response system (IDRS) within an active network, using mobile agents, and dynamic policy negotiation. Our IDRS supports both static and run-time reconfiguration, and dynamic adaption. The abilities to reconfigure and adapt are important to detect and to counteract attacks, and to react to new found vulnerabilities. Furthermore, we employ dynamic policy negotiation and formation, together with automatic removal of security-sensitive data, to enable dynamic cooperative detection and response among different policy domains. We have readily available the computational environment of NCSA (National Center for Supercomputing Applications at University of Illinois at Urbana-Champaign) as the testbed for our IDRS. 2. Architecture Framework Our IDRS architecture is targeted toward open active heterogeneous computer systems and networks, such as the NCSA environment. The architecture uses meta-level components and mobile agents to support reflection and to permit run-time modification of policies and auditing mechanisms/methods. Mobile agents are essentially "smart packets" in active networks, and have embedded user-level scripts. Our architecture also provides a mechanism for dynamic cooperation detection over wide-area networks. Logically, our architecture has three levels: host level, intra-domain level, and inter-domain level. The host, or basic level, in our architecture is the auditing manager. The auditing manager employs preconfigured auditing facilities, auditing policies, and response mechanisms, which together form the meta-level components of the auditing manager. The auditing facilities are responsible for collecting raw auditing data, saving them in log files, and forwarding significant data to the intra-domain detecting manager. The auditing manager is specifically customized to each monitored system. In the intra-domain level, there are local auditing managers and (at least) one detecting manager. The detecting manager receives the collection of (reduced) data forwarded from all auditing managers. Its meta-level components are preconfigured auditing policies, detection and response mechanisms, and filtering mechanisms. The purpose of filtering is to remove security-sensitive information from the auditing data passed to other domains' detecting managers. The detecting manager is responsible for detecting intrusion, and for pursuing an appropriate autonomous response. In the inter-domain level, the architecture implements dynamic cooperating detection by sharing of auditing data essentially through dynamic policy negotiation. Our architecture specifies policies as a framework of classes, representing policy statements as data structures. The data structures range from sets and mappings at a low level, to access control lists, to labels, and rules at higher-levels, and at the highest level, to classes representing a variety of complete policy-forms. This highest level includes types of discretionary and non-discretionary access control. The classes also contain methods that evaluate policy decisions based on the data structures. Such a policy framework allows dynamic policy formation through run-time negotiation. One significant obstacle for cooperative detection is that supplying auditing data may inadvertently release confidential information to the public or to adversaries. We explore a method which removes security-sensitive information from the auditing data before the data are passed to other domains' detecting managers. Thus we can maximize the sharing of information among detection managers in different domains. The meta-level components of the architecture provide a base to support mobile agents. Via mobile agents, new policies and new auditing mechanisms/methods can be installed statically or dynamically on top of meta-level components. The meta-level structure of the architecture permits reflection; that is, it permits the semantics of the operations of the security model to be changed dynamically. On the other hand, the default meta-level components can monitor installations and provides a certain degree of assurance. We use the architecture-aware instrumentation and visualization software technology developed by our lab to aid the process of modification and reconfiguration. The detecting manager may interact with auditing managers, via mobile auditing agents. Consequently, the detecting manager may, subject to policy constraints, request more detailed information from auditing managers and change settings of a local host (i.e. a router) through that host's auditing manager. Mobile agents would be checked using existing system's authentication and verification protocols. To ensure interoperability of auditing agents from different systems, we need to investigate uniform logging data representations. Data representations should contain all the information available and should be extensible to future data formats. The module to convert the data would be systems specific. We plan to use the POSIX standard API for accessing the log files. 3. Implementation and Performance Study We are implementing our IDRS in the NCSA computational environment. NCSA itself contains over 500 computer systems, 96 subnets, and 8 supercomputers. It gets thousands of users from about 150 academic units, 15 industrial partners, and 50 collaborators. In addition, NCSA gets hundreds of thousands of http and ftp connections. NCSA is an open computational environment, without any firewall. It interacts in a variety of different domain connections. Some supercomputing applications are distributed over several sites. We believe that NCSA provides an excellent testbed to demonstrate the innovative functions of our IDRS.