Abstract—Current intrusion detection technologies have several major shortcomings. Using intelligent agents for intrusion detection and response is expected to improve the current status of the technology. Previous research mostly focuses on the distribution of detection and response functions across a domain or several domains rather than the intelligent behavior of agents. We explain the design and implementations of Belief-Desire-Intention agents, which operate based on their (possibly imperfect) beliefs about the current status of the network and use their predefined plans and capabilities to cope with the real world intrusion detection and automated response problems. The agents are context-sensitive to accommodate the changes in the network status and are capable of re-planning to recover from the failures.

Index Terms— Belief-Desire-Intention Agents, Fuzzy Logic, Intrusion Detection and Response, Network Survivability

I. INTRODUCTION

Benefiting from the Internet’s business advantages comes at the price of high security risks. There are two extremes in network security: full security and full access. The network that is unplugged from the Internet is a completely secure network. Although this solution has been used for many years, it is not an option for public and commercial sectors anymore. A network with full access is very convenient to use, but this is not practical either, considering the increasing number of malicious activities on the Internet. Every site needs to decide for itself where between the two extremes of fully secure and fully accessible they need to be. Then, the types of network security mechanisms and practices such as intrusion detection and survivable design are decided for managing the security risks.

The fact that network attacks come at the computer speed combined with several shortcomings of the current security solutions reveal the pressing need for an intelligent, autonomous, self-managed, adaptive, and cooperative agents based distributed system to fulfill the requirements of an effective network security solution.

We proposed the Fuzzy Adaptive Survivability Architecture (FASA) in [1] and [2] to imitate a network manager’s common-sense reasoning and decision-making in effectively managing the uncertainties that exist in detecting and

providing responses to the network attacks. Automated response is designed for survivability and enables a network to automatically react to events in order to maintain its essential services. Events include attacks and harmful incidents such as flash-crowds.

Fuzzy Adaptive Survivability Tool (FAST) is an implementation of FASA as a multi-agent system, which is built based on the Belief-Desire-Intention (BDI) logic. This paper describes only the design and implementation of the FAST agents. See [2] for the details of the proposed architecture.

The organization of this paper is as follows. In Section II we present a background review of the topic. Section III describes the design methodology. The proposed model and architecture for the network survivability is briefly described in Section IV and V. Section VI describes the implemented multi-agent system. A simulation scenario is presented in Section VII. Finally the paper is concluded in Section VIII.

II. BACKGROUND

An Intrusion Detection System (IDS) is a security mechanism that can monitor and detect intrusions to the host computers and networks in real time. They may also have the capability to respond to the attacks. They are host-based (sources of data are operating system and applications’ audit trails) or network-based (monitors and analyzes network traffic). A network-based IDS can detect wider range of intrusions including network-level attacks such as Denial of Service (DoS) attacks and worms.

Conventional approaches to intrusion detection involving a central unit to monitor the entire system have several disadvantages [2], [3]. Current commercial technologies cannot cover all possible attacks on the network accurately (i.e., they drop packets and generate excessive false alarms). Moreover, they are unable to respond to attacks in a timely manner. A distributed intelligent agent-based system is expected to overcome many of the shortcomings of conventional systems.

There have been several proposed architectures and implementations of IDSs using agent technology during the last decade in attempts to solve some of the problems associated with the current technology. Although we did not find any ‘important’ research on the application of Belief-Desire-Intention (BDI) agents in intrusion detection (other than [4]), some significant research on the application of

Application of Belief-Desire-Intention Agents in Intrusion Detection & Response

Mehdi Shajari and Ali A. Ghorbani Institute for Information Technology - e-Business

National Research Council of Canada, Fredericton, NB E3B9W4

181

intelligent agents in general are described in subsection C. A brief overview of BDI agents and JACK

agent development environment is also presented in the following subsections.

A. Belief-Desire-Intention Agents

Agent systems based on Belief-Desire-Intention (BDI) architecture, which is developed by Rao and Georgeff [5], are becoming increasingly common. A BDI agent is able to continuously reason about beliefs, goals, and intentions and act accordingly. This model represents both present uncertainties (due to limitations in perception) and future uncertainty (due to dynamism). BDI also distinguishes between success and failure in the execution of events [6]. The underlying theoretical model of BDI is described briefly here, but a detailed description can be found in [5]. As illustrated in Fig. 1, there are four major concepts in the BDI architecture:

Beliefs of an agent are information about the environment. They are subject to uncertainty and error. Desires are goals assigned to the agent. Intentions are commitments by an agent to achieve particular goals. In other words, they are plans that are currently being executed. Plans are choices available to the agent at any moment of time to achieve its goals.

B. JACK Agent Development Environment

JACK

extends Java to support agent oriented programming. It provides five main class-level constructs [8]:

Agent: defines an intelligent software agent’s behavior such as the capabilities of the agent, types of messages, events it responds to, and plans it uses to achieve its goals. Event: describes an occurrence to which the agent must respond. Plan: the instructions that the agent follows in order to achieve its goals and handle its designated events.

