A mobile approach for the intrusion detection

!" # $% & ')(+*-,/.0*1324*-5687:9<;=&>?,?5@1AB4 CD EF<G<HIEKJML)NODQPSRMTVU$C$N#WYX[Z\Z]X^W_K` a JbcRMTdJ[UdRMTVefRMgihjLIklRTdHmUdF<npoQqsr#R\n P+LID&t<HmUuepJMG<v a RMklH/E w G<HyxlDQTzo{HyUuepRMg JTzH/o@}~V~dqs %JLmW vsd&wy ƒjtzgsd _q+jkxldkg sdv< ˆ DKG@ˆ DQTdJMLSvsD BJ <L/LID Š WŒ lz+_ Z ržn ˆ C ~ a r@d vsd tf @ 3 c CD L šœmœ žz]ÿ _j -` _K _ - Š J0t %š œ\œƒ žz]ÿ _ -` _^ M Z+_

Abstract A mobile approach for the intrusion detection Jaouad Skaita, Fabrice Mourlin {Skaita@univ-paris12.fr, Fabrice.Mourlin@wanadoo.fr} Laboratory of algorithmic, complexity and logic - communicating systems group Paris 12 th university The AAFID structure is a distributed monitoring and intrusion detection system. The first concept comes from CERIAS group at Purdue University. This architecture employs small stand-alone programs (Agents) to perform policy of security in the hosts of a network. AAFID is designed as a hierarchical structure of components with agents at the lowest level of the tree performing the most basic functions. It was the first architecture that proposed the use of autonomous agents for doing intrusion detection. It constitutes a true support for research and testing of intrusion detection algorithms and mechanisms. We describe the AAFID architecture with these existing prototypes and we start after this description to define our new version of AAFID (AAFID 3 ), which the strategy of operation is improved much compared to old. This metric is the mobility for agent that is implemented in Java JINI technology. Keywords: Intrusion detection, Agents, Security, Distributed system, Java, JINI, Mobility. 1. Introduction Computer security in today s networks is one of the fastest expanding areas of the computer industry because protecting resources from intruders is an arduous task that must be automatic to be efficient and responsive [Hale, 1998; GAO, 1996]. The intrusion detection is defined as the problem of identifying individuals who are using a computer system without authorization (i.e., crackers ) and those who have legitimate access to the system but are abusing their privileges [Mukherjee,1994]. Most intrusion detection systems currently rely on some type of centralized processing to analyse the data necessary to detect an intruder in real time [Lunt, 1993]. These systems of detection intrusion are not yet perfect for the needs of the policy security in today, some problems limit their facility of configuration, their scability and their effectiveness. The principal defect of existing architectures is that they are built around the only entity monolithic, which carries out most of calculations and of the collection of information. Our work consists in giving a global vision of our AAFID architecture (Autonomous Agent For Intrusion Detection): a distributed system, based on multiple entities independent working in a collective way. We call "entities these Autonomous Agents. This architecture was installed the first time in June 1998 by COAST Laboratory- Purdue University, an approach which solves part of IDS problems. In that first version of AAFID architecture (implemented in Perl) has a weak autonomy what prohibits to him to propagate the lifting the anomalies quickly and thus leads to solutions, which can be catastrophic. We propose a solution framed in the following points: 1- To make state of advanced on approach AFFID and in particular the version 2 which establishes metric news of monitoring. 2- To set up a version of this strategy of monitoring in Java with the API JINI (Java intelligent Network Interfaces). 3- To improve the stage of propagation anomaly but also continuation of monitoring after anomaly by applying the results of Mark Crosbie and Eugene Spafford. 1

