Correlation between NetFlow System and Network Views ... - CiteSeerX

Correlation between NetFlow System and Network Views for Intrusion Detection∗ Cristina Abad†‡

Yifan Li†‡

Kiran Lakkaraju†‡

Xiaoxin Yin†‡

William Yurcik†

†

‡

National Center for Supercomputing Applications (NCSA) Department of Computer Science, University of Illinois at Urbana-Champaign {cabad,yifan,kiran,xiaoxin,byurcik}@ncsa.uiuc.edu

Abstract

neer to have to explain to less experienced users how an attack affects the network. Less experienced users might get lost very easily by trying to analyze raw logs (or even IDS alerts). Visual tools could help these users get acquainted with the organization’s network and help them in visually spotting intrusions or unusual activity (e.g. hosts that are consuming a lot of bandwidth). In this paper we show how information from two visual tools, VisFlowConnect and NVisionIP, can be correlated and used to easily identify several network anomalies. As described in Sections 3 and 4, NVisionIP presents a system oriented view, emphasizing each host (IP address) whereas VisFlowConnect presents a 1 Introduction network view in an intuitive way. Since information has become a very important part The paper is structured as follows: Section 2 deof today’s organizations, increasing attention has been scribes the related work in the area. Section 3 describes given to security techniques that can help minimize NVisionIP. VisFlowConnect is presented in Section 4. the risk of unauthorized access and availability threats. In Section 5 we describe how the visual information Firewalls and Intrusion Detection Systems (IDS) are from both tools can be correlated to aid the intrusion among the security tools usually employed to prevent detection process. Future work is listed in Section 6. In and detect attacks. Section 7 we present our conclusions. But even though IDSs (e.g. Snort [22]) are usually able to detect many potential threats; as hackers 2 Related Work become more sophisticated, and as new vulnerabilities in current systems are found, Security Engineers face One of the major approaches to intrusion detection inthe hard task of single-handedly attempting to identify volve log file analysis which is employed by most secuwhat is going on in their networks. By using scripts and rity tools such as IDSs, firewalls, and log analyzers [20]. even simple commands (e.g. cat and grep), Security En- With the rapid development of electronic infrastrucgineers must find attack traces in large logs. To target tures, the sheer amount of data available renders the their actions better, reduce the amount of time spent in perusal of textual log files less and less attractive. It beattack tracing, and increase their effectiveness, Security comes a daunting task to analyze log files and perform Engineers need the aid of visual tools that are able to correlation between them even for small scale networks. represent the megabytes of data in a more intuitive and In fact, log file analysis is a major time sink for most system administrators, making it even more imperative easier to handle way. Furthermore, it is not unusual for a Security Engi- that we find an effective and efficient approach to increase attack detection accuracy while simultaneously reducing the number of false positives. This gives rise ∗ This research is funded in part by a grant from the Office of Naval Research (ONR) within the National Center for Advanced to the use of visualization within the intrusion detection context. Secure Systems Research (NCASSR) . We present several ways to correlate security events from two applications that visualize the same underlying data with two distinct views: system and network. Correlation of security events provide Security Engineers a better understanding of what is happening for enhanced security situational awareness. Visualization leverages human cognitive abilities and promotes quick mental connections between events that otherwise may be obscured in the volume of IDS alert messages.

Compared with a textual file investigation, a visualization approach has the following advantages. First, analyzing log files is inherently a serial process while interpreting graphical images is perceptually a parallel operation. This provides a much faster and more intuitive way to filter out normal data and concentrate on the suspicious parts. Second, considerably more information can be presented via images than a comparable volume of text. Usually a single picture can convey the same information as an entire report. This reduces the amount of mental context switching and makes the system assessment more efficient, as is shown in [13]. However, most previous work on visualizing networks has been motivated by the need for enhancing network performance and analysis of bandwidth characteristics [5, 12, 3, 4, 10], and little has been done on intrusion detection oriented visualization. To the best of our knowledge, the most related work is [13], where Erbacher et al. suggest a way of visualizing large scale systems for intrusion and misuse detection. They represent the substantial characteristics of the overall behavior of users within the environment via visualization. The system they built is expected to provide a tool capable of assisting in detection and identification of intrusions and misuses that would be otherwise ignored. Nevertheless, the node representation employed in [13] makes the approach less scalable in terms of the number of hosts, which would generate images too dense for users to comprehend even with small scale networks. More importantly, the lack of the ability to show additional information about hosts is a drawback, as this information would be convenient when tracking suspicious phenomena. These drawbacks are avoided in our approach. There is no consensus on the definition of correlation for intrusion detection. There are at least five different definitions: (1) correlation of events within one log, (2) correlation of events between homogeneous logs on the same network, (3) correlation of events between heterogeneous logs on the same network, (4) correlation of events between homogeneous logs on different networks, and (5) correlation of events between heterogeneous logs on different networks. In this paper we focus on definition (1) to use visualization applications to help identify events from within one log that otherwise may be missed. Managed security service providers sell protection based on definitions (2) and (3). With there being so many attacks on the Internet, there are several organizational/commercial websites where you can submit log files for correlation in the meanings of (4) and (5), and they report what they find back to the source as well as overall trends to the larger Internet

