A VISUALIZATION TOOL FOR SITUATIONAL AWARENESS OF TACTICAL AND STRATEGIC SECURITY EVENTS ON LARGE AND COMPLEX COMPUTER NETWORKS

A VISUALIZATION TOOL FOR SITUATIONAL AWARENESS OF TACTICAL AND STRATEGIC SECURITY EVENTS ON LARGE AND COMPLEX COMPUTER NETWORKS R. Bearavolu K. Lakkaraju W. Yurcik H. Raje National Center for Supercomputing Applications (NCSA) University of Illinois at Urbana-Champaign Champaign, Illinois USA Keywords: situational awareness, NetFlows, intrusion detection, anomaly detection, computer network security ABSTRACT Situational awareness of the state of military computer networks is important for both tactical battlefield operations and strategic command-and-control networks. While there have been successful efforts to visualize the state of individual network infrastructure components (routers, links) using SNMP and other network management tools, these systems do not focus on security. Although there have been multiple research proposals, to our knowledge there have only been two realized systems which attempt to visualize security events. Assessing the overall security of a large and complex network is an open problem due to the multidimensional data space. We present a tool, NVisionIP, that makes a direct contribution to solving this open problem. NVisionIP is unique from existing systems in that it simultaneously visualizes multidimensional characteristics of individual computers as well as their relationship to network-wide security events in an entire Class B IP address space. INTRODUCTION We have developed a tool, NVisionIP, that allows an operator on one screen to visualize traffic flows to/from every machine on a large and complex computer network. This tool leverages the innate cognitive processing abilities of human operators, allowing them to see security events. In addition to an overall view of an entire network on one screen, NVisionIP also includes the ability to drilldown multiple levels to view subnets of machines or view attributes on individual machines relevant to security such as connection and data transfer statistics per protocol or per port. NVisionIP is built within the Data-To-Knowledge (D2K) data mining software framework and is modular by design with the data retrieval/preprocessing component being independent of the visualization component [4]. The data source for our experiments, the NetFlow application, was selected specifically because it provides a mid-level sensing information. While in this investigation we utilize NetFlow source data, future work will integrate other audit log data sources into what we believe will become an important general-purpose tool. The visualization component of our tool uses colored grids, histograms, and connectivity diagrams that are specifically modified for this application. Usability testing is currently progressing with security experts in order to evaluate potential visualization enhancements including magnification, size, shape, color, and GUI features. Our initial results show that network-wide characteristics can be determined easily from our visualization. In particular, the features of different subnets are clearly apparent, as well as high volume machines such as clusters and web servers. Through the profiling of benchmark traffic patterns, visualization illuminates suspicious events to be investigated. We identify examples of suspicious events and show how visualization can help to identify these events more effectively. The remainder of this paper is outlined as follows: Section 2 provides background on previous related work in visualization. Section 3 describes NetFlows, its specific implementation on our instrumented network, and general problems with its use as our data source. Section 4 presents a description of the tool NVisionIP. Section 5 provides in-depth discussion of situational awareness and the contribution of NVisionIP in this area. We close with a summary and conclusions in Section 6. RELATED WORK [5] provides the most comprehensive overview of network visualizations. Low-dimension visualizations include 1 of 6