Capability: includes plans, events, and beliefs that give an agent certain abilities. BeliefSet (database): relational database representing agent beliefs.

Fig. 2 illustrates the JACK

architecture constructs and their relationships. In simple terms, a change in the agent’s beliefs (new observations) under some predefined conditions may cause new goals or desires to be adopted. A new desire consequently causes an appropriate plan to be invoked and executed. Internal events and messages from the other agents may have the same effect. When an agent receives a message event or an internal event is posted, it initiates a task to handle them. This task involves selecting and executing a plan that is both relevant and applicable to the event. The PlanChoice event is automatically posted if there is more than one applicable plan. Plans are defined at an abstract level and during execution, as more information becomes available; they are refined to fill out the details.

C. Related Work

The architecture proposed by Boudaoud and Guessoum [4] called MANSMA (Multi-agents System-based Network Security Management Architecture) is the only research work that has pointed to the use of BDI agents in intrusion detection. Although authors claim that they have adopted a BDI solution for modeling a security management system and their agents have deliberation function to reason and extrapolate on their mental attitudes, built knowledge, and experience, in a rational way, they have not published any more details about their design. Two layers of agents exist in the MANSMA: Manager Layer and Local Layer. The Manager Layer manages the global security of a large network, while the Local Layer manages the security of a domain. Three levels of agents are identified at the Manager Layer: a Security Policy Manager Agent (SPMA), an Extranet Manager agent (EMA), and several Intranet Manager Agents (IMA). The Local Layer manages the security of a domain (a set of hosts in a local network). It includes a group of Local

Fig. 2. JACKTM Constructs [8]

Fig. 1. A Belief-Desire-Intention Agent Architecture [7]

182

Agents (LAs), which have specific functions. LAs are designed to monitor specified activities and report to Manager Agents.

Autonomous Agents for Intrusion Detection (AAFID) is a distributed intrusion detection architecture and system developed in CERIAS at Purdue University [9]. AAFID uses agents organized in a hierarchical fashion for data collection and analysis. The system architecture is built around four components: agents, filters, transceivers, and monitors. An AAFID system can be distributed over any number of hosts in a network.

The Fuzzy Intrusion Recognition Engine (FIRE) [10] is a network intrusion detection system that uses fuzzy systems to assess malicious activity against computer networks. It utilizes the AAFID agents.

Deploying a number of light-weight agents, called ID agents, to various network components is proposed by Qin et al. [3]. They propose multiple ID agents and each of them specializes in a certain category of intrusions. For example, the host-based ID agents can analyze audit data, system call traces, or user shell command streams to monitor applications and user behaviors. On the other hand network ID agents are responsible for network level attacks, such as DDoS. The proposed architecture is hierarchical and divides the protection and analysis scope to Local-analysis, regional-analysis and Global-analysis. The ID agents are deployed locally to detect intrusive behavior on network components. An ID Correlator manages some local ID agents and combines the security alarms sent by local ID agents. ID Correlator is responsible for a region and reports its findings to the ID Manager, which is responsible for the whole network (e.g., campus network).

Gopalakrishna and Spafford [11] describe architecture for distributed autonomous agents that cooperate to build an intrusion detection system. In the interest-based cooperation and communication model proposed by the authors, agents request and receive information solely on the basis of their interest. They can specify new interests as the result of a new event or alert, which avoids unnecessary data flow among the agents. The major advantage of interest-based model is that the entire system is not compromised if an agent fails. Instead of complete failure, there is graceful degradation of system performance.

A prototype called the Hummingbird System [12] is developed at University of Idaho. Hummingbird is a distributed system that employs a set of Hummer agents, each assigned to a single host or a set of hosts. Each Hummer interacts with other Hummers in the system through a manager, a subordinate, and peer relationships. Managers may transmit commands to subordinates. Such commands include gather/stop gathering data or forward/stop forwarding data. Peers may send requests for data gathering, forwarding, or receiving to peers; the other peers then decide whether to accept such requests. Hummingbird is intended to allow a system administrator to monitor security threats on multiple computers from one central location. Hummingbird's real strength is the ability to share data with other sites, without

compromising security and confidentiality. Helmer and Wong [13] from Iowa State University propose

the design and architecture of an intrusion detection system built from distributed agents. They have implemented an intelligent system using distributed lightweight intelligent agents on which data mining is performed to provide global, temporal views of an entire network system. Lightweight agents are agents that accomplish their essential tasks with minimal code. They are dynamically updateable, upgradeable, smaller, simpler, and, due to their smaller size, faster to transport.

Xue et al. [14] propose a multi-agent system for distributed intrusion detection. The architecture consists of many different types of agents that communicate with each other. A public-key encryption algorithm is used to encrypt all the communication and passwords in the system. An Agent Application Layer Communication Protocol (AALCP) is designed as a protocol for agent communication.

