52 Integration2010 Proceedings

8/13/2019 52 Integration2010 Proceedings

1/12

Proceedings of Regional Conference on Knowledge Integration in ICT 2010 52

COLLABORATIVE NETWORK SECURITY MONITORING (NSM) ANALYSIS

FOR NETWORK FORENSICS INVESTIGATION

Ali Fahmi Perwira Negara1, Asrul Hadi Yaacob

2, Mohd Fikri Azli Abdullah

3

1,2Faculty of Information, Science, and Technology (FIST)

Multimedia University (MMU) MalaysiaJalan Ayer Keroh Lama Melaka 75450 Malaysia

[email protected]@mmu.edu.my

3School of Electronics and Computer Engineering

Chonnam National University, South [email protected]

AbstractEasy 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 inwhich requires a special skill in a field known as digital forensics. Its sub discipline, networkforensics, 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 ajoint 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 ofdigital forensics. Complexity of the process and massive quantity of data being analyzed are

two major problems. There exists an advanced network monitoring technique called NetworkSecurity Monitoring (NSM) that comprehensively dealing with data travels across network as

a method on network forensics investigations. Based on NSM, this research addresses thoseproblems on network forensics. NSM provides a platform to help structured evidence

collection and further analysis in a complex network forensics investigation. The existencesof 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 ininvestigation 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 thedetails of design system and its implementation. Section 5 concludes the paper with a brief

summary.


2/12


2. RELATED WORKS

CS Lee and Meling Mudin (2009) explains network forensics as a process involving thecollection 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 onlyif 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 itmay or may not lead to a legitimate event. It may give a false alarm (either positive ornegative) 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.


3/12


3.2 NSM Analysis: From Raw Data to Presentable Evidence

Common network monitoring is often only up to data acquisition and analysis for one selfspurpose 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 amongthemselves, especially between technical investigators (IT experts) and non-technical ones

(policemen, prosecutors, etc.). Larry E. Daniel (2010) has expressed his experience regardingthe 2ndsituation in his article Attorneys are from Mars, Computer Forensics People are from

Pluto mentioning that it indeed exists a communicating barrier among the kind ofinvestigators 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


4/12


identification, they go to the most critical step that is preservation process. It will be the 2nd

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 thetrickiest 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 isreported 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 alsocontrols 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 anda 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 investigatingraw.

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: 1stsituation of raw data investigation and 2nd situation


5/12


on transitional analysis for proper evidence presentation. The tools are Sguil (pronounce assgweel) 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 investigationbased 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 informationdone 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 understandfor 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, andrecovering 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 secret

information. This attacker will try to gain access by exploiting a hole to gain root shell oradmin privileges. Upon successful, the attacker will breach into secret file data storage andget 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.


6/12


4.3.1 Attack Phase

The attack phase will consist of reconnaissance phase, exploit phase, and reinforcement-consolidation-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 takeplace 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 forfuture 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:


7/12


Figure 4: Alerts generated as a result of incident

From the warnings, the investigators now can detect and recognize what is likely the attackis. 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 lowleft 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.


8/12


4.3.3 Evidence Recovery Process

Another excellent factor implementing NSM is easy to recover the evidence needed to provesuch 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 regulardirectory, 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 stealinginformation from MICROSOLVE, and (c) the exploit attacks using Snortbopre exploit to port9080 (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 duringlaw 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


9/12


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 asgraphical 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 investigators. As an addition, theres a

bulletin board provided to keep track all valuable information must be known by allinvestigators. 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 belowshows how the graph can help a team of investigators especially those less technical to grasp

factual information about the network/system:


10/12


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


11/12


5. FUTURE WORK AND CONCLUSION

The NSM technique for network forensics investigation provides promising answer over theneeds 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 ofinvestigation 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), mysupervisors (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 EvidenceVol 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/diinDigital 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 Peopleare from Pluto. Retrieved from: http://exforensis.blogspot.com/2010/03/attorneys-are-from-

mars- computer.htmlGarfinkel, Simson. (2002, April 26). NetworkForensics: 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: [email protected] [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 ACMVolume 2,Issue 4 5056

[2009, November 18]

Mandia, Kevin and Chris Prosise. (2001). Incident Response: Investigating ComputerCrimes.California: McGraw-Hill


12/12


Merkle, Laurence. D. (2008). Automated Network Forensics. Proceedings of the 2008GECCO Conference : Companion on Genetic and Evolutionary Computation 1929-

1932.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. Paperpresented 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.

Date post:	04-Jun-2018
Category:	Documents
Upload:	rajwec
View:	216 times
Download:	0 times

52 Integration2010 Proceedings

Documents