4- To define metric news to measure the cover the anomaly realized by this implementation of this monitoring system. We present thereafter a complete description of this approach, part of the results resulting from prototypes, some points relating to the design and implementation as well as the directions taken for our work (version the AAFID in JAVA - JINI). 1.1. Intrusion detection During the last ten years, the intrusions detection became a discipline with whole share and is equipped a vocabulary become standard in fact. An intrusion is somebody (A.K.A. "hacker" or "cracker") [Spafford and Zamboni,2000] attempting to break into or misuse your system. The word "misuse" is broad, and can reflect something severe as stealing confidential data to something minor such as misusing your email system for spam (though for many of us, that is a major issue!). An "Intrusion Detection System (IDS)" is a system for detecting such intrusions. Intrusions generally fall into two categories: misuse and anomalies. Misuse attacks exploit some vulnerability in the system hardware or software to gain unauthorized access. Many of these attacks are well documented and are easily detected by computer systems, but new ones are constantly being discovered. Anomalies are harder to detect since they often originate from an inside user who already has access to the system. They are characterized by deviations from normal user behaviour, and detection requires some type of user profiling to establish a normal behaviour pattern. An intrusion detection system (IDS) is a data-processing program able to carry out this function by combination of various techniques. Most traditional intrusion detection systems (IDS) take either a network- or a host-based approach to recognizing and deflecting attacks. In either case, these products look for attack signatures, specific patterns that usually indicate malicious or suspicious intent. When an IDS looks for these patterns in network traffic, it s network-based. When an IDS looks for attack signatures in log files, it s host-based. Each approach has its strengths and weaknesses; each is complementary to the other. A truly effective intrusion detection system will employ both technologies. The definition [Spafford and Zamboni,2000] of intrusion detection system does not include preventing the intrusion from occurring, only detecting it and reporting it to an operator. There some intrusion detection systems that try to react when they detect an unauthorized action occurring. This reaction usually includes trying to contain or stop the damage, for example by terminating a network connection. Note that there are two types of potential intruders: Outside Intruders: Most people perceive that outside world to be the largest threat to their security. The media scare over hackers coming in over the Internet has only heightened this perception. Inside Intruders: FBI studies have revealed that 80% of intrusions and attacks come from within organisations. Think about it an insider knows the layout of your system, where the valuable data is and what security precautions are in place. 2

1.2. Characteristics of a Good Intrusion Detection System The reference work [Spafford and Zamboni,2000] defined the basic requirements for a good intrusion detection system : The system must run continually with minimal human supervision. The system must recognize any suspect activity or triggering event that could potentially be an attack. In system, Escalating behaviour on the part of an intruder should be detected at the lowest level possible. The system must be fault tolerant for system crashes (accidental or caused by malicious activity), must be able to recover the system previous state and resume its operation unaffected. Components on various hosts must communicate with each other regarding level of alert and intrusions detected. The system must respond appropriately to changing levels of alertness. The detection system must have some manual control mechanisms to allow administrators to control various functions and alert levels of the system. The system must be able to adapt to changing methods of attack. The system must be able to handle multiple concurrent attacks. The system must be scalable and easily expandable as the network changes. The system must be resistant to compromise, able to protect itself from intrusion. The system must be efficient and reliable. The system must be configurable to accurately implement security policies of the systems that are being monitored. The system must allow dynamic reconfiguration, allowing the administrator to make changes in its configuration without the need to restart the whole intrusion detection system. The system must provide graceful degradation of service. If some components of IDS stop working for any reason, the rest of them should be affected as little as possible. 1.3. Distributed and centralized intrusion detection systems. Most intrusion detection systems currently rely on some type of centralized processing to analyze the data necessary to detect an intruder in real time [Lunt, 1993]. A centralized approach can be vulnerable to attack. If an intruder can disable the central detection system, then most, if not all, protection is subverted. This approach of intrusion detection system is one where the analysis of the data is performed in a fixed number of locations, independent of how many host are being monitored. The examples of intrusion detection systems using a centralized approach, we classify : NADIR[1], NSM[2], IDIOT[3]. A distributed system allows detection software modules to be placed throughout the network with a central controller collecting and analyzing the data from all the modules, the analysis of the data is performed in a number of locations proportional to the number of hosts that are being monitored. Some intrusion detection systems that we classify as distributed, are: AAFID[Spafford and Zamboni,2000], EMERALD[4], GrIDS[5]. 3

