><
1
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

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-DesireIntention 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 plan
failure.
managing the uncertainties that exist in detecting and
providing responses to the network attacks. Fuzzy Adaptive
Survivability Tool (FAST) is an implementation of FASA as a
multi-agent system, which is built based on the Belief-DesireIntention (BDI) logic. This paper describes the design and
implementation of the FAST agents.
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
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
network security mechanisms and practices such as
intrusion detection and survivable design are needed to
manage 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
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 networkbased (monitors and analyzes network traffic). A networkbased 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 to the network accurately
(i.e., they 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
application of 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.
><
2
Fig. 2. JACK Constructs [8]
Fig. 1. A Belief-Desire-Intention Agent Architecture [7]
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.
JACK introduces 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. Simply, 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 later on, as more
information becomes available; they are refined to fill out the
details.
C. Related Work
The proposed architecture 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 its
mental attitudes, built knowledge, and experience, in a rational
way, they have not published any more detail 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). Local Layer manages
the security of a domain (a set of hosts in a local network). It
includes a group of Local Agents (LAs), which have specific
functions. LAs are designed to monitor specified activities and
report to Manager Agents.
><
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, transcivers, 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 Autonomous Agents for Intrusion Detection (AAFID)
architecture.
Deploying 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 BSM 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 and
probing attacks. 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 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. This avoids unnecessary data flow among the agents. As
the major advantage, the entire system is not compromised if
an agent fails. Instead, 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 the peer relationships. Managers may
transmit commands to subordinates; such commands include
commands such as gather/stop gathering data, or forward/stop
forwarding data. Peers may send requests for data
forwarding/gathering/receiving to peers; the peer decides
whether to honor 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
3
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 networked system. Lightweight
agents are agents that accomplish their essential tasks with
minimal code. They are dynamically updateable and
upgradeable, smaller, simpler and faster to transport (due to
their smaller size).
A multi-agent system is proposed in [14] for distributed
intrusion detection. The architecture consists of many different
types of agents that communicate with each other. A publickey encryption algorithm is used to encrypt all the
communication and password. 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 Agentbased 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 alarm 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,
are assigned by 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 constraint such as legal and
ethical. 6) Tactics agent, which decomposes abstract course of
action into specific actions.
III. DESIGN METHODOLOGY
A layered approach to security engineering has been proposed
><
4
TABLE 1
MAJOR COMPONENTS OF THE FUZZY ADAPTIVE SURVIVABILITY MODEL
Component
Processes
Flows
Variables
Profiles
Signatures
Events
Suspicious Flow Tables (SFTs)
Services
Response Plans
Contexts
Description
Three major programs that are running concurrently
Records of network traffic that appears between IP/port pairs
Represent different aspects of network activities
Characterize the behavior of the network variables
Describe attacks or events of interest
Generated when a new flow matches one of the signatures
Data structures that record the suspicious activities
Describe important services provided/needed by the network
Actions taken when all necessary conditions are satisfied
Evaluate the desirability of each plan with respect to the network status
in [17]. Using the layered 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 highlevel 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.
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.
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
V. ARCHITECTURAL COMPONENTS
The FASA architecture as shown in Fig. 3 consists of three
functional boxes, namely: Monitor (M-box), Detection (Dbox), 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
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
><
5
Fig. 4. Decision-box
Fig. 3. The fuzzy Adaptive Survivability Architecture
normal and abnormal behavior of each variable. Using 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 by 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.
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 attack 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
services to be blocked (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 and Information about the
><
6
ongoing attack collected in the SFTs 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 agentbased 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. Using the
Fig. 5. Agents of the Fuzzy Adaptive Survivability Tool
information provided by Monitor agents, Detection agents can
detect known attacks by using their signatures. The variables
are calculated from one of the information sources using
VariableDefinition database that are predefined for each
monitor agent.
Profiles are maintained in VariableProfile databases. In the
current implementation, they can be used by network manager
in building membership functions that is 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 profiling period, the variable profile can be used in
building variable’s membership functions. In the current
implementation, the network manager should update the
membership functions manually.
Extension of UML for designing JACK agents
(JACK/UML) is proposed by Papasimeon [20]. Current
implementation of 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 new value for the variable
according to its definition.
><
7
Fig. 6. Overall Design for the Monitor Agent with JACK/UML
Fig. 7. Overall Design for the Detection Agent with JACK/UML

NewValueSending: Sending 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 process.
 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 variable to detect an
attack. Each Monitor agent receives 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 HCI agent.
 SendNewValue: Sends the newly calculated value for a
variable to the relevant Detection agents using
NewValue event.
 VariableCalculation: Calculate the value for the
monitored variable using and the Monitor agent’s
VariableDefinition database. To use the Monitor
agent’s
VariableDefinition
database,
VariableCalculation plan uses an interface implemented
by the Monitor agent.
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 databases.
Using the configuration information and profile of each
variable, a fuzzy partitioning method is proposed, which
automatically builds the membership functions [1]. The
following configurations are defined for each variable:
 Number of membership functions: 2 partitions (normal
and abnormally-high) or 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 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 it’s 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. If the input crisp
conditions don’t match with the input traffic, the status of 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 Detection agent is described
in Fig. 7. The Detection agent has the following capabilities:
 ConfigurationChanging: changing the configuration
parameters using new values provided by network
manager through 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
><




8
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
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.
D. Decision Agent
A response plan defines the system’s skills in reacting to
different attacks encountered in the network. Decision agent
decides about an alert and selects a response plan based on the
predefined criteria and network’s survivability policy. 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
instance of 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
Fig. 8. Overall Design for the Decision Agent with JACK/UML


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 one
that has a matching #handles event statement.
Using relevant() method, which are defined in each plan, the
Decision agent identifies those plans with preconditions that
are currently satisfied with respect to the alert attributes from
the plans that can handle an alert. relevant() method must
always be 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 current
implementation, the precondition in each plan checks the
severity of the ongoing attack that is associated with each
attack event and decides if an automated 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
><
9
ongoing attack.
Using a 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 based solely on the current stress level of the
network
represented
by
InboundTraffic
rate
or
OutboundTraffic rate variables. Upon request by the
ChooseResponse plan, the contexts beliefset returns different α
and β values in different inbound and outbound traffic
situations (see Fig. 9). α and β are defined in [0,1]. α 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 posted
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 JACK 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
Fig. 9. Context Database
proceeds like any other plan execution in JACK.
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 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 a
Decision agent (traffic regulation). 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 is used to choose a desirable plan to mitigate the attack
in case there are applicable ones. As shown in Fig. 10, 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 probing-out Detection agent,
informs the Decision agent of a suspicious activity. Then it is
the Decision agent’s duty to decide if such an event needs a
response or not. 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 traffic mitigation 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 with 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
><
10
Fig. 10. Agent Interaction Diagram During Initialization
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 replanning to recover from the initial plan failure or
Fig. 11. Agent Interaction Diagram During an Attack
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 multiagentbased 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 entire
system and system-wide survivability policy.
REFERENCES
[1]
[2]
[3]
[4]
[5]
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 18 th International Conference on
Information Security (SEC2003), D. Gritzalis, S. Vimercati, P.
Samarati, and S. Katsikas, Eds., Athens, Greece, pp. 241-252, May
2003.
M. Shajari, Ali Ghorbani, and Steve Marsh, “Fuzzy Adaptive Network
Survivability Architecture,” Submitted for publication in IEEE
Transaction on Dependable and Secure Computing, 2004.
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. 329344, Florence, Italy, April 2002.
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.
A. Rao and M. Georgeff, “Modeling rational agents within a BDIarchitecture,” Proceedings of the Second International Conference on
Principles of Knowledge Representation and Reasoning, J. Allen, R.
><
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
11
Fikes, and E. Sandewall, eds., pp. 473–484. Morgan Kaufmann
Publishers, San Mateo, CA, 1991.
A. Rao and M. Georgeff, “Intentions and Rational Commitment,”
Proceedings of the First Pacific Rim International Conference on
Artificial Intelligence (PRICAI-90), Japan, 1990.
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.
Jack Intelligent Agent User Guide, http://www.agentsoftware.com, 2004.
E. Spafford and D. Zamboni, “Intrusion detection using autonomous
agents,” Computer Networks, vol. 34, no. 4, pp. 547-570, October 2000.
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.
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.
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.
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.
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.709712, May 2003.
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.
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.
R. Sandhu, “Engineering Authority and trust in cyberspace: The OMAM 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.
W. T. Yao, “Trust Management for Widely Distributed Systems,” Ph.D.
Thesis, Jesus College, University of Cambridge, February 2003.
R. Bellman and L. Zadeh, “Decision making in a fuzzy environment,”
Management Science, vol. 17, no. 4, pp. 141-164, 1970.
M. Papasimeon and C. Heinze, “Extending UML for Designing JACK
Agents,” Proceedings of 13th Australian Software Engineering
Conference (ASWEC’01), Canberra, Australia, August 2001.