networks mapped onto geography, logical diagrams of equipment (including network management tools based on SNMP), traffic level representations in X-Y diagrams/pie charts/histograms, connectivity diagrams with links sized/colored corresponding to bandwidth capacity, and packet-level animation of network simulations (as best exemplified in OPNET 1 and Nam) [7]. High-dimension visualizations include the peacock diagrams of Lumeta 2 which show the Internet in its own space independent of geography and the SKITTER diagrams of CAIDA 3 which show peer interconnections projected on a polar-projected longitude graph. There has been a small amount of work combining network visualization and computer security that we now describe (in chronological order). [10] presents a prototype design tool from the Harris Corporation named the Network Vulnerability Tool (NVT) that visually depicts the network topology under study (using the HP Openview SNMP product) and generates a vulnerability assessment window with results from proactive scans and a vulnerability database. [11] proposes visual symbols to better communicate security events to users. [17] states visualization should be the next focus of intrusion detection systems (IDSs) since it can convert the essentially serial IDS alarm process to the parallel process of visual perception. [15] presents a prototype system visualization of aggregate IP address spaces for routing attacks and misconfigurations. The most relevant work is a rapid visual feedback system originally developed by the NASA Jet Propulsion Laboratory for tracking the status of spacecraft components that has now been adapted for network security as a commercial tool called TowerView Security [16]. It should be noted that neither of these two working visualization systems [15,16] show network traffic flows or individual host statistics vital for security. NETFLOWS AS A DATA SOURCE A basic point is not being addressed by current research - it is fundamental to know how a network is being used. Without some insight into network usage operators will always be reactive to crisis situations and never able to effectively manage, prevent, or anticipate security events. In this context we use the term usage to mean services and applications and not necessarily user data. The stateof-the-art in security monitoring is alarming/blocking known packet events and monitoring network component status such as CPU utilization, bandwidth utilization, packet volume, and error states. Note also that current monitoring is focused on components and does not reflect relationships between end system network usage or a holistic view of an entire network (network-wide events). NetFlows provides such requisite information about network usage using the metric of traffic flows where a flow is defined as a sequence of related packets in time. 4 While there are some security events that may not have associated network traffic (a floppy-based virus that does not propagate), the overwhelming majority of security events involve flows through characteristic host ports. The basic unit in the NetFlow system is a NetFlows record, a record of a distinct port connection between two machines for a period of time. Since resolution is at the flow level, packet level details are aggregated for an entire flow. Figure 1 shows the NetFlows record format we use: byte byte offset length 0 1 version (set to 1) 1 1 pad (set to 0) 2 4 router ip 6 4 src ip 10 4 dst ip 14 2 src port 16 2 dst port 18 4 flow bytes 22 4 flow packets 26 1 protocol 27 1 tcp flags 28 4 start time (seconds since epoch) 32 2 start time (milliseconds offset) 34 4 end time (seconds since epoch) 38 2 end time (milliseconds offset) 40 4 pad (set to 0) Figure 1. NCSA Unified NetFlows Record Format As packets are forwarded through routers or past open source software (Argus [2]) installed on an enabled host, a record for each flow is created and kept in a cache until one of the following conditions are met upon which the flow record is thus exported [3]: (1) a flow record has been idle for a specified time, (2) a flow record is active longer than the cache size limits, or (3) TCP connections which encounter a FIN or RST flag. NCSA operates multiple internal core routers with NetFlows capability as depicted in Figure 2. Currently, each of these routers is configured to send NetFlow output to one NetFlow Collector, a host dedicated to receiving NetFlow export packets. This load balancing between multiple internal routers provides robustness to handle short-term large traffic volume spread across multiple machines (no single internal router point of failure) as well 1 http://www.opnet.com/ 2 http://www.lumeta.com/ 3 http://www.caida.org/ 4 sequenced TCP packets in a virtual circuit connection or UDP datagrams with the same full association (source/destination IPs and port numbers) within a short delta period of time on the same interfaces 2 of 6

