COLLABORATIVE NETWORK SECURITY MONITORING (NSM) ANALYSIS FOR NETWORK FORENSICS INVESTIGATION Ali Fahmi Perwira Negara1, Asrul

Hadi Yaacob2, Mohd Fikri Azli Abdullah3

1,2

Faculty of Information, Science, and Technology (FIST) Multimedia University (MMU) Malaysia Jalan Ayer Keroh Lama Melaka 75450 Malaysia 1 ali.fahmi.pn@gmail.com 2 asrulhadi.yaacob@mmu.edu.my 3 School of Electronics and Computer Engineering Chonnam National University, South Korea 3 mfikriazli@gmail.com

Abstract Easy information exchange supported by recent networking technology exposes a security issue. To determine and then to recover from a computer-related incident, theres necessity to have a measure and to determine responsive steps like a possibility of legal proceedings in which requires a special skill in a field known as digital forensics. Its sub discipline, network forensics, in particular has increasingly been popular due to the fact that most incidents occur through a network. Network forensics still encounters some problems due to its nature as a joint field of study comprising from computing knowledge to law area. As a joint field of many areas of expertise, network forensics shares same problems encountered in the field of digital forensics. Complexity of the process and massive quantity of data being analyzed are two major problems. There exists an advanced network monitoring technique called Network Security Monitoring (NSM) that comprehensively dealing with data travels across network as a method on network forensics investigations. Based on NSM, this research addresses those problems on network forensics. NSM provides a platform to help structured evidence collection and further analysis in a complex network forensics investigation. The existences of collaborative tools in this research are used by investigators to simplify joint network forensics investigation enabling various people from different backgrounds to work together. Keyword: Network Security Monitoring (NSM), collaborative tool, network forensics 1. INTRODUCTION Network forensics are performed by making use network monitoring techniques in which they commonly involve only few types of data like log and alert data investigation. However, there exists advanced network monitoring technique that more comprehensively dealing with data travels across network. The technique is called Network Security Monitoring (NSM). NSM provides a platform to help structured evidence collection and further analysis in a complex network forensics investigation. The paper will show how NSM is used in investigation and how one existing tool and another one newly introduced prototype tool are used in a collaborative network forensics investigation. The rest of paper is structured in 5 sections. Section 2 describes about related works. Section 3 demonstrates on using NSM in network forensics investigation. Section 4 explains the details of design system and its implementation. Section 5 concludes the paper with a brief summary.

Proceedings of Regional Conference on Knowledge Integration in ICT 2010

52

2. RELATED WORKS CS Lee and Meling Mudin (2009) explains network forensics as a process involving the collection of network packets from wired or wireless networks, analyzing, recovering the information from the packets and reporting them in presentable and forensically sound manner. Tons of data from networks can only become useful information and evidence only if investigators understand on how to correlate Network-Based Evidences (NBEs) so that they able to reduce NBEs only to a useful remainder. Only by then, this useful remainder is subsequently analyzed further. Wei Wang and Thomas E. Daniels (2005) respond the challenges of network forensics as stated by Brian Carrier (2005) about complexity in investigation process and massive data involved in it. Wang and Daniels explain the demands of network forensics analysis technology. In their arguments, they emphasize about friendly interface to help investigators producing evidence like intrusion evidence and also argue about analysis results should be presented in an intuitive approach. The ad-hoc nature of cyber attacks indicates that expert opinion and out-of-band information must be efficiently integrated into the human reasoning intuitively especially to the non-technical investigators. 3. NETWORK SECURITY MONITORING (NSM) 3.1 NSM in Network Forensics Investigation It is often realized in during network forensics investigation that data collected is neither sufficient nor presentable to analyze and even to use it as evidence of an incident. This mostly happens due to either lack of data collected or less comprehensive data collected. Common network monitoring technique involving only analysis of few types log -based data usually encounters those obstacles. Considering those, NSM is introduced to fill the void. Bejtlich and Vischer (2005) define Network Security Monitoring (NSM) as The collection, analysis, and escalation of indications and warnings to detect and respond to intrusions.(p.25). NSM allows investigators to collect, identify, examine, correlate, analyze all traffic that may and may be not related to the incident. NSM is different from a merely an intrusion detection often used in common network monitoring. In NSM, it more comprehensively focuses towards the whole packet and traffic that may cause an alert in intrusion, be it a traffic that preceding the primary event causing alert, traffic during incidents/events, or a traffic after the main event. Through NSM, investigators may be able to see a clearer picture of an incident compared to common network monitoring. They do not depending on solely alert generation which is not a reliable way to perform network forensics. Alert is just simply an early alarm by which it may or may not lead to a legitimate event. It may give a false alarm (either positive or negative) which can be confusing in investigation. NSM gives a full picture of data and traffic from the event generating alert so that analyst and investigator won't be misled. Another difference with common network monitoring is in terms of data types to collect. NSM performs standard data collection encompassing 4 data forms: statistical data, session data, full content data, and alert data. By collecting them, NSM gives full clues and leads neutrally to investigators that may be necessary for forensics investigation, reducing chance of false negative or positive data. This principle is in conjunction of basic investigation principle: Assume nothing over a crime scene.