The Intrusion Detection Agent system (IDA) [15] developed by the Information Technology Promotion Agency (IPA) in Japan is an example of prototypes that use mobile agents for intrusion detection. In IDA, mobile agents trace intruders collecting information related only to the intrusion along the intrusion-route, and decide whether an intrusion has occurred. These functions enable efficient information retrieval, as well as make it possible to detect compromised intermediate hosts.

Ragsdale et al., [16] describe several adaptation techniques, which are used in the Adaptive Hierarchical Agent-based Intrusion Detection System (AHA! IDS) and Adaptive Agent-based Intrusion Response System (AAIRS). AHA! IDS is based on a fully distributed, multiagent framework. The major components in this framework are: 1) Director agents, which are responsible for detecting intrusive behavior; 2) Surrogate agents, which takes the Director's responsibilities in the event that Director fails; 3) Manager agents, which are responsible for detecting intrusive activities on a subset of systems for which a Director is responsible; 4) Tool agents, which are employed by a Manager agent to detect intrusive activity. The authors also elaborate on adaptation mechanisms that they have used for intrusion response in AAIRS. The following agents are defined: 1) Interface agents, which maintain a model of each IDS based on the number of false alarms they have already generated; 2) Master Analysis agent, which classifies an event based on the intrusion report and confidence metric from the Interface agent; 3) Analysis agents, which are assigned by the Master Analysis agent to handle an event. They analyze an event until it is resolved and an abstract course of action is decided; 4) Response Taxonomy agent, which is invoked by an analysis agent to classify the attack; 5) Policy Specification agent, which is invoked by an analysis agent to determine a response goal and to limit the response based on the different predefined legal and ethical constraints; 6) Tactics agent, which decomposes abstract course of action into specific action.

183

III. DESIGN METHODOLOGY

A layered approach to security engineering has been proposed in [17]. Using this approach, survivability design issues can be separated into four layers. These four layers from top to bottom are [18]:

1. Policy: states the high-level survivability goals. It is usually written in a natural language.

2. Model: is a simplified description of a complex system. It describes the system using abstract terms that can be analyzed and implemented.

3. Architecture: describes major components of a high-level design and their inter-relationships.

4. Mechanism: is a set of enabling technologies that are used to implement the design.

Policy and model are concerned with determining objectives and trade-offs, while architecture and mechanism are concerned with meeting these requirements. The complex inter-relationships between the layers may be inappropriate for top-down design (used in software engineering). An approach based on iterative refinement may be more suitable [18]. For example, the implications of the chosen mechanisms (e.g. the use of the Belief-Desire-Intention (BDI) agents in our design) must be taken into account on different layers.

IV. THE FUZZY ADAPTIVE SURVIVABILITY MODEL

The Fuzzy Adaptive Survivability Model (FASM) [2] is a model for monitoring network activities, detecting suspicious traffic, and mitigating network-level attacks. By mitigating attacks, the FASM is designed to fulfill survivability requirements that are specified by survivability policy. Survivability policy divides the network services and hosts into essential and non-essential. It may also state the most valuable resources (local and remote services and hosts) in an ordered list based on their essentiality or importance.

The major components of the FASM are shown in Table 1. Three different processes are defined to run concurrently: 1) monitoring and data collection; 2) event detection; and 3) response planning and execution.

The aim of the monitoring is to analyze the network traffic, looking for deviations from what is considered normal for the variables that represent important aspects of the network’s operation. This process reveals the degree of abnormality in each network variable by comparing the monitored value with the profile of the variable.

The event detection process simulates a network manager’s commonsense reasoning in handling events. This process uses the predefined attack signatures and approximate reasoning to represent the degree of certainty of each attack and its severity, even if the attack is vaguely defined. Detection processes inspect each flow for the signs of a predefined attack. When one of them detects the intention of an attack, the corresponding flow information is recorded in the SFT of that process.

The response planning process runs in parallel with other processes and is provided with the latest information about ongoing attacks and the network status. It follows a cost-based approach to selecting desirable responses, while avoiding responses that are more damaging than the intrusion itself. Relevancy-check and context functions are used to determine the relevant plans based on the type and the severity of an ongoing attack, and to customize plans based on the current status of the network. It also evaluates the desirability of each relevant plan by analyzing attack traces in SFT and taking into account the local policies and preferences.

V. ARCHITECTURAL COMPONENTS

The FASA architecture as shown in Fig. 3 consists of three functional boxes, namely: Monitor (M-box), Detection (D-box), and Decision (X-box).

A. Monitor-box (M-box)

The M-box is used to monitor networks’ operational variables. Each M-box is dedicated to monitoring one of the network variables and making its state available to the other boxes. It also maintains a profile for each network variable.

Network packet flows are the major source of network data in FASA. For flow-based monitoring, a flow is identified by source-destination addresses and port numbers. Several

TABLE 1