as a scalable architecture to add additional internal routers with long-term increased loads. A complementary approach is a NetFlows capability at an Internet connection (border router) that we also employ. specific flows, FlowScan visualizes aggregate properties of a network, as seen through all network flows. None of these tools can identify specific machine or subnet traffic. Despite this success, there are potential problems with the use of NetFlows as a data source that should be addressed: Cache Flushing: A router has a finite cache size that limits the maximum amount of time flows can be cached before being flushed. This time limit is configurable with additional cache the default configuration is 30 minutes. In the default configuration a flow longer than 30 minutes would be split into more than one flow as the old cache is flushed and the new empty cache is refilled. This problem can be handled with post-processing to check the TCP flags field or by comparing beginning/end timestamps. Duplicate Records: When a flow passes through multiple routers, each router creates a separate NetFlow record that may be exported to a common NetFlow Collector resulting in duplicate records for a single flow. This can be handled by using heuristics to determine if multiple records actually refer to the same flow. Figure 2. NCSA s Network Instrumentation for NetFlows We post-process NetFlows in a multi-stage process as shown in Figure 3. We developed software to combine simultaneous NetFlows output from multiple internal routers into a unified NetFlows file for all network flows within a defined time period (at present we use 5 minutes). The unified NetFlows files are then converted to binary at the Flow Collector and another storage machine runs a script to convert binary to ASCII as needed. Figure 3. Streaming NetFlows Transformation into Log Files There has been some research published on the use of NetFlows. In [8] a fairly sophisticated package of NetFlow analysis tools were created and actively used for network management and security, mainly aimed at detecting backdoors and stepping sizes through packet size correlation. [9] develops a flow processing and X-Y plot tool that displays specific flows. In contrast, [12] uses a commercial MySQL database to store and manage flows. By far the most popular NetFlow visualization tool is FlowScan [13] that is an X-Y plot that has been used for characterizing network traffic anomalies [1]. Whereas previous attempts focused on filtering and visualization of Reliability: NetFlows from routers are exported using UDP datagrams that have no windowing retransmission/ acknowledgment mechanisms for reliability. Thus the NetFlows Collector will be unaware of flows lost during export transmission especially during times of overload (e.g. DoS attack). Argus does not have this reliability issue and can be used for calibration and error detection of lost NetFlows via router export. Authentication: Router-exported NetFlows can be spoofed. Antispoofing filters, unicast reverse path forwarding, and authentication encryption can mitigate this problem. Integrity: Router-exported NetFlows are vulnerable to modification and DoS attacks since they are unencrypted datagrams. Appending message digests or error detection codes to datagrams will detect modifications but not manin-the-middle replay attacks. Argus does not have this vulnerability due to network transmission. Confidentiality: Router-exported NetFlows are vulnerable to passive sniffing since they are unencrypted. Argus does not have this vulnerability due to network transmission. We have determined that inaccurate information from cache flushing and duplicate records is minimal and detectable in our environment and thus does not significantly change the effectiveness of our tool. Another unique problem for our network environment is that some traffic (we have identified) is cut-through switched at data 3 of 6

link layer Ethernet hubs and thus not seen by network layer routers instrumented with NetFlows. TOOL DESCRIPTION Figure 4 highlights how NVisionIP is built within the Data-to-Knowledge (D2K) software environment. D2K is a rapid, flexible, machine-learning system that effectively integrates different data mining methods and offers a set of software modules and application templates that can be accessed through a visual programming environment [4]. Figure 5. NVisionIP GUI Figure 4. NVisionIP Software Organization NVisionIP uses modules that are part of D2K as well as modules specifically written for analyzing data sources for intrusion detection. NVisionIP is modularly designed so that the data retrieval/preprocessing component and the visualization component are independent. While currently NVisionIP uses only one data source (NetFlows), in the future we plan to integrate other data sources relevant to intrusion detection. The modular design of NVisionIP makes it easy to extend and analyze multiple data sources. A formatted NetFlows file is taken as an input by the Compute Stats module of the NVisionIP tool to generate statistics for each IP in a given network. Some of the statistics we generate using NetFlows are the number of times - the IP is present in the NetFlow file, is in the destination column, is in the source column etc. The statistics Compute Stats generates is dependent on the data source. The results generated by the Compute Stats module are further processed by the Create Vis module to create scientific visualizations that are displayed using the D2K Display Vis module. One of the primary goals of the NVisionIP GUI (Figure 5) is to effectively display information about the entire network on one screen called the Galaxy View (see Figures 5 & 6). This is accomplished by representing an entire class B IP address space as a 256 X 256 grid in the Create Vis model. The NVisionIP GUI also allows the operator two different levels of zoom-in capabilities: (1) from the Galaxy View to a subset of IP addresses within the network the Small Multiple View and (2) from a subset of IPs to a specific IP the Machine View. The Galaxy View is a 256*256 grid where a single point (x,y) on the grid represents a machine with the corresponding IP address (see Figure 6). The subnets are on the X-axis and the hosts are on the Y-axis. All the diagrams shown in this paper are displaying NCSA s Class B IP address space (141.142.x.y). Figure 6. NVisionIP Galaxy View (GV) The Galaxy View Menu section is divided into two main categories: Informational and Interactive. In the Informational category we have: Stat Panel: displays the essential statistics about the attribute that is displayed in the GV. Filter Option Display Panel: displays the filter options selected by the operator. 4 of 6

