Visual Correlation of Network Alerts

Visualization for Cybersecurity
Visual
Correlation of
Network Alerts
Stefano Foresti, James Agutter,
Yarden Livnat, and Shaun Moon
University of Utah
Robert Erbacher
Utah State University
ociety’s dependence on information systems has made cybersecurity an increasingly important issue. Computer networks transport
financial transactions, sensitive government information, power plant operations, and personal health information. The spread of malicious network activities
poses great risks to the operational integrity of many
organizations and imposes heavy economic burdens on
life and health.
Of particular concern is the identification of sophisticated attacks. Naive attacks are easily detected and have
small likelihood of success—for
instance, system administrators and
network analysts aren’t very conThe VisAlert visual
cerned with script kiddies or unsophisticated vulnerability exploits
correlation tool facilitates
because intrusion detection systems
(IDSs) readily detect them. Port
situational awareness in
scans are another example. These
attacks try to identify the services
complex network
running on a system by sending network packets to that service (a specenvironments by providing
ified network port). A naive scan
uses simple TCP connect packets
a holistic view of network
sent as quickly as possible. An IDS
can easily detect port scans because
security to help detect
of their close proximity in time and
high volume. Sophisticated attacks
malicious activities.
are harder to detect because they
use stealthy mechanisms and more capable techniques.
A sophisticated port scan can use alternatives to TCP
connect packets or dilute the scan over time such that
there is a delay of 0.4 seconds, 15 seconds, 5 minutes, or
even longer between packets. This delay prevents easy
algorithmic identification and can cause activities to be
lost in the noise.
IDSs analyze network traffic and host-based processes in an attempt to detect malicious activity. When they
identify anomalous activity or activity matching known
malicious activity, these systems generate an alert to
notify the administrators or analysts of their impending
doom. Each alert identifies the threat type using the
alert type classification system. IDSs often store these
alerts in stove-piped databases that aren’t easily corre-
S
48
March/April 2006
lated to other alerts or logs on the network. Thus, network analysts must use a myriad of tools that show different information in different formats, making it
difficult for them to gain an overall understanding of
the network’s security status. The high rate of false positives that these systems generate compounds this complexity.
Because attacks are dynamic, if analysts can’t absorb
and correlate the available data, it’s difficult for them to
detect sophisticated attacks. Developing tools that
increase the situational awareness and understanding of
all those responsible for the network’s safe operation
can increase a computer network’s overall security. System administrators are typically limited to textual or
simple graphical representations of network activity
(Bejtlich1 describes many available capabilities and their
applications).
Information visualization techniques and methods in
many applications have effectively increased operators’
situational awareness, letting them more effectively
detect, diagnose, and treat anomalous conditions.2 A
growing body of research validates the use of visualization to solve complex data problems3-5 (see the “Previous
Work” sidebar). Visualization elevates information comprehension by fostering rapid correlation and perceived
associations. To that end, the display’s design must support the decision-making process: identify problems,
characterize them, and determine appropriate responses. It must also present information in a way that’s easy
for the user to process. Our visualization technique integrates the information in log and alert files into an intuitive, flexible, extensible, and scalable visualization
tool—VisAlert—that presents critical information concerning network activity in an integrated manner,
increasing the user’s situational awareness.
Objectives and assumptions
We based our research and development on several
premises to ensure that visualization for cybersecurity
reflects the needs of operational environments. In general, the visualization techniques must be scalable,
robust, and effectively and intuitively represent the data
and relationships that are relevant to decision making.
The objective is to overcome the limitations of existing
Published by the IEEE Computer Society
0272-1716/06/$20.00 © 2006 IEEE
Previous Work
Historically, visualization has been applied to network
monitoring and analysis, primarily for monitoring network
health and performance. Initial visualization techniques for
intrusion detection system (IDS) environments focused on
simple scales and color representations to indicate state or
threat level. The need for better analysis mechanisms for
security and IDS-related data has motivated the exploration
of more advanced visualization techniques. Many of these
techniques effectively visualize malicious activities such as
worm or denial-of-service (DoS) attacks. However, these
visualization techniques tend to focus on specific problems
rather than general alert correlation for an entire enterprise.
Other techniques have focused on visual pattern
matching⎯that is, the representation of known attacks.
Teoh et al.1,2 analyze worms and other large-scale attacks
on Internet routing data. Similarly, McPherson et al.3
developed a technique for visualizing port activity that’s
geared toward monitoring large-scale networks for naive
port scans and DoS attacks.
Yin et al.4 and Lakkaraju et al.5 focus on representing
netflows and associated link relationships. Such techniques
are critical for analyzing attacks and IDS data, but they
quickly suffer scalability issues and are limited as to the
number of representable parameters.
Wood6 describes basic graph-based visualization
techniques, such as pie charts and bar graphs, and how
analysts can apply them to typical network data available to
all system administrators. This work describes how users can
implement visualization and apply it to such data, as well as
the meaning behind the identified results. The technique is
limited only in the visualization’s simplicity, which currently
can’t analyze the high-volume, high-dimensional data
generated by today’s environments. This remains a major
challenge for IDS data analysis in general.
Traditional representations and network alert-reporting
techniques tend to use a single sensor-single indicator
display paradigm. Each sensor uniquely represents its
information (indicator) and doesn’t depend on information
cybersecurity tools and visualizations that focus on narrow problems, work on small data sets, or don’t effectively map to the human visual and decision-making
processes. To this end, our premises include:
■ Analyst involvement. We worked with security ana-
lysts with experience in large government networks.
Their continual interactive involvement has ensured
our work’s value and validity and thus a good fit
between problem and solution, based on user needs.
■ Realistic data. We developed a realistic scenario to validate the design and used simulated data for testing.
■ Data size and completeness. The visualization handles
an organization’s subnets and hosts, numerous data
sets, and disparate relationships across multiple logs.
Our scalability solution has widespread applicability
in visualization research.
■ Holistic view. Providing a visual holistic view of the
network’s status—the least fulfilled need in state-of-
gathered by other sensors. The benefit of such an approach
lies in the separation of the various sensors. The user can
thus optimize each sensor’s indicator for the data it
produces, and then can choose which sensors to use in an
analysis. Furthermore, the failure of one sensor doesn’t
impact the rest of the system’s capability.
Consequently, the separation between sensors is also the
weakness of this representation technique. Because each
indicator is isolated, the user must observe, condense, and
integrate information generated by the independent sensors
across the entire enterprise. This process of sequential,
piecewise data gathering makes it difficult to develop a
coherent, real-time understanding of the interrelationship
between the information being displayed⎯particularly the
identification of malicious attacks.
References
1. S. Teoh et al., “Case Study: Interactive Visualization for Internet
Security,” Proc. IEEE Conf. Visualization, IEEE CS Press, 2002, pp.
505–508.
2. S. Teoh, K. Ma, and S. Wu, “Visual Exploration Process for the
Analysis of Internet Routing Data,” Proc. IEEE Conf. Visualization,
IEEE CS Press, 2003, pp. 523–530.
3. J. McPherson et al., “Portvis: A Tool for Port-Based Detection of
Security Events,” Proc. CCS Workshop Visualization and Data Mining for Computer Security, ACM Press, 2004, pp. 73-81.
4. X. Yin et al., “Vis-Flowconnect: Netflow Visualizations of Link Relationships for Security Situational Awareness,” Proc. CCS Workshop
Visualization and Data Mining for Computer Security, ACM Press,
2004, pp. 26-34.
5. K. Lakkaraju, W. Yurcik, and A. Lee, “NVisionIP: Netflow Visualizations of System State for Security Situational Awareness,” Proc.
CCS Workshop Visualization and Data Mining for Computer Security, ACM Press, 2004, pp. 65-72.
6. A. Wood, Intrusion Detection: Visualizing Attacks in IDS Data, Global Information Assurance Certification (GIAC) Practical, SANS Inst.,
2003.
the-art technology—helps analysts quickly decide
how pervasive and severe problems are, and how to
direct further attention.
■ Environment extensibility. We gave users the ability to
add new data sources, alert types, attack signatures,
and data views, as well as to enrich the visualization
with user suggestions.
Our goal is to aid analysts’ decision making by providing a visual correlation mechanism. We don’t try to
solve the entire intrusion-detection problem, nor do we
aim to make decisions for the user.
Interdisciplinary design process
We employed a user-centered interdisciplinary
methodology6 for developing information displays that
promotes design as a function of human behavior and
interaction between subject and object. We drew our
research techniques from several disciplines, including
IEEE Computer Graphics and Applications
49
Visualization for Cybersecurity
solid task analysis at the onset tend to be consistently
more useable, lead to better human performance, and
require less training.10
In the study, we used the knowledge of intrusiondetection analysts, network administrators, and security-assessment professionals. The goal of the analysis is
to ensure that the intended users will find the visualizations meaningful and intuitive, identify the components
from a list of alternatives, and extract useful information from the domain-specific design.
To achieve an understanding of the user’s mental
model, we
Analysis
Problem space analysis
Team
Mental model analysis
Refinement
Data analysis
Design
Conceptual representation scheme
Information
architecture
Scenario representation
Usability testing
Design evaluation protocol
Implementation
Computer
science
Refinement
Team
■ performed background analysis, including a litera-
Refinement
User interaction
Technical representation assessment
ture review and informal consultations with
researchers;
■ conducted semistructured interviews with administrators, security analysts, and decision makers;
■ made unstructured naturalistic observations of problem solving; and
■ organized and reported the data into workflow diagrams.
During the domain analysis, we attempted to gain
understanding in these key areas:
Prototype development
■ rules of thumb or tricks of the trade that guide rea-
soning;
Cognitive
psychology
Formal testing
■ empirical knowledge gained by experience, drawing
High-fidelity simulation
■ expert’s overall model of the problem; and
■ tasks, including control, prediction, diagnosis, plan-
on laws and relationships;
ning, monitoring, instruction, and interpretation.
Company
Success
1 Interdisciplinary design methodology using techniques from
cognitive psychology, architecture and design, and computer
science.
architecture, cognitive psychology, and computer science
(see Figure 1). We loosely based our design approach on
Snodgrass and Coyne’s hermeneutical circle concept,7
which is an iterative process of implementing a design,
learning and understanding from discussion and feedback, and subsequently refining the design.
Domain analysis
Our domain analysis study aims to identify the most
important objects and operations in the chosen domain,
these objects’ attributes, the relationships among
objects, and how people in the domain interact with
them.8 The result is a conceptual model representing
the system scenarios and the functional relationships
and criticality among variables, whether objective or
subjective (in the user’s mental model). This is necessary to design the software and the visual displays that
fulfill a group of people’s needs for a particular purpose.9
Systems that have been designed or modified with a
50
March/April 2006
We’ll submit the specifics of the procedure used for
domain analysis and the details of the cognitive analysis studies to a cognitive and human-factor studies publication.
Decision-making process
The domain analysis work identified six discrete steps
in the decision-making process. These steps identify critical areas where analysts need additional support, and
where visualization can provide the greatest benefit.
1. Identify an incident related to the computer network
that the individual is responsible for (that is, detect
that an incident occurred).
2. Evaluate the incident to see if it’s a benign alarm or
an indication that further investigation is needed
(that is, is the detected incident suspicious?).
3. Determine how prevalent the problem is and what
else is being affected. The analyst determines the
problem’s boundaries by analyzing other information to gain knowledge about the problem’s criticality. Analysts also explore what other machines are
experiencing these problems.
4. Drill down data to identify patterns and test hypotheses. The analyst tests multiple hypotheses with
detailed information about the questionable matter.
5. Report and mark results to communicate information to others. After identifying a problem, the ana-
Network flow data
Size
Protocol
Port
IP
address
Heuristic
knowledge
External
information
Hint from Jonzy: 20 suspicious
source IP’s sending too much
email
Query: view 20 suspicious
source IP’s flow data
Suspicious source IP isolated by
previous experience; others were
legitimate
Contacts suspicious source
IP user
Check suspicious source
IP flow
Destination IP not in use
Machine is probably
compromised and sends large
amounts of email
Port scan on suspicous IP:
blocked by firewall
Check protocols used by
suspicious source IP
Discovers protocols not
frequently used
Internet storm center states
protocol is increasingly
dangerous
Will check change tomorrow;
will repeat process
2
A portion of the network analysts’ workflow diagram resulting from the domain analysis.
lyst records and describes it within the larger context.
6. Direct a response. The analyst directs the responsible individuals to respond appropriately to the
problem.
Figure 2 shows the workflow diagram section resulting from the domain analysis. These workflow diagrams
help designers determine the most relevant information
to visualize different stages of the decision-making
process.
their network of responsibility. The source IP might
become an object of interest and investigation after
they detect a problem.
■ Detecting potentially dangerous attacks requires the
query and correlation of enterprise-wide large data
sets. Users want access to all sorts of data, but need
the capability to filter and remove clutter.
Our findings provided guidelines and priorities for
designing the visualization.
Visualization design
Relevant factors in data analysis and user
requirements
The domain analysis work also let us identify the data
analysis priorities and process. Our relevant findings
include:
■ A false-positive alert shouldn’t appear correlated to
other alerts, but a sustained attack will likely raise
several alerts. Furthermore, real attack activities will
likely generate multiple alerts of different types.
■ Users need a primary view of the destination IPs in
The first step in the design phase is to develop a set of
visual metaphors and descriptors along with rules defining why, how, and where to use each descriptor. The
objective is to represent information by exploiting perceptual abilities innate to human beings and embedding
them into a set of objects’ graphic properties, behaviors,
and relationships. We use basic 2D and 3D design principles such as
■ mapping data values to 1D, 2D, and 3D geometrical
primitives;
IEEE Computer Graphics and Applications
51
Visualization for Cybersecurity
determined that alerts must possess what we term the
W3 premise: the when, where, and what attributes. This
concept lets us visually correlate multiple alerts.
When
■ When refers to the point in time at which the alert
occurred.
■ Where refers to the local network node—for example,
an IP address that the alert pertains to.
■ What refers to an indication of the alert type—for
example, ($log = snort, gid = 1, sid = 103$).
Where
What
3
The VisAlert W3 visualization concept: a line connecting an alert type
(what) at time (when) to a resource (where) represents an alert instance.
■ assigning graphic attributes such as color and texture;
■ using graphic associations such as proximity, loca-
tion, similarity, and contrast; and
■ assigning transformations such as changes in the
design geometry or organization.
For instance, the application of perceptual grouping
(using color, similarity, connectedness, motion, sound,
and so on) can facilitate the understanding of the relationships between individual pieces of data. Proper presentation of information also affects the speed and
accuracy of higher-level cognitive operations.
Modern human factors theory suggests that for effective data representation we must present information in
a manner consistent with the user’s perceptual, cognitive, and response-based mental representations. When
the information is consistent with cognitive representation, performance is often more rapid, accurate, and consistent. Conversely, failure to use perceptual principles
appropriately can lead to erroneous information analyses. It’s therefore imperative that we present information in a manner that facilitates the user’s ability to
process it and minimizes any mental transformations
that must be applied to the data. This qualitative filtering
and depiction of information toward achieving a clear
end essentially constitutes representation design.11,12
We typically correlate alerts based on their when or
what attributes. If we group the alerts based on their
what attributes, we correlate them within their groups
based on additional attributes associated with that
attribute. However, the alert’s real value relates to the
local resources it pertains to. Preserving the resources’
status and integrity is in fact an IDS’s main focus. The
alerts’ what and when attributes have little if any inherent value by themselves. Consequently, visually correlating alerts with respect to resources is the key factor of
this work. A discussion of prior work and issues of correlating alerts is available elsewhere.13
The need to correlate the who attribute is secondary
in the decision-making process. Using the W3 concept
lets us simplify the representation, considering the visual
clutter that would arise from such a huge domain as
remote IPs. We can thus concentrate on the local
resources, which are what analysts try to protect. However, we incorporate the who to obtain a full representation of who, when, where, and what (W4) using the
virtual log, which we describe later.
Visualization concept
Figure 3 shows our design layout, which maps an alert’s
where attribute into the center of the circle. We represent
this using a topology map of the network under scrutiny.
The layout maps an alert instance’s what attribute to
the different sections of the outside circular element.
This arrangement allows for flexibility with regard to
the number of alert types as well as easy integration of
new alert types.
The layout maps the when attribute of an alert
instance to the circle’s radial sections, moving from most
recent (closest to the topology map) to the least recent
as it radiates outward.
We can now visualize alert instances as lines from
ρ(what, when) → (angle, radius) on the outer ring, to
Ψ(where) → (x, y) in the inner circle, where ρ and Ψ are
general projections of the alerts into our two domains.
Our system lets the user dynamically control and configure these two projections as necessary.
To reduce the possible visual clutter when showing
all alerts simultaneously, we divide the when space into
varying intervals and show only the alert instances for
the most recent history period. The remaining history
periods show only the number of alert instances that
occurred during that period.
W3 concept
The main problem in correlating alerts from disparate
logs is the seeming lack of mutual grounds on which to
base any kind of comparison between alerts. We’ve
52
March/April 2006
Additional visual indicators
We incorporated additional visual indicators that
encode information to increase the user’s situational
awareness. In the design’s first iterations, we used color
to identify alert classifications. In current display implementations, color indicates that user-determined thresholds have been exceeded. For instance, red indicates
high priority, while green indicates low priority. We’ve
also adopted a method of increasing the icon size for
nodes experiencing several alerts. The assumption is
that a resource or node on the topology that’s experiencing multiple unique alerts from both host- and network-based sources has a higher probability of malicious
activity than one experiencing only one alert. A scan of
a particular machine is an example. Although the scan
might generate a Snort alert, the activity might be
benign; however, a standard IDS will catch this simple
probe and reject the traffic. If, on the other hand, a
machine is receiving a Snort alert in addition to a Windows log alert, that machine might be experiencing an
intrusion attempt or even a successful attack. The node’s
size is a clear indicator and easily distinguishes the node
from other machines, thus attracting the attention of
the user, who can correct the problem on the suspect
machine.
The alert beams encode a problem’s persistence. If
many of the same alerts are triggered on a particular
machine over a given time interval, the line thickens to
show the number of alerts (see Figure 4). In this manner,
continual or recurring problems quickly become evident, letting the user take swift action. A beam’s color
encodes the alert’s severity when available⎯for example, Snort associates a severity level with each alert.
Thus, more severe problems become immediately distinguishable from other alerts.
Visual filters
VisAlert provides many ways to filter the data to
reduce visual clutter or help network analysts focus
on particular events of interest. Users can turn the
alert beams on and off globally, resulting in small lines
indicating which alert has been triggered on the particular nodes using color and orientation. Users can
selectively turn particular alert beams on or off by
clicking the desired beam. Users can turn alert groupings and individual alerts on or off through a dialog
box. This can help users fine-tune the display to show
only alerts that are relevant and of high priority to
their organization, eliminating many instances they
would otherwise observe. In addition, users can filter
the data to show machines experiencing a certain
number of alert types, with specific IP ranges, experiencing the same alerts, or that have the same outside
IP associated with them or a particular alert.
Simulated attack scenario
We used a simulated attack scenario to validate the
display’s efficacy prior to implementation. The sequence
of the images in this scenario shows how a malicious
attack emerges out of the background noise in our visualization design, helping users to rapidly detect and identify the attack. The attacks consisted of exploiting a
vulnerable host to gain access to more secure machines.
A security assessment expert developed the scenario. He
generated an attack using different methods and broke
When
Where
What
4 VisAlert exhibiting multiple alerts and additional relevant visual indicators, including alert type using color coding, larger node size showing more
alert types, and larger beam size for persistence of a particular problem.
the attack into different stages. To add sufficient noise,
we fed this information into a data set polluted with
other network traffic. We characterize this scenario as
an external attacker with five distinct stages. During the
five stages, as it moves from normal network activity to
data exfiltration, the visualization will show how the
node under attack slowly emerges out of the background
because of the number of types of alerts it receives.
Stage 1: reconnaissance
Reconnaissance is the identification of hosts and services on a targeted network. This form of reconnaissance
often involves simple Web queries, social engineering,
and dumpster diving.
Figure 5 (next page) shows the network’s status during the reconnaissance stage. Given the attacker’s lack
of presence on the network, this can also be considered
normal network activity with multiple instances of Snort
alerts tripped at a particular time. In this initial attack
stage, the attacker is generally passive with respect to
the network. At this time, identifying an attack in the
noisy normal network activity is unlikely.
Stage 2: probe
In this context, a probe is an attacker’s attempt to
gather information about services on a targeted host or
hosts discovered during the reconnaissance phase. Analysts could see the Internet Protocol Communication
(IPC) violations during this phase because of a particular Snort alert that was tripped on a machine on their
IEEE Computer Graphics and Applications
53
Visualization for Cybersecurity
Checksum
-45
-35
-25
-15
-5
5
-0
Win
do
w
ev
en
ta
ler
ts
P
FT
ale
rt s
H TTP
a le r t s
Sn
ta
or
le
r
ts
5 In stage 1, the attacker is doing reconnaissance—that is, looking for
hosts and services on the network. VisAlert exhibits normal activity.
requirements. This often indicates a forged packet⎯
that is, an attacker created a packet not conforming to a
proper connection. This could indicate an attempt to
hijack a session, scan a system, or attack a vulnerability.
The line’s thickness indicates the persistence of the
same Snort alert over time. A persistent Snort alert
indicates its recurrence. This is typical of naive scans in
which an attacker begins scanning a sequence of ports
on a single or multiple machines. In this case, the
attacker has targeted a single host with a long-running
scan. Such a scan can not only identify what services
are running but can also potentially identify what version of the services are in use, as well as the version
of the operating system. An attackers can use this type
of detailed information to identify detailed vulnerabilities for known attacks—that is, it can identify a version of a service with a known buffer-overflow
vulnerability.
The environment’s extensibility lets the visualization
represent any alert, no matter what instrument generated it. In other words, if a new instrument generates
other types of alerts, VisAlert can directly incorporate
its results through a plug-in architecture.
Figure 6 shows a probe and a connection (correlation)
between the IPC interface (shown with a higher-priority Snort alert) and a Windows VMTools alert. Such a correlation between events indicates a progressing attack.
Stage 3: attack
Checksum
-45
-35
-25
-15
-5
5
-0
Win
do
w
ev
en
ta
ler
ts
P
FT
ale
rts
H TTP
a le rt s
Sn
ta
or
le
r
ts
6 In stage 2, the attacker probes the network. VisAlert exhibits persistence
of an alert on a host. Simultaneously, the attacker triggers a second alert
type.
network topology. An IPC violation occurs when a connection attempts to violate defined TCP or IP interface
54
March/April 2006
In this context, an attack on a vulnerable system is an
attempt to gain unauthorized access to a network host,
usually by exploiting a vulnerable network service. We
captured several attacks during this simulation.
The first attack was an attempt to access the vulnerable system by guessing the administrator password—
a common brute-force attempt to break into a system.
Computer logs indicate repeated failed passwords as
attempted logins.
The second attack exploited a vulnerability in the
Windows Local Security Authentication Subsystem Service. LSASS has a known buffer-overflow vulnerability
in several of its versions. Snort uses pattern recognition
to identify packets containing the compromised code
for this vulnerability and generates an alert on identifying such a packet. MS Windows uses LSASS for all
authentication, thus it appears in this attack multiple
times.
Figure 7 shows another attack, which involves generating heavy scanning activity on another host on the network as a diversion. Sophisticated attackers often create
noise to cover their tracks. Generating many alerts
through port scanning makes it far more difficult for an
analyst to pick out and identify the more noteworthy
alerts.
The heavy lines that emerge out of the background
represent two machines experiencing persistent indications of a scan.
Stage 4: dig-in
Dig-in is a catch-all term for describing actions taken
by an attacker that leverages newly gained privileges on
the compromised system. This could include download-
ev
en
ta
ler
ts
P
FT
ale
r ts
H TT P
a le r t s
le
rts
7 In stage 3, the attacker attempts to access a vulnerable system and
trigger multiple alerts on the host while diverting attention by heavily
probing another host.
Checksum
-45
-35
-25
-15
-5
5
-0
Win
do
w
ev
en
ta
ler
ts
P
FT
ale
rts
H TTP
a le r t s
Migration is a human attacker’s attempt to use a compromised system to attack other systems within the targeted network. Migration relies on the fact that the
attacker has gained access to a host on the secure side of
the firewall, and will be able to see hosts and services
not visible from an external host.
In this simulation, the attacker generated a successful attack on the victim, followed by a TFTP session to
download a toolkit, followed immediately by rapid scans
for other vulnerable hosts.
Figure 9 (next page) shows the correlation of these
almost simultaneous alert triggers of different kinds on
the same host, while other hosts have triggered alerts,
but of one kind. The node’s increasing size lets analysts
focus their attention on the host that’s actually being
attacked, while the divertive or normal activity remains
in the background, cause for lesser concern.
Win
do
w
ta
or
Stage 5: migration
Checksum
-45
-35
-25
-15
-5
5
-0
Sn
ing toolkits or modifying files on the compromised system to hide malicious activity. The end goal is installing
a rootkit, which will let the attacker gain easy access in
the future, cover his or her tracks, provide complete
access to all system resources, and let the attacker identify and attack additional systems using the just-compromised system as a jumping-off point.
In this simulation, the attacker generated a Trivial File
Transfer Protocol (TFTP) GET command, commonly
generated by compromised systems and using automated attack tools and worms. (This TFTP command is part
of the first LSASS attack described earlier.) The attack’s
goal here is to download the appropriate rootkit and the
attacker’s toolkit for use against other systems in the
network. The attack then redirected a Windows command prompt, followed by multiple TFTP GET commands. This redirection let the attacker execute
command from a file and subsequently download an
entire set of files in rapid succession.
Figure 8 illustrates this attack. In this stage, the
attacked node begins to expand, which might indicate
to a network analyst the need for action. The node’s size
indicates the number of alerts associated with that host.
A large number of distinct alerts suggests a progressing
attack.
Testing VisAlert
Sn
ta
or
To test our system’s capabilities with larger and more
complex data, we used a data set generated by Skaion
Corporation for use by the Intelligence Community,
Advanced Research and Development Activity (ICARDA) research projects. This data set, which contained
numerous disparate logs and alerts from various sensors and hardware, simulated attack scenarios in large
notional unclassified intelligence community environments. Because of the research’s sensitive nature, we
can’t provide additional details on the specifics of the
data or attack scenarios.
Figure 10 shows alerts for Snort, dragon, and firewall
logs. The firewall generated numerous alerts (blocked
traffic), but of only two types. On the other hand, the
Snort log had thousands of alert types but few were
actually triggered in the tests we present here. In con-
le
r
ts
8 In stage 4, the attacker attempts to access other systems, triggering
multiple alerts on the already compromised system.
trast, the dragon log provides a rich set of alerts, many
of which were triggered.
IEEE Computer Graphics and Applications
55
Visualization for Cybersecurity
Checksum
-45
-35
-25
-15
-5
5
-0
Win
do
w
ev
en
ta
ler
ts
P
FT
ale
r ts
H TTP
a le r t s
Sn
ta
or
le
r
ts
(a)
Checksum
-45
-35
-25
-15
-5
5
-0
Win
do
w
ev
en
ta
ler
ts
P
FT
ale
r ts
H TTP
a le r t s
Note the correlation between alerts from the dragon
(blue), Snort (green), and firewall logs (orange).
Figure 10c shows a large attack on many nodes. This
view includes the virtual log (top talker), which shows
the attack’s who attribute. These outside IPs show in
one view what alerts they’ve generated at what time and
on what local machine. Using this view, a user could easily see a distributed attack on one node on their system.
We deployed the VisAlert prototype at the Air Force
Research Lab (AFRL) in Rome, New York. We worked
with system analysts with a decade of experience and
network-wide responsibility for specific AFRL sites. Such
key analysts have been a focal point in our new technology’s development and the network data’s analysis.
In this installation, VisAlert generated a positive
response. Users specifically noted its effectiveness, simplicity, and flexibility. They stated that it might increase
situational awareness by letting them see a holistic view
of their network security status. AFRL staff want to integrate VisAlert with their tools because it lets them see
information that their systems might not currently identify. Specifically, they used VisAlert as a visualization
front end to demonstrate their Air Force Enterprise
Defense system to the US Department of Defense.
To a great extent, we’ve incorporated the analysts’
suggestions, resulting in a more usable and useful tool.
AFRL continues to evaluate the tool, and we incorporate analysts’ suggestions as we receive them. Evaluation and testing is scheduled at the Army Research Lab
and at the US National Security Agency.
We presented VisAlert at the Information Assurance
Workshop (Philadelphia, February 2005) and other
meetings where it was exposed to analysts and higherlevel officials within the intelligence community and
other organizations in the Department of Defense. They
expressed interest in performing formal testing in operational environments, including VisAlert in a software
bundle for their customers, and further developing the
tool, including its incident reporting functionality.
VisAlert features and limitations
Sn
ta
or
le
r
ts
(b)
9 In stage 5, (a) the attacker attempts to access a vulnerable system, triggering multiple alerts on that host, while diverting attention by heavily
probing another host; and (b) the analyst has filtered out activities of hosts
that aren’t of interest.
The images in Figure 10 show different examples of
the visualization in different scenarios. Figure 10a shows
normal traffic. A few machines are experiencing alerts;
however, the alerts are uncorrelated, as expected.
Figure 10b shows an attack on several local machines.
56
March/April 2006
The VisAlert software already has several interactive features allowing it to filter out or expand details, including
the implementation of virtual logs (see the “The Virtual
World” sidebar, pg. 58) and the level of detail of the when
and what attributes. In the when axis, VisAlert lets users
configure different time increments to explore potential
patterns at different time scales. In the what axis, VisAlert
software lets users collapse and expand alert groupings,
allowing varying detail levels in the log hierarchies.
In its current implementation, VisAlert’s ability to
interact with the where attribute space is limited. We’re
currently implementing automatic topology generation,
which is a priority for testing in different environments.
Future research includes detail level in the topology display and the representation of dynamic networks.
We distilled the domain analysis underpinning
VisAlert’s visualization concept into a decision-making
process that’s common among many of the analysts we
observed. However, VisAlert might be limited in its ability to, or inappropriate for, enhancing some problem
types experienced by certain analysts and organizations.
Future work
Ongoing and future work is in several areas. First, we
plan to design additional visualization structures to let
analysts perform analysis and hypothesis testing of alert
details, and to let decision makers view incident reports
(the VisAlert system will evolve in a visual continuum
to allow seamless transition from a holistic view of the
system to detail drill-down).
We’ll also develop feature enhancements to let users
encode and correlate their own alert algorithms, and
enhanced capabilities for selecting and displaying detail
level. In addition, we’ll deploy VisAlert in an operational
environment.
Finally, we’ll perform formal testing—that is, measure
performance with respect to existing tools on equivalent
scenarios—in a simulated environment. Formal testing
of VisAlert will show whether VisAlert improves recognition and identification of a compromised computer network or workstation. We’ll use various simulated network
states, both threatened and nonthreatened, to assess the
visualization tool’s applicability. We’ll test users individually in two experimental sessions, counterbalancing network conditions to control for order effects.
We also hypothesize that the visualization tool will
reduce analysts’ workload, as workload assessments measured by NASA’s task load index tool should indicate. We
believe the anticipated difference in workload will derive
from the integrated and intuitive presentation of information afforded by the visualization tool.
■
(a)
Acknowledgments
We thank the network security experts and managers
from Battelle, the AFRL, and the University of Utah (Information Security Office, NetCom, Center for High Performance Computing, and Scientific Computing and Imaging
Institute), who significantly contributed to the domain
analysis work. We also thank AFRL and NSA for hosting
tests of the VisAlert system, and to the Skaion Corporation and IC-ARDA for providing us with their attack simulation data set. Special thanks to Jeff Thomas for creating
the simulated attack described in this article, Kirsten Whitley for providing valuable feedback and access, and Marty
Sheppard for providing continuous feedback and suggestions on the technology development.
A grant from the IC-ARDA (with contracting and technical management by AFRL Information Directorate)
and the Utah State Center of Excellence Program partially supported this work.
(b)
References
1. R. Bejtlich, The Tao of Network Security Monitoring: Beyond
Intrusion Detection, Addison-Wesley Professional, 2004.
2. E. Tufte, The Visual Display of Quantitative Information,
Graphics Press, 1983.
3. K. Lakkaraju, W. Yurcik, and A. Lee, “NVisionIP: Netflow
Visualizations of System State for Security Situational
Awareness,” Proc. CCS Workshop Visualization and Data
Mining for Computer Security, ACM Conf. Computer and
Comm. Security, ACM Press, 2004, pp. 65-72.
(c)
10
Visualization of alerts. (a) Normal activity. (b) Attack on specific
machines. A purple color log represents the attack’s who attribute. (c)
Multiple attacks on many machines and a firewall blocking a scan activity.
IEEE Computer Graphics and Applications
57
Visualization for Cybersecurity
The Virtual World
To expand the domain over which VisAlert operates, we
introduce the notion of a virtual world—that is, a domain of
information or metadata about the logs and alerts stored in
the database. In accordance with our general approach, we
don’t generate new alerts based on alerts in the database.
Other intrusion detection systems (IDSs) perform data
mining and create new types of logs and alerts. The key
difference is that these IDSs generate persistent data that
are stored in a database. Our virtual world extension is
temporary. The information is gathered on the fly, depends
on the current user setup, and isn’t archived.
Virtual alerts
A virtual alert represents any kind of information that
occurs during a particular time period and can be gathered
from the alerts. We call this information an alert because we
provide it to VisAlert via the regular alert mechanism. For
example, a key issue raised by the analysts we collaborated
with is the notion of top talkers. In the context of our
discussion, top talkers are nodes outside the installation that
generate the most alerts during a specific time period (for
example, the most recent history period or the innermost
ring). Obviously, such information can be computed and
gathered in the database, but it isn’t explicitly stored or
computed ahead of time.
To facilitate this talkalot example, we define new alerts
whose type indicates a remote machine. The alert contains
the number of alerts that the remote node generated in the
specified time period with respect to our local nodes. Given
a specific time period, we aggregate the alerts in the
database based on the remote machine, sort them based
on the number of alerts per machine, and then select the
top 10 talkers.
Virtual views
The top talkers in particular, and the virtual alerts in
general, extend the model domain and increase the
number of alert types. As such, we can use the same
presentation methods we applied to the regular persistent
alerts, such as hierarchical grouping and multiple views.
For example, we can group the top talkers based on their
IP addresses, or, if we list the top 100 talkers, we can
organize them in groups of 10. We can also use a view in
which we place the top talkers in order along the circle
based on the number of alerts. The problem with this
approach is that in the likely event that a top talker in a
particular time period is also one of the top talkers in the
next period, the relative position might differ. In this case,
the user might lose track of the top talker and not notice
the problem’s persistence.
An alternative view might consider the top talkers in the
previous time period. Once a top talker is assigned a
position around the circle, it stays in that position for as
long as it’s part of the top-talker group. This approach
provides consistency, but requires the user to notice when
the top talker drops out of the top group and is replaced by
a new top talker. To help the user notice such changes, we
add a dark red background to the top talker’s name (its IP
address). If the top talker remains in place after the next
clock cycle, the background becomes brighter, signaling
this top talker’s persistence.
We can also ask for the top talkers with respect to the
number of types of alerts (signatures) these remote
machines triggered rather than the number of alerts they
generated. In this case, the top talker definition differs (total
number of alerts versus number of unique signatures) and
thus these two views are essentially two different (virtual)
logs. However, because these virtual logs represent two
views of the same concept (top talker), we can regard them
as two views of a single log.
W4 and top talkers
Top talkers are an example of how to correlate relevant
who attribute information, thus filtering the immense
source IP data set. The who information might also be of
interest when requesting event details: the source IP can be
included in a pop-up display.
4. K. Vicente, K. Christoffersen, and A. Pereklita, “Supporting Operator Problem Solving through Ecological Interface Design,” IEEE Trans. Systems, Mass, and Cybernetics,
vol. 25, 1995, pp. 529-545.
5. J. Agutter et al., “Evaluation of a Graphic Cardiovascular
Display in a High Fidelity Simulator,” Anesthesia and Analgesia, vol. 97, 2003, pp. 1403-1413.
6. J. Bermudez et al., “Interdisciplinary Methodology Supporting the Design Research & Practice of New Data Representation Architectures,” Proc. European Assoc. for
Architectural Education/Architectural Research Centers Consortium (EAAE/ARCC) Research Conf., Dublin Inst. of Technology, 2004, pp. 223-230.
7. A. Snodgrass and R. Coyne, “Models, Metaphors, and the
Hermeneutics of Designing,” Design Issues, vol. 9, no. 1,
1992, pp. 56-74.
8. D. Monarchi and G. Puhr, “A Research Typology for Object-
58
March/April 2006
9.
10.
11.
12.
13.
Oriented Analysis and Design,” Comm. ACM, vol. 35, no.
9, 1992, pp. 35-47.
R. Priéto-Díaz, “Domain Analysis: An Introduction,” ACM
Sigsoft/Software Eng. Notes, vol. 15, no. 2, 1990, pp. 47-54.
W. Zachary, J. Ryder, and J. Hicinbothom, “Building Cognitive Task Analyses and Models of a Decision-Making
Team in a Complex Real-Time Environment,” Cognitive
Task Analysis, Lawrence Erlbaum Assoc., 2000, pp. 365384.
C. Ware, Information Visualization: Perception for Design,
Morgan Kaufmann, 2000.
A. Triesman, “Preattentive Processing in Vision,” Computer Vision, Graphics, and Image Processing, vol. 31, 1985, pp.
156-177.
Y. Livnat et al., “A Visualization Paradigm for Network
Intrusion Detection,” Proc. IEEE Workshop Information
Assurance and Security, IEEE CS Press, 2005, pp. 92-99.
Stefano Foresti is cofounder and
director of the Center for the Representation of Multi-Dimensional Information (CROMDI), senior scientist at the
Center for High-Performance Computing at the University of Utah, and president of Intellivis. His research interests
include visualization, user-interaction
design, security, distributed computing, intellectual property, and technology commercialization. Foresti has a doctorate in mathematics from the University of Pavia, Italy.
Contact him at [email protected].
James Agutter is an assistant
research professor in the College of
Architecture + Planning, University of
Utah, and assistant director of CROMDI. His research interests include
information visualization, human–
computer interaction, user interface
design, and technology transfer. Agutter has an MS in architecture from the University of Utah.
Contact him at [email protected].
Yarden Livnat is a research scientist at the Scientific Computing and
Imaging Institute at the University of
Utah. His research interests include
visual analytics with emphasis on situational awareness, scientific visualization, and software common components architecture. Livnat has a
PhD in computer science from the University of Utah. Contact him at [email protected].
Robert Erbacher is an assistant
professor in the Computer Science
Department at Utah State University.
His research interests include computer security, intrusion detection, computer forensics, data visualization,
and computer graphics. Erbacher has
an ScD in computer science from
the University of Massachusetts-Lowell. Contact him at
[email protected].
Shaun Moon is a research assistant
at CROMDI and is pursuing an MS in
computational design at Carnegie
Mellon University. His research interests include communication design
and information visualization. Moon
has a BS in architectural studies from
the University of Utah. He is a student
member of the IEEE and the Information Architecture Institute. Contact him at [email protected].
For further information on this or any other computing
topic, please visit our Digital Library at http://www.
computer.org/publications/dlib.
Join the IEEE Computer Society
online at
www.computer.org/join/
Complete the online application and get
• immediate online access to Computer
• a free e-mail alias — [email protected]
• free access to 100 online books on technology topics
• free access to more than 100 distance learning course titles
• access to the IEEE Computer Society Digital Library for only $118
Read about all the benefits of joining the Society at
www.computer.org/join/benefits.htm
IEEE Computer Graphics and Applications
59