MAJOR COMPONENTS OF THE FUZZY ADAPTIVE SURVIVABILITY MODEL

Component Description Processes

Three major programs that are running concurrently

Flows Records of network traffic that appears between IP/port pairs Variables Represent different aspects of network activities Profiles Characterize the behavior of the network variables Signatures Describe attacks or events of interest Events Generated when a new flow matches one of the signatures Suspicious Flow Tables (SFTs) Data structures that record the suspicious activities Services Describe important services provided/needed by the network Response Plans Actions taken when all necessary conditions are satisfied Contexts Evaluate the desirability of each plan with respect to the network status

184

operational variables are calculated from the network flows, which are used to detect network-level attacks as well as other events of interest. These variables are calculated using a measurement window.

In each Monitor-box, fuzzy sets are used to represent normal and abnormal behavior of each variable. Using these fuzzy sets also enables an M-box to apply linguistic terms to the regions of the continuum. In fuzzy monitoring, the universe of network variable is partitioned into fuzzy sets such as abnormally-low, normal, and abnormally-high. normal is a fuzzy set that describes the normal behavior of a variable. Other terms are used to describe deviation of a variable from normal operation.

B. Detection-box (D-box)

Each D-box determines if the outputs from the M-boxes are indicative of an attack and estimates the degree of suspicion. Each D-box is dedicated to detecting a single attack, which can be defined specifically or in a general form. It decides about flows as they appear on the network and divides them into 3 categories: 1) normal traffic, when there is no indication of suspicious activity in a network flow; 2) suspicious traffic, which is recorded into the SFT of the D-box; and 3) attack traffic, which needs to be dealt with by an appropriate response.

FASA’s Detection approach is neither a rigid signature-based, nor a purely anomaly-based detection. A combination of signatures and anomalies is used to detect network-level attacks. For each attack event, a set of fuzzy-crisp rules representing the security experts' knowledge is defined. A fuzzy signature can be defined very specifically to match the

description of a known attack, or in a general form to detect a group of attacks that belong to the same family. Partial knowledge about an attack is usually sufficient to write a generalized fuzzy signature that can detect (degree of suspicion to) different variations of a known attack (including new ones). For example, an abnormally-high number of connections to the same host but different services or the same service but different hosts can be a generalized signature for probing attacks. Traffic is labeled as DDoS/flash-crowd, if there is an abnormally-high number of source addresses connecting to a single destination address. The abnormally-high number of half-open flows to the same destination is used as the signature of SYNflooding attack.

C. Decision-box

Fuzzy decision theories are used in FASA to accommodate the uncertainties of the decision process in automated responses. In the proposed architecture, the decision for a response is made in three stages (see Fig. 4). First, the severity (degree of threat) of the attack is used to select a subset of available response plans that are relevant. Severity is a fuzzy variable, with linguistic values including low, medium, and high. It is calculated from the relevant attributes of the ongoing attack and is an estimation of the cost of the damage resulted from successful completion of the attack.

In the second stage of decision process, the context of the current attack is applied to evaluate relevant responses considering the current network status. Decisions in FASA are context-dependent. In other words, decisions in FASA do not depend merely on the different criteria, but also on the evaluation of these criteria in the current context. For example, while SQL service may be essential for a given network, it may be blocked if the inbound traffic is going to cripple the network. This would be an attempt to allow the other more essential services to survive.

Relevant plans are defined at an abstract level (e.g., block some inbound services). When information about the actual type of the traffic to be blocked (determining the service

Fig. 3. The fuzzy Adaptive Survivability Architecture

Fig. 4. Decision-box

185

numbers by analyzing SFT of the attack) and the context are applied to the relevant plans, they form a set of applicable plans.

At the last stage of decision process, a variation of fuzzy multi-attribute decision theory [19] is applied to choose a desirable response from the applicable responses. The evaluation is carried out according to the predefined criteria. The local survivability policy, Information about the ongoing attack collected in the SFTs, and context of the attack are used to determine the degree of satisfaction of each criterion. The desirable plan is a plan that satisfies all of the relevant criteria at least to some degree.

VI. THE FUZZY ADAPTIVE SURVIVABILITY TOOL

Fuzzy Adaptive Survivability Tool (FAST) is an agent-based implementation of FASA. Each functional box of FASA is implemented as an agent using the JAVA/ JACK

[8] development environment. The application of intelligent agents allows an intricate and complex architecture such as FASA to be implemented in a highly organized manner.

The current implementation of FAST, as shown in Fig. 5, consists of four different types of agent, namely HCI, Monitor, Detection, and Decision agents. The HCI agent maintains an appropriate user interface for control by a human operator. Monitor agents identify anomalous network activities represented by different variables (M-box). Detection agents inspect each flow for signs of attacks as they appear on the network (D-box). Decision agents, upon receiving an attack alert, initiate a task that involves selecting and executing a desirable plan that is both relevant and applicable to the event in the current context (X-box).