community1 . An often overlooked aspect of correlation for intrusion detection is determining which logs to use as data sources. As indicated in [14], a key capability for an IDS is to associate different priorities to different logs for distinctive attacks. This prioritizing is of special interest since usually a certain attack can be efficiently identified with several closely related logs. In [29], Yurcik et al. discuss 15+ logs commonly available on computer networks. In [27] Yin et al. discuss principles of selecting logs for correlation. It should be no surprise that some logs are superior in detecting certain attacks and poor for detecting other attacks; but overall, correlating events across multiple logs enhances IDS accuracy and reduces false positives [1]. Several papers have been written recently on correlation for intrusion detection. [7, 8, 11, 18] correlate IDS alerts. Whereas, [29, 27, 21] correlate information presented in different logs. The typical problem with alert correlation is the flood of alerts that contains a high percentage of false positives. It is not feasible for experts to examine those alerts. Thus, several approaches to reduce the number of alerts have been proposed. In [23, 24, 25], similar alerts are merged together to greatly reduce the volume of alarms. The similarity between two alerts is measured by the similarity over several predefined features. Porras et al. [19] develop a system called M-Correlator to consolidate and rank a stream of security incidents in terms of the needs of analysts, given the topology and operational objectives of the network. Another approach is taken in [7, 6, 11, 16, 15], where the set of alarms is efficiently pruned by a set of predefined rules. These manually written or automatically generated rules help identify alerts that could not be part of a real attack. However, none of this previous work uses visualization to correlate different views for intrusion detection. To our knowledge, this is the first work to leverage human senses to quickly draw inferences as opposed to weeks of analysis. 3 NVisionIP System Views NVisionIP, first introduced in [28], is a traffic visualization tool that aids in visually monitoring computer traffic in multiple integrated views – specifically an overall network-wide view, a subnet view, and an individual machine view. NVisionIP is built within the Data-to-Knowledge (D2K) software environment [9]. D2K is a flexible machine learning and data mining system that provides 1 For an example of (4) see and for an example of (5) see .

support for several analytical data mining methods for prediction, discovery and deviation detection. D2K permits visual programming enabling users to easily connect software modules together. D2K provides a data flow environment and a set of software modules and application templates. NVisionIP takes advantage of some of these modules, and also extends it with specific modules for analyzing data sources for intrusion detection. NVisionIP currently uses data in NetFlow log format (either ascii or binary). NetFlow is a network based log source that can be generated by routers or specialized open source software (e.g. Argus logs [2]) and stores information about traffic that passes through an observation point. The NetFlow files currently used when testing NVisionIP and VisFlowConnect are larger than 500MB per day. Table 1 shows the NetFlow record format. We plan to extend NVisionIP to read and visualize data from other logs (e.g. syslog). byte offset 0 1 2 6 10 14 16 18 22 26 27 28 32 34 38 40

byte length 1 1 4 4 4 2 2 4 4 1 1 4 2 4 2 4

version (set to 1) pad (set to 0) router IP src IP dst IP src port dst port flow bytes flow packets protocol TCP flags start time (seconds since epoch) start time (milliseconds offset) end time (seconds since epoch) end time (milliseconds offset) pad (set to 0)

