ALERT CORRELATION BASED ON A LOGICAL HANDLING OF
ADMINISTRATOR PREFERENCES AND KNOWLEDGE
Salem Benferhat and Karima Sedki
CRIL-CNRS UMR-8188, Universit d’Artois, Rue Jean Souvraz SP 18 62307 Lens, Cedex, France
Keywords:
Alert correlation, preferences logic, administrator’s preferences and knowledge.
Abstract:
Intrusion detection systems (IDSs) are important tools for infortation systems security. However, they generate
a large number of alerts which complicate the task of network administrator to understand these triggered alerts
and take appropriate actions. In this paper, we present a logic-based approach to alert correlation. This logic
allows to integrate administrator’s preferences and knowledge. Our logic, called Extended Qualitative Choice
Logic (EQ C L), is an extension of a fragment of first order logic. It adds a new connector, denoted
~
×, that
allows to represent administrator preferences. The objective of our logic-based alert correlation approach is to
rank-order alerts generated by IDS on the basis of administrator preferences and knowledge. Only alerts that
fully fit administrator’s preferences and knowledge are first presented. Then if needed, less preferred alerts
(which falsify less important preferences) will be presented, and so on.
1 INTRODUCTION
Intrusion detection system (IDS) is an active area of
research for almost thirteen years (Anderson, 1980).
Actually, there are two main intrusion detection ap-
proaches used to detect attacks on the network.
Anomaly detection (Lunt, 1990), (Porras and Neu-
mann, 1997) is based on defining a profile repre-
senting normal activities. Any action or behavior
that deviates from the normal profile is considered
as anomaly or possible intrusion. This approach has
the advantage of being able to detect unknown at-
tacks. However, it generates a large volume of false
alerts. Misuse detection (Kumar and Spafford, 1995),
(Paxson, 1999)focuses on the characteristics or sig-
natures of known attacks that exploit weaknesses in
system and application software. They have the ad-
vantage that they achieve very high detection rates on
known attacks. However, they are not able to detect
new attacks that do not follow predefined patterns.
Clearly, whatever the used approach, an administra-
tor is confronted with a large amount of alerts pro-
duced by IDS. In this context, several alert correla-
tion approaches have been proposed in recent years to
address this problem. Alert correlation tools are im-
portant for reducing the large volume of alerts that are
generated by IDSs. Generally, they can be classified
into three categories: approaches based on similarity
between alert attributes (Valdes and Skinner, 2001),
(Julisch, 2003) , alert correlation based on known at-
tacks scenarios (Eckmann et al., 2000), (Morin et al.,
2002)and approaches that are based on prerequisites
and consequences relationship (Cuppens and Mi
`
ege,
2002), (Ning et al., 2002).
Even if existing alerts correlation approaches are
quite efficient to remove redundant information or
to detect complex coordinated attacks, they still pro-
duce a large number of alerts. Moreover to the best
of our knowledge, none of existing alert correlation
tools take into account administrator preferences and
knowledge. The alert correlation proposed in this pa-
per follows another direction of the current correla-
tion techniques. It is also complementary to exist-
ing alert correlation approaches. It consists in mod-
eling administrator knowledge (on system, network,
IDS) and his preferences. The main idea is to develop
a logic that ranks-order alerts and classifies them in
different categories that fit more or less administrator
knowledge or preferences. Alerts in the first category
are those that should be first presented to administra-
tor. And if needed alerts of the second category will
be presented, and so on. The rest of this paper is or-
ganized as follows: Section 2 describes our new logic
and Section 3 presents our alert correlation approach.
Section 4 concludes the paper.
50
Benferhat S. and Sedki K. (2008).
ALERT CORRELATION BASED ON A LOGICAL HANDLING OF ADMINISTRATOR PREFERENCES AND KNOWLEDGE.
In Proceedings of the International Conference on Security and Cryptography, pages 50-56
DOI: 10.5220/0001924000500056
Copyright
c
SciTePress
2 A NEW LOGIC FOR
HANDLING PREFERENCES
We present our new logic to be used to represent ad-
ministrator preferences. The starting point is an ex-
isting logic called Qualitative Choice Logic (QCL)
(Brewka et al., 2004). It is an extension of proposi-
tional logic. The non-standard part of QCL logic is a
new logical connective
~
×, called ordered disjunction.
Intuitively, if A and B are propositional formulas then
A
~
× B means: “if possible A, but if A is impossible
then at least B”. QCL logic can be very useful for rep-
resenting preferences. However, its inference relation
is less satisfactory. This is due on the one hand to
the way rules are handled, where ordered disjunction
is lost when preferences are associated with negation
(see (Benferhat and Sedki, 2007) for more details).
On the other hand propositional logic is not appro-
priate to express complex knowledge. It cannot ex-
press generic knowledge that involve variables. The
extensions of QCL proposed in (Benferhat and Sedki,
2007) are not satisfactory for our application, in par-
ticular they are defined within propositional language.
What is needed is a richer language to express general
pieces of information. This is the aim of the following
subsections.
2.1 EQ C L Language
EQ C L language is composed of three encapsulated
sub-languages: Propositional Logic Language, the set
of Basic Choice Formulas (BCF) and the set of Gen-
eral Choice Formulas (GCF).
1. Basic Choice Formulas (BCF): Let PS denotes a
set of propositional symbols and PROP
PS
denotes
the set of propositional formulas. BCF formulas
are ordered disjunctions of propositional formu-
las. The language composed of BCF formulas is
denoted by BCF
PS
, is defined as follow:
(a) If φ PROP
PS
then φ BCF
PS
(b) If φ, ψ BCF
PS
then (φ
~
×ψ) BCF
PS
(c) Every basic choice formula is only obtained by ap-
plying the two rules above a finite number of times.
2. General Choice Formulas (GCF): GCF formu-
las represent any formula that can be obtained
from PS using connectors
~
×,, ,¬. The lan-
guage composed of GCF formulas, denoted by
GCF
PS
, is defined inductively as follows:
(a) If φ BCF
PS
then φ GCF
PS
(b) If φ,ψ GCF
PS
then (φ ψ),¬(ψ),(φ
ψ),(φ
~
×ψ) GCF
PS
.
(c) The language of GCF
PS
is only obtained by applying
the two rules above a finite number of times.
Example 1. The formula “Bro-Alerts
~
× Snort-
Alerts” is a BCF formula, while the formula
“(Bu f f erover f low-Alerts
~
× Ping-Alerts) (Scan-
Alerts
~
× Badtra f f ic-Alerts)” is a GCF formula.
2.2 Inference Relation of Basic Choice
Formulas
The semantics of EQ CL formulas is based on the de-
gree of satisfaction of a formula in a particular model
I. An interpretation I is an assignment of the classical
truth values T,F to the atoms in PS. Inference relation
of BCF formulas is given in the following definition:
Definition 1. 1. Let φ = a
1
~
×a
2
~
×.. .
~
×a
n
BCF
PS
, I |=
k
φ iff I |= a
1
a
2
... a
n
and k = min{j |I |= a
j
}.
2. Let φ PROP
PS
. I |=
1
φ iff I |= φ.
2.3 Normalization Form and Inference
from General Choice Formulas
This section proposes our inference relation for GCF
formulas which departs from (and overcomes limita-
tions of) the one defined in (Brewka et al., 2004).
Inference relation of GCF simply reuses Definition 1
after a normalization step which transforms a GCF
formula into a BCF formula. Namely, first, an equiv-
alent BCF formula of each GCF formula is provided,
and then Definition 1 applied. The following intro-
duces the notion of normal form function denoted
by N
EQ CL
which associates with each GCF formu-
las (complex form of preferences), its corresponding
BCF formulas (simple form of preferences).
Definition 2. We define a normal function denoted by
N
EQ CL
, a function from GCF
PS
BCF
PS
, such that:
1. Normal form of basic choice formulas and propo-
sitional formulas are these formulas themselves:
φ BCF
PS
,N
EQ C L
(φ) = φ.
2. The normal form with respect to negated formu-
las: φ GCF
PS
, and (φ 6∈ BCF
PS
),
N
EQ C L
(¬φ) N
EQ C L
(¬N
EQ C L
(φ)).
3. The normal form is decomposable with respect to
conjunction, disjunction and ordered disjunction
of GCF formulas:
(a) φ,ψ GCF
PS
and (φ 6∈ BCF
PS
or ψ 6∈
BCF
PS
), N
EQ C L
(φ ψ) N
EQ C L
(N
EQ C L
(φ)
N
P Q C L
(ψ)).
(b) φ,ψ GCF
PS
and (φ 6∈ BCF
PS
or ψ 6∈
BCF
PS
), N
EQ C L
(φ ψ) N
EQ C L
(N
EQ C L
(φ)
N
EQ C L
(ψ)).
(c) φ,ψ GCF
PS
and (φ 6∈ BCF
PS
or ψ 6∈ BCF
PS
), N
EQ C L
(φ
~
×ψ)
N
EQ C L
(N
P Q C L
(φ)
~
×N
EQ C L
(ψ)).
ALERT CORRELATION BASED ON A LOGICAL HANDLING OF ADMINISTRATOR PREFERENCES AND
KNOWLEDGE
51
4. Normal form of negated, conjunction and dis-
junction of BCF formulas are: Let φ =
a
1
~
×a
2
~
×. ..
~
×a
n
, and ψ = b
1
~
×b
2
~
×. ..
~
×b
m
such
that a
i
s and b
i
s are propositional formulas,
(a) N
EQ C L
((a
1
~
×a
2
~
×.. .
~
×a
n
) (b
1
~
×b
2
~
×.. .
~
×b
m
))
c
1
~
×c
2
~
×.. .
~
×c
k
, where k = max(m, n), and
c
i
=
[(a
1
... a
i
) b
i
] [a
i
(b
1
... b
i
)]
i f i min(m, n)
((a
1
... a
n
) b
i
) i f n < i m
(a
i
(b
1
... b
m
)) i f m < i n
(b) N
EQ C L
(φ ψ) c
1
~
×c
2
~
×.. .
~
×c
k
where k =
max(m, n), and
c
i
=
(a
i
b
i
) i f i min(m, n)
a
i
i f m i n
b
i
i f n i m
(c) N
EQ C L
¬( a
1
~
× a
2
~
×.. .
~
× a
n
)
¬ a
1
~
׬ a
2
~
×.. .
~
׬ a
n
.
Example 2. Assume that the network administrator
wants to analyze R2L alerts that are preferred to
Probe ones and also U2R alerts that are preferred
to Dos ones. These preferences are represented by
the following GCF formula ψ = (R2L-Alerts
~
× Probe-
Alerts) (U2R-Alerts
~
× DoS-Alerts).
To give the satisfaction degree with respect to a given
model of ψ, we first normalize the formula ψ (namely,
we transform ψ in the equivalent BCF formula) as in-
dicated in Definition 2, then we use Definition 1 to
give the inference relation of obtained BCF formula.
1. Normalization of ψ: Using item 4-(a) of Defini-
tion 2, we obtain:
N
EQ C L
(ψ)=N
EQ C L
((R2L-Alerts
~
×
ProbeAlerts)
(U2R-Alerts
~
×DoS-Alerts))
((R2L-Alerts U2R-Alerts) (R2L-Alerts
U2R-Alerts))
~
×((R2L-Alerts Probe-Alerts)
DoS-Alerts) (Probe-Alerts (U2R-Alerts
DoS-Alerts)).
(R2L-Alerts U 2R-Alerts)
~
×
((R2L-Alerts DoS-Alerts) (Probe-Alerts
DoS-Alerts) (Probe-Alerts U2R-Alerts)).
2. Satisfaction degree of ψ:
- Let I
1
={Probe-alerts, DoS-Alerts}. Using
item 2 of Definition 1, we have I
1
6|=R2L-
AlertsU2R-Alerts, I
1
6|=R2L-AlertsDoS-Alerts,
I
1
6|=Probe-AlertsU 2R-Alerts, and I
1
|=Probe-
AlertsDoS-Alerts, so I
1
|= (R2L-Alerts
DoS-Alerts)(Probe-Alerts DoS-Alerts)(Probe-
Alerts U2R-Alerts). Using item 1 of Definition
1, we have I
1
|=
2
N
EQ C L
(ψ). We conclude that I
1
satisfies ψ to degree 2.
- If I
2
={DoS-Alerts}, then I
2
6|=N
EQ C L
(ψ). I
2
does
not satisfy ψ.
- If I
3
={R2L-Alerts, U2R-Alerts}, then I
3
|=
1
N
EQ C L
(ψ). We conclude that I
3
satisfies
ψ to degree 1. Namely, ψ is fully satisfactory in I
3
.
The following defines preferred models when we have
a set of knowledge and a set of preference. Let K
be a set of propositional formulas which represents
knowledge, and let T be a set of preferences that con-
tains only simple form preferences (BCF formulas).
We suppose that all complex form preferences (GCF
formulas) are first transformed into simple form pref-
erences, using Definition 2.
Definition 3. Let M
k
(T ) denote the subset of ba-
sic choice formulas of T satisfied by a model M to
a degree k (using Definition 1). A model M
1
is
{ K T }-preferred over a model M
2
if there is k
such that | M
k
1
(T )| > | M
k
2
(T )| and for all j < k:
| M
j
1
(T )| = | M
j
2
(T )|. M is a preferred model of
{ K T } iff :
1. M is model of K,
2. M is maximally {K T }-preferred.
2.4 Universally Quantified First Order
EQ C L
Propositional logic is not appropriate to express com-
plex knowledge. It can only deal with pieces of infor-
mation regarding particular situations or properties,
and cannot express knowledge that involve variables.
So, what is needed is a richer language to express gen-
eral information. In the following, we slightly extend
our logic to a fragment of universally quantified first
order formulas that do not involve function symbols.
For the purpose of our application there is no need to
consider the full first order logic. More precisely, let
X = {x,y,z,...} be a set of variables. Let C = {c
1
,
c
2
,...,c
n
} be a set of constants. We define a term as
either a constant of C or a variable of X . Let us de-
note by P = {p,q, r, ...} a set of predicate symbols.
The following defines the notion of unquantified first
order EQ C L formulas:
Definition 4. Unquantified first order EQ C L formu-
las are defined as follows:
1. If p is a predicate symbol of arity n, and t
1
,...,t
n
are terms, then p(t
1
,...,t
n
) is an unquantified first
order EQ CL formula.
2. If φ and ψ are two unquantified first order E Q C L
formulas, then φ ψ, φψ, ¬φ, φ
~
×ψ are unquan-
tified first order EQ CL formulas.
In this paper, for sake of simplicity, we only restrict
ourselves to universally quantified first order E Q C L
formulas given by the following definition:
Definition 5. Universally quantified first order
EQ C L formulas are obtained by:
SECRYPT 2008 - International Conference on Security and Cryptography
52
If φ is an unquantified first order QCL formula,
and {x
1
,..., x
n
} are the set of variables used in φ,
then x
1
,..., x
n
φ is a universally quantified first
order EQ CL formula.
Example 3. Assume that the network administrator
prefers alerts that are issued by Bro IDS to those is-
sued by Snort IDS. We use the universally quantified
EQ C L formula ψ to define this preference: ψ = x,
y Alert-Bro(x)
~
×Alert-snort(y).
Universally quantified first order EQ C L language of-
fers flexibility for expressing knowledge and prefer-
ences. However, from reasoning point of view, it is
better to work on propositional level in order to ex-
ploit existing inference tools. Namely, it is important
to instantiate first order knowledge’s bases to propo-
sitional ones. The instantiation steps are:
1. Let K and T be two sets of universally quantified
first order EQ C L formulas, where K does not involve
the ordered disjunction symbol
~
×.
2. Let E(K, T ) be the set of constant symbols used in
K and T .
3. Let ψ = x
1
,..., x
n
φ be a universally quantified
first order EQ C L formula. Define D(ψ) as the do-
main associated with ψ. D(ψ) is a subset of E(K,T )
n
composed of feasible n-uplets of E(K,T )
n
. It is either
set by an expert, or initialized by default to E(K,T )
n
.
4. Define I nstantiation(ψ) as the set of all grounded
EQ C L formulas obtained by replacing (x
1
,..., x
n
) in
ψ respectively by an element (c
1
,..., c
n
) of D(ψ).
5. Define I nst(K) (resp. I nst(T )) as the result of in-
stantiating each formula of K (resp. of T ).
The inference relation for EQ C L formulas is given
by the following steps:
* Apply Definition 2 to transform universally quanti-
fied first order GCF formulas into universally quanti-
fied first order BCF formulas.
* Apply the instantiation steps for each formula as in-
dicated above for K and T .
* Apply Definition 1 (item 1) for all obtained BCF
formulas or (item 2) for propositional ones.
* Compute preferred models of { K T } using Defi-
nition 3.
3 APPLICATION OF EQ CL TO
ALERT CORRELATION
3.1 Description of Inputs
The inputs of our model are:
1. A Group of Alerts G Produced by IDSs: Each
alert is characterized by a set of attributes called
“basic attributes”. Examples of basic attributes
are: Signature Identifier (SID), messages associ-
ated with alerts, Protocol, TTL (Time To Live),
etc. Each attribute will be represented by a pred-
icate symbol. The sets of predicate facts contain-
ing values of alert attributes of G will be repre-
sented by K
1
.
Example 4. Assume that G contains one alert
identified by id1. Assume that the attributes con-
cerning this alert are: IDS identity is Snort,
the used protocol is TCP and the class of at-
tack is DoS. These facts will be represented
by K
1
= {IDS(id1,Snort), Protocol(id1,TCP),
Class(id1,DoS)}. Note that in general, some at-
tributes may not be informed (known) by an IDS.
Types of Facts: We distinguish two kinds of
facts:
(a) Alerts Facts: These facts are directly defined
on basic attributes of alerts. Protocol(A
1
,TCP)
is an example of alert fact which indicates that
the attribute protocol of alert A
1
is TCP.
(b) Other Facts: These facts concern attributes
that are not known by the IDS from which the
alerts are issued. Direction of alert is an exam-
ple of this kind of facts. It is based on source
and target IP addresses. These information al-
low to know the direction of concerned alerts
on the system (inbound, outbound, inside).
2. Knowledge of the Network Administrator: Ad-
ministrator network can provide some knowledge
or beliefs on networks, on system, etc. This
knowledge base is denoted by K
2
, it contains a
set of universally quantified propositional formu-
las (namely, formulas that do not involve
~
×).
3. Preferences of the Network Administrator:
The network administrator can express his prefer-
ences according to what he wants to first analyze
and what he would like to ignore. This will be
represented with a set of EQ C L formulas T .
3.2 Output of our Model
The output of our model is a subset G
0
G. More pre-
cisely, the subset of alerts in G to be first presented to
the network administrator. The objective of our alert
correlation, is to first present only alerts that satisfy
knowledge and preferences of the network adminis-
trator, namely, we only present preferred alerts. Then
if needed second preferred alerts will be presented,
etc. So, we need to preprocess available alerts and
encode them in our logical framework. Namely, we
need to:
- Extract the set of facts K
1
from the given alerts.
ALERT CORRELATION BASED ON A LOGICAL HANDLING OF ADMINISTRATOR PREFERENCES AND
KNOWLEDGE
53
Table 1: Group of inputs alerts.
Alerts Timestamp Sid Message Protocol IPsrc Portsrc IPdst Portdst TTL
A
1
3/8/16/39/12.024 1156 WEB-MISC TCP 199.174.194.16 1028 172.16.114.50 80 62
A
2
3/8/16/39/12.02671156 WEB-MISC TCP 199.174.194.16 1028 172.16.114.50 80 62
A
3
3/8/16/39/12.030 1156 WEB-MISC TCP 199.174.194.16 1028 172.16.114.50 80 62
A
4
3/11/17/50/16.384 469 ICMP PING ICMP 207.103.80.1048 (Type) 172.16.114.50 0 (Code) 63
A
5
4/1/02/19/43.008 1893 SNMP missing UDP 172.16.0.1 1336 207.181.92.211 161 63
A
6
3/8/15/01/13.344 1648W EB-CGI perl.exe TCP 206.48.44.18 1061 172.16.112.100 80 127
- Represent each preference of the administrator as
a universally quantified first order EQ CL formula.
This will be represented by T .
- Represent each knowledge of the administrator as
a universally quantified propositional formula. This
will be represented by K
2
. Then,
- Use N
EQ CL
to normalize the GCF formulas.
- Apply the steps of instantiation according to the all
constants in E(K
1
K
2
,T ).
- Select only instantiated formulas that concern con-
sidered facts.
- Provide the inference relation (satisfaction degree)
of the instantiated formulas.
- Determine preferred models. Finally,
- Define G
0
as a set of alerts which are true in preferred
models.
3.3 A Detailed Example
Assume that the input is a set of alerts given in Table
1. This input contains 6 alerts given by Snort IDS on
some traffic data. Note that in general, some attributes
may not be informed by the IDS. For instance, Snort
does not provide the attribute Direction (which is de-
rived). Because of the important number of alerts and
presence of false alerts, it is not useful to analyze all
alerts. So, we assume that, a network administrator
provides the following set of knowledge and prefer-
ences to select and choose preferred ones:
1. Administrator’s Preferences:
- The network administrator prefers alerts which
are identified with TCP protocol than alerts iden-
tified with UDP protocol than those identified
with ICMP protocol. Namely, if x, y,z are three
alerts, and if the protocol of x (resp. y,z) is TCP
(resp. UDP, ICMP), then it is preferred to first
present x, then y and lastly z.
- He prefers inbound alerts than outbound ones.
2. Administrator’s Knowledge:
- He wants to ignore all ICMP alerts.
- He wants to ignore redundant alerts.
The predicate symbols of our language are associated
with alerts attributes Timestamp, Sid, Portdst,..., and:
* Di f f er(A
i
,A
j
) which means that alerts A
i
and A
j
have different identities.
* Present-alert(id) when it is true, means that the
alert should be presented to the administrator.
1. Extract the Fact Base K
1
:
- Alert facts are directly extracted from the given
alerts (see Table 1). Protocol(A
1
,TCP) is an ex-
ample of alerts fact.
- Other facts that we may defined: The fact
that concerns direction of alerts. In this exam-
ple, inbound alerts are alerts where the source
IP address is different to ”172.16.x.y” and the
destination IP address in equal to ”172.16.x.y”.
Outbound alerts are alerts where the source IP
address is equal to ”172.16.x.y” and the desti-
nation IP address is different to ”172.16.x.y”.
The facts SameIPsrc, SameIPdst, SamePortsrc,
SamePortdst, SameSid, Timestamp-samaller-
than are corresponding respectively to alerts that
have the same attributes (Sid, protocol, source and
target IP addresses, source and destination ports,
smallest timestamp). These facts are applied on
alerts A
1
, A
2
, A
3
. A
2
and A
3
are repetitive alerts.
We only specify facts that are relevant to knowl-
edge and preferences of the network administra-
tor:
K
1
=
Protocol(A
1
,T CP),Protocol(A
2
,T CP),Protocol(A
3
,T CP)
Protocol(A
4
,ICMP),
Protocol(A
5
,UDP),Protocol(A
6
,T CP),Direction(A
1
inbound)
Direction(A
2
,inbound),Direction(A
3
,inbound)
Direction(A
4
,inbound)
Direction(A
5
,outbound),Direction(A
6
inbound)
SameIPsrc(A
1
,A
2
),SameIPsrc(A
1
,A
3
),SameIPsrc(A
2
,A
3
)
SameIPdst(A
1
,A
2
)
SameIPdst(A
1
,A
3
),SameIPdst(A
2
,A
3
),SamePortsrc(A
1
,A
2
)
SamePortsrc(A
1
,A
3
)
SamePortsrc(A
2
,A
3
),SamePortdst(A
1
,A
2
),SamePortdst(A
1
,A
3
SamePortdst(A
2
,A
3
)
SameSid(A
1
,A
2
),SameSid(A
1
,A
3
)
Timestam p-Smaller-than(A
1
,A
3
)
Timestam p-Smaller-than(A
2
,A
3
),SameSid(A
2
,A
3
)
Timestam p-Smaller-than(A
1
,A
2
)
2. Formalize the Preferences Base T:
Administrator’s preferences given above are for-
malized respectively by φ
1
and φ
2
as follows:
φ
1
= x, y, z Protocol(x,TCP)
Protocol(y,UDP) Protocol(z,ICMP)
Di f f er(x,y, z) Present-alert(x)
~
× Present-
alert(y)
~
× Present-alert(z).
SECRYPT 2008 - International Conference on Security and Cryptography
54
φ
2
= x, y Direction(x,inbound)
direction(y,outbound) Di f f er(x, y) Present-
alert(x)
~
× Present-alert(y).
3. Formalize the Knowledge Base K
2
:
φ
3
= x Protocol(x,ICMP) ¬ Present-alert(x).
φ
4
= x,y SameIPsrc(x,y) SameIPdst(x, y)
SamePortsrc(x,y) SamePortdst(x,y)
SameSid(x, y) Timestamp-Smaller-than(x,y)
Di f f er(x,y) Present-Alert(x) ∧¬Present-
Alert(y).
4. Define I nst(T ) and I nst(K
2
): To compute
I nst(T ) and I nst(K
2
), a direct way is to con-
sider all different possibilities regarding differ-
ent values of alert identities. For instance, for
φ
1
, we need to consider all pairs (x, y, z)
from {A
1
,A
2
,A
3
,A
4
,A
5
,A
6
}
3
. However, with
the help of K
1
, some instantiations are sim-
ply impossible. For instance, in φ
1
, there is
no need to consider (A
1
,A
4
, A
5
) since this will
lead: Protocol(A
4
,TCP) Protocol(A
5
,UDP)
Protocol(A
1
,ICMP) Present-alert(A
4
)
~
×
Present-alert(A
5
)
~
× Present-alert(A
1
).
Since together with Protocol(A
1
,ICMP) K
2
,
this rule will never be applied, and can be re-
moved. Given this observation, I nst(K
2
) and
I nst(T ) are given in the following:
I nst(K
2
) =
ψ
1
= Protocol(A
4
,(ICMP) ¬Present-alert(A
4
)
ψ
2
= SameIPsrc(A
1
,A
2
) SameIPdst(A
1
,A
2
)
SamePortsrc(A
1
,A
2
) SamePortdst(A
1
,A
2
)
SameSid(A
1
,A
2
) Timestamp-Smaller-than(A
1
,A
2
)
Present-alert(A
1
) ¬Present-alert(A
2
)
ψ
3
= SameIPsrc(A
1
,A
3
) SameIPdst(A
1
,A
3
)
SamePortsrc(A
1
,A
3
) SamePortdst(A
1
,A
3
)
SameSid(A
1
,A
3
) Timestamp-Smaller-than(A
1
,A
3
)
Present-alert(A
1
) ¬Present-alert(A
3
)
ψ
4
= SameIPsrc(A
2
,A
3
) SameIPdst(A
2
,A
3
)
SamePortsrc(A
2
,A
3
) SamePortdst(A
2
,A
3
)
SameSid(A
2
,A
3
) Timestamp-Smaller-than(A
2
,A
3
)
Present-alert(A
2
) ¬Present-alert(A
3
).
.
To compute the set of preferred models of {K
2
T },
namely to give preferred alerts, we provide the
satisfaction degree of all formulas in I nst(K
2
)
and I nst(T ), namely formulas ψ
1
, ψ
2
, ψ
3
, ψ
4
,
ψ
5
, ψ
6
, ψ
7
, ψ
8
, ψ
9
, ψ
10
, ψ
11
, ψ
12
, ψ
13
for each
interpretation. For lack of space, we do not give
the table of preferred models. One can check that
all preferred models contain {Present-alert(A
1
),
Present-alert(A
6
)}. Hence G’ = {A
1
, A
6
} and this
will be first presented to the administrator.
and I nst(T ) =
ψ
5
= Protocol(A
1
,TCP) Protocol(A
5
,UDP) Protocol(A
4
,ICMP)
Present-alert(A
1
)
~
×Present-alert(A
5
)
~
×Present-alert(A
4
)
ψ
6
= Protocol(A
2
,TCP) Protocol(A
5
,UDP) Protocol(A
4
,ICMP)
Present-alert(A
2
)
~
×Present-alert(A
5
)
~
×Present-alert(A
4
)
ψ
7
= Protocol(A
3
,TCP) Protocol(A
5
,UDP) Protocol(A
4
,ICMP)
Present-alert(A
3
)
~
×Present-alert(A
5
)
~
×Present-alert(A
4
)
ψ
8
= Protocol(A
6
,TCP) Protocol(A
5
,UDP) Protocol(A
4
,ICMP)
Present-alert(A
6
)
~
×Present-alert(A
5
)
~
×Present-alert(A
4
)
ψ
9
= Direction(A
1
,inbound) Direction(A
5
,outbound)
Present-alert(A
1
)
~
×Present-alert(A
5
)
ψ
10
= Direction(A
2
,inbound) Direction(A
5
,outbound)
Present-alert(A
2
)
~
×Present-alert(A
5
)
ψ
11
= Direction(A
3
,inbound) Direction(A
5
,outbound)
Present-alert(A
3
)
~
×Present-alert(A
5
)
ψ
12
= Direction(A
4
,inbound) Direction(A
5
,outbound)
Present-alert(A
4
)
~
×Present-alert(A
5
)
ψ
13
= Direction(A
6
,inbound) Direction(A
5
,outbound)
Present-alert(A
6
)
~
×Present-alert(A
5
)
4 CONCLUSIONS
In this paper, we presented our alert correlation ap-
proach which follows another direction of existing
correlation techniques. It is complementary to exist-
ing alert correlation approaches. It consists in mod-
eling administrator knowledge (on system, network,
IDS) and its preferences in order to classify alerts, dis-
card information that are less important and present
alerts that fit administrator preferences. A future work
is to enrich knowledge bases and preferences in our
experimental studies. A first experimental study on
real network traffic shows that reduction of more than
60 % of generated alerts can be performed.
ACKNOWLEDGEMENTS
This works is supported by the SETIN06 project
PLACID (Probabilistic graphical models and Logics
for Alarm Correlation in Intrusion Detection).
REFERENCES
Anderson, J. (1980). Computer security threat monitoring
and surveillance. Fort Washington, Pennsylvania.
Benferhat, S. and Sedki, K. (2007). A revised qualitative
choice logic for handling prioritized preferences. In
ECSQARU, pages 635–647.
Brewka, G., Benferhat, S., and Berre, D. L. (2004). Qualita-
tive choice logic. Artificial Intelligence Journal(AIJ),
157(1-2):203–237.
Cuppens, F. and Mi
`
ege, A. (2002). Alert correlation in a co-
operative intrusion detection framework. In SP, USA.
ALERT CORRELATION BASED ON A LOGICAL HANDLING OF ADMINISTRATOR PREFERENCES AND
KNOWLEDGE
55
Eckmann, S., Vigna, G., and Kemmerer, R. (2000). Statl:
An attack language for state-based intrusion detection.
Julisch, K. (2003). Clustering intrusion detection alarms to
support root cause analysis.
Kumar, S. and Spafford, E. (1995). A software architecture
to support misuse intrusion detection. In Proceedings
of the 18th National Information Security Conference.
Lunt, T. (1990). Detecting Intruders in Computer Systems.
In In Proc of the Sixth Annual Symposium and Techni-
cal Displays on Physical and Electronic Security.
Morin, B., Ludovic, M., Debar, H., and Ducass
´
e, M. (2002).
M2d2: A formal data model for ids alert correlation.
Ning, P., Cui, Y., and Reeves, D. S. (2002). Constructing at-
tack scenarios through correlation of intrusion alerts.
In CCS’2002, pages 245–254.
Paxson, V. (1999). Bro: a system for detecting network
intruders in real-time. Computer Networks, 31(23–
24):2435–2463.
Porras, P. A. and Neumann, P. G. (1997). EMERALD:
Event monitoring enabling responses to anomalous
live disturbances. In NIST-NCSC, pages 353–365.
Valdes, A. and Skinner, K. (2001). Probabilistic alert corre-
lation. In RAID 200, number 2212.
SECRYPT 2008 - International Conference on Security and Cryptography
56