A. HCI Agent

The HCI agent provides an appropriate user interface for creating and initializing other agents. It also allows human administrator to intervene in the detection and response, when it is necessary. HCI agent has four major capabilities:

AgentCreating: creating new agents upon request from human operator. ConfigurationChangeRequesting: Requesting a change in the configuration of the other agents upon receiving a request from human operator. NewFlowReading: reading network flows from the data set already collected from the network. FilterSimulating: Simulating a requested filter to block certain types of traffic from input date set.

Note that in the current prototype the HCI agent reads a flows dataset, which is collected in a real campus network, at the exact sequence that they have appeared in the real network. These flows are sent to the Monitor agents to simulate the real situation. The applications of chosen responses are also simulated. For example, the Traffic Regulation Decision agent may choose a response plan that filters a particular type of traffic in one of the routers. The HCI agent receives the characteristics of the traffic that should be filtered and apply it to the dataset. As the result, as long as

the filter is active, the flows with the specified characteristics will not appear in the simulated network.

B. Monitor Agent

Each Monitor agent implements an M-Box by monitoring one of the network variables. Monitor agents identify anomalous network activities (represented by different variables) and use them to detect known attacks and events of interest. The variables are calculated from one of the information sources using the VariableDefinition database that is predefined for each Monitor agent. Using the information provided by Monitor agents, Detection agents can detect the status of attacks by using attack definition stored in a rule-base.

Profiles are maintained in VariableProfile databases. In the current implementation, they can be used by the network manager in building membership functions that are used by the Detection agent in calculating the degrees of normality or abnormality of the variable.

Each variable’s profile represents the behavior of that variable. If the status of the network is evaluated as normal during the profiling period, the variable profile can be used in building the variable’s membership functions. In the current implementation, the network manager should manually update the membership functions.

An extension of Unified Modeling Language (UML) for designing JACKTM agents (JACK/UML) is proposed by

Fig. 5. Agents of the Fuzzy Adaptive Survivability Tool

186

Papasimeon [20]. The current implementation of the Monitor agent using JACK/UML is described in Fig. 6. The Monitor agent has the following capabilities:

Initializing: initializing itself upon receiving command from HCI agent. NewFlowHandling: handling a new flow sent by HCI agent by calculating the new value for the variable according to its definition. NewValueSending: sending the latest value of the variable to detection agents.

The following events are defined in the Monitor agent: InitializationRequired: is sent by HCI agent to remind the Monitor agent that initialization is required. NewFlow: is sent by HCI agent to inform the Monitor agents that a new flow is read (i.e., received) and ready for processing. NewValueAvailable: is posted by the Monitor agent when a new value for the monitored variable is calculated. NewValue: is sent by a Monitor agent to the relevant Detection agents. The relevant Detection agents are the Detection agents that use this value to detect an attack. Each Monitor agent is given a list of Detection agents during initialization.

A Monitor agent uses the following plans: SelfInitialization: initializes the agent with the values supplied by human operator through the HCI agent. SendNewValue: sends the newly calculated value for a variable to the relevant Detection agents using the NewValue event. VariableCalculation: calculates the value for the monitored variable using and the Monitor agent’s VariableDefinition database.

C. Detection Agent

Each Detection agent is used to detect one of the known attacks. Detection agents receive their inputs from various Monitor agents. These input values are fuzzified by membership functions that partition each input variable. These membership functions are stored in a VariableMembershipFunctions database.

Using the configuration information and profile of each variable, a fuzzy partitioning method automatically builds the membership functions [1]. The following configurations are defined for each variable:

Number of membership functions: 2 partitions (normal and abnormally-high), 3 partitions (normal and abnormally-low and abnormally-high), or more. The characteristics of the membership function (e.g., trapezoidal or triangular).

The Detection agents use fuzzy Inference [2] as their reasoning method to decide about the status and attributes of the attacks. The rule-base of each Detection agent is defined in a FuzzyRules database. The name of the relevant FuzzyRules database for each Detection agent is the same as its own name. The detection rules may contain categorical, binary, and fuzzy conditions. When there are crisp conditions, the inference engine of the Detection agent first matches the crisp conditions stored in the CrispConditions database. If the input crisp conditions do not match the input traffic, the status of the attack is labeled as not-detected. Otherwise, the agent performs a fuzzy inference using the fuzzy rules.

The current implementation of the Detection agent is described in Fig. 7. The Detection agent has the following capabilities:

ConfigurationChanging: changing the configuration parameters using new values provided by the network manager through the HCI agent. Detecting: detecting a known attack stated by the CrispConditions and FuzzyRules databases in the specific or general form and calculating its attributes.

The following events are defined in the Detection agent: ConfigurationChangeRequired: is sent by the HCI agent to inform a Detection agent that a change in configuration is requested. NewValue: is sent by a Monitor agent to provide a Detection agent with the latest value of a variable that is relevant in detecting an attack. AttackDetected: is sent to the Decision agent to inform it of a suspicious or attack activity.