is displayed for each host (e.g. IP count, incoming connections, outgoing connections, number of ports used), filter the information displayed (with respect to specific ports/port ranges, protocol(s), source/destination IP, flow connections count and byte count) and customize the visualization properties (change color, swap axis). NVisionIP supports two drill-down capabilities: 1. Small Multiple View – from the Galaxy View to a subset of IP addresses within the network (see Figure 2(a)). Allows users to view a specific subset of addresses in more detail. The colored histograms shown in the figure represent traffic levels on predefined well-known ports and dynamic unregistered ports. 2. Machine View – from a subset of IPs to a specific IP (see Figure 2(b)). Presents more detailed information about port traffic on a specific host. Thus, NVisionIP provides a system-oriented view of the network in which statistical information is collected for each host (represented by a unique IP) and presented in a way that makes it easier to analyze than just using regular raw log files or other low level tools. For more information on NVisionIP, read [17]. Next we present the newest addition to the set of intrusion detection tools being developed at NCSA: VisFlowConnect, a tool that provides a network-wide view of the traffic. In Section 5 we describe how the information presented by each of these views can help in the intrusion detection process.

4 VisFlowConnect Network Views To visualize the network flows between internal and A formatted NetFlow file is inputted to the module external hosts, we built a VisFlowConnect view sysCompute Stats to generate statistics for each IP in tem2 . There are three vertical axes shown in the window a given network. This statistic results are further (see Figure 3(a)), where each point of the middle axis processed by the module Create Vis that in turn, indicates an internal host and each point of the outdisplays the results in a user-friendly way, using the side axes denote external domains. The network trafD2K Display Vis module. fic is depicted with segments that connect the points NVisionIP’s graphical user interface provides three (host/domains) on the axes. Hence, the segments bemain views that display the statistical information in tween the left axis and the middle axis represent the different ways: the Galaxy View, the Small Multiple traffic coming from outside, while the segments between View, and the Machine View. Read [28] for more details the middle axis and the right axis represents outgoing on NVisionIP’s usability issues. traffic. In this way, traffic entering the internal network The Galaxy View (see Figure 1) is the main view. as well as leaving the internal network is clearly shown. It displays an entire Class B IP address space as a Note that the left and right axes are symmetric to each 256×256 grid. A single point (x,y) on the grid rep- other, since they both represent exactly the same doresents a machine with the corresponding IP address. mains. The subnets are on the x-axis, and the hosts are on the y-axis (255.255.x.y). The examples shown in this paper 2 Currently the view is displayed upon reading log files. We display NCSA’s Class B address space. From within the plan to extend VisFlowConnect to provide real-time traffic visuGalaxy View, the user can customize what information alization by reading streaming data directly from a socket. Table 1: NCSA unified NetFlow record format

A

NVisionIP Menu Bar. (File → Save (Saves Main view; lets user add))

B

Panel about the version, group etc.

C

Panel displays the basic statistics of the view being displayed

D Panel displays the filter options being used E “Axis Swap” button to swap the subnet and host axis (Q, R) F

“Magnify” button magnifies the area around the cursor in P

G

“Filter” button lets the user apply specific filters to the view

H I J K L

“Reset Filters” button resets all the filters Legend that explains the mapping of range of values to a color “Remove Bin” button. adjusts P

Removes a mapping from I and

“Add Bin” button. Add bins (a range of values and color assignment) Change Color button to change the color of a bin

M

Interface to set which attribute of an IP to display in P

N

Notes user can add (describing picture) when saving Main view

O

Panel displaying the input files used to generate the view

P

Galaxy view: subnetwork

Q

Subnets are by default represented on the X-axis (default view)

R

Hosts are by default represented on the Y-axis (default view)

Each dot represents a unique IP in the

Figure 1: NVisionIP Galaxy View

(a) Small multiple view

(b) Machine view

Figure 2: NVisionIP small multiple view and machine view A

Range of IPs being displayed

B

Change the scale of bars charts from relative to absolute and viceversa

C

Set/change the number of bars displayed in a bar chart

D

Legend that explains mapping of port number to a color

E

Add more ports to display

F Remove a port G Change port color H I J K L M

Show byte count instead of flow count (default) Interface to apply protocol filter. This would result in showing ports that were used in junction with the protocol specified Show the machine view of a single IP Clear the selected IP Panel where all the IPs selected (NVisionIP Main) are displayed. A host

A Address of the machine being viewed B Activity on the other ports used by the IP C “Well-know” ports activity

(a) Main view, external network domains to internal hosts

(b) Drill-down of hosts within specific external subnet to internal hosts