Figure 7. NVisionIP Filter Option Display Panel The top of the SMV window displays the zoom view of the IP address space selected by the operator to enable quick comparison and browsing of port traffic patterns. The bottom of the SMV window provides options for the operator to zoom in further to look at the port traffic on a specific machine - The Machine View (MV). The MV for an IP is displayed by selecting an IP from the SMV and clicking on the "Show Composite" button. An example MV is shown in Figure 9. In the Interactive Category, we have the following options: AxisSwap Button: swaps the axes in the GV. Magnify Button: enables a magnifier in the GV. Filter Button: Figure 7 is the filter panel displayed upon clicking the filter button to select attributes to be displayed on the GV such as IP address (all/source/destination), activity type (connections/ bytes), protocol (all/subset), or ports (all/source/destination/subset). Color Legend shows mapping of a range of values to colors. The initial mapping is defined by the system and can be modified using Add Bin and Remove Bin buttons. The first zoom-in view is activated by clicking and dragging the mouse over a section of the IP address space in the Galaxy View. This results in displaying a window with detailed port traffic information about a selected subset of IP addresses, subnets, or multiple subnets as shown in Figure 8. The colored histograms represent traffic levels on pre-defined well-known ports and dynamic unregistered ports. Figure 8. NVisionIP Small Multiple View (SMV) Figure 9. NVisionIP Machine View (MV) SITUATIONAL AWARENESS To the military commander, situational awareness is knowing where his troops are, their readiness and capabilities, and more importantly intelligence on the location of enemy troops, their readiness and capabilities. A more simplified definition is knowing what is going on around you. Assessing security on large and complex computer networks poses challenges to situational awareness similar to the battlefield fog of war : information overload, dynamically changing information, and a high degree of uncertainty about what is happening. NetFlows provide unidirectional flow records between source and destination machines along with information about how much data is transferred, over which port, and for how long. Hence NetFlows track all security events (~99%) reflected in flow level details. For example, scans, stepping stones, DoS attacks, chains, botnets, irc channels, rogue access points, authentication attacks, warez ftp sites, and countless unauthorized services have all been detected using NetFlows. NetFlows are also a good source for traffic profiling statistical traffic benchmarks for a 5 of 6

