Internet DRAFT - draft-yang-aff
draft-yang-aff
INTERNET-DRAFT Yixian Yang
Expires: April 2006 Jian Li
Xu Zhu
Beijing University of
Posts and Telecom.
October 2005
Alert Filtration and Fusion(AFF)
in Intrusion Management System
draft-yang-aff-00.txt
Intellectual Property Rights (IPR) statement:
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
Alert Filtration and Fusion (AFF) is proposed to solve the problems
of existing IMS(Intrusion Management System). The Alert Filtration
is used to filtrate original alerts and reduce the alerts which are
obviously unavailable. The Alert Fusion is used to reduce redundant
alerts and find the relationships of alerts. The false positive
Yixian Yang, et al. Expires March, 2006 [Page 1]
INTERNET-DRAFT Alert Filtration and Fusion September,2005
rate and false negative rate can be reduced by Alert Filtration and
Fusion.
Table of contents
Status of This Memo ......................................... 1
Abstract .................................................... 1
1. Introduction ............................................ 3
2. AFF Location ............................................ 4
3. Alert Filtration Model .................................. 6
3.1 Alert Filtration structure ............................ 6
3.2 Alert Filtration Process .............................. 6
3.2.1 Local Alert Filtration Process ........................ 7
3.2.2 Intranet Alert Filtration Process ..................... 10
4. Alert Fusion Model ...................................... 11
4.1 Alert Fusion structure ................................ 11
4.2 Concept of Alert Class ................................ 12
4.3 Alert Fusion Process .................................. 12
4.3.1 Alert Classification .................................. 13
4.3.2 Alert Corelation ...................................... 17
4.3.3 Situation Assessment .................................. 21
5. References ............................................. 22
6. Acknowledgements ....................................... 24
7. Authors' Addresses ..................................... 24
Full Copyright Statement .................................... 25
Yixian Yang, et al. Expires March, 2006 [Page 2]
INTERNET-DRAFT Alert Filtration and Fusion September,2005
1. Introduction
This document addresses the Alert Filtration and Fusion mechanism and
the structure of AFF. There are millions of alerts created by IMS
everyday, and the huge amount of alerts can't be processed by
administrators efficiently. So Alert Filtration and Fusion is
proposed to be added in IMS.
In this document, the structure of Alert Filtration and Fusion
is presented. There are different functional modules in Alert
Filtration and Fusion. The two parts can cooperate with each other
to reduce the false positive and false negative rate.
Yixian Yang, et al. Expires March, 2006 [Page 3]
INTERNET-DRAFT Alert Filtration and Fusion September,2005
2. AFF Location
Large scale distributed intrusion management system should has a
four-layer structure. The raw data which is prepared for detecting
is collected by Collection Layer. The raw data is analyzed in
Analysis Layer. In Fusion Layer, alerts are sorted, merged and
corelated. In the end, The senior alerts are sent to Harmonization
and Management Layer.
+------------------------------------+
| Harmonization and Management Layer |
+------------------------------------+
^
| Senior alert
+------------------------------------+
| Fusion Layer |
+------------------------------------+
^
| Junior alert
+------------------------------------+
| Analysis Layer |
+------------------------------------+
^
| Raw data
+------------------------------------+
| Collection Layer |
+------------------------------------+
Figure 1: IMS Four-Layer Structure
Generally, the detecting engine of Analysis Layer is based on rule
database. Although the attack can be detected, it can't be corelated
with local information. So attacks which is unavailable (Such as
RedCode attacks Linux host) can also produce alerts. These are false
positive alerts.
To solve the problem, Alert Filtration is added between Analysis
Layer and Fusion Layer. The original alerts created by Analysis
Layer are first sent to Alert Filtration and then flow to Fusion
Layer. The unavailable attacks are filtrated, so alerts in Fusion
Layer are fewer and more reliable. It also reduces some burden for
Fusion Layer.
Yixian Yang, et al. Expires March, 2006 [Page 4]
INTERNET-DRAFT Alert Filtration and Fusion September,2005
+------------------------------------+
| Harmonization and Management Layer |
+------------------------------------+
^
| Senior alert
+------------------------------------+----+
| Alert Fusion | |
+------------------------------------+ |
^ |
| Junior alert > AFF
+----------------------------------------+ |
| +------------------------------------+ | |
| | Alert Filtration | | |
| +------------------------------------+-|--+
| ^ |
| | Original alert |
| +------------------------------------+ |
| | Detecting Engine | |
| +------------------------------------+ |
| Analysis Layer |
+----------------------------------------+
^
| Raw data
+------------------------------------+
| Collection Layer |
+------------------------------------+
Figure 2: Alert Filtration and Fusion Location
Yixian Yang, et al. Expires March, 2006 [Page 5]
INTERNET-DRAFT Alert Filtration and Fusion September,2005
3. Alert Filtration Model
Alert Filtration is based on expert system. It contains Knowledge
Base, Filtrating Engine and Management System.
3.1 Alert Filtration Structure
Original Alert +------------------+
| +--------| Admining System |
| | +------------------+
| | |
v v v
+-------------------+ +----------------+
| Filtrating Engine |<----| Knowledge Base |
+-------------------+ +----------------+
|
v
Junior Alert
Figure 3: Alert Filtration Structure
Compared with common expert base, Alert Filtration doesn't have
explaining module. Since there are more works for Alert Fusion,
explaining module is unnecessary here. Filtrating Engine works as
reasoning machine. The main part of it is a Filtrating Tree. This
structure is better for extension. And it is also independent of
Knowledge Base. The Knowledge of Filtrating Engine is from Knowledge
Base. Knowledge Base locates in each host. It contains the
information of the host, such as security grade, operating system,
open service, open port, fixed vulnerability, hardware inform and
Agent Location. Filtrating Engine filtrates alerts by matching the
information from Knowledge Base. Knowledge Base and Filtrating
Engine are both controlled by Admining System.
3.2 Alert Filtration Process
The original alerts are divided into two kinds. One is created by
the data which flows in the local machine, the other one is created by
the data which flows out of the local machine. The flow-in alerts
are sent to Local Alert Filtration Module. Some of the flow-in alerts
are dumped, some are turned into the Junior Alerts. The dumped
alerts will be archived. The flow-out alerts (May be caused by
Trojan or worm) have different targets. They may be in intranet or
extranet. So the flow-out alerts whose target is intranet will be
sent to Intranet Alert Filtration Module. The others are turned into
the Junior Alerts directly.
Yixian Yang, et al. Expires March, 2006 [Page 6]
INTERNET-DRAFT Alert Filtration and Fusion September,2005
Original Alerts
|
v
flow-in +-------------------------+ flow-out
+--| Source Address Judgment |--+
| +-------------------------+ |
| |
v v
dump +-------------+ Intranet +----------------+ Extranet
<----| Local Alert | +----| Target Address |------+
| Filtration | | | Judgment | |
+-------------+ | +----------------+ |
| | |
| | |
| | |
| | |
| v v
| dump +---------------+ inform +------------+
| <-----| Intranet Alert|-------> | Alert |
| | Filtration | coordination | Generation |
| +---------------+ agent +------------+
| | |
v v v
Junior Alert Junior Alert Junior Alert
Figure 4: Alert Filtration General Process
3.2.1 Local Alert Filtration Process
Local Alert Filtration is an important module, Most of the filtration
work is done by it. The alerts which flow in must be processed. The
alerts which flow to extranet can't be filtrated because it is
difficult to get the information of hosts in extranet.
Local Alert Filtration has a structure of Filtration Tree. Original
Alerts first pass the Security Grade, then pass the other five tests
one by one. If the alert passes all the tests, then it will become
Junior alert, or it will be dumped.
Yixian Yang, et al. Expires March, 2006 [Page 7]
INTERNET-DRAFT Alert Filtration and Fusion September,2005
Original Alert
|
v
+----------------+
| Security Grade |
+----------------+
. . . . .
. . . . .
. . . . .
. . . . .
.-----.-----.-----.---->. Ordinal And
. . . . .
. . . . .
. . . . .
. . . . .
v v v v v
+----+ +-------+ +------+ +-------------+ +----------+
| OS | | Open | | Open | | Fixed | | Hardware |
+----+ |Service| | Port | |Vulnerability| | Inform |
+-------+ +------+ +-------------+ +----------+
Figure 5: Filtration Tree Structure
o Security Grade
Security Grade is dynamically set by IMS and Loading the five
following modules is decided by security Grade. If the traffic is
so heavy that system can't afford and the system isn't important,
the Security Grade should be reset, the too much alerts will be
dumped directly and the heavy pressure of system is eased.
When the alert comes, Knowledge Base is checked to get Security
Grade. If the grade is low, load the modules following the grade,
or load all the modules directly. If the grade is "Ignore", then
all the modules are skipped, all the alerts are dumped.
o Operating System
Local operating system and operating system which is influenced
are checked in this module. If Local OS is influenced, go to the
next module, or the alert will be dumped.
This module can identify incidents such as Red Code attacks Linux
host. This module mainly deals with the attack which uses the
vulnerabilities of OS. There are much more vulnerabilities than
OS. So matching OS is more efficient than matching vulnerability.
Since alert should contains the influenced OS, the Detecting
Engine needs to be rebuilt. CVE vulnerability list will be
helpful. All the information of vulnerability can be found there.
Yixian Yang, et al. Expires March, 2006 [Page 8]
INTERNET-DRAFT Alert Filtration and Fusion September,2005
o Open Service
The attacked service in alert and local open service are checked
in this module. If the attacked service is not open in local
host, then the alert is dumped, or the next module is launched.
o Open Port
The attacked port in alert and local open port are checked in this
module. If the attacked port is not open in local host, then
dump the alert, or go to the next module.
o Fixed Vulnerability
The attacked vulnerability and the fixed vulnerability of local
host are checked in this module. If the attacked vulnerability is
in the fixed vulnerability list of local host, the attack is
unavailable, the alert will be dumped.
o Hardware Inform
Some hardware may has special protecting effect, so this module is
for these hardware.
Original Alert
|
v
+----------------+ Unmatched
+---------| Security Grade |---------->dump
| +----------------+
| |
| v
| Control +----------------+ Unmatched
+---------| OS |---------->dump
| Message +----------------+
| |
| v
| Control +----------------+ Unmatched
+---------| Open Service |---------->dump
| Message +----------------+
| |
| v
| Control +----------------+ Unmatched
+---------| Open Port |---------->dump
| Message +----------------+
| |
| v
Yixian Yang, et al. Expires March, 2006 [Page 9]
INTERNET-DRAFT Alert Filtration and Fusion September,2005
| Control +----------------+ Unmatched
+---------| Fixed |---------->dump
| Message | Vulnerability |
| +----------------+
| |
| v
| Control +----------------+ Unmatched
+---------| Hardware Inform|---------->dump
Message +----------------+
|
v
+----------------+
| Alert |
| Generation |
+----------------+
|
v
Junior Alert
Figure 6: Local Alert Filtration Process
3.2.2 Intranet Alert Filtration Process
The alert created by the data which flows to Intranet is processed in
this module.
First, the Knowledge Base is checked to find whether the target host
has an agent. If the target host has an agent, the local host dumps
the alert. The target host will create the alert. It can reduce
redundant alerts. It's also a preparation for Alert Fusion.
Original Alert
|
v
+--------------+ Yes
| Target Agent |------> dump
| Judgment |
+--------------+
| No
v
+------------------+
| Agent Generation |---->Inform
+------------------+ Coordination Agent
|
v
Junior Alert
Figure 7: Intranet Alert Filtration Process
Yixian Yang, et al. Expires March, 2006 [Page 10]
INTERNET-DRAFT Alert Filtration and Fusion September,2005
4. Alert Fusion Model
The Alert Fusion composes of Alert Classification, Alert Corelation
and Situation Assessment.
4.1 Alert Fusion structure
^
senior Alert |
+------------------------------+-----------------------------+
| | Alert Fusion |
| +--------+--------+ |
| | Assessing | |
| +-----------------+ |
| ^ ^ |
| Corelated Alert | | |
| | | |
| +--------+---+ +-+----------+ |
| | Corelating | ... | Corelating | |
| +------------+ +------------+ |
| ^ ^ ^ |
| Alert Class | | | |
| | | | |
| +----------+--+ +--+----------+ +-+-----------+ |
| | Classifying | | Classifying | ... | Classifying | |
| +-------------+ +-------------+ +-------------+ |
| ^ ^ ^ |
| | | | |
+-----------+----------------+--------------------+----------+
Junior Alert | | |
+------+------+---------+----------+---------+-----+
| | | |
+--------+ +--------+ +--------+ +--------+
|Analysis| |Analysis| ... |Analysis| |Analysis|
+--------+ +--------+ +--------+ +--------+
Figure 8: The Alert Fusion Structure
in Large-scale Distribute IMS
The Junior Alert was sent to Alert Classification module by Alert
Filtration in Analysis Layer. The alerts are classified there. Then
the Alert Class is sent to Alert Corelation module. The Alert
Classes are corelated with each other. Then the corelated alerts
are sent to Alert Assessment module. The reliability is given to
each alert. The alert with low reliability could be dumped or
kept as reference information for administrators.
Yixian Yang, et al. Expires March, 2006 [Page 11]
INTERNET-DRAFT Alert Filtration and Fusion September,2005
4.2 Concept of Alert Class
Alerts are used to be classified by methods of attack, such as the
class of Trojan, Worm, and so on. In this way of classifying, each
attack has to be arranged to build the attacking scene for alert
fusion. When another scene is needed, attacks must be rearranged.
Even in the same attacking scene, if one or more attacks can be
replaced by some others, the scene must be rebuilt along with the
changing of attacks. So it's a hard way of building attacking scene,
and when the sequence of attacks changes, it can't be recognized.
To solve the problem above, a new classifying way is proposed in this
document. Alerts can be classified into three classes: Invalidation,
Scan and Penetrate by intensions of attacks.
Class of Invalidation: Land, Smurf, Syn-Flood, some other
vulnerabilities of buffer overflow and so on are in this class. The
intention of these attacks is paralyzing the system and making it
invalid.
Class of Scan: nmap and some other scanning tools are usually used to
detect the active hosts ,get information of hosts, such as operating
system type, username, password and so on. The intention of attacks
is getting the information and preparing for the real attack
following.
Class of Penetrate: Breaking into others' computers is the final
intention of all attacks. Attacks of this class are to finish the
final work. They are mainly Trojans and some vulnerabilities of
getting privileges.
Nearly all the attacks can be classified into these three classes.
Through finding the corelation of the classes, we can find out the
complicated attacks from millions of alerts.
4.3 Alert Fusion Process
Junior Alert
|
v
+----------------------+
| Alert Classification |
+----------------------+
|
v
+------------------+
| Alert Corelation |
+------------------+
|
v
Yixian Yang, et al. Expires March, 2006 [Page 12]
INTERNET-DRAFT Alert Filtration and Fusion September,2005
+----------------------+
| Situation Assessment |
+----------------------+
|
v
Senior Alert
Figure 9: Alert Fusion Process
There are three modules in Alert Classification. Alert Fusion Time,
Alert Property Classification and Alert Class Clustering.
There are two modules in Alert Corelation. Basic Corelation and
Advanced Corelation.
Situation Assessment is an independent part. It is removable.
4.3.1 Alert Classification
1) Alert Fusion Time
Createtime is a property of alert. It describes the time when the
alert is created. Alert Fusion Time is a scope. The alerts are
picked up in this scope based on createtime.
2) Alert Property Classification
Classification is a property of a alert. The alerts are
classified into Invalidation Class, Scan Class or Penetrate Class
by this property.
3) Alert Class Clustering
There are different alerts in Alert Class. It is necessary to
cluster the alerts.
a) Repeated Alerts Merging
Many of alerts are repeated, such as a hacker attacks a host
with Syn-Flood. Host will get many Syn-Flood alerts with the
same source and target address. These are redundant alerts.
They will be merged as one alert and the amount will be
recorded as the parameter of the alert priority.
b) Same Target Alerts Merging
After the merging of redundant alerts, there are still some
alerts with the same source address or target address. The
reason why merging the alerts that have the same target
address is that target of attack is the key of corelation, and
attack sources are usually much more than targets. So the
alerts in the class are clustered by target addresses.
Yixian Yang, et al. Expires March, 2006 [Page 13]
INTERNET-DRAFT Alert Filtration and Fusion September,2005
In the end, the alerts are rearranged from high to low by
priority. This can improve the efficiency of the corelation.
The Process:
Input: Junior Alert
Output: Alert Class (Invalidation, Scan, Penetrate)
Step1 Search for the alerts with the same source and target
address, the alert priority adds the times which is
repeated.
Step2 Merge the redundant alerts and delete the redundancies.
Step3 Search for alerts with the same target address, merge
them as a cluster. The cluster is treated as an alert,
but it keeps all its source addresses.
Step4 After the merging, delete the single alerts that have
been merged.
Step5 Rearrange the alerts in the cluster from high to low by
priority. Compute the cluster priority.
Step6 Rearrange the clusters and alerts in the alert class.
Step7 Output the alert class.
The process in C code:
Repeated Alerts Merging
Step1:
for (i=1;i<=m;i++)
{
if( Alert[i].mark==0)
// repeat mark is 0, it's not repeated
{
for(k=i+1;k<=m;k++)
{
if(Alert[i].source_address==Alert[k].source_address&&
Alert[i].target_address==Alert[k].target_address)
// find repeated alert
{
Alert[k].mark=1;
// mark repeated alert, prepare for deleting
Yixian Yang, et al. Expires March, 2006 [Page 14]
INTERNET-DRAFT Alert Filtration and Fusion September,2005
repeat_num++;
// counter of repeated alert adds 1
Alert[i].priority++;
// priority adds 1
}
}
}
}
Step2:
for(i=1;i<=m;i++) // delete repeated alerts
{
if(Alert[i].mark==1) // find a repeated alert
{
for(k=i+1;k<=m;k++)
// search for the unrepeated alert
// following the repeated one
{
if(Alert[k].mark==0) // find unrepeated alert
{
Alert[i]=Alert[k];
// copy unrepeated one to the repeated
Alert[k].mark=1;
// mark it after copying
}
}
}
}
for(i=m-repeat_num+1;i<=m) // delete repeated alerts behind
{
delete(Alert[i]);
}
The unrepeated alerts are picked out, the number is
m-repeat_num
Same Target Alerts Merging
Step3:
n=m-repeat_num;
repeat_num=0; // counter resets
for(i=1;i<=n;i++)
{
if(Alert[i].mark==0) // work on unmerged alerts
{
for(k=i+1;k<=n;k++)
{
Yixian Yang, et al. Expires March, 2006 [Page 15]
INTERNET-DRAFT Alert Filtration and Fusion September,2005
if(Alert[i].target_address==Alert[k].target_address)
// find an alert with the same target
{
Alert[i]=combine(Alert[i],Alert[k]);
// merge the alerts
// keep the source addresses
Alert[i].combine_num++;
// record the number of alerts in cluster
Alert[k].mark=1; // mark the alerts
repeat_num++; // counter adds 1
Alert[i].combine_flag=1; // mark merged alert
}
}
}
}
Step4:
for(i=1;i<=n;i++) // delete merged alert
{
if(Alert[i].mark==1) // find a merged alert
{
for(k=i+1;k<=n;k++) // search for unmerged alert behind
{
if(Alert[k].mark==0) // find unmerged alert
{
Alert[i]=Alert[k]; // copy unmerged one to the merged
Alert[k].mark=1; // mark it after copying
}
}
}
}
for(i=n-repeat_num+1;i<=n) // delete merged alerts behind
{
delete(Alert[i]);
}
Step5:
for(i=1;i<=n-repeat_num;i++)
{
if(Alert[i].combine_flag==1) //find cluster
{
for(k=1;k<=Alert[i].combine_num;k++)
// arrange the high priority alert before
Yixian Yang, et al. Expires March, 2006 [Page 16]
INTERNET-DRAFT Alert Filtration and Fusion September,2005
{
Alert[i].priority=Alert[i].priority+Alert[i][k].priority;
// compute cluster priority
for(j=k+1;j<=Alert[i].combine_num;j++)
{
if(Alert[i][k].priority<Alert[i][j].priority)
{
cup=Alert[i][k];
Alert[i][k]=Alert[i][j];
Alert[i][j]=cup;
}
}
}
}
}
Step6:
for(i=1;i<=n-repeat_num;i++)
{
for(k=i+1;k<=n-repeat_num;k++)
{
if(Alert[i].priority<Alert[k].priority)
{
cup=Alert[i];Alert[i]=Alert[k];Alert[k]=cup;
}
}
}
4.3.2 Alert Corelation
1) Basic Corelation
The basic corelation is mainly realized by searching for alerts in
the different classes which have the same source and target
addresses.
First, hacker scans the net, the alert in scan class is
created. Then hacker chooses target, tries to get in the host by
vulnerability, the alert in penetrate class is created. If the
penetrating loses, hacker may invalidated the host, the
alert in invalidation class is created.
So the three alerts with the same source and target addresses can
be corelated. An intermediate alert is created.
The process:
Input: Alert Class (Invalidation, Scan, Penetrate)
Yixian Yang, et al. Expires March, 2006 [Page 17]
INTERNET-DRAFT Alert Filtration and Fusion September,2005
Output: Intermediate Alert
Step1: traverse scan class, alert is called A.
Step2: traverse invalidation class, alert is called B.
Step3: traverse scan penetrate class, alert is called C.
Step4: If there are two alert in different class having the same
source and target address, then they should be corelated.
The intermediate alert is created.
The process in C code
for(i=1;i<=scan.target_num;i++)
{
for(j=1;j<=invalidation.target_num;j++)
{
for(k=1;k<=penetrate.target_num;k++)
{
if(scan[i].target_address==invalidation[j].target_address
&& penetrate[k].target_address==invalidation[j].target_address)
// three alerts(A,B,C) have the same target
{
if(scan[i].source_address==invalidation[j].source_address
&& penetrate[k].source_address==invalidation[j].source_address)
// A, B, C have the same source too
connect(scan[i],invalidation[j],penetrate[k]);
// corelate A, B, C
}
elseif(scan[i].target_address==invalidation[j].target_address)
// A and B has the same target
{
if(scan[i].source_address==invalidation[j].source_address)
// A and B has the same source
connect(scan[i],invalidation[j]);
// corelate A and B
}
elseif(scan[i].target_address==penetrate[k].target_address)
// A and C has the same target
{
if(scan[i].source_address==penetrate[k].source_address)
// A and C has the same source
Yixian Yang, et al. Expires March, 2006 [Page 18]
INTERNET-DRAFT Alert Filtration and Fusion September,2005
connect(scan[i],penetrate[k]);
// corelate A and B
}
elseif(penetrate[k].target_address==
invalidation[j].target_address)
// C and B has the same target
{
if(penetrate[k].source_address==
invalidation[j].source_address)
// C and B has the same source
connect(penetrate[k],invalidation[j]);
// corelate C and B
}
}
}
}
2) Advanced Corelation
Basic Corelation is only used as a simple method, the direct
attack can be corelated by it. But there are more and more
complicated attacking methods, such as distribute and reflect
attack. So the Advanced Corelation is needed.
IPspoofing is one of the complicated attacks. It composes of
a series attacks. Hacker(A)'s target is the server(C), and
host(B) is trusted by C. So A will imitate B to get into C.
The process of IPspoofing:
a. A invalidates B, B is paralyzed.
b. A connects to C, guesses ISN.
c. A imitates B to connect to C, and sends commands.
The Alerts created:
a. A->B, Invalidation Class.
b. A->C, Scan Class.
c. B->C, Penetrate Class.
These attacks can't be corelated by basic corelation. So the
Advanced Corelation is needed.
Yixian Yang, et al. Expires March, 2006 [Page 19]
INTERNET-DRAFT Alert Filtration and Fusion September,2005
The process of Advanced Corelation:
Input: Alert Class(Invalidation, Scan, Penetrate) and the single
alerts.
Output: Senior Alerts
Step1: Traverse invalidation class. The target address is called
B.
Step2: Traverse source addresses of B, the source is called A.
Step3: Search for source A in scan class.
Step4: Traverse scan class. Search for the alert with source A,
Its target is called C.
Step5: Traverse penetrate class. Search for target C.
Step6: Find the alert with target C.
Step7: Traverse sources of the alert with target C in penetrate
class. Search for source B.
Step8: Find B, A->B, A->C, B->C can be corelated. Senior alert
is created.
The process in C code:
for(i=1;i<=invalidation.target_num;i++)
{
for(j=1;j<=invalidation[i].source_num;j++)
{
for(k=1;k<=scan.source_num;k++)
{
if(scan[k].source_address==invalidation[i][j].source_address)
{
for(l=1;l<=penetrate.target_num;l++)
{
if(scan[k].target_address==penetrate[l].target_address)
{
for(a=1;a<=penetrate.source_num)
{
if(penetrate[l][a].source_address==
invalidation[i].target_address)
connect(invalidation[i][j],scan[k],penetrate[l][a]);
}
}
}
}
}
Yixian Yang, et al. Expires March, 2006 [Page 20]
INTERNET-DRAFT Alert Filtration and Fusion September,2005
}
}
4.3.3 Situation Assessment
The Dempster-Shafer decision theory is considered a generalized
Bayesian theory. It is proposed here to calculate the belief of
senior alerts. The alerts will be judged by expert system based on
the belief.
This is the example of IPspoofing:
Assume situations of the senior alert is A1(IPspoofing) and A2.
On t1, there is an alert in invalidation class(A->B). This is state
S1. Based on expert experience, probability mass function
m1(A1,A2)=(0.4,0.6).
On t2, there is an alert in scan class(A->C). This is state S2.
Based on expert experience, probability mass function
m2(A1,A2)=(0.5,0.5).
On t3, there is an alert in penetrate class(B->C). This is state
S3. Based on expert experience, probability mass function
m3(A1,A2)=(0.8,0.2).
On t3, there is an alert in penetrate class(B->C). This is state
S4. Based on expert experience, probability mass function
m4(A1,A2)=(0.8,0.2).
Combine the data:
m=m1¨’m2=(0.4,0.6)
m=m¨’m3=(0.73,0.26)
m=m¨’m4=(0.92,0.08)
Yixian Yang, et al. Expires March, 2006 [Page 21]
INTERNET-DRAFT Alert Flitration and Fusion September,2005
5. References
[1] Denning, D.E. An intrusion detection model[J], IEEE
Transactions on Software Engineering, 1987, 13(2):222-23.
[2] Bass-Intrusion detection systems and multisensor data fusion
[J], Communications of the ACM, 2000, 43(4):99-105.
[3] H.Debar, A.Wespi, "Aggregation and Correlation of Intrusion-
Detection Alerts", In Proceedings of the Fourth International
Symposium on the Recent Advanced in Intrusion Detection
(RAID'2001), LNCS2 212, pp.85-1032001.
[4] F.Cuppens, Managing Alerts in a Multi-Intrusion Detection
Environment, In 17th Annual Computer Security Applications
Conference New-Orleans, New-Orleans, USA, December 2001.
[5] Stuart Staniford etc. Practical Automated Detection of Stealthy
Portscans. Silicon Defense,
http://www.silicondefense.corn/software/spice/index.htm.
[6] S.Kumar and E.Spaford. An Application of Patern Matchingin
Intrusion Detection. Department of Computer Sciences, Purdue
University, CSD-TR-94-013, Coast TR 94-07, 1994.
[7] S.Kumar. Classification and Detection of Computer Intrusions.
PhD thesis, Department of Computer Sciences, Purdue University,
August 1995.
[8] Slagell,M. The Design and Implementation of MAIDS (Mobile Agent
Intrusion Detection System) . Master's thesis, Computer Science
Department, Iowa State University, 2001.
[9] G.Helmer, J.Wong, M.Slagell, V.Honavar, L.Miller and R.Lutz.
Software Fault Tree and Colored Petri Net Based Specification,
Design and Implementation of Agent-Based Intrusion Detection
Systems. Submited to ACM Transactions on Information and System
Security (TISSEC).
[10] Jain, K. and Sekar, R. User-Level Infrastructure for System Call
Interposition: A Platform for Intrusion Detection and
Confinement. In Proceedings of the Year 2000 Network and
Distributed Systems Security Symposium (NDSS 2000).
[11] Warrender, C., Forrest, S., and Pearlmutter, B.Detecting
Intrusions Using System Calls: Alternative Data Models. In
Proceedings of the 1999 IEEE Symposium on Security and Privacy.
[12] Helmer, G., Wong, J., Honavar, V., and Miller, L. Automated
Discovery of Concise Predictive Rules for Intrusion Detection.
Technical Report TR99-01, Department of Computer Science, Iowa
State University.
Yixian Yang, et al. Expires March, 2006 [Page 22]
INTERNET-DRAFT Alert Filtration and Fusion September,2005
[13] Hofmeyr, S.A.,Forrest, S., and Somayaji, A. Intrusion Detection
Using Sequences of System Calls. Journal of Computer
Security, 6(3):151180,1998.
[14] T.Tidwell, R.Larson, K.Fitch and J.Hale. "Modeling Internet
Attacks". Proceedings of System Calls. Journal of Computer
Security, 6(3):151180,1998. the 2001 IEEE Workshop on
Information Assurance and Security, pp .54-59,2001.
[15] Ming-Yuh Huang, Thomas M.Wicks. A Large-scale Distributed
Intrusion Detection Framework Based on Attack Strategy Analysis.
Technical Report, Boeing Company, Seattle, WA,U.S.A.
[16] C.Geib and R.Goldman. Plan Recognitionin Intrusion Detection
Systems. In DARPA Information Survivability Conference and
Exposition(DISCEX), June 2001.
[17] C.Geib and R.Goldman. Probabilistic Plan Recognition for Hostile
Agents. In Florida 115 AI Research Symposium (FLAIR), Key-West,
USA, 2001.
[18] Ulf Lindquist and Philip Porras. Detecting Computer and Network
Misuse Through the Production-Based Expert System Toolset (P-
Best). In IEEE Symposium on Security and Privacy, Oakland, USA,
1999.
[19] A.Mounji and B.Le Charlier. Continuous Assessment of a Unix
Configuration: Integrating Intrusion Detection and Configuration
Analysis. In ISOC'97 Symposium on Network and Distributed System
Security, San Diego, USA, February1997.
[20] DEMPSTER A P. Upper and lower probabilities induced by a
multivalued mapping [J]. Annals of Mathematical Statistics,
1967(38): 77-87.
[21] SHAFER G. A mathematical theory of evidence [M].Princeton:
Princeton University Press, 1976.
Yixian Yang, et al. Expires March, 2006 [Page 23]
INTERNET-DRAFT Alert Filtration and Fusion September,2005
6. Acknowledgement
The authors gratefully acknowledge the contributions of Ming Cao,
Xiuling Zhu, Huayi Rao, Xinliu Wang and Shuai Zeng.
7. Authors' Addresses
Yixian Yang
Information Security Center,
Beijing University of posts and telecom.(BUPT),
Beijing, China,100876
Phone:8610-62283366
Email:yxyang@bupt.edu.cn
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Yixian Yang, et al. Expires March, 2006 [Page 24]