Figure 3: VisFlowConnect: main and drill-down views Due to the large amount of traffic we monitor, we concentrate on significant flows selected according to the magnitude of traffic. Only traffic whose volume is larger than some predefined threshold is shown in the window. In addition, different colors are used to indicate the different volume sizes. Users can select the ports or network protocols they wish to observe. This serves as a convenient and efficient approach to the following query: I want to see all the TCP connections on port 80 and 23. For ease of use, IP resolution is enabled (see Figure 3(a)). Typically there are tens of thousands of outside hosts communicating with the internal network; all cannot fit in the external axes. To cope with this, each point of the external axes represents a network domain and not an external host. We use hosts for middle (internal) axis since there is a finite IP address allocation that limits how many possible hosts are active within the internal network. A line segment connecting to axes represents the unidirectional traffic between the internal host and some external domain (or vice versa). A user can drill down into an external network domain to get more detailed information about hosts flows within that domain. Figure 3(b), shows the VisFlowConnect view of the communication between hosts of external domains and the internal network. The half hidden window on Figure 3(b) is the original VisFlowConnect view. Generally the change of patterns of traffic is of great interest to intrusion detection. We catch such critical pattern variations by animation. Basically, we

perform the animation based on snapshots of traffic, corresponding to some time slot. As a result, the drastic difference between patterns can be identified effectively by viewing the animation. Moreover, we highlight the traffic that is unbalanced (i.e., there is an obvious disparity between the incoming flow from some domain to some internal host and the corresponding outgoing flow, in terms of the volume of traffic). The rationale behind this is that the unbalanced flow may be an indicator of suspicious activity. In summary, the VisFlowConnect view can effectively and efficiently provide different-grain-level pictures of the incoming and outgoing traffic for an instrumented network, making it a valuable complement for NVisionIP. 5 Correlating System and Network Views NVisionIP and VisFlowConnect provide system and network views obtained from NetFlow logs. By presenting this information to the user in two very distinct ways, we enable different kinds of analysis and correlation that help when detecting anomalies and enhance the intrusion detection process. NVisionIP’s interface allows a user to perform the following anomaly detection actions: Visualize pattern changes A host usually has similar traffic characteristics for the same day/time of the week. By periodically monitoring the traffic through NVisionIP, a user can note significant pattern changes. Detection of these pattern changes is indeed easy since hosts are colored representing different amounts of

(a) Outside host/subnet connected to many inside hosts

(b) Inside host hosts/subnets

contacting

many

outside

Figure 4: Many-to-one and one-to-many connections (host with multiple connections is illuminated) traffic being transfered; a host that suddenly “lights-up” may have been compromised. This should be further investigated to learn if it corresponds to an intrusion, misuse (e.g. file-sharing) or some well-justified reason (user downloading Linux distribution CDs). In the future we plan to extend NVisionIP to automatically report to the user these pattern changes. Filter with respect to anomalous IP/subnet If a specific subnet/IP presents anomalous behavior, the user can filter the information presented and only show hosts that have been contacted by that subnet/IP. This allows us to identify potential victims. Filter to a particular port Several bulletins periodically inform Security Engineers of vulnerabilities exploitable through specific ports. By filtering the information visualized in NVisionIP to one or more of this ports, the user may spot compromised hosts more easily. Visualize activity on unusual ports NVisionIP can distinguish traffic to/from well-known ports and unknown or dynamic ports. If the user displays only unknown/dynamic port traffic, it can isolate potential anomalies and observe them without being distracted with the rest of the traffic.

a sign of intrusion or misuse.

VisFlowConnect is a less complex but equally powerful tool that presents a network-oriented view of the logged data. Significant pattern changes can be identified by a user that periodically monitors the network with VisFlowConnect. Furthermore, VisFlowConnect allows the user to “animate” traffic flows making it easier to identify suspicious patterns. A host that presents any of the following characteristics (and did not present them before) should be further analyzed: An outside host/subnet contacting many inside hosts Can be easily visualized in VisFlowConnect (see Figure 4(b)) and may be a sign of an anomaly (e.g. DoS attack). An inside host contacting many outside hosts Can also be easily visualized (see Figure 4(a)) and should be further analyzed as it may be a sign of an anomaly (e.g. compromised host trying to compromise outside hosts by exploiting a vulnerability). Increased bandwidth consumption May be a sign of a misuse (e.g. the use of company resources to download excessive media content). Asymmetry A node with in/out unbalanced network connections. May be a sign of a DoS attack. • Visualize unusual ports used on many hosts – If Once an anomaly has been spotted in either NViparticular unknown/rare ports are being used by sionIP or in VisFlowConnect, the user should use the several hosts in the subnet, it may be an indication other complementary tool to find more information to of anomalous behavior. help understand the context. There are several typ• Visualize unusual ports with large traffic – May be ical correlations among the information presented by