network, subnet within a network, class of machine, specific machine, or specific service. Lastly, one of the biggest arguments in favor of NetFlows is the availability of open source software independent of routers (Argus) such that a NetFlows sensing capability can be dynamically implemented anywhere on a network. The situational awareness provided by NetFlows does have uncertainty in two areas: (1) correctly determining the client/server relationship between two hosts, and (2) correctly interpreting live flows [6, 14]. NetFlows are unidirectional and do not contain an indication of which host initiated the flow but heuristics such as timestamps, byte counts, port numbers, and other log data sources may be queried to infer the client/server relationship. In the case where client/server flows are asymmetric (inbound/outbound flows travel different paths), records from different NetFlow sensors will need to be correlated to infer the client/server relationship. As for determining live flows, since NetFlow records are created upon flow termination and not upon flow establishment it follows that (1) most flows are reported in near-real-time only after they have terminated, (2) only flows longer than the cache flush period (30 minute default configuration) may be caught in progress, and (3) it is inevitable that streams of exported NetFlow records will easily become out-ofstarting-time-order since short flows will be sequenced ahead of any long flows that terminates later. Determining live flows can be handled by timestamp sort postprocessing but this institutes a near-real-time delay equal to the cache flush period. In summary, despite uncertainty in some situations, NetFlows provide situational awareness unavailable from other sources. 5 While NetFlows may provide complete situational awareness in many cases, the ultimate value of NetFlows will be realized when correlated with other logs. CONCLUSIONS We have presented a novel visualization tool that provides holistic multi-level security monitoring of an entire IP address space on one screen. Initial testing with operators emphasizes the situational awareness provided by being able to simultaneously visualize traffic activity at different levels (network-wide, subnet, individual machine) to discover new relationships and patterns that otherwise would have been obscured by the sheer volume of raw data and difficulty of gathering and analyzing this data. 5 For just one example: Suppose a flood of small packets is directed at a group of campus addresses. The flood will be visible on NVisionIP based on NetFlows but obscured on a graph of aggregate packet traffic since the spike produced by the flood is a larger percentage of total flows than it is of total packets. REFERENCES [1] Barford, P., and D. Plonka. Characteristics of Network Traffic Flow Anomalies, ACM SIGCOMM Internet Measurement Workshop, 2001. [2] Bullard, C. Audit Record Generation and Utilization System (Argus). <http://www.qosient.com/argus/> and <ftp://ftp.andrew.cmu.edu/pub/argus> [3] Cisco Systems. NetFlow Services and Applications, White Paper. 1999. <http://www.cisco.com/warp/public/cc/pd/iosw/iof t/neflct/tech/napps_wp.htm> [4] Data-to-Knowledge (D2K) Ref. Manual, NCSA, 2001. <http://archive.ncsa.uiuc.edu/alg/d2k/> [5] Dodge, M., R. Kitchin, Atlas of Cyberspace, Addison-Wesley, 2001. [6] Dunn J. Security Applications for Cisco NetFlow Data, SANS Institute, 2001. <http://www.sans.org/rr/software/netflow.php> [7] Estrin D. et al., Network Visualization with Nam, the VINT Network Animator, IEEE Computer, Nov. 2000, pp. 63-68. [8] Fullmer, M. and S. Romig. The OSU Flow-tools Package and Cisco NetFlow Logs, 14th Systems Admin. Conf. (LISA) Usenix, 2000, pp. 291-303. [9] Haberman, M. et. al. flowboy: An Object-Oriented Framework for Generic Network Flow Management, Passive/Active Measuremt. (PAM) Workshop, 2000. [10] Henning, R., K. Fox, The Network Vulnerability Tool (NVT) A System Vulnerability Visualization Architecture, National Information Systems Security Conference (NISSC), 1999. [11] Hosmer, H., Visualizing Risks: Icons for Information Attack Scenarios, National Information Systems Security Conference (NISSC), 2000. [12] Navarro, J-P. et al. Combining Cisco NetFlow Exports with Relational Database Technology for Usage Statistics, Intrusion Detection, and Network Forensics, 14th Systems Admin. Conf. (LISA) Usenix, 2000, pp. 285-290. [13] Plonka, D. FlowScan: A Network Traffic Flow Reporting and Visualization Tool, 14th Systems Administration Conference (LISA) Usenix, 2000. [14] Sommer, R. and A. Feldmann. NetFlow: Information Loss or Win? ACM SIGCOMM Internet Measurement Workshop (IMW), 2002. [15] Teoh, S. et al. Case Study: Interactive Visualization For Internet Security, IEEE Visualization, 2002. [16] TowerView Security <http://www.hightowersecurity.com/> [17] P. Varner and J. Knight, Security Monitoring, Visualization, and System Survivability, IEEE/SEI Information Survivability Workshop (ISW), 2001. 6 of 6