A Cognitive Model for Alert Correlation in a
Distributed Environment1
Ambareen Siraj and Rayford B. Vaughn
Center for Computer Security Research,
Department of Computer Science and Engineering
{ambareen, vaughn}@cse.msstate.edu
Abstract. The area of alert fusion for strengthening information assurance in
systems is a promising research area that has recently begun to attract attention.
Increased demands for “more trustworthy” systems and the fact that a single
sensor cannot detect all types of misuse/anomalies have prompted most modern
information systems deployed in distributed environments to employ multiple,
diverse sensors. Therefore, the outputs of the sensors must be fused in an
effective and intelligent manner in order to provide an overall view of the status
of such systems. A unified architecture for intelligent alert fusion will
essentially combine alert prioritization, alert clustering and alert correlation. In
this paper, we address the alert correlation aspect of sensor data fusion in
distributed environments. A causal knowledge based inference technique with
fuzzy cognitive modeling is used to correlate alerts by discovering causal
relationships in alert data.
Keywords: Network security, intelligent alert fusion, alert correlation, fuzzy
cognitive modeling.
1
Introduction
Research in IDS improvement has taken on new challenges in the last few years. One
such contemporary and promising approach in this area is alert fusion in a multisensor environment. Increased demands for “more trustworthy” systems and the fact
that a single sensor cannot detect all types of misuse/anomalies have prompted most
modern information systems deployed in distributed environments to employ
multiple, diverse sensors. Therefore, the outputs of the sensors must be fused in an
effective and intelligent manner to provide an overall view of the status of the system.
Alert fusion, alert aggregation, alert clustering, alert correlation - all serve the same
primary purpose – i.e., to provide some form of high level analysis and reasoning
capabilities beyond low level sensor abilities. We refer to alert fusion as the process
of interpretation, combination and analysis of alerts to determine and provide a
1
This work is supported by NSF Cyber Trust Program Grant No: SCI-0430354, NSA IASP
Grant No: H98230-04-1-0205, Office of Naval Research Grant number N00014-01-1-0678.
and the Department of Computer Science and Engineering Center for Computer Security
Research at Mississippi State University (http://www.cs.msstate.edu/~security).
P. Kantor et al. (Eds.): ISI 2005, LNCS 3495, pp. 218 – 230, 2005.
© Springer-Verlag Berlin Heidelberg 2005
A Cognitive Model for Alert Correlation in a Distributed Environment
219
quantitative value for the system such that the value is representative of the degree of
concern in the system. In a distributed environment, characterized by physically (and
maybe geographically too) dispersed but networked systems, sensors are used to
monitor security violations in the protected network. In such environment, fusion of
sensor reported alerts is necessary for:
− Alert Clustering: To find structural relationships in data by grouping/aggregating
alerts with common features. Alert clustering can aid in alert reduction and
discovery of general attack patterns.
− Alert Correlation: To find causal relationships in data by associating alerts, which
are parts of linked chains of events. Alert correlation can help to identify multistaged attacks and to reduce alert volume.
In this paper, we address the alert correlation aspect of sensor data fusion for
distributed environments. Here we illustrate the use of a causal knowledge-based
inference technique with Fuzzy Cognitive Modeling to discover causal relationships in
sensor data. The following sections will outline the research, provide necessary
background information, describe the technique we use in alert correlation, report on
experimental results on a benchmark dataset and lastly conclude.
2
Related Work
Research in the area of alert fusion/alert aggregation/alert clustering/alert correlation
has emerged in last few years and primarily concerns information modeling and high
level reasoning. Among them, the ones that are relevant to our work are the following.
Julisch introduces attribute generalization in alarm (i.e., alert) clustering as a
method to support root cause discovery [3]. This work outlines a semi-automatic
approach for reducing false positives in alarms by identifying the root causes with
clustering of alerts by abstraction and then eliminating the root causes to reduce alarm
overload. Ning et al. proposes an alert correlation model based on prerequisites and
consequences of intrusion [8]. With knowledge of prerequisites and consequences, the
correlation model can correlate related alerts by matching the consequences of
previous alerts with prerequisites of later ones and then hyper alert correlation graphs
are used to represent the alerts. In the prerequisite-consequence model, the authors
conduct reasoning with predicate logic where predicates are used as basic constructs
to represent the prerequisites and consequences of attacks. This approach requires
extensive modeling of attacks in terms of specifying prerequisite and consequence of
each alert type in the sensor report. Yu and Frincke propose a model for Alert
Correlation and Understanding (ACU) based on Hidden Colored Petri-Nets (HPCN)
[13]. HPCNs model agents, resources, actions, and functions of a system with
transition and observation probabilities. To perform correlation, a model based on
prerequisites and consequences is generated using domain knowledge. Training of
model is required to best fit the model parameters. Qin and Lee generate high level
aggregated alerts from low level sensor data and then conduct causal analysis based
on a statistical technique, known as the Granger Causality Test, to discover new
patterns of attack relationships [10]. Although this approach does not require apriori
220
A. Siraj and R.B. Vaughn
knowledge of attacks behavior, it still requires some human intervention in
background alert identification used in the statistical technique employed.
Fuzzy Cognitive Maps (FCMs) originated from the combination and synergism of
fuzzy logic and neural networks. Researchers have used FCMs for many tasks in
several different domains. Use of FCMs was first reported in [11] for fusing alert
information in a multi-sensor intrusion detection environment to assess network
health. Fuzzy Intrusion Recognition Engine, a network based IDS, also use FCMs in
detecting attacks from features extracted from network traffic [12]. The work that we
present in this paper differs from our previous work [11] primarily in the focus of the
research, which is discovery of causal relationships between alerts rather than
structural relationships and in the use of abstract FCM models to address issues of
scalability and uncertainly.
3
A Cognitive Model for Alert Correlation with FCMs
The principal objective of our intelligent alert fusion model is to provide an overall
condensed view of the distributed system by assessing the health of the primary
resources in the network, which are essentially the computing nodes/hosts in the
network. Therefore, our fusion model is resource-centric, i.e., analysis is centered
upon the resources in the system in terms of the communication involving them. A
resource-centric view inherently reduces alert volume by:
− presenting an overall picture of the compromised resources to the security
administrator instead of alerts;
− not having to take account of information out of the scope of resource perimeter.
For any environment where performance heavily depends on system resources,
such a view only seems natural.
A cognitive model is a “generalization over repeated experience” where knowledge
- acquired through perception and experience – is organized into mental structures.
One such cognitive modeling and inferencing technique uses Fuzzy cognitive map
(FCM) that allows us to represent our perception of the real world in a structured way.
We are using fuzzy cognitive modeling to correlate alerts in sensor data because it
offers a straightforward structural representation of causal knowledge and allows
what-if kinds of reasoning for causal analysis of data. Proposed by Kosko, FCMs
model the world as concepts and causal relations between concepts in a structured
collection [4,5,6]. Concepts (nodes) in an FCM (fig. 1) are events that originate in the
system and whose values change over time. The causality links between concepts are
represented by directed edges that denote how much one concept impacts the other(s).
The concepts in the FCMs can be crisp or fuzzy. Concepts typically take values in the
interval [0,1]. In the simplest case, a concept is either on (1) or off (0). A concept can
also be represented by a fuzzy set and can fire to some degree. The edges typically
have values between 0 and 1 or –1 and 1. Edges can also be fuzzy, and in those cases
we can use linguistic words such as “a little,” “highly,” “somewhat,” to represent the
edges. When the edges between concepts are fuzzy values, fuzzy set operators like Tnorms and T-conorms can be applied to the particular chain of concepts to infer the
total effects of concepts in the chain.
A Cognitive Model for Alert Correlation in a Distributed Environment
Ci
e ij
221
Cj
Fig. 1. Two FCM Concepts with a Causal Link
With the premise that every cause is bound to have an effect (whether high or low),
our cognitive model views the alerts issued by the sensors as causes that have the
potential to generate specific effects in systems. Different alerts in sensor report
pertain to different actions of attackers with different objectives. The effects
generated can potentially be coupled together in a causal chain to reveal the possible
correlations between the alerts initiating them.
In this respect, our fusion model recognizes two kinds of events in systems:
− Cause Events (CEvent): This type of event is generated as a result of alerts seen in
the sensor reports and corresponds to possible actions taken by the attacker to
achieve some goal.
− Effect Events (EEvent): This type of event is generated as a result of activation of
cause events and corresponds to specific security incidents in the system.
Effect events can in turn act as cause events to further produce some other effect
events (i.e., incidents).
To illustrate the use of such cognitive modeling for alert correlation, a common
attack such as Distributed Denial of Service (DDoS) is examined. Suppose, a DDoS
attack is to be launched using a known vulnerability of the sadmind service in Solaris
systems. In this case, the following steps are usually carried out by an intruder [7]:
−
−
−
−
−
Conduct IPSweep from a remote site to find out existence of hosts;
Probe the hosts looking for sadmind daemon running on Solaris hosts;
Break into host(s) using the sadmind vulnerability;
Install Trojan mstream DDoS software on some host(s); and
Launch the DDoS.
Fig. 2 is an FCM that models the scenario described above for the DDoS attack
using cause and effect types of events (the EEvents shown here are similar to the
consequences of hyper alert types as in [8]). The FCM in this figure denotes that an
IPSweep alert in the sensor report will generate an IPSweep CEvent, from which
HostExits EEvent can be inferred. Later, when the SadmindPing CEvent is generated
from the alert report, the fusion model can associate this with a previously generated
HostExits EEvent and the combination of both will generate a new EEvent
VulnerableToSadmind. All alerts contributing to CEvents of a particular FCM model
can be correlated as part of the attack scenario depicted by the FCM model.
But, problems with such specific/exact knowledge modeling are that:
− it does not scale well; and
− it does not work well when there are deviations in data (due to heterogeneous
sources) or incomplete data (due to incomplete/imperfect source coverage).
222
A. Siraj and R.B. Vaughn
Therefore, in order to address these issues and make FCM models more applicable
to real world situations, our fusion model employs abstract or more generalized
cognitive models such that:
− a particular model can accommodate variations of similar knowledge/evidence;
and
− inference can still take place with incomplete/varied information.
IPSweep
Host Exists
Sadmind
Ping
Vulnerable to
Sadmind
Gain Access
Sadmind
Amslverify
Overflow
System
Compromised
RSh
Mstream
Zombie
Ready To
Launch DOS
DOS Attack
Launched
StreamDOS
Fig. 2. An FCM Model for Detecting DDoS Attack Exploiting Sadmind Service Vulnerability
In this regard, our fusion model uses FCMs that employ more abstract or
generalized events than specific ones (fig. 3.).
Risk of Disclosure
of Host
+0.25
Scan
+1.00
Disclosure of
Host
+1.00
Risk of Disclosure
of Service
+0.25
Probe
+1.00
+1.00
Disclosure of
Service
Risk of System
Environment Corruption
+0.50
Access Control
Violation
+1.00
System Environment
Corruption
+1.00
Risk of System
Seizure
+0.75
Suspicious
Transfer Activity
Illegal
Installation
+0.50
+1.00
System
Seizure
+1.00
Risk of System
Distress
+0.50
System
Distress
Fig. 3. An Abstract FCM Model for Detecting DDoS Attacks in General
For example, instead of generating specific CEvents like Sadmind
AmslverifyOverflow (fig. 2), it abstracts alerts by using a generalization hierarchy
such as in fig. 4, to activate more generalized CEvents like AccessControlViolation
A Cognitive Model for Alert Correlation in a Distributed Environment
223
(fig. 3). Note that the same CEvent will also be generated for similar types of alerts
such as StatdOverflow or SolarisLPDOverflow. Also, instead of generating specific
EEvents like VulnerableToSadmind, the fusion model activates more generalized
EEvents like DisclosureOfService. Note that the same EEvent can also replace other
specific EEvents like VulnerableToStatd, or VulnerableToSolarisLPD. Thus, a single
such cognitive model of an abstract attack scenario can replace multiple explicit
attack models and help with scalability issues in alert correlation modeling.
Generalized Alerts (CEvents)
Scan
Probe
Information Policy
Leakage
Violation
Access
Control Violation
Suspicious
Transfer Activity
Illegal Installation
Attack Launch
(e.g., IPSweep) (e.g., SadmindPing) (e.g., FTP_User) (e.g., Admind) (e.g., Email_Almail_Overflow) (e.g., FTP_Put) (e.g., MStream_Zombie) (e.g., Stream_DoS)
Specific Alerts
Fig. 4. Generalization of Low Level Sensor Alerts to Abstract CEvents
Different actions of an attacker targeted at a particular host activate different
incidents for the host. The degree to which an incidence occurs depends not only on
the report of the corresponding action taken by the attacker, but also on the existing
risk of such an incidence taking place (Fig. 3). For example, the EEvent
SystemEnvironmentCorruption primarily depends on the sensor reporting of CEvent
AccessControlViolation (alert impact1 designated by FCM edge of +1.00). But this
type of action is not always successful and therefore, sensor notification of this alert
does not guarantee that such an incidence actually took place in reality. Our model
deals with this uncertainty by taking additional information into account - which is the
existing risk of such incidence happening for the particular resource in question. Fig.
3 shows the risk impact designated by FCM edge of +0.50 for the incident
SystemEnvironmentCorruption. Note the difference in between alert and risk impact.
This is because usually, we pay more attention on the report of the alert itself than on
the existing risks. But, sometimes when alerts such as - rsh, Telnet XDisplay, ftp_put are issued by sensors, which may or may not result from actual malicious activities,
the existing risk (or possibility) of such incident occurring should impact the incident
1
The edge values used in the correlation model come from security experts’ common sense
judgment and experience. Note that edges represent how much a certain concept impact the
other, on a scale of 0 to 1 or 0 to -1. Although these impact values are determined from
expert knowledge and experience, once the values are initially set, their performance can be
observed over time and their values can be tuned for optimal performance by the security
administrator based on the empirical performance of the alerts generated. We have found that
FCMs offer a highly flexible structure in this regard. A variety of both manual and automated
techniques can potentially be used to fine-tune these parameters.
224
A. Siraj and R.B. Vaughn
more than the alert itself. Hence impacts of such CEvents, like Suspicious
TransferActivity, are less than the impact of associated risk.
The degree to which an incidence occurs for a particular resource designates its
incidence strength. In order to compute incidence strengths and also to fuse the
overall impact of the different incidents activated for each host, the resemblance
between FCMs and neural networks is utilized [1]. In the neural network approach,
the concepts of the FCMs are represented by neurons and the edges are represented by
the weights of the connecting neurons. The incidents, treated as neurons, trigger
activation of alert levels with different weights depicting causal relations between
them. An adjacency matrix is used to list these cause and effect relationships between
the FCM concepts. In an FCM, the runtime operation is observed by determining the
value of the effect concept from the cause concepts and the connecting edge values.
Disclosure of
Service
System Environment
Corruption
+0.20
+0.50
Disclosure of
Host
+0.05
Incidence Alert Level
+1.00
+0.75
System Distress
System Seizure
Fig. 5. FCM model for Fusing Evidences of Incidents
As incidents are activated for a resource, our model correlates the alerts that
contribute in activating the incidents. Along with identifying the correlated alerts, our
model also fuses the different incidence strengths of a particular resource to measure
the degree of the incidence alert level (IAL) of the resource in the correlated alerts.
Fig. 5 shows how the evidence of different incidents activated for a resource
contribute to the IAL of the resource with different impacts. The degree of impact
depends on the nature of the incidence and security policy. At any time, IAL of any
particular resource collectively represent the effects of all the incidents activated for
the resource at the time. Therefore in accordance with FCM inference [6], the IAL of
a resource Ri at tn+1 time for each contributing incidents Ik with impact eki, can be
represented as the following:
IAL ( R i )( t n + 1
⎡
⎢
) = ⎢
⎢
⎢⎣
n
∑
k =1
(I
k
)( t n ) * e
n
∑
k =1
e
ki
(tn )
ki
⎤
(tn ) ⎥
⎥
⎥
⎥⎦
IAL can be considered a confidence score given by the fusion model to represent
the degree of concern for a particular resource in its involvement in correlated
incidents resulting from multi-staged attacks. It should be pointed out that with FCM
modeling of system events, the presence of all predecessor events is not mandatory in
a correlation scenario for inferring subsequent events. Alert correlation with abstract
fuzzy cognitive modeling allows inference to progress with missing/incomplete alerts
A Cognitive Model for Alert Correlation in a Distributed Environment
225
in sensor reports. Due to space constraints in this paper, discussion on dealing with
missing alerts is left for future avenues.
4
Experimental Results
To evaluate the effectiveness of our alert correlation technique based on fuzzy
cognitive modeling, we started out with experiments in a traditional distributed
environment where our objective was to evaluate the alert fusion model’s ability to
correlate low level sensor alerts that are part of coordinated attacks.
We chose to use MIT Lincoln’s Lab’s DARPA 2000 Intrusion Detection
Evaluation (IDEVAL) Scenario Specific Data Sets [7] for the experiments because it
is a renowned benchmark dataset that contains simulated multi-staged attack
scenarios in a protected environment. Use of this dataset also allows us to compare
our experimental results to work by other researchers in this area. The dataset
includes a series of attacks carried out over multiple network and audit sessions by an
attacker who probes hosts, successfully breaks in some of them to prepare for and
finally launch DDoS attacks against an off-site government website. In the DARPA
2000 dataset, there are three segments of a simulation network: a network inside an
Air Force base, an internet outside an Air Force base and the demilitarized zone
(DMZ) that connects the outside to inside [7]. Also, there are two attack scenarios:
one that includes DDoS attacks carried out by a novice attacker (DDoS 1.0) who
compromises three hosts individually and one that includes DDoS attacks carried out
by a more sophisticated attacker (DDoS 2.0.2) who compromises one host and then
fans out from it. The DARPA website provides a list of all the hosts in the three
segments of the evaluation network [7].
Since we are interested in the fusion of sensor data, we needed to work on sensor
alert report generated on the Lincoln Lab dataset. Such a sensor alert report by
RealSecure network sensor (Version 6.0) [2], executed with Maximum Coverage
Policy on the Lincoln Lab’s datasets, has been made available by researchers at North
Carolina State University as a part of the TIAA (A Toolkit for Intrusion Alert
Analysis) project [9]. We used this sensor alert report in our experiments to evaluate
the usefulness of our approach for alert correlation.
For our experiments, we used a similar abstraction hierarchy as shown in fig. 4 to
generalize the alert types in the sensor alert report. The low level alerts reported by
RealSecure were generalized to abstract categories with the help of attack signatures
descriptions provided by ISS, Inc.’s X-Force database, a very comprehensive threats
and vulnerabilities database (http://xforce.iss.net/). In addition, security experts were
consulted for their valuable comments/suggestions on the generalization scheme.
As we ran our cognitive model on the DDoS 1.0 inside zone sensor alert report, we
were able to correctly identify the three victim hosts (mill: 172.016.115.020, pascal:
172.016.112.050 and locke: 172.016.112.010), which the attacker compromised
individually and then used to launch the DDoS attack. The graph in fig. 6 shows the
DDoS attack scenario represented from the alerts correlated by our experiment. The
graph shows four specific incidents identified by the model that represents four
distinct phases of the attacks, which are as follows:
226
–
–
–
–
A. Siraj and R.B. Vaughn
Probing activities were conducted to discover services running on in the hosts,
which resulted in the incidence Discloser of Service (DSV). (Here the attacker
probed the hosts with sadmind ping to detect which ones had the sadmind service
running.)
Exploitation attacks were executed that resulted in the incidence System
Environment Corruption (SEC). (Here the attacker used the vulnerability
associated with the sadmind service to gain root access into the victim hosts.)
Remote-to-root activities were carried out that resulted in the incidence System
Seizure (SSZ). (Here the attacker uploaded necessary files for installing mstream
software on the compromised hosts via telnet and rsh.)
Attack tools were installed which resulted in the incidence System Distress (SDT).
(Here the attacker installed Trojan mstream DDoS software to carry out DDoS
from the victim hosts.)
Disclosure of Service
(DSV) Incident
Incident Phases
6
5
System Environment
Corruption (SEC)
Incident
4
3
System Seizure (SSZ)
Incident
2
1
0
40000
45000
50000
55000
60000
System Distress (SDT)
Incident
TimeLine (HHMMSS)
Fig. 6. Correlated Alerts depicting DDoS Attack Scenario
According to DARPA documentation [7], there are two additional phases in the
coordinated attack and these were not reported by the FCM model. In DDoS 1.0, the
attacker first conducted an IPSweep of the network from a remote site. Since the
sensor RealSecure missed this alert, consequently our model was unable to analyze
the corresponding alert data. Ning et al. report this same problem during their
experiments with the DARPA data [8]. This highlights the fact that effectiveness of
any high level analysis of sensor data is largely dependent on the quality of the sensor
data itself. The final phase of the DDoS attack concerns launching of the Stream_DoS
attack itself, which was also missed by the model. The reason is that our model is
resource-centric and therefore, concentrates on communications to/from legitimate
hosts in the network. Since this final DDoS attack was launched from a spoofed IP
address and targeted a host outside of the network, our model did not consider the
corresponding communication for analysis. However, it does not severely affect the
alert situation awareness for the network because the critically significant System
Distress incidence inherently places the concerned system under severe alert.
A Cognitive Model for Alert Correlation in a Distributed Environment
227
To show the alert correlation capability of our model, we use correlation
performance metrics suggested by Qin and Lee [10]. Table 1. denotes the alert
correlation results. We refer to the DARPA documentation to determine the number
of causal relationships in data. It should be noted that the information in the table
concerns only the correlated alerts in the sensor report. The abbreviations used in the
table are the following:
SA: Sensor reported alerts, CR: Causal Relationships, CA: Correlated Alerts, CCA:
Correctly Correlated Alerts, ICA: Incorrectly Correlated Alerts, MA: Missed Alerts,
ARR: Alert Reduction Rate, TCR: True Causality Rate, FCR: False Causality Rate.
The values in the Dataset column designate the following: 1: DDoS 1.0 Inside Zone,
2: DDoS 1.0 DMZ Zone, 3: DDoS 2.0.2 Inside Zone, and 4: DDoS 2.0.2 DMZ Zone.
Table 1. Correlation Performance of the FCM Model
D
a
ta
se
t
1
SA
C
R
CA=
CCA+
ICA
922
44
43
2
891
57
3
489
4
425
CCA
ICA
MA
=
CRCA
41
2
3
58
55
3
16
11
11
6
4
4
ARR=
(1-CA/
SA)
TCR=
CCA/CR
FCR=
ICA/CA
95.33%
93.18%
4.65%
1
93.49%
96.49%
5.17%
0
5
97.75%
68.75%
0%
0
2
99.06%
66.67%
0%
Ning et al. conducted alert correlation and reported experimental results on the
same datasets using hyper-alert correlation graphs [8]. The work we present here is
primarily different from Ning et al.’s work in the technique used. In [8], the authors
refer to correctly correlated alerts as true alerts and report the following true alerts for
the datasets: (1: 41, 2: 54, 3: 10, and 4: 3). Here we refrain from comparing our results
to theirs because of the differences in the way we consider and count truth. For
example, in counting causal relations in data we include alerts for telnet sessions that
were initiated by an attacker in preparation for installing DDoS tools in the
compromised hosts [7]. Every telnet session generated three alerts by RealSecure:
Telnet Terminal Type (TTT), Telnet Env_All (TEA) and Telnet XDisplay (TXD). In the
FCM model, TTT, TEA alerts are generalized to InformationLeakage CEvent, which
does not generate any incidence that is part of a coordinated attack such as in fig. 3.
Since we generalize TXD to SuspiciousTransferActivity (because this alert denotes
actual initiation of a remote session), our model is able to correlate this alert to be part
of the attack scenario. Therefore, we count the number of causal relations as 44 (the
same 41s reported by Ning et al. in [8] plus three more for one telnet session). We
also include two of the telnet alerts (TTT and TEA) as missed alerts along with the one
for Stream_DoS. For dataset 3, the number of missed alerts is five (four for two telnet
sessions plus one more for Stream_DoS). As we consider the missed alerts as false
negatives, Table 1. shows that the TCRs we report are better for scenario one than for
228
A. Siraj and R.B. Vaughn
scenario two. Also, our model incorrectly correlates two alerts in dataset 1 which are
the FTP_Syst and Email_Almail_Overflow alerts generated for host 172.016.113.148.
In dataset 2, in addition to the same two false positives as in dataset 1, there is an
additional one for UDP_Port_Scan alert for host 172.016.112.050. While correlation
of these alerts is justifiable but since this is not mentioned in the DARPA
documentation [7], we count them as false positives.
A significant advantage of using alert correlation is reduction of alert volume
such that the security administrator is not overwhelmed with a large volume of alert
data. Table 1. also shows the effectiveness of our approach in reducing alert volume
in terms of correlated data (i.e., data that are part of multi-staged attacks).
The ultimate goal of the FCM model is to provide the security administrator with
a condensed view of the system in terms of the resources that are affected in alert
situations and also their involvement in such situations by reporting their incidents
strengths and incidence alert levels. Therefore, our model also reports overall
situation of the hosts that are under alert and not just in terms of the alerts themselves.
Fig. 7 is a snapshot of the alert situation discovered for the compromised host mill
(172.016.115.020) in the coordinated multi-staged attacks as captured in all four
datasets. Here the x-axis shows the incident strengths of the incidents that were
activated for this host and y-axis shows the underlying dataset the analysis is based
upon.
DHS
DSV
SEC
SSZ
DataSets
0.268
4
0.020
3
0.020
SDT
0.804
0.673
1
0.000
37.6%
0.100
0.804
0.673
0.935
75.0%
0.100
0.321
2
Incidence
Alert Leve l
0.820
0.100
0.820
0.100
0.200
0.400
0.600
0.800
0.964
0.940
0.988
0.964
0.940
54.3%
93.8%
1.000
Incident Strengths
Fig. 7. Alert Situation for Host 'mill'
One can observe from fig. 7 how the existence of the intruder’s action (that causes
the incidence) and the existing risks (that give rise to possibility of incidence) jointly
affect the strength of the incidence itself. For example, the SystemEnvironment
Corruption (SEC) incidence for mill has a high strength of 0.94 for scenario one
(dataset 1 & 2) and a moderate strength (0.673) for scenario two (dataset 3 & 4). This
is because for scenario two, the attacker used more sophisticated probing technique
(DNS_HInfo), which was not reported by the network sensors and therefore, no
preceding EEvents were generated for the host mill that had the potential to place mill
under risk of SEC. Consequently, as mill was under no initial risk of SEC, the
incidence SEC activated with lesser strength. Fig. 7 also shows the total incidence
A Cognitive Model for Alert Correlation in a Distributed Environment
229
alert levels for mill for each of the datasets. It is highest in dataset 1 (because of
activation of almost all incidents in correlation chain) and lowest in dataset 4 (because
of absence of most detrimental incidents, such as SystemDistress). Table 2. denotes a list
of the compromised hosts for all the datasets along with their incidence alert levels. The
shaded rows show four hosts that we report as compromised but were not listed as
compromised according to the DARPA documentation [7]. The attacker tried to
compromise these hosts by exploiting the system vulnerabilities but the attempts were
unsuccessful. Since the sensor cannot report on the success of these alerts, we justifiably
correlate them. However absence of any further activity for these hosts result in low
incidence alert level (25.4%) for them. With effective threshold schemes, it is possible
to avoid these false positives (e.g., acceptable IAL level with threshold 33%).
In our experiments with the DARPA scenario specific dataset we were able to
discover the multi-staged attack scenarios successfully, reduced the alert volume
significantly and also reported extent of involvement of the compromised resources in
the coordinated attacks.
Table 2. Incidence Assessment for Compromised Hosts
Dataset
# of Compromised
Hosts Reported in
Correlated Data
1
4
2
7
3
2
4
1
Hosts
172.016.112.010
172.016.112.050
172.016.115.020
172.016.113.148
172.016.112.010
172.016.112.010
172.016.112.050
172.016.113.148
172.016.114.010
172.016.114.020
172.016.114.030
172.016.112.050
172.016.115.020
172.016.115.020
Incidence
Alert Level
(IAL)
93.8%
93.8%
93.8%
25.4%
54.3%
54.3%
54.3%
25.4%
25.4%
25.4%
25.4%
75.0%
75.0%
37.6%
5 Conclusion and Future Work
In this paper, we described the use of cognitive modeling of cause and effect
relationships to correlate alerts in a distributed environment. We used scenario
specific DARPA 2000 dataset for our experimentations as an initial effort to evaluate
the effectiveness of our alert correlation model. The results show potential for this
simple but effective approach in alert correlation and in incident assessment. The
limitations of this approach include inability to deal with unknown alerts and
mapping requirement of sensor alert types into generalization hierarchy. A misuse
type sensor would miss unknown/unfamiliar attacks and since our knowledge base
depends on the sensors’ knowledge, so would we. Although our approach requires
230
A. Siraj and R.B. Vaughn
knowledge of attack behavior in terms of its impact, the use and encoding of this
knowledge is straightforward. We have found FCMs to be particularly suitable in
dynamic environment as they are flexible enough to capture adaptive nature of human
knowledge. Currently, we are in the process of simultaneously generating multisensor data from the DARPA 2000 dataset to demonstrate usefulness of our approach
in improving alert correlation by corroborating evidences in multi-sensor
environment. Our ongoing research concentrates on developing a unified alert fusion
model which will combine alert prioritization, alert clustering and alert correlation in
a single framework and can be used to provide a security administrator with a better
overall understanding of the health of the system resources. Also, we are developing a
model that will be suitable for a high performance computing (HPC) cluster
environment where assurance issues must not severely affect performance, which is
the essence of HPC environment. In near future, we will experiment in the cluster
environment with simulated cluster specific attacks.
References
1. D. Brubaker, “Fuzzy Cognitive Maps,” EDN Access, Apr. 1996.
2. Internet Security Systems, “RealSecure Network 10/100,”
http://www.iss.net/products_services/enterprise_protection/rsnetwork/sensor.php (current
January 30, 2005).
3. K. Julisch, “Mining Alarm Clusters to Improve Alarm Handling Efficiency,” Proceedings:
17th Annual Computer Security Applications Conference (ACSAC'01), New Orleans, LA,
December 10 - 14, 2001.
4. B. Kosko, “Fuzzy Cognitive Maps,” International Journal of Man-Machine Studies, vol.
24, 1986, pp. 65-75.
5. B. Kosko, Neural Networks and Fuzzy Systems: A Dynamical Systems Approach to
Machine Intelligence, Prentice Hall, Englewood Cliffs, NJ, 1992.
6. B. Kosko, Fuzzy Engineering, Prentice Hall, Upper Saddle River , NJ, 1997.
7. M.I.T Lincoln Laboratory, “2000 DARPA Intrusion Detection Scenario Specific Data
Sets,” http://www.ll.mit.edu/IST/ideval/data/2000/2000_data_index.html (current January
30, 2005)
8. P. Ning, Y. Cui, and D.S. Reeves, “Constructing Attack Scenarios through Correlation of
Intrusion Alerts,” Proceedings: ACM Conference on Computer & Communications
Security, Washington D.C., WA, Nov. 2002.
9. P. Ning, “TIAA: A Toolkit for Intrusion Alert Analysis,”
http://discovery.csc.ncsu.edu/software/correlator/ current January 30, 2005).
10. X. Qin, and W. Lee, “Statistical Causality Analysis of INFOSEC Alert Data,”
Proceedings: Recent Advances in Intrusion Detection, Pittsburgh, PA, Sep. 2003.
11. A Siraj, S.M. Bridges, and R.B. Vaughn, “Fuzzy Cognitive Maps for Decision Support in
an Intelligent Intrusion Detection System,” Proceedings: International Fuzzy Systems
Association/ North American Fuzzy Information Processing Society (IFSA/NAFIPS)
Conference on Soft Computing, Vancouver, Canada, Jul. 2001.
12. J.Q. Xin, J.E. Dickerson, and J.A. Dickerson, “Fuzzy Feature Extraction and Visualization
for Intrusion Detection,” Proceedings: FUZZ-IEEE, St. Louis, MO, 2003.
13. D. Yu and D. Frincke, “A Novel Framework for Alert Correlation and Understanding,”
Proceedings: International Conference on Applied Cryptography and Network Security
(ACNS), Yellow Mountain, China, 2004.