Figure 5: Correlation between VisFlowConnect network and NVisionIP system views each tool that can be identified. Figure 5 shows the different anomalies observable in NVisionIP and VisFlowConnect, and indicates what information presented by each should be correlated with the other. Correlation of information presented by both tools can go both ways, but in general, it is easier to spot strange behavior in VisFlowConnect and then look for more hints about it in NVisionIP: • Scans – An anomaly that looks like that in Figure 4(a) should be analyzed in NVisionIP. If it consists of ICMP packets or connection attempts at odd ports, it is a sign that the someone is “scanning” the network and may try to exploit wellknown vulnerabilities.

obvious what is going on. If not, it is still suspicious behavior and the host can be monitored in more detail to determine if the behavior is indeed a sign of infection. 6 Future Work We plan to extend NVisionIP to use multiple logs in the visualization process. More animation will be implemented as it aids in the recognition of pattern changes. We are also studying statistical and automated host profiling that will help the user in identifying pattern changes. Finally, the system is now running in a forensic mode and it is critical to enable the future support for streaming real-time analysis.

7 Conclusions • Pattern change with many-to-one asymmetry – As computer networks and associated infrastructures Possible DoS attack; should check in NVisionIP to become ubiquitous and more important to the nation’s what ports this outside host/subnet is connecting. communication, it becomes infeasible to handle intrusion detection by textual log perusal, owing to the large • Any other pattern changes – If NVisionIP shows volumes of data. Graphic representation has proved to that unusual ports are being used, it may be an be an efficient way to handle large data sets in other indication of a compromised host. fields. However, little work has been performed on intrusion detection with visualization tools. A user that periodically monitors the network with In this paper, we described two visualization tools NVisionIP can identify pattern changes. Particularly, we have implemented and showed that correlating the if a host “lights-up” (i.e. traffic increases significantly), information they visually provide improves the intrusion the user should then check in VisFlowConnect to which detection process. Our tools are scalable with respect to hosts it has connections with. the size of network flow and easy to use. A clear global Spotting unusual behavior may be tedious at first, picture as well as detailed local additional information since many patterns that seem unusual may turn out can be obtained by using the tools. Their periodic to be legitimate. Nevertheless, a user that periodically use allow a Security Engineer get acquainted with the (e.g. once per day) monitors the network using the two network traffic patterns and use this information as part tools presented, can – after a short period of getting of the intrusion detection process. acquainted with the network patterns – spot intrusions like the recent Welchia worm [26]: Once an inside host 8 Acknowledgments is infected, it will try to infect other hosts. This will We thank the following NCSA/UIUC colleagues who look as a many-to-one pattern in VisFlowConnect. By made significant indirect intellectual contributions to analyzing these connections in NVisionIP we can note this paper: Loretta Auvil, Jim Barlow, Ratna Bearthat they are using TCP port 135 (to exploit a DCOM avolu, Randy Butler, David Clutter, Jiawei Han, RPC vulnerability), a signature of the virus. If an Doru Marcusiu, Jeff Rosendale, Michael Welge, and advisory about this worm has been released, it becomes