Network Based Intrusion Detection: Network-based intrusion detection systems use raw network packets as the data source. A network-based IDS typically utilizes a network adapter running in promiscuous mode to monitor and analyze all traffic in real-time as it travels across the network. Its attack recognition module uses four common techniques to recognize an attack signature: Pattern, expression or bytecode matching, Frequency or threshold crossing Correlation of lesser events Statistical anomaly detection Once an attack has been detected, the IDS response module provides a variety of options to notify, alert and take action in response to the attack. These responses vary by product, but usually involve administrator notification, connection termination and/or session recording for forensic analysis and evidence collection. AAFID is also classified by the way their components are distributed and that s the architecture system for intrusion detection system using the network based approach. Host Based Intrusion Detection: Host-based intrusion detection started in the early 1980s before networks were as prevalent, complex and interconnected as they are today. In this simpler environment, it was common practice to review audit logs for suspicious activity. Intrusions were sufficiently rare that after- the-fact analysis proved adequate to prevent future attacks. Today s host-based intrusion detection systems remain a powerful tool for understanding previous attacks and determining proper methods to defeat their future application. Host-based IDS still use audit logs, but they are much more automated, having evolved sophisticated and responsive detection techniques. Host based IDS typically monitor system, event, and security logs on Windows NT and syslog in Unix environments. When any of these files change, the IDS compares the new log entry with attack signatures to see if there is a match. If so, the system responds with administrator alerts and other calls to action. Host-based IDS have grown to include other technologies. One popular method for detecting intrusions checks key system files and executables via checksums at regular intervals for unexpected changes. The timeliness of the response is in direct relation to the frequency of the polling interval. Finally, some products listen to port activity and alert administrators when specific ports are accessed. This type of detection brings an elementary level of network-based intrusion detection into the host-based environment. 1.4. Using autonomous Agents to construct a good distributed intrusion detection system [Spafford and Zamboni, 2000] defined the autonomous agent that is a software entity which function continuously and autonomously in a particular environment... able to carry out activities in a flexible and intelligent manner that is responsive to changes in the environment... Ideally, an agent that functions continuously...would be able to learn from its experiences. We expect an agent that inhabits an environment with other agents and processes to be able to communicate and cooperate with them, and perhaps move from place to place in doing so. In addition, we define an autonomous agent as a software agent that performs a certain security monitoring function at a host. We term the agents as autonomous because they are independently running entities. Agents may or may not need data produced by other agents to perform their work. Additionally, agents may receive high-level commands such as indications to start or stop execution, or to change some operating parameters from other entities. 4

Using autonomous agents and respecting the desirable characteristics listed in section 1.2. We built a better-distributed intrusion detection system: Adaptability Configurability Minimal system overhead Fault tolerance Subversion resistance Scalability Dynamic reconfiguration Compatibility Graceful degradation of service Autonomous Agents Advantages: Possibility to add/remove agents to monitor most interesting effects during certain period of time. An agent can be configured specifically for the host needs where it runs - this gives possibility to implement wide range of security policies. By dynamically enabling/disabling agents we can use system resources only for the tasks needed and therefore minimize system overhead. We can enable cross-verification between agents to keep their integrity. With increasing amount of hosts in the system we can dynamically increase amount of agents therefore making IDS scalable. If couple of agents are stopped (lets say for maintenance) other can continue working therefore allowing dynamic reconfiguration. Agents can run on different platforms (like Windows NT family PCs or Sun servers) providing compatibility of IDS with different platforms. If one agent accidentally stops for any reason only operation of couple of those related with it may be affected 2. Architecture AAFID 3 One of the first works proposing the use of autonomous Agents to develop Intrusion Detection Systems was [Crosbie94]. In this work, the author proposed that IDS tasks should get divided into several small subtasks compound of simple activities, that should be assigned, each one, to static autonomous software agents. The agents should be custom-built to the assigned tasks, with aid of Artificial Intelligence techniques (Genetic Programming). Here we present a research project to create and deploy an intrusion detection system based on autonomous mobile software agents. It was called that an intrusion detection system is an administration and management tool that identifies and reacts to intrusion and unauthorized use attempts. These agents will use mobility facilities, allowing an efficient use of resources, by dynamically distributing processing tasks, with a minimal degradation of performance perceived by users. With this kind of system, it s easy to setup an efficient defense for environments such as multimedia system, where there s no much experience about potential security. 2.1. An overview of AAFID. The AAFID architecture [Zamboni et al, 1998] appears the most similar to the one we propose. AAFID is designed as hierarchy of components with agents at the lowest level of the tree performing the most basic functions. The agents can be added, started, or stopped, 5

depending on the needs of the system. AAFID agents detect basic operations and report to a transceiver, which performs some basic analysis on the data and sends commands to the agents. A transceiver may transmit data to a transceiver on another host. If any interesting activity takes place, it is reported up the hierarchy to a monitor. The monitor analyzes the data of many transceivers to detect intrusions in the network. A monitor may report information to a higher-level monitor. The AAFID monitors still provide a central failure point in the system. AAFID has been developed into two prototypes: AAFID, which had many hard-coded variables and used UDP as the inter-host communication, and AAFID 2, which was developed completely in Perl and is more robust. They run only on Unix based systems. E B C Monitors Transceivers Agents Hosts A D Control Flow Data Flow Filters C UI A B D E Fig. 1. Physical and logical representations of a sample intrusion detection system that follows the AAFID architecture (called an AAFID system) 2.1.1. Agents An agent is a software entity that runs independently, monitors certain aspects of a host and reports to the appropriate transceiver to perform certain security monitoring function, 6