Proceedings of Regional Conference on Knowledge Integration in ICT 2010

53

3.2 NSM Analysis: From Raw Data to Presentable Evidence Common network monitoring is often only up to data acquisition and analysis for one selfs purpose while network forensics investigation, the process is longer, starting from preparation to a presentation of evidence. Therefore, network forensics is not only things about capturing data and analysis only. There are at least 2 main phases in investigation, one (1) is the data acquisition (which most of the time investigators deal with raw, uninterpreted data) and its analysis (pre-analysis) and the other one is (2) another analysis process of producing presentable evidence (post-analysis). The earlier phases will mostly be concerned by investigators possessing technical backgrounds in computing technology while the latter is much of concerned to investigators related to legal matters. According to the phases above, there is often a difficulty that occurs in 2 type of situation when (1) an investigation is taking place during analysis of raw data and (2) in transition from passing a data from pre-analysis consisting full technical information to convert it to presentable evidence during post-analysis. The difficulty most of the time occur as the investigators dont have a proper tool to communicate and to collaborate the data among themselves, especially between technical investigators (IT experts) and non-technical ones (policemen, prosecutors, etc.). Larry E. Daniel (2010) has expressed his experience regarding the 2nd situation in his article Attorneys are from Mars, Computer Forensics People are from Pluto mentioning that it indeed exists a communicating barrier among the kind of investigators like attorneys and the computer-types investigators like him when communicating findings or delivering presentable data to non technical investigators. 3. NETWORK FORENSICS WITH NSM METHODOLOGY As a sub discipline of digital forensics, network forensics using NSM shares same methodology to conduct an investigation. The methodology consists of three (3) main steps which are (A) identification, (B) preservation, and (C) reporting/presentation. In details, preservation process can be further elaborated into two (2) sub-processes which are data collection/acquisition and analysis of data.

Figure 1: Standard digital forensics investigation method (Courtesy of Cyber Security Malaysia) The first step is the identification process to determine a starting point on investigation. This step is to decide from which position to start the investigation. Upon completion of
Proceedings of Regional Conference on Knowledge Integration in ICT 2010 54

identification, they go to the most critical step that is preservation process. It will be the 2 nd step as it will deal directly to data and to process on how data is collected and subsequently then analyzed to extract useful information towards the aim of investigation. This is the trickiest part as investigators are exposed to risk of either collecting evidence that contains insufficient to analyze it or collecting evidence but not presentable to analyze, or worst is unable to collect the data. The last step to be accomplished is about how the information is reported and presented from analyzed data properly. 4. DESIGN AND IMPLEMENTATION 4.1 System Architecture Design on Local Area Network (LAN)

Figure 2: System architecture of NSM in a LAN for forensics purpose The system architecture of NSM mainly consists of 3 components as the essential building block of any NSM systems which are the sensor, the server, and the client. The sensor is basically a device where all tools for data acquisition and collection are deployed into. The sensor can be either connected to dedicated network tappers and run in promiscuous mode to avoid traffic generation from itself or it can be installed in the gateway where all inbound and outbound traffic over a network pass it by. The server is the element that functions like the brain and heart of the system as it controls and serves the flows of data and request flowing from sensor to server, client to server, server to sensor, and server to sensor. Moreover, it also controls on how data is being stored and archived in the database of evidence collection. The last element, the client, is basically an interface for analysts to retrieve and analyze data from the server. In the sensor, besides tools for capturing purposes, it is installed a web server and a web-based collaborative tool for post-analysis of forensics investigation. In client side, a client application is installed to provide a collaborative tool among analysts investigating raw. 4.2 Collaborative Tools on NSM-based System for Network Forensics The collaborative tools which enable collaborative NSM analysis in this research are basically divided into two categories: 1st situation of raw data investigation and 2 nd situation
Proceedings of Regional Conference on Knowledge Integration in ICT 2010 55