The Detection agent uses the following plans: ChangeParameters: apply changes that are requested to the configuration of a Detection agent. CalculateAttackAttributes: calculate the status of an attack and its different attributes using a fuzzy inference engine.

Fig. 6. Overall Design for the Monitor Agent with JACK/UML

187

D. Decision Agent

The Decision agent decides about an alert and selects a response plan based on the predefined criteria and network’s survivability policy. A response plan defines the system’s skills in reacting to different attacks encountered in the network. The survivability policy is an ordered list of essential, important, and non-essential services and their associated Essentiality Factor (EF). EF for each service is defined in the interval [0,1] and is stored in the EssentialityFactors database.

Context-sensitivity is at the heart of any rational behaviour [8]. Context is defined in this paper as the status of the network that can be sensed by the decision agent at any given time. Decision agent can distinguish different contexts and adapt its behavior accordingly. The network manager provides a context-dependent policy in the contexts beliefset. The policy shows a network manager’s preferences in each context and describes how the change of a context affects his preferences.

Fig. 8 shows the overall design of the Decision agents. The Decision agent for traffic regulation has the following capabilities:

Deciding: decides whether or not to act when a suspicious or attack event is received. Mitigating: enables the Decision agent to respond to traffic-based attacks by blocking malicious traffic without affecting the network’s essential traffic flows.

The following events are defined in the Decision agent: AttackDetected: is sent by a Detection agent to inform the Decision agent of a possible attack and its attributes. MitigationRequired: is posted after a change in the agent’s belief regarding an ongoing attack in order to

remind it that the attack in progress must be responded to (belief-driven event). PlanChoice: is posted automatically when there is more than one relevant response plan to an ongoing attack. FilterRequired: is sent to the HCI agent to inform it of a filter or a set of filters that need to be activated to block malicious traffic. The HCI agent then applies the requested filters to the input flow.

The Decision agent uses the following plans: Decide: is executed when an AttackDetected event is received from one of the Detection agents. It updates the agent’s Attacks beliefset. A change in the agent’s belief may result in a decision about the necessity of a response. MitigationRequired is posted automatically, if the new status and severity of an attack indicates that mitigation is necessary. ChooseResponse: is executed to handle the PlanChoice event and choose the desirable plans from the set of relevant plans. ChooseResponse receives as an input the list of all of the applicable plans. It also can obtain the information that is required during the decision process (e.g., the filter attributes) directly from each of the applicable plans. Response Plans: these are actual automated response plans that are designed to block or isolate particular types of network traffic in order to mitigate the attack.

E. Meta-level reasoning

The Decision agent uses BDI logic as the reasoning framework to choose the desirable response plans. By claiming to handle an attack alert, the agent looks through its plans to find plans that have a matching #handles event statement. The Decision agent then executes one of the plans

Fig. 7. Overall Design for the Detection Agent with JACK/UML

Fig. 8. Overall Design for the Decision Agent with JACK/UML

188

from those that handle this event. Using the relevant() method, which is defined in each plan,

the Decision agent identifies those plans with preconditions that are currently satisfied with respect to the alert attributes. The relevant() method must always be a static Boolean method. If this method returns true, the plan is relevant to the alert. Usually, relevant() tests one or more of the alert's attributes to make a decision. In the current implementation, the precondition in each plan checks the severity, which is associated with each ongoing attack event and decides if a response plan is relevant or not. In other words, when relevant() is present, it provides the agent with a filter to exclude plans that are not appropriate to handle the alert considering the low severity of ongoing attack.

Using the relevant() method in this way, the agent can filter out those plans it knows it will not want to execute before proceeding with the applicability calculations described in the following paragraphs. Typically, these applicability calculations are more resource-intensive, so well thought out relevant() methods can improve the computational efficiency of the application.

Evaluation of the various applicable response plans is carried out in the current context of ongoing attack by the ChooseResponse plan. In the current implementation, contexts are selected solely based on the current stress level of the network represented by Total Inbound/outbound Traffic rate variable. Upon request by the ChooseResponse, the contexts beliefset returns different a and ß values in different inbound and outbound traffic situations (see Fig. 9). a and ß are defined in [0,1]. a is the upper boundary of the interval that defines the essential services and ß is the lower boundary of the interval that determines the non-essential services of the network.

The Decision agent interprets the desirability based on the network manager’s preferences in a particular context. The main objective of our design is maintaining network’s essential services, which are defined differently in different contexts to reflect the network manager’s preferences in different contexts. Thus, a decision could be evaluated as desirable under heavy inbound traffic that could cripple the network, while the same decision may not be desirable when the network does not have this condition.

Whenever there is more than one applicable plan for a given attack event, a PlanChoice event is automatically activated within the agent. PlanChoice gives the agent an opportunity to choose which of the applicable plans it will execute. By handling this event, a decision agent can implement meta-level reasoning. Metalevel reasoning chooses a desirable plan based on evaluation of different criteria in the current context. Unlike the other event classes in the JACKTM Agent Language, a user would not explicitly post a PlanChoice