with the capability to move from place to place. For example, an agent could be looking for a large number of FTP connections to a protected host, and consider their occurrence as suspicious. Usually, the agent generates a report that is sent to the transceiver. The agent does not have the authority to generate an alarm. Agents do not communicate directly with each other in the AAFID architecture. The original AAFID prototype implemented a polling-loop structure for the agents, which covers many possible applications, but is insufficient for more complex monitoring tasks where, for example, the agent needs to block on a certain system resource or wait for a specific signal to occur. Agents may perform any functions they need. Some possibilities (which have not been used by any existing AAFID agents) are: Generic behaviour of an agent [Zamboni et al, 1998], agents may evolve time using genetic programming techniques. Agents could migrate from host to host by appliquéing the mobile agent architecture. Agents may employ the techniques to retain state between sessions. AAFID is based on multi agent defence introduced by each agent observes some aspect of network trace and acquires a model of its normal activity during a training phase so that anomalies can be detected. Do initialization Loop Process input If STOP message was received then Cleanup and exit End if Perform checks If abnormal condition detected then Generate STATUS_UPDATE message with new Status information End if Sleep for a certain amount of time (inter-check period) End loop 2.1.2. Filters The filters are envisaged like an abstraction layer of data for agents. In architecture AAFID 1, each agent was responsible to obtain the data, which it needed. And when the prototype was applied, this approach showed the following problem: On a simple system, there will be several agents, which exchange data with the same point emission. And to make this architecture extensible on the level of communication between various entities of the system, solution: group CERIAS thought of adding with architecture, entity filters which will be used to bind an agent to entity of control (transceiver or monitor) to exchange information and data. 2.1.3. Transceivers The transceivers have the responsibility for a machine. Their first role is to collect the information transmitted by the agents then to make the synthesis of it. They are thus ready to detect intrusions on the level of a machine. They can also transmit information to the higher level in order to detect distributed attacks, in this direction; they constitute the points of communication on the level of each machine. Their second role is to manage the agents present on machine. This management includes/understands the operations of creation, 7

destruction and (Re) configuration. They represent the kernel of safety and can thus apply the strategy safety of a person in charge for a network. 2.1.4 Monitors On the most level of the hierarchy, the monitors differ primarily from the transceivers by their knowledge of the state of its system, which it manages, on several machines. Their task is however comparable with that of the transceivers but on a level of additional hierarchy. A monitor can be connected to another monitor whereas a transceiver is never connected to another transceiver. The interaction with IDS is done through an interface connected to the monitor of higher level. 2.1.5. Users interfaces The most complete system of intrusion detection becomes useless if it does not have good mechanisms of abstraction of information making it possible to the users to interact with him. Architecture AAFID separates in a clear way user interfaces, the data acquisition and the elements of data processing. A user interface requires being able to interact with a monitor and to be able to use APIs that this one exports for its requests for information and to provide its instructions. This separation authorizes various implementations of the user interfaces (even concurrent) within architecture AAFID. For example graphic user (GUI) interfaces it can be used to provide interactive accesses to IDS while an interface based on lines of orders turns with scripts in order to automate certain functions of maintenance and report/ratio. Moreover when the interface is selected by respecting the existing standards of posting, it is possible to connect prototype AAFID to another tool for visualization (even more known) such as Tivoli/IBM (Security Storage and Management Software) or Open Master/Bull. 2.2. Communication mechanisms The communication between the various entities of architecture AAFID is done by transmission of messages, the latter are regarded as a central point in the operation of system AAFID. These mechanisms must take into account considerations as regards safety, it is with being said that they must resist the attempts making them not exploitable and must still provide mechanisms of authentication and confidentiality. We defined a message format with the following fields for AAFID3 messages: Message type. Message subtype. Source identifier. Destination identifier. Time stamp. Data. 2.3 Mobility in AAFID 3 Mobility is a key function to AAFID 3 system. Mobility is our solution that provides IDS components with the ability to hide within a network, evade an attacker during an attack situation, and to recover from being killed. We do this by wrapping internal components of the hierarchical IDS as mobile agents. The internal components of our approach can be mobile because they do not take data directly from the hosts or network. They receive data 8