Yuanyuan Zhou. References [1] C. Abad, J. Taylor, C. Sengul, W. Yurcik, Y. Zhou, and K. Rowe. Log correlation for intrusion detection: A proof of concept. In Proc. of the 19th Annual Computer Security Applications Conf. (ACSAC 2003), Dec. 2003. [2] Argus real time flow monitor, Jan. 2003. . (Oct. 2003). [3] S. Card, J. D. Mackinlay, and B. Shneiderman, editors. Readings in Information Visualization: Using Vision To Think, chapter Visualizing Network Data, by R. Becker, S. Eick, and A. Wilks. 1999. [4] S. Card, J. D. Mackinlay, and B. Shneiderman, editors. Readings in Information Visualization: Using Vision To Think, chapter Measuring the Web, by T. Bray. 1999. [5] K. Cox, S. Eick, and T. He. 3D geographic network displays. ACM SIGMOD Record, 25(4):50–54, 1996. [6] F. Cuppens, F. Autrel, A. Mi`ege, and S. Benferhat. Correlation in an intrusion detection process. ´ In SEcurit´ e des Communications sur Internet (SECI 2002), Sep. 2002. [7] F. Cuppens and A. Mi`ege. Alert correlation in a cooperative intrusion detection framework. In Proc. of the IEEE Symp. on Security and Privacy, May 2002. [8] O. Dain and R. K. Cunningham. Fusing a heterogeneous alert stream into scenarios. In Proc. of the ACM Workshop on Data Mining for Security Applications, Nov. 2001. [9] D2k toolkit user manual. Automated Learning Group. NCSA. Apr. 2003. . (Oct. 2003). [10] C. Davidson. What your database hides away. New Scientist, pages 28–31, Jan. 1993. [11] H. Debar and A. Wespi. Aggregation and correlation of intrusion-detection alerts. In Proc. of the 4th Intl. Symp. on Recent Advances in Intrusion Detection (RAID 2001), Oct. 2001. [12] S. G. Eick and G. J. Wills. Navigating large networks with hierarchies. In Proc. of the IEEE Visualization Conf., 1993. [13] R. F. Erbacher, K. L. Walker, and D. A. Frincke. Intrusion and misuse detection in large-scale systems. IEEE Computer Graphics and Applications, 22(1):38– 48, Jan. 2002. [14] J. Haines, D. K. Ryder, L. Tinnel, and S. Taylor. Validation of sensor alert correlators. IEEE Security & Privacy, 1(1):46–56, Jan. 2003. [15] C. Kr¨ uegel and T. Toth. Distributed pattern detection for intrusion detection. In Proc. of the Network and Distributed System Security Symp. (NDSS 2002), Feb. 2002. [16] C. Kr¨ uegel, T. Toth, and C. Kerer. Decentralized event correlation for intrusion detection. In Proc. of the 4th Intl. Conf. on Information Security and Cryptology (ICISC 2001), Dec. 2001.

[17] K. Lakkaraju, R. Bearavolu, and W. Yurcik. NVisionIP – A traffic visualization tool for security analysis of large and complex networks. In Proc. of the Intl. Multiconf. on Measurement, Modeling, and Evaluation of Computer-Communications Systems (Performance TOOLS 2003), Sep. 2003. [18] P. Ning and Y. Cui. An intrusion alert correlator based on prerequisites of intrusions. Technical Report TR2002-01, North Carolina State University, Department of Computer Science, 2002. [19] P. A. Porras, M. W. Fong, and A. Valdes. A missionimpact-based approach to INFOSEC alarm correlation. In Proc. of the 5th Intl. Symp. on Recent Advances in Intrusion Detection (RAID 2002), Oct. 2002. [20] S. Romig, M. Fullmer, and R. Luman. The OSU flowtools package and CISCO NetFlow logs. In Proc. of the 14th Systems Administration Conf. (LISA 2000), Dec. 2000. [21] C. Silvestro. Intrusion detection systems and log correlation. Master’s thesis, Cefriel: Consorzio per la Formazione e la Ricerca in Ingegneria dell’Informazione, Jun. 2002. [22] Snort: The open source network intrusion detection system, Sep. 2003. . (Sep. 2003). [23] A. Valdes and K. Skinner. Blue sensors, sensor correlation, and alert fusion. In Proc. of the 3rd Intl. Workshop on the Recent Advances in Intrusion Detection (RAID 2000), Oct. 2000. [24] A. Valdes and K. Skinner. An approach to sensor correlation. In Proc. of the 4th Intl. Symp. on Recent Advances in Intrusion Detection (RAID 2001), Oct. 2001. [25] A. Valdes and K. Skinner. Probabilistic alert correlation. In Proc. of the 4th Intl. Symp. on Recent Advances in Intrusion Detection (RAID 2001), Oct. 2001. [26] W32.welchia.worm – Symantec security response, Oct. 2003. . (Oct. 2003). [27] X. Yin, K. Lakkaraju, Y. Li, and W. Yurcik. Selecting log data sources to correlate attack traces for computer network security: Preliminary results. In Proc. of the 11th Intl. Conf. on Telecommunication Systems, Modeling and Analysis (ITCSM 11), Oct. 2003. [28] W. Yurcik, J. Barlow, K. Lakkaraju, and M. Haberman. Two visual computer network security monitoring tools incorporating operator interface requirements. In Proc. of the Workshop on Human-Computer Interaction and Security Systems (HCISEC 2003), Apr. 2003. [29] W. Yurcik, J. Barlow, Y. Zhou, H. Raje, Y. Li, X. Yin, M. Haberman, D. Cai, and D. Searsmith. Scalable data management alternatives to support data mining heterogeneous logs for computer network security. In Proc. of the SIAM Workshop on Data Mining for Counter Terrorism and Security, May 2003.