event by executing a method or a reasoning method statement in a plan. Instead, an agent posts PlanChoice events internally. PlanChoice event proceeds like any other plan execution in JACKTM.

In our implementation, the ChooseResponse plan examines

a set of applicable plans and selects the most desirable one using fuzzy multi-criteria decision analysis described in [2]. For example, to choose a desirable plan among traffic filtering responses, it requests the filter characteristics from the applicable filtering response plans and compares them according to predefined criteria (e.g., Traffic Matching Factor, Essentiality Factor, Origin Factor) using the trace of suspicious traffic in SFT and local survivability policy. An effective response for blocking malicious traffic, which also has minimum impact on the legitimate traffic, is chosen as the desirable plan.

VII. A SIMULATION SCENARIO

An experiment that shows the operation of FAST is presented in this section. The flow data for this experiment is collected at a campus network after a Worm infection. The data set includes outbound scan traffic from worm-infected local computers.

The agent interaction diagram of Fig. 10 shows the initialization phase of the experiment. The agents in this experiment include HCI agent (start), two Monitor agents (shdstwo and ssdstwo), a Detection agent (probing_out) and the Traffic Regulation Decision agent. The HCI agent provides an appropriate user interface for activating, initializing, and configuring other agents. The Monitor agents monitor the number of outbound flows to the same host but different services and to the same service but different hosts in the time window. The Detection agent recognizes the suspicious probing activities in the outbound traffic. Finally, the Decision agent chooses a desirable plan to mitigate the attack from any applicable plans. As shown in Fig. 10, the HCI agent continuously reads the flows from the data set, and the Monitor agents calculate new values for the monitored variables. These values are sent to the Detection agent and are used in calculating the attack possibility.

Fig. 11 shows the interactions among different agents when a suspicious or attack activity is detected. AttackDetected event, which is generated by the probing-out Detection agent, informs the Decision agent of a suspicious activity. Then it is

Fig. 9. Context Database

189

the Decision agent’s duty to decide if such an event needs a response. The diagram does not show the internal events and activities of each agent. These events and activities are explained in the previous section.

When an attack becomes serious, the Decision agent finds a plan to enable the network to survive the attack. The available plans for the Traffic Regulation agent are in the form of traffic filters that can be applied on the routers or the firewalls.

The process of filtering is simulated in our experiment. The FilterRequired event in Fig. 11 that is sent to the HCI agent includes a set of filters that are chosen by the Decision agent. The HCI agent compares any new flow with the set of active filters and discards it if it matches any of the selected filters. In the real-world operation of our system, a separate program will translate the selected filters to the actual Access Control List (ACL) commands that can be applied to the routers or other types of commands for other filtering devices.

VIII. CONCLUSIONS AND FUTURE WORK

Design and implementation of the different agents of the FAST are described. FAST is the multi-agent implementation of the FASA architecture. FAST is designed to address several problems that current intrusion detection and response technologies are facing with. Agents use approximate reasoning in all the stages of monitoring the network variables, detecting the attacks and responding to them. A simulation scenario, which shows how the Decision agent provides a desirable response, is also presented.

When an attack is identified, there are often a variety of possibilities regarding where and how a response can be deployed. The choice of the actual response action or response locations can have tremendous impact on the functionality of the network. FAST imitates the ability of the human mind to reason under uncertainty, but it employs more accurate observation and analysis. This enables FAST to make decisions that meet the criteria and policies accurately and to launch a response quickly (compared to what a human could do).

One of the important aspects of the autonomous behavior of an agent is the balance between reactivity (event driven) and proactivity (goal-driven). One of our current research goals focuses on the design and test of goal-driven proactive behavior. Goal-driven behavior involves taking courses of actions to achieve a predefined goal and continuously re-planning to recover from the initial plan failure or accommodate a change in the network status.

Mitigating the Internet-scale attacks is impossible without coordination across different administrative (and policy) domains. We research the design and implementation of a cooperation framework, which is aimed to enable the FAST agents to cooperatively monitor and effectively mitigate the attack in a distributed domain. We investigate a multiagent-based teamwork framework that can decide on the desirable local responses as well as optimal global ones. Global responses contribute to an overall goal of maintaining essential service quality by taking into account the state of the

Fig. 10. JACKTM Agent Interaction Diagram During Initialization Fig. 11. JACKTM Agent Interaction Diagram During an Attack

190

entire system and system-wide survivability policy.

ACKNOWLEDGMENT

This work was funded in part by Atlantic Canada Opportunity Agencies (ACOA) through Atlantic Innovation Fund (AIF). Mr. Mehdi Shajari’s work was funded by National Research Council – Institute of Information Technology – e-Business.

REFERENCES