from other components, process the data, and send it onward (by the use of JINI services). Thus, this processing can be performed at any location in the network. We must make the mobile agent that it can be useful to us in several situations, such : It is necessary that agents get audited periodically. Allocate an auditory module on each agent would imply in resource waste. Mobile agent can audit one by one, each of defended hosts sequentially. When an agent finds an abnormal pattern, it only needs to call for another agent to handle the abnormality. Without mobility, all agents should need to get loaded exactly at the point where the abnormality would occur, to detect or handle it. A mobile agent, instead, can move to the exactly point where it is needed. A mobile agent can easily track a worm attack, where the aggressor jumps quickly from one machine to another. The processing load can get dynamically distributed along the defended machines. There are two kinds of mobile features : the first one corresponds to the activity of agent, the second one is the mobility of the services. The migration of agent is implemented with RMI protocol (Remote Method Invocation) but the mobility of service is implemented by the use of JINI protocol. This protocol allows the agents to communicate each other. This is the basis of the genetic part of each agent and their ability to infer new statements from the states of their neighbour agents. We expect that using mobility we can get the system to see a minimal amount of resources, and concentrate the maximal amount of resources at the exact point where they are needed, at the exact moment when they are needed. Many mobility frameworks are available, offering mobility facilities to agents [Endler98]. Our solution provides a distributed network defense of AAFID system, using the autonomous agent developed in Java with the new technology called JINI and introducing the mobility character for the agent entity. 3. Conclusion We presented in this paper, our approach of the detection intrusion on a network. We based our work on the experience of Spafford and Zamboni but we do not accept the limits of their approach. Also, we chose some other technical choices which involve that the messages are now structured and each agent is totally independent for the plateform. It possess its own rules for the control. Each tranceiver possess its own rules for the synthesis of the collected data. These first improvments allow an easier use for the manager than before. We apply the same mobile approach for all the entities of the AAFID architecture. The use of JINI protocol allows us to define mobile services on specific plateforms. These are used by the agents after their arrival on such a plateform. The leasing functions of JINI protocol gives also the possibility to manage different versions of agents, transceivers and monitors. The lease is a key feature to deploy new entities on an existing architecture. A second important feature is the pluggable aspect of our prototype with other existing plateform. This feature is a good opportunity to introduce and to complete some other approaches. We consider that the mobility features will be considered as a real solution for some of the network problems which are encountered in intrusion detection domain. 9

4. References [Spafford and Zamboni,2000] E. Spafford and D.Zamboni. Intrusion detection using autonomous agents, Computer Networks, 34(4):547-570, October 2000. [Hale,1998] Hale, Ron, Intrusion Crack Down, Information Security, August 1998. [GAO,1996] Government Accounting Office, Information Security : Computer Attacks at Departement of Defense Pose Increasing Risks, GAO/AIMD-96-84, May 22, 1996. [Mukherjee,1994] B. Mukherjee, T.L. Heberlien, K.N. Levitt, Network Intrusion Detection, IEEE Network 8(3) (1994) 26-41. [Lunt,1993] Lunt, Theresa F. A Survey of Intrusion Detection Techniques. Computer & Security, 12:405-418,1993. [1] J. Hochberg, K. Jackson, C. Stallings, J.F. McClary, D. DuBois, J. Ford, NADIR : an automated system for detecting network intrusion and misuse, Computers and Security 12(3)(1993)235-248. [2] L. Heberlien, G. Dias, K. Levitt, B. Mukherjee, J. Wood, D. Wolber, A network security monitor, in : Proceedings of the IEEE Symposium on Research in Security anad Privacy, May 1990. [3] S. Kumar, Classification and detection of computer intrusions, Ph.D. Thesis, Perdue University, West Lafayette, IN 47907,1995. [4] P.A. Porras, P.G. Neumann, EMERALD : Event monitoring enabling responses to anomalous live disturbances, in : Proceedings of the 20 th National Information Systems Security Conference, National Institute of Standards and Technology, 1997. [5] S. Cheung, R. Crawford, M. Dilger, J. Frank, J. Hoagtland, K. Levitt, J. Rowe, S. Staniford-Chen, R. Yip, D. Zerkle, The design of GrIDS : a graph-based intrusion detection system, Technical Report CSE-99-2, Department of Computer Science, University of California at Davis, Davis, CA, January 1999. [Crosbie94] M. Crosbie, E. Spafford, Defending a computer System using autonomous agents, Technical Report 95-022, COAST Laboratory, Department of Computer Sciences, Perdue University, West Lafayette, IN 47907-1398, March 1994. [Zamboni et al, 1998] J.S. Balasubramaniyan, J.O. Garcia-Fernandez, E. Spafford, D. Zamboni, An architecture for intrusion detection using autonomous agents, Technical Report 98-05, COAST Laboratory, Purdue University, May 1998. [Endler98] Endler, Markus. Novos paradigmas de Interaçào usando Agentes moveis. IME/USP.1998 10