on transitional analysis for proper evidence presentation. The tools are Sguil (pronounce as sgweel) and PacketMonzeight. The role of each collaborative tool differs from the part they contribute in investigation. This research shows how the tools take their part on investigation based on an investigation later. The role of each tool is briefly described according the categories as following: 4.2.1 Collaborative Tool for Pre-Analysis (Raw Data Analysis) Raw data analysis often mentioned as a nightmare in investigation process as it involves very large and massive data about traffic across a network especially if the network investigated is a high bandwidth and fast network. Coupled with the nature of investigation process that is complex, existence of a tool in this process is highly regarded as very helpful during investigation. Here, the main tool for collaborative analysis for low level and raw data used is Sguil which enabling analysts to investigate together. The Sguil tool originally developed by Bamm Vischer basically is the back bone of the NSM system implemented in this research. 4.2.2 Collaborative Tool for Post-Analysis (Evidence Presentation) Upon completion of analysis of low level data format and extraction of useful information done by technical investigators (analyst), the subsequent step is to communicate findings and present evidence (NBE) in a proper way to present it in such a way that is easy to understand for non-technical reader and accepted by legal proceeding. To achieve those, the collaborative tool must appear in intuitive way, be able to keep track of investigation process goals (investigation target and scheduling, etc), enable in such a way that the tool drives collaborative effort such as discussion in findings, easy access to collection of evidence, report, etc. in investigation for cross check analysis, file sharing, and so on. If the tool can be made ubiquitous and easy to access while mobile, that will be another advantage. Therefore, a web-based collaborative tool is the solution over those requirements above. PacketMonzeight is then introduced in this paper and proposed to cater those requirements. 4.3 Implementation on Scenario-based Incident The implementation of the tools is demonstrated through a scenario that simulates an incident. This scenario incorporates demonstration of possible security incident in a fictive entity. The scenario covers from attacking scenario, detection and identification scenario, and recovering the NBE. The scenario is as following: A company named MICROSOLVE has been targeted by an attacker who trying to get into the network to steal companys s ecret information. This attacker will try to gain access by exploiting a hole to gain root shell or admin privileges. Upon successful, the attacker will breach into secret file data storage and get some confidential data in it. Lastly, the attacker will make use of FTP service in targeted host to transmit the backdoor to access the compromised host next time. MICROSOLVE has deployed NSM system into their network with router/firewall NAT-enabled which also acts as a sensor. Variables here used are 192.168.1.100 for attacker and 192.168.1.101 for the gateway/sensor of MICROSOLVE network. The testing scenario are done inside a LAN where sensor and attacker at the same LAN and the other LAN resembles MICROSOLVE is NATed by the sensor/gateway/firewall in 192.168.2.0/24 network.

Proceedings of Regional Conference on Knowledge Integration in ICT 2010

56

4.3.1 Attack Phase The attack phase will consist of reconnaissance phase, exploit phase, and reinforcementconsolidation-pillage phase. The reconnaissance phase uses techniques such as port scanning to determine services running on targeted host that can be a hole to exploit later on. In this research port 21, 22, 53, 80, and 9080 are purposely opened. Then, the exploit phase will take place upon completion of reconnaissance or information gathering. Here, the exploit is launched to port 9080 using a module of Metasploit Framework (MSF) v3.3 called Snortbopre (exploit to back orifice stack overflow of unpatched Snort v2.4.x to port 9080) that resulting a shell root gained.

Figure 3: Exploitation to vulnerable port 9080 resulting root shell access Upon successful exploitation, the attacker then successfully gain access to the system and start doing reinforcement and consolidation by transmitting and installing a backdoor file for future access. Then, attacker will do the pillage phase which is to steal the desired file he/she wants to steal. 4.3.2 Detection and Identification to Respond: Sguil in Action In MICROSOLVE side, the NSM system notifies to the investigators that theres a possible breach attempt or even breach event. Alert data has been generated by the sensor to warn the investigators that theres event been taking place in the network. The warnings are:

Proceedings of Regional Conference on Knowledge Integration in ICT 2010

57

Figure 4: Alerts generated as a result of incident From the warnings, the investigators now can detect and recognize what is likely the attack is. To verify and examine the event, the investigators must also look to other data rather than just warnings. This can be done using Sguil. Furthermore, when investigators are using Sguil together, they can communicate through their running Sguil connecting to the same host when doing real time analysis together at the same time. This is the deeper look of warnings in Sguil:

Figure 5: Sguil simplifies investigation with its friendly UI and discussion features The output of NSM over the incident is displayed in simple interface in Sguil. In Sguil, it can be seen the TCP stream session flow data (timestamp, communicating parties IP and Port No.), the alert data (spp_boo: Back Orifice Snort Attack exploit, etc.), Statistical Data (in low left corner panel; packet stat, bandwidth consumed, alert generation rate, etc.) and also full content data at the low right corner displaying the actual content and payload along with the disassembled protocol data to make analysis easier. From here, the analysts/investigators have gained critical and valuable insights to determine the more similar process through other tools to verify the data obtained and also to extract other type of information in which Sguil cant adequately provide in its interface. As an example, using Wireshark to examine the pcap packets captured across network using NSM technique. Later in the evidence recovery, it will be shown on how to verify the NBE found and to see the information.

Proceedings of Regional Conference on Knowledge Integration in ICT 2010

58

4.3.3 Evidence Recovery Process Another excellent factor implementing NSM is easy to recover the evidence needed to prove such an incident truly happened. Through NSM, during setting up the sensor, a NSM sensor is configured to have the suspicious packet related to alert to be reduplicated separately from other packet in a form of libpcap-based file. Among all packets captured in the regular directory, it is possible that there are a lot of other files that can be the NBE for an incident. However, the massive size of them makes it not feasible to check the whole packet per individual packet basis. By configuring sensor to do reduplication specific packet that generates alert into separate directory/partition, the investigators have a more focused object to be examined. If later other packets related to the specific packet deemed necessary to be inspected also, then at least investigators have a clear starting point to inspect a packet rather than a random checking one. The evidence that can be recovered from the incident scenario is shown as following:

Figure 6: The information obtained from NSM in the incident The NBE above shows some useful information about the chronology on how the attack was carried out resulting in incident. The evidence above shows 3 types of events prior to the breach to the 192.168.2.0/24. They are done by exploiting and attacking the gateway/firewall/router/sensor in 192.168.1.101 (which NATed the 192.168.2.0/24 network). Above information displays three (3) types of attack to the sensor: (a) aggressive port scanning to reveal vulnerable hole displayed in red colored TCP/IP stream, (b) FTP session in (light violet colored) to the 192.168.1.101 to transmit malicious backdoor and also stealing information from MICROSOLVE, and (c) the exploit attacks using Snortbopre exploit to port 9080 (in W32 system known as glrpc port) to gain root shell/admin privilege. The attacker address is also able to be recorded to trace it later on or to explain source of incident during law enforcement hearing/investigation session. 4.3.4 Communicating to the Less Technical Investigators Identification to determine the starting point to acquisition and raw data analysis is done. Technical investigators have agreed on conclusion upon data analysis and interpretation on the look of incident. Simply said, the pre-analysis is done to post-analysis turn. Now its the time to make the information obtained useful for further process especially the legal

Proceedings of Regional Conference on Knowledge Integration in ICT 2010

59

proceedings. The legal proceeding requires well organized investigation process, concise, trusted, and accurate evidence. To present NBE and show how investigator is conducted in well archived and concise manner, PacketMonzeight will be used. This software is designed to facilitate the investigation communication and provide tracking to progress and schedule as well as graphical information and information findings. Therefore, the software will provide few functions to help the investigation. For example, a schedule tracker in a form of calendar is provided to see schedules, plans, and deadlines on investigation. Besides, it also provides a bulletin board where all analysts can exchange information, ask and reply to issue/topic/question, and to announce important information. Those investigation assisting tools against the incident scenario are shown below:

Figure 7: PacketMonzeight provides schedule tracking for investigation Figure 7 depicts the tool functions in overview section as a tracker of agenda, plan, and schedule for the general purpose of legal proceeding process. The tracker is implemented in a form of calendar which serves as the notes of the schedule on a particular date lead investigator can set. By this, the workflow of investigation can be done in well organized manner. Besides, it serves as general reminder for all inve stigators. As an addition, theres a bulletin board provided to keep track all valuable information must be known by all investigators. In graphs section, the factual information over incident like the top ten attacking IP and the number of malicious packet attempting to compromise the system can be displayed in intuitive manner together with the ability to create a report of them. This will give the understanding upon evaluation of event taking place to the system. Figure below shows how the graph can help a team of investigators especially those less technical to grasp factual information about the network/system:

Proceedings of Regional Conference on Knowledge Integration in ICT 2010

60

Figure 8: Graphically presented data gives intuitive understanding In collaborative section, the tool as depicted in Figure 9 and 10 below serves as the repository of all evidences found either to be or been analyzed, report, and analysis collection accessible in intuitive manner.

Figure 9: PacketMonzeight provides discussion board and file exchange for investigation

Figure 10: PacketMonzeight provides repository tool for investigation

Proceedings of Regional Conference on Knowledge Integration in ICT 2010

61

5. FUTURE WORK AND CONCLUSION The NSM technique for network forensics investigation provides promising answer over the needs and challenges in a complex network forensics investigation with massive data collection. The existence of collaborative tools in NSM analysis comprising pre-analysis tool and post analysis tool will help a team of investigators to easily set the workflow of investigation in organized manner and to work easier dealing with low level raw data. Using this approach in network forensics investigation, a well organized, concise, and clear investigation to presentation process will make legal proceedings benefit over the framework proposed in this research. Future work will be made for improvement in aspects of further development of prototype proposed in the post-analysis collaborative tool and developing intermediate application between those two types of collaborative tools. ACKNOWLEDGEMENT I sincerely express my utmost heartfelt appreciation and thanks to NSM worldwide community (Bejtlich, Vischer, Bianco, Edward F., Meling Mudin and CS Lee), my supervisors (Mr. Asrul Hadi Yaacob and Mr. Mohd Fikri Azli), and my cliques in Linux SIG MMU Melaka (Adnan Mohd Shukor, Leong Jaan Yeh, and Hafez Kamal).

REFERENCES Bejtlich, R. (2005). The Tao of Network Security Monitoring. Boston: Addison-Wesley. Carrier, Brian. (2003). Defining Digital Forensic Examination and Analysis Tools Using Abstraction Layers. International Journal of Digital Evidence Vol 1, 4 Casey, Eoghan. (2003). Network Traffics as A Source of Evidence : Tool Strengths, Weaknesses, and Future Needs .Digital Investigation (2004) I (p.28-43). Retrieved from : http://www.elsevier.com/locate/diin Digital Forensic Research Workshop. (2001). A Research Road Map to Digital Forensics. Utica, NY : DFRW E. Daniel, Larry. (2010, March 2010). Attorneys are from Mars, Computer Forensics People are from Pluto. Retrieved from: http://exforensis.blogspot.com/2010/03/attorneys-are-frommars- computer.html Garfinkel, Simson. (2002, April 26). Network Forensics: Tapping the Internet. Retrieved from: http://www.oreillynet.com/pub/a/network/2002/04/26/nettap.html [2009, November 27] Halliday, Paul. (2007, April 3). Squert-0.4.0 Has been released (Snort User). Retrieved from e-mail: hr@neohapsis.com [2009, November 17]. Jones, K. J., Bejtlich, R., & Rose, C. W. (2006). Real Digital Forensics: Computer Security and Incident Response. Upper Saddle River, NJ: Addison-Wesley. Kanellis, Panagiotis, Evangelos Kiountouzis, Nicholas Kolokotronis, Drakoulis Martakos. (2006). Digital Crime and Forensics Science. London: Idea Group Laurie, Ben.(2004, June) Network Forensics. Queue: Portal ACM Volume 2,Issue 4 50 56 [2009, November 18] Mandia, Kevin and Chris Prosise. (2001). Incident Response: Investigating Computer Crimes. California: McGraw-Hill

Proceedings of Regional Conference on Knowledge Integration in ICT 2010

62

Merkle, Laurence. D. (2008). Automated Network Forensics. Proceedings of the 2008 GECCO Conference : Companion on Genetic and Evolutionary Computation 19291932. Mohay, George et. al. (2003). Computer and Intrusion Forensics. Massachusetts: Artech House Inc. Mudin, Meling and C.S Lee. (2009, October). Network Forensics for Dummies. Paper presented at conference of HiTB SecConf 2009 Kuala Lumpur, Malaysia. Wang, W., & Daniels, T. E. (2005). Building Evidence Graphs for Network Forensics Analysis. Proceedings of the 21st Annual Computer Security Applications Conference (ACSAC 2005). IEEE Computer Society.

Proceedings of Regional Conference on Knowledge Integration in ICT 2010

63