[1] M. Shajari and Ali Ghorbani, “Using Fuzzy Logic to Manage False Alarms in Intrusion detection,” Security and Privacy in the Age of Uncertainty, Proc. of IFIP TC11 18th International Conference on Information Security (SEC2003), D. Gritzalis, S. Vimercati, P. Samarati, and S. Katsikas, Eds., Athens, Greece, pp. 241-252, May 2003.

[2] M. Shajari, Ali Ghorbani, and Steve Marsh, “Fuzzy Adaptive Network Survivability Architecture,” Submitted for publication in IEEE Transaction on Dependable and Secure Computing, 2004.

[3] X. Qin, W. Lee, L. Lewis, and J. B. D. Cabrera, “Integrating Intrusion detection and Network Management,” Proc. of the 8th IEEE/IFIP Network Operations and Management Symposium (NMOS), pp. 329-344, Florence, Italy, April 2002.

[4] Karima Boudaoud and Zahia Guessoum, “A Multi-agents System for Network Security Management,” Proc. of Telecommunication Network Intelligence, IFIP TC6 WG6.7 Sixth International Conference on Intelligence in Networks (SMARTNET 2000), Harmen R. van As, eds., Vienna, Austria, pp. 172-189, September 2000.

[5] A. Rao and M. Georgeff, “Modeling rational agents within a BDI-architecture,” Proceedings of the Second International Conference on Principles of Knowledge Representation and Reasoning, J. Allen, R. Fikes, and E. Sandewall, eds., pp. 473–484. Morgan Kaufmann Publishers, San Mateo, CA, 1991.

[6] A. Rao and M. Georgeff, “Intentions and Rational Commitment,” Proceedings of the First Pacific Rim International Conference on Artificial Intelligence (PRICAI-90), Japan, 1990.

[7] M. J. Wooldridge, “Practical Reasoning with Procedural Knowledge: A logic of BDI Agents with Know-How,” Proc. of the International Conference on Formal and Applied Practical Reasononing (FAPR’96), pp. 663-678, June 1996.

[8] Jack Intelligent Agent User Guide, http://www.agent-software.com, 2004.

[9] E. Spafford and D. Zamboni, “Intrusion detection using autonomous agents,” Computer Networks, vol. 34, no. 4, pp. 547-570, October 2000.

[10] J. Dickerson, J. Juslin, O. Koukousoula, and J. Dickerson, “Fuzzy intrusion detection,” IFSA World Congress and 20th North American Fuzzy Information Processing Society (NAFIPS) International Conference, Vancouver, British Columbia, Vol. 3, pp. 1506-1510, July 2001.

[11] R. Gopalakrishna and E. Spafford, "A Framework for Distributed Intrusion Detection using Interest Driven Cooperating Agents," Proc. of Recent Advances in Intrusion Detection, 4th International Symposium (RAID 2001), October 2001.

[12] D. Frincke, D. Tobin, J. McConnell, J. Marconi, and D. Polla, “A Framework for cooperative Intrusion Detection,” Proc. 21st National Information Systems Security Conference, Arlington, VA, pp. 361-373, October, 1998.

[13] G. Helmer, J. S. K. Wong, V. Honavar, and L. Miller, “Intelligent Agents for Intrusion Detection,” Proc. IEEE Information Technology Conference, Syracuse, NY, pp. 121-124, September 1998.

[14] Q. Xue and J. Sun and Z. Wei, "TJIDS: an intrusion detection architecture for distributed network," Proc. of the Canadian Conference on Electrical and Computer Engineering (IEEE CCECE 2003), pp.709-712, May 2003.

[15] M. Asaka, S. Okazawa, A. Taguchi, and S. Goto, “A Method of Tracing Intruders by Use of Mobile Agents,” Proc. 9th Annual Internetworking Conference (INET’99), San Jose, CA, pp. 1-12, June 1999.

[16] D.J. Ragsdale and C.A. Jr. Carver and J.W. Humphries and U.W. Pooch, “Adaptation techniques for intrusion detection and intrusion response systems,” Proc. of the 2000 IEEE International Conference on Systems, Man, and Cybernetics, Nashville, TN USA, pp. 2344-2349, 2000.

[17] R. Sandhu, “Engineering Authority and trust in cyberspace: The OM-AM and RBAC way,” Proc. of 5th ACM Workshop on Role-Based Access Control (RBAC-00), New York, NY, pp. 111-119, ACM Press, July 2000.

[18] W. T. Yao, “Trust Management for Widely Distributed Systems,” Ph.D. Thesis, Jesus College, University of Cambridge, February 2003.

[19] R. Bellman and L. Zadeh, “Decision making in a fuzzy environment,” Management Science, vol. 17, no. 4, pp. 141-164, 1970.

[20] M. Papasimeon and C. Heinze, “Extending UML for Designing JACK Agents,” Proceedings of 13th Australian Software Engineering Conference (ASWEC’01), Canberra, Australia, August 2001.

191