Adaptable Software-based Log Consolidation and ...

Adaptable Software-based Log Consolidation and Incident Management for a Security Information Event Management System AdLCIM

A Thesis Presented to the Faculty of the College of Computer Studies De La Salle University

In Partial Fulfillment of the Requirements for the Degree of Bachelor of Science in Computer Science by Pineda, Justin David G. Yatco, Roberto F.

Mr. Miguel Gomez Faculty Adviser

December 17, 2010

Adviser’s Recommendation Sheet The thesis entitled Adaptable Software-based Log Consolidation and Incident Management for a Security Information Event Management System developed by: Pineda, Justin David G. Yatco, Roberto F. and submitted in partial fulfillment of the requirements of the Bachelor of Science in Computer Science degree, has been examined and recommended for acceptance and approval. ____________________________, Adviser ______________________________, Date

Panel’s Approval Sheet The thesis entitled Adaptable Software-based Log Consolidation and Incident Management for a Security Information Event Management System after having been reviewed, is hereby approved by the following members of the thesis committee:

Date

Date

Date

College Acceptance Sheet The thesis entitled Adaptable Software-based Log Consolidation and Incident Management for a Security Information Event Management System after having been recommended and reviewed, is hereby approved by the Computer Technology Department, College of Computer Studies, De La Salle University:

Mr. Clement Ong Chairperson Computer Technology Department

Dr. Rachel Roxas Dean College of Computer Studies

Date

Date

Acknowledgement Having experiences filled with difficulties and struggles are unavoidable in life. As years go by in our lives as being students, we realize that this is true. However, there are people who could boost your motivation along the way. The thesis stage may be the most difficult and struggling stages on being a college student. The group had to endure more than a year to develop its thesis, which is AdLCIM. Since there were people who motivated us during the development, the end of the thesis stage was reached. For that, I would like to thank the following people who helped us to complete this stage. To Mr. Paul Inventado. Thank you for helping us in using Latext for the thesis conference documentation. Even though you were not our student in any subject, you willingly helped us in troubleshooting and fixing our issues regarding the documentation. To my classmates and friends. Thank you for the support. Without your encouragement, help and inspiration, we may not have made it to the finish. To Ms. Ana Pedro. Thank you for being our temporary thesis adviser even if it is for only a few weeks. Those few weeks still helped us in our thesis progress. To Kuya Davis and Kuya Rommel. Thank you for always letting us use the Netlab and CT lab. It has been a great help in our testing and development. To our panelists, Mr. Gregory Cu, Ms. Jocelyn Cu and Ms. Rhia Trogo. Thank you for being there all throughout our these terms for our thesis. Your comments and suggestions helped improve our thesis, whether it be documentation or software. To our current thesis adviser Mr. Miguel Gomez. Thank you for having the patience in being our adviser. Even though there were some bumps along the way, we really appreciate your support and effort in guiding us to the very end. To my parents. Thank you for the undying support you gave us as we struggle throughout the years in our college life. Your presence and support gave us a positive output in our studies. To my thesismate, Justin David Pineda. Thank you for always being patient with me whenever it involves meeting. I know I sometimes have been irresponsible but times, but you kept me going in doing my responsibilities. I know that this has been quite an adventure for the both of us. Lastly, to our previous thesis adviser, Mr. Alexis Pantola. Thank you for the times when you were our teacher in some subjects and for being our first adviser. The thesis had a good start because of your knowledge in our specialization and because of your feedbacks regarding our document and software. Even though there was a separation between you and the group, we really appreciate your help in the progress of our thesis. We are sorry for the times we fail to meet the demo requirements during deadlines.

Even though the group had to extend a term for our thesis, we sincerely thank all of these people. Without them, we may not have been able to completely finish our thesis. Roberto Yatco Jr. I’m very proud and happy that Yatco and I are able to finish our thesis. Thanks for your patience, Yatco! I personally admit that we are not the best students in CCS but certainly I think that doing the thesis on our own helped us become better individuals. I learned a lot especially becoming responsible for actions and decisions I’ve made. For this I would like to express my sincerest gratitude to the following: 1. To God Almighty, the source of my knowledge, strength and wisdom. This thesis for you Lord. Thank you for always being there for me in every step of the way. I know you won’t leave me behind and I offer this work for you. 2. To my parents who have always supported me in the completion of my thesis. I know there are a lot of times that I made you angry, disappointed or upset. But thank you for all the rest and giving me all out support, love and care. Thank you for helping me made the right decisions and brought the best out of me. You’re the best mama and papa in the world! 3. To Dr. Raymund Sison, Dr. Ada Pablo-Dela Cruz and my FORMDEV family. You have been there since Day 1. You listened and supported me all the way. Thank you for all the prayers everyday and most especially during the times I was so down. Thank you and God bless. 4. To Sir Miko Gomez, my beloved adviser. Thank you for helping the group in spite of all uncertainties and doubts. Thank you for staying with us and staying positive that we can finish the thesis. I’m sorry for arguing sometimes. You know how I’m scared that I am not going to finish this. 5. To Sir Alexis Pantola, my former adviser. Thank you for being with us until the last moment you can. I really appreciate you. I learned a lot from you. I’m sorry if I’m not person you expect me to be. I admit I’m not great. I’m just me and trying to do my best. Thank you for staying with us and giving us good advice for our thesis. You’re my favorite professor in school. Thank you for everything. God bless in your dissertation! 6. To Sir Clement Ong, the instructor present in the Summer Camp. It’s you who made me pick Network Engineering. Thank you Sir for being part of my decision making. I realized I’m not really into the electronics part but I learned a lot in NE. I really don’t know where I’ll be if not for your CT influence. You gave me

knowledge of what to pick although sometimes I regret of choosing NE. But later on I think that it is one if the best courses ever made! Thank you very much. 7. To Sir Paul Inventado, thank you for being our third thesis mate in THSNE-2. You joined the pressure in finishing the journal. I really appreciate your advice and participation in making our document in ACM format. God bless in your dissertation! 8. To my relatives (both in mother and father side) and friends who didn’t surrender in encouraging me that I can do my thesis and finish it even if not on time. Thank you for always praying and continuously supporting me. I feel more blessed than a famous star with lots of fans. You made be stronger and better. 9. To Rommel Borlagdan, the CT-Lab technician. I thank you Kuya Rommel for helping us setup the devices and allotting time so that we can use both the Netlab and the CT-Lab. 10. To those people who think that we can’t finish the thesis. Thank you for challenging me to do and give my best shot in finishing this. I’ve never been this serious before. I’m sorry that I disappoint you because we did finish our thesis. But I really thank you for trying to pull us down because it made us stronger and more resilient in overcoming our problems. Thank you. 11. Last but not the least, to Ashley Dy who has been the most understanding and loving person all the time. Thank you for being my inspiration. I love you very much and this thesis is just another sign that I’m moving towards a new chapter in my life with you. For some trimesters we have been doing this thesis, there are a lot of emotions that touched my heart. But no matter how bad or good the situation is, the thesis is done and I’m free. Thank you. Justin David Pineda

Abstract The Security Information and Event Management (SIEM) enhances the security management of an organization by storing and analyzing logs coming from different network devices and giving possible recommendations that can be warnings, notices or alarms. Companies are beginning to invest in SIEM to protect their data and to help network or system administrators monitor the state of their workplace. A lot of SIEM products focus on security tools and lack log consolidation and incident management solutions. The Adaptable Software-based Log Consolidation and Incident Management (AdLCIM) is a type of SIEM that works on a typical Local Area Network (LAN) where various network devices report status to the system. The system is capable of collecting different logs coming from different, identified network devices. It is also capable of standardizing logs into its format, consolidates and correlates patterns through its inventories. All resolvable attack logs are event sniped, while non-resolvable logs are flagged as alerts. The system is capable of handling different scenarios with different devices, and tests result confirmed successful log analysis. The system, moreover, is capable in running for long durations of time to see if the system is capable of analyzing all the logs coming from different, identified network devices. Overall, the performance of the system came up with the correct and accurate results in verifying log analysis from different network devices having different scenarios.

Table of Contents 1.

Introduction....................................................................................................................... 1-1 1.1 Overview ................................................................................................................... 1-1 1.2 Problem Statement .................................................................................................. 1-3 1.3 Research Objectives................................................................................................. 1-3 1.3.1 General Objective ............................................................................................... 1-3 1.3.2 Specific Objectives .............................................................................................. 1-3 1.4 Project Scope and Limitations ............................................................................... 1-4 1.5 Test and Verification Method ................................................................................ 1-5 1.5.1 Log Identity Test ................................................................................................. 1-5 1.5.2 Log Grouping Accuracy Test ............................................................................ 1-5 1.5.3 Report and Recommendation Generation Test.............................................. 1-6 1.5.4 Incident Management Test ................................................................................ 1-6 1.5.5 Comprehensive Test ........................................................................................... 1-6 1.6 Significance of the Study......................................................................................... 1-6 1.7 Research Methodology............................................................................................ 1-7 1.7.1 Research................................................................................................................ 1-7 1.7.2 Initial Test............................................................................................................. 1-7 1.7.3 Implementation of SIEM................................................................................... 1-7 1.7.4 2nd Testing........................................................................................................... 1-7 1.7.5 Gantt Chart of Activities.................................................................................... 1-7 1.8 Resources .................................................................................................................. 1-8 1.8.1 Hardware .............................................................................................................. 1-8 1.8.2 Software ................................................................................................................ 1-8 2. Review of Related References......................................................................................... 2-1 2.1 Review of Related Work ......................................................................................... 2-1 2.1.1 ArcSight [4]........................................................................................................... 2-1 2.1.2 Open Source Security Information Management (OSSIM) [25].................. 2-1 2.1.3 Intellitactics Security Manager (ISM) [20]........................................................ 2-2 2.1.4 Cisco Security Monitoring, Analysis and Response System (MARS) [7] .... 2-2 2.1.5 Centralized Security Manager (CSM) [1].......................................................... 2-2 2.1.6 Virtual Information Security Testing System (EPSILON) [12] ................... 2-2 2.1.7 Network Monitoring System Using RMON Standards (NEMSYS Online)............................................................. 2-2 2.2 Review of Related Literature.................................................................................. 2-3 2.2.1 Design and Implementation for Security Information Management (DIMSIM) [27] ...................................................... 2-3

2.2.2

Analyzing Logs for Security Information Event Management (ALSIEM) [2] ................................................................... 2-3 2.2.3 iSims SI (EIT/SDT) Management System (iSIMS) [21]................................ 2-3 2.2.4 Distributed and Decentralized Event Management for Embedded Systems (DDEMES) [18] ........................................................ 2-4 2.2.5 Forward Integrity for Secure Audit Logs (FISAL) [5]................................... 2-4 2.2.6 Integrated Event Management: Event Correlation Using Dependency Graphs (IEMECUDG) [13]............................................ 2-4 2.2.7 Magic Quadrant for Security Information and Event Management (MQSIEM) [23]................................................................ 2-4 2.2.8 Mining Event Data for Actionable Patterns (MEDAP) [14]........................ 2-4 2.2.9 Correlating SIM Information to Detect Insider Threats (CSIDIT) [10]..... 2-5 3. Theoretical Framework.................................................................................................... 3-1 3.1 Security Information Event Management (SIEM).............................................. 3-1 3.2 Security Information Management (SIM) ............................................................ 3-1 3.3 Security Event Manager (SEM) ............................................................................. 3-1 3.4 Log Normalization................................................................................................... 3-1 3.5 Log Parsing ............................................................................................................... 3-2 3.6 Log Consolidation ................................................................................................... 3-2 3.7 Log Consolidation Time ......................................................................................... 3-2 3.8 Event Sniping ........................................................................................................... 3-2 3.9 Shunning.................................................................................................................... 3-3 3.10 Incident Management.............................................................................................. 3-3 3.11 Alert Management.................................................................................................... 3-3 3.12 Threat Correlation ................................................................................................... 3-3 3.13 Reporting Operational Efficiency/Effectiveness Compliance ......................... 3-4 3.14 Intrusion Detection System (IDS)......................................................................... 3-4 3.15 Dynamic Loading..................................................................................................... 3-4 3.16 .dll File ....................................................................................................................... 3-4 3.17 Simple Network Management Protocol (SNMP) ............................................... 3-4 3.18 SNMP Agent ............................................................................................................ 3-5 3.19 Syslog ......................................................................................................................... 3-5 3.20 Syslog Agent ............................................................................................................. 3-5 3.21 TCP/IP...................................................................................................................... 3-6 3.22 TCP............................................................................................................................ 3-6 3.23 UDP ........................................................................................................................... 3-6 3.24 ICMP ......................................................................................................................... 3-6 3.25 Hostname.................................................................................................................. 3-7 3.26 IP Address................................................................................................................. 3-7 3.27 Facility........................................................................................................................ 3-7 3.28 Severity ...................................................................................................................... 3-7 3.29 Priority....................................................................................................................... 3-7 3.30 Device Discoverer ................................................................................................... 3-8 3.31 NMAP ....................................................................................................................... 3-8 3.32 RST Packet................................................................................................................ 3-8 3.33 Tini ............................................................................................................................. 3-8

3.34 Device Inventory ..................................................................................................... 3-8 3.35 Attack Inventory ...................................................................................................... 3-9 3.36 Port Mirroring .......................................................................................................... 3-9 4. Adaptable Software-based Log Consolidation and Incident Management System (AdLCIM) ..................................................................... 4-1 4.1 System Overview...................................................................................................... 4-1 4.2 Architectural Design................................................................................................ 4-2 4.2.1 Device Identifier Module ................................................................................... 4-3 4.2.2 Device Recognizer Module................................................................................ 4-3 4.2.3 Log Collector Module......................................................................................... 4-3 4.2.4 Log Normalizer Module..................................................................................... 4-3 4.2.5 Log Consolidator Module.................................................................................. 4-4 4.2.6 Event Analyzer Module...................................................................................... 4-4 4.2.7 Incident Manager Module.................................................................................. 4-4 4.2.8 Alert Manager Module........................................................................................ 4-4 4.2.9 Report/Recommendation Generator Module................................................ 4-4 4.2.10 Events Updater Module................................................................................. 4-5 4.3 Theoretical Analysis................................................................................................. 4-5 4.3.1 Device Identifier Module ................................................................................... 4-5 4.3.2 Device Recognizer Module................................................................................ 4-5 4.3.3 Log Collector Module......................................................................................... 4-6 4.3.4 Log Normalizer Module..................................................................................... 4-6 4.3.5 Log Consolidator Module.................................................................................. 4-6 4.3.6 Event Analyzer Module...................................................................................... 4-7 4.3.7 Incident Manager Module.................................................................................. 4-7 4.3.8 Alert Manager Module........................................................................................ 4-8 4.3.9 Report/Recommendation Generator Module................................................ 4-8 4.3.10 Events Updater Module................................................................................. 4-9 4.4 System Design ........................................................................................................4-10 4.4.1 Device Identifier Module .................................................................................4-11 4.4.2 Device Recognizer Module..............................................................................4-13 4.4.3 Log Collector Module.......................................................................................4-14 4.4.4 Log Normalizer Module...................................................................................4-16 4.4.5 Log Consolidator Module................................................................................4-18 4.4.6 Event Analyzer Module....................................................................................4-20 4.4.7 Incident Manager Module................................................................................4-21 4.4.8 Alert Manager Module......................................................................................4-22 4.4.9 Report/Recommendation Generator Module..............................................4-23 4.4.10 Events Updater Module...............................................................................4-24 5. System Implementation..................................................................................................5-25 5.1 Device Identifier Module......................................................................................5-25 5.2 Device Recognizer Module ..................................................................................5-26 5.3 Log Collector Module ...........................................................................................5-26 5.4 Log Normalizer Module .......................................................................................5-27 5.5 Log Consolidator Module.....................................................................................5-29 5.6 Event Analyzer Module ........................................................................................5-30

5.7 Incident Manager Module.....................................................................................5-30 5.8 Alert Manager Module ..........................................................................................5-30 5.9 Report Recommendation Generator Module....................................................5-31 5.10 Events Updater Module........................................................................................5-31 6. Performance Evaluation .................................................................................................. 6-1 6.1 Verifying the Functionality of the Device Identifier Module............................ 6-1 6.2 Verifying the Functionality of the Device Recognizer Module ........................ 6-3 6.3

Verifying the Functionality of the Device Identifier and Device Recognizer Modules in a Live Normal Environment........................... 6-4 6.4 Verifying the Functionality of the Log Collector Module ................................. 6-7 6.5 Verifying the Functionality of the Log Normalizer Module ............................. 6-9 6.6 Verifying the Normalization of Logs in a Live Normal Environment ..........6-13 6.7 Verifying the Functionality of the Log Consolidator Module.........................6-14 6.8 Verifying the Functionality of the Log Correlation Process............................6-16 6.9 Verifying the Functionality of the Log Consolidation Time of the Log Consolidator Module...............................................................6-18 6.10 Verifying the Functionality of the Alert Manager Module ..............................6-20 6.11 Verifying the Functionality of the Incident Manager Module.........................6-23 6.12 Verifying the Functionality of the Report Generator Module ........................6-26 6.13 Verifying the Functionality of the Events Updater Module............................6-27 6.14 Verifying the Functionality of the Incident Manager Module in a Live Network ................................................................... 6-29 6.15 Verifying the Functionality of the Incident Manager Module in a Live Network with a Different Subnet.........................................6-30 6.16 Verifying the Comprehensiveness, Accuracy, Stability and Usability of All the Modules in Integration Running in a Normal Live Environment through Massive Logs from Different Devices and Users .....6-32 6.17 Verifying the Comprehensiveness, Accuracy, Stability and Usability of All the Modules in Integration in a Different Network Setup........................6-36 6.18 Verifying the Functionality of the SNMP Processing of the System .............6-39 7. Conclusion and Recommendations................................................................................ 7-1 7.1 Conclusion ................................................................................................................ 7-1 7.2 Recommendation ..................................................................................................... 7-2 7.2.1 Recommendation for the Device Identifier Module...................................... 7-2 7.2.2 Recommendation for the Log Normalizer Module ....................................... 7-3 7.2.3 Recommendation for the Log Consolidator Module..................................... 7-3 7.2.4 Recommendation for the Incident Manager Module .................................... 7-3

1.

Introduction 1.1

Overview

The Security Information and Event Management System (SIEM) is one key technology to address security risks as it serves as a secured central logging and analysis solution that leverages the investment that has already been made in the organization's technology up to a higher, more useful level. SIEM can be put in a simple routine that takes alerts from a range of systems (firewalls, routers, anti-malware, and servers), gathers and secures input logs and informs IT teams of unusual occurrences which warrant further investigation. As well as collecting and storing this raw log data, the system safeguards the data for subsequent audit needs and for compliance-aligned reporting. [28] There are four major functions of SIEM solutions: 1. Log consolidation, which centralizes logs to a server; 2. Threat correlation that serves as the pattern or algorithm used to sort through multiple logs and log entries to identify attackers; 3. Incident management that takes action after a threat is identified; and 4. Reporting Operational Efficiency/Effectiveness Compliance that checks if the network devices are working properly. There are two branches on the SIEM tree – operational efficiency and effectiveness, and log management/compliance. Both are achievable with a good SIEM tool. The most compelling reason for an SIEM tool from an operational perspective is to reduce the number of security events on any given day to a manageable, actionable list, and to automate analysis such that real attacks and intruders can be discerned. [29] The SIEM market is driven by an increasing need for customers to meet compliance requirements as well as continued need for near-real-time awareness of external and internal threats. The market remains fragmented with no dominant vendor. [23] SIEM companies set their own SIEM standards based from their company needs. Gartner made a comparison of different SIEM products that show extreme differences from prices to features. There are a lot of companies that currently offer SIEM but three existing products are used for comparison and contrast. [23] Each of these products is part of a particular SIEM category (enterprise, small business, shareware) and from there, it finds out a common problem, which this paper tries to solve. The Open Source Security Information Management (OSSIM) is a shareware SIEM software that offers several software components that can be useful in safeguarding a system. There are tools that can be used for anomaly detection, intrusion detection and prevention, vulnerability assessment and other network security tools. There are good existing tools that can be helpful in giving security to a network system that is provided by OSSIM such as Arpwatch, P0f, Pads, Nessus, Snort, Spade, Tcptrack, Ntop, Nagios, Osiris, OCS-NG and OSSEC. There have been limitations to these existing programs though because the intended scope was to protect a small business or even a private network. Implementation for the OSSIM tools is simple and available Adaptable Software-based Log Consolidation and Incident Management for a Security Information Event Management SystemAdLCIM

1-1

everywhere to download and use. It answers the need for common network security problems but it cannot solve sophisticated attacks. The Intellitactics Security Manager (ISM) is another SIEM software but not a shareware compared to OSSIM. It uses host intrusion detection and prevention system (IDS/IPS) events with other security events (like that of OSSIM). It answers the limitation of OSSIM which is incident management by providing reports although it does not generate or conclude solutions or recommendations when there are problems detected in a certain system or environment. The system is good for mid-range businesses that need an SIEM, which is not very limited with common features but not as specific as those high-end software. [20] Based on the common features mentioned, ISM overlooked some features found in other common SIEM software which includes operational performance, user monitoring, log data for log consolidation and proves and/or assures compliance. ArcSight is an enterprise SIEM product that has the elements of an SIEM software. It can manage to secure a particular based from its sophisticated network security infrastructures with high-end software-implemented components. It also has scalable audit quality log collection option for remote locations across the enterprise. It can be concluded that it is the best SIEM product. [4] However, the enterprise cost starts at $15,000, which is quite impractical and expensive to buy for small and medium scale businesses. Another limitation for the product is that it is not optimized in collection and indexing of all logs. It also requires server and database expertise. Based on the common features, ArcSight has all these features, which is why according to Gartner it was concluded to be the best SIEM product. [23] There are features applied to have secured input logs, event management in a system, as well as convenience for the users in each SIEM software. Common features of an SIEM software are used as a criteria in evaluating the level of usefulness of existing SIEM products. Log consolidation organizes logs and gives security to its contents. Intrusion Detection/Prevention System detects unwanted access to computer systems. Security Event/Information Management is a tool used to store and interpret logs of events. Incident Management is an action taken in finding out solutions after an attack is made. Operational performance is a measurement on the response of the software to commands. User monitoring is the capability of the software to supervise users in their network activities. A predecessor SIEM called Central Security Manager (CSM) was designed as an undergraduate thesis in De La Salle University in 2004. [1] The CSM became the central storage of logs for a proprietary Intrusion Detection System (IDS). The CSM, for its part, aside from logging data, acts as an event sniper, which resets a particular configuration of a computer component (e.g. firewall) when an abnormal behavior is interpreted. The thesis may be considered as an SIEM because of its logging ability and a slight incident management capability. However, the software has compatibility issues Adaptable Software-based Log Consolidation and Incident Management for a Security Information Event Management SystemAdLCIM

1-2

because it is only limited to particular IDS to work. The incident management part of the SIEM is also limited because it only acts as an event sniper. In most of the existing SIEM solutions, there have been problems with Log Consolidation and Incident Management. ArcSight has incident management; however, it lacks the segregation of logs, which might make incident management solutions ineffective. Intellitactics also has incident management by providing different reports however, it does not conclude or recommend solutions when there are problems in a certain system or environment. [20] OSSIM has different components that can safeguard a system however, it needs to expand its internal incident management function and support customized reports. [25] With respect to other existing SIEM products like Consul, IBM Tivoli Neusecure and NetIQ Security Manager for instance, these focus more on the network security implementation with the security tools and have overlooked proper log analysis. [23] 1.2

Problem Statement

A lot of SIEM products focus on security tools and lack solutions in log consolidation and incident management. Furthermore, the SIEM predecessor CSM is limited to logging and to compatibility with other devices. However, it does not give any recommendations and its action is limited to event sniping. 1.3 1.3.1

Research Objectives General Objective

The study of the SIEM aims to present and implement log analysis that gives actions and recommendations after analyzing collected logs and incident management that analyzes attacks and component crashes, determines its effects and gives report for possible solutions. 1.3.2

Specific Objectives

Specifically, this study aims to: • • • • •

create a software that accepts packet logs from existing network devices that are connected in a network; scan through large amounts of logs and gather relevant information based from the information collected; generate reports based on logs gathered and give possible recommendations; recognize different incidents such as attacks, component crashes and respond by giving appropriate recommendations and solutions; and test the effectiveness of the prototype SIEM tool by injecting different packet scenarios and see the response of the tool.

Adaptable Software-based Log Consolidation and Incident Management for a Security Information Event Management SystemAdLCIM

1-3

1.4

Project Scope and Limitations

The solution presented in this study covers analyzing accepted logs and giving recommendations based on the results generated. The AdLCIM accepts logs from different network devices such as routers, Intrusion Detection/Prevention System (IDS/IPS), firewalls and switches. Log information gathered from these network devices includes date, time, source and destination IP, protocol, source and destination port number, classification (whether it is a normal log or a threat) and priority. The system implements a Log Normalization Module for product compatibility, which accepts different format of each device and makes the devices compatible with AdLCIM. Both Simple Network Management Protocol (SNMP) agent and Syslog events are used in collecting information for the Log Normalization. The module uses dynamic loading to solve compatibility issues without recompiling the software again. Logs gathered are put in a log table with the essential information needed as mentioned. The logs are consolidated through threat correlation techniques like logical correlation1, cross correlation2 and inventory correlation3 [3]. Usage of artificial intelligence is still undetermined and may be used in the study. The system does not detect attacks. The IDS/IPS performs the actual incident detection. The system only consolidates attack-related logs from network security devices like IDS/IPS. The table shown below is a list of vulnerabilities or incidents found by Nessus. [30]. These vulnerabilities or incidents are detected and classified afterwards. The system is going to have a similar table with recommendations added in the table’s column for the vulnerabilities or incidents. Table 1-1. List of Sample Incidents/ Vulnerabilities, Classification and Recommendations from Nessus Incidents/ Vulnerabilites

Classification Recommendation/s

Open Port

Low

Ping the remote host

Low

Further observation of activity or connection. Further observation of activity or connection.

It refers to logical rules to join different small events to match a new pattern. This type of correlation compares information from IDS's and vulnerability scanners, prioritizing the event in case the information is vulnerable or not to a particular attack. 3 It checks if the attack affects a certain Service and Operating System type and version, and checks if the attacked host has that OS/Service active, discarding the event if not. 1-4 Adaptable Software-based Log Consolidation and Incident Management for a Security Information Event Management SystemAdLCIM 1 2

Traceroute

Low

OS Identification

Low

Show Connections

Low

VMware Guest

Low

Bad Login: user input wrong username/ password for more than 10 times Unable to detect hardware

High Medium

Further observation of activity or connection. Further observation of activity or connection. Further observation of activity or connection. Further observation of activity or connection. Terminate session. Check physical layer or ports of the hardware.

The AdLCIM implements the three major features of an SIEM solution that includes log consolidation, threat correlation and incident management The scope of this study does not include the implementation of the fourth SIEM solution- reporting operational efficiency/effectiveness compliance. The recommendations for each log are based on the current knowledge of existing IDS/IPS in detecting attacks. Other attacks that are beyond the knowledge of the IDS/IPS are not detected and must be checked manually by the network administrator/ authorized person. The software is implemented using C#. It is not portable and can only run in a Windows operating system. The software is expected to run in a typical Local Area Network (LAN) workplace with computers, printers, routers and switches. The log analysis gets logs from network devices like routers, switches, firewalls, servers and workstations. 1.5 1.5.1

Test and Verification Method Log Identity Test

This test verifies the correctness of the packet collected by the SIEM. It aims to see if the logs are put in the proper place in the log table. The tester knows the content of each packet. After the series of injected packets, the parameters of the log table are compared to the correct contents in the tester’s scripted report. 1.5.2

Log Grouping Accuracy Test

This test aims to know the accuracy of the software in consolidating logs based on its similarities and patterns. The system accepts several logs and groups the logs according to its knowledge based on the groupings of the logs. The scripted record, which includes the correct groupings of the logs, is compared to the groupings made by the software.


1-5

1.5.3

Report and Recommendation Generation Test

This test aims to see the accuracy of the report, which the software generates. It checks if the report generated is accurate based from the log and packet it has received. It also checks the recommendations’ effectiveness based from its decision skills. The decision is made from a condition given to the log. Based from the packets and logs that the software has gathered, it has to prepare a report and a possible recommendation. 1.5.4

Incident Management Test

This test aims to check if the SIEM is able to handle different incidents that are logged to the AdLCIM and solved by the IDS/IPS. Different incidents like port scanning and ARP poisoning are used to see if the software can respond to it in the expected manner. 1.5.5

Comprehensive Test

This is a comprehensive test, which involves tests from 1.5.1 to 1.5.4. It aims to simulate a near real-life deployment of the software. It sees the stability of the software by simulating different events that might occur. In this test, 5 different events are set within an hour. Different devices are configured to respond to these events by sending logs to the AdLCIM. The system should be able to group the logs based on the events that triggered the transmission of the logs. 1.6

Significance of the Study

Currently, a lot of SIEM software is prevalent by giving different features of what the company needs. Most companies provide tools that are intended to help and to answer their problems. However, since these companies are highly-specialized in their SIEM product, a lot of companies that are just starting in the market and beginning to become aware of the need of an SIEM do not have the enough knowledge about it. These companies do not know the kind of SIEM product that is suitable for them. The software addresses the most essential need of a company by giving useful network security tools that safeguard its workplace. The sophisticated tools can be rooted from the logs and recommendations that are gathered. Once these companies have known the frequent things and events that happen in the network, they can look for the suitable tools that they can complement with the SIEM software. The study aims to implement and perform log analysis and incident management at small- to medium-sized networks. Existing computer resources can also be used in upgrading the software made. This system can address the issue of data collection and tools needed to be used in actual company deployment. The software’s implementation contributes in network security development with affordable and available resources.


1-6

1.7 1.7.1

Research Methodology Research

The initial phase of the study involves researching on key related topics like functions, features and existing products of Security Information Event Management (SIEM) system. Included also in the research are the design and implementation of different SIEM documentation. The research on log consolidation includes the study of different algorithms in data collection. Different parameters that are used in placing logs in the log table are included in the study. A more comprehensive study on data segregation is also researched. Patterns in logs are remembered and logs with commonalities are combined together. A research on the different incident responses is also conducted. List of possible incidents and possible solutions are studied. 1.7.2

Initial Test

This phase tests existing enterprise and shareware SIEM products. These all differ from one another because of their available features. 1.7.3

Implementation of SIEM

Log consolidation and incident management are designed and implemented. It is designed in such a way that it is capable of collecting logs scanned by the system and group them based on their contents. 1.7.4

2nd Testing

This phase tests the whole functionality of the system. The system generates a report with a possible solution or recommendation based from the logs gathered. The possible solution or recommendation is based from the decision skills of the software. 1.7.5

Gantt Chart of Activities

Activity Technology overview Supporting references

Jan ‘09

Feb ’09

Mar ‘09

Apr ‘09

Theoretical framework Documentation Adaptable Software-based Log Consolidation and Incident Management for a Security Information Event Management SystemAdLCIM

1-7

Activity System design Log analysis and incident management design Modifications

May ‘09

Jun ’09

Activity Sept - Oct ‘09 Log analysis and incident management creation Implementation Software testing

Nov - Dec ’09

Activity Combination of software made and existing tools Compare to freeware and enterprise SIEM Final documentation

Jul - Aug ‘10

1.8

May - Jun ‘10

Jul ‘09

Aug ‘09

Jan – Feb ‘10

Mar – Apr ‘10

Sept - Oct ‘10

Nov - Dec ‘10

Resources

1.8.1 Hardware  Mediation server A computer which is used as the main server of the system where it analyzes and groups logs and gives recommendations.  Network devices Routers, switches or hubs that can be used to elicit logs for the software implemented.  Workstation Computers are used by users that are connected to network devices. 1.8.2 Software  OSSIM This software is a shareware SIEM version that is available to everybody. It is used to have a comparison of SIEM to the SIEM study that is implemented.


1-8

 WinSysLog This is sample log consolidation software that can be used as a basis in creating a software for study.  Wireshark It is a network protocol analyzer used to check packets passing through a network.


1-9

2.

Review of Related References 2.1

2.1.1

Review of Related Work ArcSight [4]

ArcSight Logger supports collection from any raw syslog or file based log source. ArcSight Logger also supports the vast library of ArcSight Connectors which optimize collection for over 275+ distinct log generating sources. Additionally, the ArcSight FlexConnector framework extends log collection capabilities to custom sources and inhouse applications that are required for regulatory compliance. With the flexibility of software or appliance based turnkey deployments, ArcSight Connectors provide a scalable audit quality log collection option for remote locations across the enterprise. In addition to providing a secure and reliable connection to the ArcSight Logger data store, ArcSight Connectors also offer bandwidth controls, log traffic prioritization by time or severity, local caching, and failover across ArcSight Logger appliances. At the high end, ArcSight Logger captures raw logs at sustained rates in excess of 100,000 events per second (EPS) per appliance. Performance can be linearly scaled through the addition of ArcSight Logger appliances which operate as an array of peers. Across the Logger appliance family, a range of collection performance options are available to optimally address the needs of both large and small organizations. 2.1.2

Open Source Security Information Management (OSSIM) [25]

The goal of OSSIM is to provide a comprehensive compilation of tools which, when working together, grant a network/security administrator with detailed over each and every aspect of his networks. It provides a strong correlation engine, detailed low, mid and high level visualization interfaces as well as reporting and incident managing tools, working on a set of defined assets such as hosts, networks, groups and services. It features the following software components: Arpwatch, P0f, Pads, Nessus, Snort, Spade, Tcptrack, Ntop, Nagios, Osiris, OCS-NG and OSSEC. OSSIM is a good choice for organization, with limited resources, that are looking for an "lout of the box" SEM solution with modest server-side resource requirements. It needs to expand its internal incident management function and its support for customized reports. Organizations that are focused primarily on SIM or have compliance-oriented requirements should evaluate offerings that are more mature in these areas.


2-1

2.1.3

Intellitactics Security Manager (ISM) [20]

The Intellitactics Security Manager (ISM) automatically uses host intrusion detection and intrusion prevention system (IDS/IPS) events with other security events to bring a broader context on threats. Security Manager focuses the security analyst on alerts with the greatest impact on the business and enables compliance with regulatory standards. Third Brigade, a software company, announced the integration of its product with Intellitactics™ Security Manager, a comprehensive security information and event management (SIEM) solution. The thing about this tool is that it does not generate or conclude solutions or recommendations when there are problems detected in a certain system or environment. 2.1.4

Cisco Security Monitoring, Analysis and Response System (MARS) [7]

Cisco Security Monitoring, Analysis, and Response System (MARS) provides security monitoring for network devices and host applications supporting both Cisco and other vendors. Security monitoring with MARS greatly reduces false positives by providing an end-to-end topological view of the network, which helps improve threat identification, mitigation responses, and compliance. 2.1.5

Centralized Security Manager (CSM) [1]

The Centralized Security Manager (CSM) is considered predecessor SIEM that is limited to logging and to compatibility with other devices. It does not generate any possible reports and recommendations in its reports. Moreover, its action is limited to event sniping. The aim of this study is to create a centralized security manager that coordinates intrusion detection in its segments of a single network using localized intrusion-detection sensors in its segments. 2.1.6

Virtual Information Security Testing System (EPSILON) [12]

The Virtual Information Security Testing System (Epsilon) utilizes virtualization of technology in order to create a library of virtual machines serving as an information security library. The reason for this is that the implementation of information security libraries, mainly composed of isolated physical networks, is difficult to implement due to the amount of time and money in setup and maintenance. It is composed of two components: the Epsilon Server and the Epsilon Administrator. These components enable the system to perform several tasks. 2.1.7

Network Monitoring System Using RMON Standards (NEMSYS Online) [7]

The Online Network Monitoring System Using RMON Standards (NEMSYS Online) is a network monitoring application that uses RMON together with SNMP to see graphical representation of network traffic and detects any network-related issues that may occur Adaptable Software-based Log Consolidation and Incident Management for a Security Information Event Management SystemAdLCIM

2-2

in the network. The system has an implemented optimized problem and symptom list for net 2.2 2.2.1

Review of Related Literature Design and Implementation for Security Information Management (DIMSIM) [27]

This is a proprietary design and implementation paper made by RSA®, The Security Division of EMC. Included in the paper are the services of the software- asset identification, baseline, reports, alerts, forensics and incident management. The RSA enVision appliance uses an advanced, agent-less architecture to collect and correlate all your security information. Information stored on the EMC Celera system is highly accessible, enabling efficient real-time analysis. The EMC Centera system is a purpose built, cost effective archive designed to assure the authenticity of stored data. The information is stored on the Centera system for the duration of the required retention period and is used for forensicanalysis and compliance reporting. 2.2.2

Analyzing Logs for Security Information Event Management (ALSIEM) [2]

The paper describes the importance of Log Analysis. It also explained the technical definition of SIEM, that it is a combination of SIM and SEM. The Log Analysis consists of collecting, analyzing, archiving and reporting of data. The paper also suggests the use of ManageEngine® EventLog Analyzer for SIM asnd ManageEngine® Firewall Analyzer for SEM. All network systems and devices like Windows/Linux desktops and servers, routers, switches, firewalls, proxy server, VPN, IDS and other network resources generate logs by the second. And these logs contain information of all the system, device, and user activities that took place within these network infrastructures. Log files are important forensic tools for investigating an organizations security posture. Analysis of these log files provide plethora of information on user level activities like logon success or failure, objects access, website visits; system and device level activities like file read, write or delete, host session status, account management, network bandwidth consumed, protocol and traffic distribution; and network security activities like identifying virus or attack signatures and network anomalies. 2.2.3

iSims SI (EIT/SDT) Management System (iSIMS) [21]

iSims uses a specialized, intuitive user interface and based on the iMux Multiplexer, a robust and capable system for data streaming activities. You can filter which events or services may pass through a connection which allows you to easily design the data flow Adaptable Software-based Log Consolidation and Incident Management for a Security Information Event Management SystemAdLCIM

2-3

the way you want it to be. The system can be used in headends, playout centers and contribution and distribution networks. 2.2.4

Distributed and Decentralized Event Management for Embedded Systems (DDEMES) [18]

The paper introduced a new distributed architecture which is able to provide event management services for embedded systems running complex applications which can meet the implied future scalability demands among other demands. It has also put special focus on the main bottleneck for the communication infrastructure between the embedded systems themselves and the lowest event management instances in the event management infrastructure. 2.2.5

Forward Integrity for Secure Audit Logs (FISAL) [5]

In this paper it defined forward integrity security as property that motivate its security system requirement's appropriateness and demonstrate designs that achieve this property. Applications include secure audit logs (e.g. syslogd data) for intrusion detection or accountability communications security and authenticating partial results of computation for mobile agents. It proved security theorems on our forward integrity message authentication scheme and discussed secure audit log application in detail. 2.2.6

Integrated Event Management: Event Correlation Using Dependency Graphs (IEMECUDG) [13]

Event correlation addresses the practical need in handling today's fault management that requires sophisticated event management to condense events to meaningful fault reports. This paper introduces an approach for event correlation that uses a dependency graph to represent correlation knowledge. It is well suited to instrument an existing management system for event correlation. 2.2.7

Magic Quadrant for Security Information and Event Management (MQSIEM) [23]

This paper introduces the different companies that create and provide SIEMS products. It gives a comparison of the features between the products depending on the area of specialization it gives. 2.2.8

Mining Event Data for Actionable Patterns (MEDAP) [14]

Event management is a fundamental part of systems management. Over the last fifteen years, automated operations have increased operator productivity by using correlation rules to interpret event patterns. While productivity has improved, a substantial bottleneck remains—determining what correlation rules to write. This paper describes data mining and its use to identify patterns of events that indicate underlying problems. Adaptable Software-based Log Consolidation and Incident Management for a Security Information Event Management SystemAdLCIM

2-4

Traditionally, data mining has been applied to consumer purchases, often referred to as market basket data. A central consideration in this work is scalability. This is achieved by using a level-wise search in which patterns are discovered by building larger patterns from smaller ones. It shows the application of data mining to event data in an efficient and effective way. Several patterns are identified that are of particular interest to event management—event bursts, periodicities, and mutual dependencies. It provides interpretations for each, and it shows the pattern discovery structure to exploit a levelwise search, thereby improving scalability. The latter is particularly important since, based on our experience, tens of millions of events may need to be analyzed in order to discover actionable patterns. 2.2.9

Correlating SIM Information to Detect Insider Threats (CSIDIT) [10]

Most of the common security devices we deploy today (such as ﬁrewalls and IDS) cannot differentiate or interpret intent. In addition, looking at a single log ﬁle of a server is not enough to determine harmful activity. Only a system that collects and carefully correlates information from many sources can detect the most common type of internal attacks, such as data leakage, and be able to implement proactive solutions to stop someone from causing continuous harm to an organization. Table 2-1. List of Existing SIEM Products with Features Product OSSIM [4]

L.Col.

L.Cor.

T.C.

Rec.

I.M.

Rep.

O.E.

ISM [5]

ArcSight [4] CSM [1] Legend: L.Col. – Log Collection L.Con. – Log Consolidation T.C. – Threat Correlation Rec. – Recommendations I.M. – Incident Management Rep. – Reports O.E. – Operational Efficiency


2-5

3.

Theoretical Framework 3.1

Security Information Event Management (SIEM)

It is a software used by organizations that need network security. It is made to collect logs from different network devices, analyze them and give possible recommendations or solutions to the logs collected. Solutions or recommendations may be in the form of reminder, alarm or an action. The SIEM is expected to help companies in stopping intruders from tampering and accessing their system. Thus, it helps the network administrators in monitoring events. [29] 3.2

Security Information Management (SIM)

It is a term related to the collection of data into the central management or repository of a system. The central management or repository is also referred to as the security console, which is operated and monitored by a human being, who reviews consolidated information and takes action in response to any alerts issued. This helps in computer environments in security. It displays reports if there are security-related issues ongoing. [29] 3.3

Security Event Manager (SEM)

It is a tool used on data networks to centralize the storage and interpretation of logs or events generated by other software running on the network. The generated events are kept in event logs, which are essentially list of events generated on the network. [29] 3.4

Log Normalization

This function in the system converts and simplifies logs that have been collected by the system. [1] Log parsing is used to convert and simplify logs coming from different network devices. Each network device has a .dll file used for normalization. The .dll files contain the process on how to convert and simplify a certain log. This process is one of the most essential modules of the system. Collected logs may be sometimes too long or too short. This takes time for the network administrator to view and to analyze all the logs coming in to the system. Furthermore, logs may come in massive amounts in a small span of time. Network administrators need to monitor the network and to resolve alerts and incidents as fast as possible to resume normal network operation. Reading and understanding the logs one by one would take time for the network administrator to monitor all logs. As long as logs are simplified, it is easy for the network administrator to view the logs coming from different network devices. Adaptable Software-based Log Consolidation and Incident Management for a Security Information Event Management SystemAdLCIM

3-1

3.5

Log Parsing

When the device details are checked and there is already a normalizer class for the device, the log can now be parsed according to how it is supposed to be parsed. [1] For many of the networked devices, there is no need for parsing since the message in the Message field is just a phrase. However, in some strict, organized proprietary device manufacturing, the Message field can be divided into five or more. It is just up to the user on how he programs the parsing to be done. 3.6

Log Consolidation

It is a major function in SIEM wherein the system scans through large amounts of information and logs and gathers relevant information. [23] The information gathered is grouped or consolidated, based on its message on the Message field, for it to be organized and for the network administrator to view the logs much easier and faster. Messages that are exactly similar with other messages are grouped as one in a span of time depending on the log consolidation time. For example, there are thirty logs having the same exact message collected in twenty seconds. These thirty logs, when consolidated, appear as only one log. The thirty logs, that have the same exact message, are shown under the Count field of the consolidated log as ‘30’ to indicate the number of times that log was sent. If logs were not consolidated, it would take time for the network administrator to view all the logs. For example, there are thousands of logs having the same message, this would somehow frustrate the network administrator because he or she needs to view each log for network monitoring purposes. 3.7

Log Consolidation Time

The log consolidation time determines on how long before another consolidation can occur again. The user can adjust the time consolidation time to his or her liking. The log consolidation time is initially set to 20 seconds. For example, the user wants to change the log consolidation time from 20 seconds to 40 seconds. With this change, logs collected by the system and having similar logs are now consolidated every 40 seconds instead of every 20 seconds. 3.8

Event Sniping

It is a security measure in SIEM wherein it terminates an attack session via a TCP reset or ICMP unreachable message, stopping the attack before real damage can occur. [1] The TCP reset or ICMP unreachable message is sent to the victim’s port to terminate the Adaptable Software-based Log Consolidation and Incident Management for a Security Information Event Management SystemAdLCIM

3-2

attack session of the attacker and to stop the attacker from accessing and tampering the victim device. Logs that have been event sniped fall under the incident management. 3.9

Shunning

Shunning is the ability to use a network device to prevent entry to either a specific network host or to a whole network. [7] This feature is used when the non-resolvable attack event is found outside the network. 3.10 Incident Management Incident management is a process to bring back a normal service operation as soon as possible and to minimize impact on users while ensuring the best possible levels of service quality. Incidents are the results of errors or failures in the Information Technology infrastructure. [23] Logs falling under the incident management appear on the window for the network administrator to view. Moreover, logs falling under the incident manager are logs that have been event sniped by the system for normal service operation to be uninterrupted. 3.11 Alert Management Any threats, attacks or intrusions not found on the list, however, cannot be solved by the system. The system can only give out recommendations, instead, to these kinds of issues. The alert messages appear on the window for the network administrator to view. [7] Examples of alert logs are interfaces of switches and routers being down or set to administratively down. [7] The administrator can only solve these kinds of logs manually by checking and/or configuring the interfaces that went down. Other examples that the system can process can be seen on the list of possible alerts and recommendations on Appendix C. 3.12 Threat Correlation Threat correlation is part of an SIEM function that determines patterns on how to group logs and sort them according to its similarities. [23] For example, there is an attack that only works on a particular operating system. The threat of that attack is critical since it works on that operating system. However, if a certain operating system is not vulnerable to an attack, the threat of that attack is low and still is going to be logged for the network administrator to view.


3-3

3.13 Reporting Operational Efficiency/Effectiveness Compliance It is a major function in SIEM used to measure the time the computer responds to its functions. [23] In this feature, time is considered a very important element because the usefulness of the SIEM lies on its efficiency and effectivity. All modules are tested to see if they are efficient and effective in their response to any logs being accepted by the system. 3.14 Intrusion Detection System (IDS) It is a software or hardware used to detect unwanted attacks by accessing or manipulating of devices in a computer system through network. It is used to detect malicious behaviors that compromise security of a system. [8] The system is dependent on the IDS since the system is not capable of detecting unwanted attacks. The IDS is configured to send its logs to the server whenever it detects unwanted attacks. The system accepts logs from the IDS. Usually, attack logs are sent to the system coming from the IDS. These attack logs, when sent to the system, contain the destination and source IP address, destination and source port number and the attack name. Consequently, attack logs coming from the IDS are event sniped by the system. IDS logs, similar to other logs coming from different network devices, are collected, simplified and consolidated. This is because IDS logs are long and IDS logs are being sent numerous times to the system, depending on the attack. 3.15 Dynamic Loading Dynamic loading is a process or mechanism wherein a computer program can load a library or other binary into memory, retrieve contents in the library, execute and access its contents, and unload the library from memory. It is used to track or to trace a particular device’s brand of product with the module, with the help of the library, which is manually updated or manually configured, for the module to normalize certain logs coming from this particular device brand of product. [34] 3.16 .dll File .dll files or dynamic-link library files are used for the log normalizer module. [33] Each device type has a .dll file used for normalization. The format name of the .dll file is __NORMALIZER. .dll files can be connected dynamically to a specific program. 3.17 Simple Network Management Protocol (SNMP) It is a component used in network management systems to network-attached devices to tell whether they are in good or bad condition and if they need administrative attention Adaptable Software-based Log Consolidation and Incident Management for a Security Information Event Management SystemAdLCIM

3-4

or assistance. It consists of a set of standards that are an established norm or requirement for network management. [22] The protocol is based on the model of manager and agent, which consists of an SNMP agent, SNMP manager, managed SNMP devices, network protocol and the database including management information. The SNMP manager gives the interface of the physical devices and the manager. It uses fives messages to make communication between the SNMP agent and SNMP manager. These messages are GET, GET-NEXT, GET-RESPONSE, SET, and TRAP. SNMP Format: , , , , , 3.18 SNMP Agent An SNMP Agent is a software that monitors and manages a specific network device. It maintains that device's Management Information Base (MIB), a directory listing information that used and maintained by a network's management protocol, and responds to requests from the Network Management System (NMS), a windows-based system that is responsible for managing a network. [22] 3.19 Syslog Syslog is the de facto standard for forwarding log messages in an Internet Protocol (IP) network. It is both a client and server protocol. The syslog sender sends a small size message to the syslog receiver which can be sent via the TCP or UDP. The data sent is in clear text and can be encrypted through an SSL wrapper. [11] The syslog can be seen in the Request for Comments (RFC) 3164. It is now a standardized within the syslog working group of the Internet Engineering Rask Force (IETF). The syslog elicits and fills the parameters Date/Time, IP address, Facility (Kernel, User Level, Mail System, System Daemon, etc), Severity (Emergency, Alert, Critical, Error, Warning, Notice, etc) and the Message. Syslog Format: , , , , , 3.20 Syslog Agent A Syslog Agent is a software installed as a transparent service on any network device. [11] It sends all syslog information of all aspects with its corresponding category. These information received by the system are the timestamp, the hostname of the network device, facility, severity and message. It helps the network administrator in monitoring different network devices. Adaptable Software-based Log Consolidation and Incident Management for a Security Information Event Management SystemAdLCIM

3-5

3.21 TCP/IP TCP/IP is a two-layer program. The higher layer, Transmission Control Protocol, manages the assembling of a message or file into smaller packets that are transmitted over the Internet and received by a TCP layer that reassembles the packets into the original message. The lower layer, Internet Protocol, handles the address part of each packet so that it gets to the right destination. Each gateway computer on the network checks this address to see where to forward the message. TCP/IP uses the client/server model of communication in which a computer user requests and is provided a service by another computer in the network. TCP/IP communication is primarily point-to-point, meaning each communication is from one point in the network to another point or host computer. [7] In the system, the AdLCIM server is treated as the server, while the computers, IDS, device discoverer, switch, router and firewall are treated as the clients. 3.22 TCP TCP provides the service of exchanging data between two hosts. TCP provides reliable, ordered delivery of a stream of bytes from a program on one computer to another program on another computer. TCP is the protocol that major Internet applications rely on, applications such as the World Wide Web, e-mail and file transfer. [9] The system is tested with TCP-related attacks to test the collection of these logs from the IDS and to test the event sniping of these logs. 3.23 UDP UDP provides the service of sending messages to other hosts on an IP network by computer applications without requiring prior communications to set up special transmission channels or data paths. [9] These messages are referred to as datagrams. The system uses UDP port 514 for all syslog messages to be sent to the server. The server accepts logs coming from UDP port 514. UDP port 514 is specifically for syslog messages. 3.24 ICMP ICMP is primarily used by operating systems to send error messages, such as a requested service is not available or a destination cannot be reached. ICMP is also used to relay query messages such as ping messages. [9]


3-6

A common log that is being received by the system is an ICMP ping echo request and an ICMP ping echo reply. These logs are detected by the IDS and are sent to the system for processing and viewing. 3.25 Hostname The hostname is a label to a particular network device used to identify and differentiate a network device from other network devices. If a hostname is not found, the IP address is treated as the network device’s hostname. [19] 3.26 IP Address The IP address is a numerical label that is assigned to any network device in the network. Each network device must have a unique IP address to differentiate the network devices from other network devices. If this is not met, conflicts between IP addresses can cause problems in network connectivity. The IP address is used as the hostname that appears for the network administrator to view in case a network device has no specific hostname. [19] 3.27 Facility The facility is an information field associated with a syslog message which has an integer value. It is defined by the syslog protocol. It is meant to provide a very rough clue from what part of a system the message originated from. Traditionally, under UNIX, there are facilities like KERN, LPD and the like. There are also the LOCAL_0 to LOCAL_7 facilities, which were traditionally reserved for administrator and application use. [16] However, for the system, the integer values are now represented as text based on their corresponding facility value and message. 3.28 Severity The severity is an information field associated with a syslog message which has an integer value from 0 to 7. The lower the number, the more important the syslog message is. This is also often to be used to filter incoming messages. [16] However, for the system, the integer values are now represented as text based on their corresponding severity value and message. 3.29 Priority The priority is an information field associated with a syslog message, which has an integer value from 0 to 191. To compute for the priority, multiply the facility value and 8 then add the severity value. [16] Adaptable Software-based Log Consolidation and Incident Management for a Security Information Event Management SystemAdLCIM

3-7

However, for the system, the integer values are now represented as text and logs are now classified into three priority categories: LOW, MEDIUM and HIGH. 3.30 Device Discoverer The device discoverer is primarily used for network devices in identifying their version or operating system. An example of a device discover is Zenmap, a network mapper where the user has to type a command to scan a particular network device or a large group of devices. [24] 3.31 NMAP NMAP, sometimes called Zenmap, is a network mapper and a device discoverer to identify a network device’s operating system or version. [24] This is primarily used for the system in identifying the operating system or version of all network devices that are supposed to be in the network. NMAP is used for the system to discover the operating system of the network devices located in its topology. The device hostname and its operating system are needed for the device inventory. 3.32 RST Packet An RST packet can terminate and close a TCP connection. The termination of that TCP connection can only be closed after a predetermined time. [15] In Event Sniping, TCP RST packets are sent to the victim port to terminate and close an attack session. [1] This prevents the attacker from doing harm and damage to the victim computer. 3.33 Tini Tini is a backdoor having a size of 3 KB that can access a victim’s computer once properly installed on the victim’s computer. The Tini backdoor accesses the victim computer’s port 7777. Once a connection has been made, the attacker can now access the victim computer’s directory. This only works on a Windows-based platform. [32] This backdoor attack is primarily used for Incident Management testing. 3.34 Device Inventory The Device Inventory contains the list of identified devices’ hostnames along with their operating systems. This inventory is updated whenever the network administrator Adaptable Software-based Log Consolidation and Incident Management for a Security Information Event Management SystemAdLCIM

3-8

identifies an unidentified device for that device to send logs to the system. This inventory is later on used for the Attack Inventory. [7] 3.35 Attack Inventory The Attack Inventory is a list of attacks that the network administrator wants to prevent from occurring in the network. The attacks are paired with an operating system that is vulnerable to that particular attack. [7] Devices that are affected and vulnerable with the attack have a priority of ‘HIGH’. On the other hand, the priority is ‘LOW’. The list of attacks can be added, modified and/or deleted by the network administrator. 3.36 Port Mirroring Port mirroring is enabled on the Cisco switch to send a copy of network packets seen on one switch port or an entire VLAN to a network monitoring connection on another switch port. [9] This is commonly used on network applications that require monitoring of network traffic such as an IDS.


3-9

4.

Adaptable Software-based Log Consolidation and Incident Management System (AdLCIM) 4.1

System Overview

NETWORK

PC1 IDS 1

FIREWALL 2

ROUTER 1 PC2

SWITCH 1

FIREWALL 1

IDS 3

SWITCH 2 PC3

PC4

IDS 2

USER AdLCIM

Figure 4-1. System Diagram of the Adaptable Software-based Log Consolidation and Incident Management System (AdLCIM) The set up of the Adaptable Software-based Log Consolidation and Incident Management System (AdLCIM) is seen in Figure 4-1, with all the devices reporting to the AdLCIM. Different devices in the network are included in the scope of AdLCIM. This includes desktop computers, switches, firewalls, servers and router. Intrusion Detection Systems (IDS) are placed in different parts of the network to check if there are threats coming. The AdLCIM accepts the logs from these different devices, analyzes it and tries to group them. The user or also known as the network administrator is alerted when significant events occur and tries to resolve any issue which the AdLCIM cannot give action. It can be noticed that devices in the system are from different proprietary brands which have their own sets of protocols when logging. The AdLCIM can cater devices with different standards through a process of normalization which makes the format of the logs uniform. Adaptable Software-based Log Consolidation and Incident Management for a Security Information Event Management SystemAdLCIM

4-1

4.2

Architectural Design

Figure 4-2. Block Diagram of the System Adaptable Software-based Log Consolidation and Incident Management for a Security Information Event Management SystemAdLCIM

4-2

The system contains ten modules as seen in Figure 4-2: the Device Identifier Module, Device Recognizer Module, Log Collector Module, Log Normalizer Module, Log Consolidator Module, Event Analyzer Module, Incident Manager Module, Alert Manager Module, Report/Recommendation Generator Module and Events Updater Module. It also has six databases namely: Identified Devices Database, Unidentified Devices Database, Normalized Log Database, Attack Inventory Database, Network Monitoring Database and Report/Recommendation Database. The system accepts logs from different devices, standardizes the logs into a common format, groups it based from consolidating patterns, classifies it whether it is an attack, normal or critical events and generates report. These modules comprise the whole operation of the AdLCIM. The primary modules which define the operation of the AdLCIM are the Log Collector Module, Log Consolidator Module, Incident Manager Module and the Report/Recommendation Generator Module. The other modules are created to make the AdLCIM more effective and efficient to maximize utilization. 4.2.1

Device Identifier Module

The Device Identifier Module accepts logs from the devices on the network. The logs are passed to the Device Identifier Database to check the identity of the logs. All identified logs are passed to the Log Collector Module while the unidentified logs are directed to the Device Recognizer Module. 4.2.2

Device Recognizer Module

The Device Recognizer Module accepts logs that are not identified in the Device Identifier Database. These details of the logs are recognized in the Device Identifier Database. Added or discarded unidentified logs are passed to the network administrator to decide whether the logs are put in the database and set in the module. 4.2.3

Log Collector Module

The Log Collector Module collects logs that come from the Device Identifier database. As long as there is activity going on in the network, the Log Collector Module keeps on acquiring logs from the different network devices. These logs then go to the Log Normalizer Module to standardize the logs into same formats. 4.2.4

Log Normalizer Module

The Log Normalizer Module accepts the logs that are collected from the Log Collector Module. The logs collected are in different formats since these come from different devices with different protocols. Logs are transformed into a standardized format that Adaptable Software-based Log Consolidation and Incident Management for a Security Information Event Management SystemAdLCIM

4-3

the software can easily understand. These normalized logs are put in the Normalized Log Database. 4.2.5

Log Consolidator Module

The Log Consolidator Module groups logs according to similarity of content that come from the Normalized Log database. Once these logs are grouped, the logs are summarized into fewer logs to prevent flooding of system with huge number of similar logs. This module makes logs appear less complicated as these simplified logs are classified into the Event Analyzer Module. 4.2.6

Event Analyzer Module

The Event Analyzer Module receives the grouped logs from the Log Consolidator Module. This module analyzes the consolidated logs whether these logs are ordinary events that happen most of the time, alerts or threats. Consolidated logs have its corresponding Event Type ID. After analysis, events are created with reports and recommendations, threats go to the Incident Manager Module, critical logs go to the Alert Manager Module and non-critical logs to the Report/Recommendation Generator Module. 4.2.7

Incident Manager Module

The Incident Manager Module is responsible in handling different incidents found in the system. This module resolves attack-related logs. If the Incident Manager Module fails to resolve the attack on its own, manually configured commands from the network administrator are used in resolving the attack. If the incident can be resolved, the module resolves the incident automatically. Log updates are put in the Report/Recommendation Generator Module 4.2.8

Alert Manager Module

The Alert Manager Module alerts the system to critical logs, which come from the Event Analyzer Module. The module alerts the network administrator when critical logs or nonresolvable logs are detected. Alerts that are sent may be through an SMS message or an email. 4.2.9

Report/Recommendation Generator Module

The Report or Recommendation Generator Module receives all logs that are normalized and consolidated whether logs are threat events, critical events, or just ordinary events. The module keeps all the records for possible study and documentation. It also gives recommendations for critical and threat events. Adaptable Software-based Log Consolidation and Incident Management for a Security Information Event Management SystemAdLCIM

4-4

4.2.10 Events Updater Module The Events Updater Module accepts newly discovered attacks and network monitoring statuses from the user or automatic updates from IDS/IPS and Network Monitoring Tool and put it in the Attack Inventory Database and Network Monitoring Database respectively. 4.3 4.3.1

Theoretical Analysis Device Identifier Module

The Device Identifier Module is a module that can be implemented by a manuallyconfigured database updated by the network administrator. The database, as it initially accepts the logs, checks whether the device reporting to the AdLCIM is part of the designed network. The database has three fields namely: IP address, device type and device specification. A simple if-else condition that iterates in the IP address field looks whether there is an existing device that matches the IP address in the database. If there is an IP address that matches then the device sending the log proceeds to the log collector for log elicitation. However, when the IP address does not match in the database, the network administrator is informed about it and the logs from the device are blocked. The network administrator decides whether the device is allowed to be included in the database. When it is included, the logs from the device are accepted in the Log Collector Module for initial analysis. The network administrator can also block the device of a particular IP address so that it cannot try to enter the Device Identifier database again. The device type field of the database is the type of device the IP address corresponds. The device type may be a router, computer, switch, server etc. The device specification field on the other hand is the brand of the device. For example, the device type is a router then the device specification is a type of router which is Linksys. 4.3.2


The Device Recognizer Module takes part in the system when unrecognized devices are detected. It can be implemented through the help of the Identified Devices Database and the Unidentified Devices Database. When the devices are unrecognized in the Identified Devices Database, the Device Identifier Module puts the IP address of the unknown device in the Unidentified Devices Database and passing it in the Device Recognizer Module. The contents of the unrecognized devices are collected and the user can view it anytime, deciding whether the device should be added in the Identified Devices Database, thus supplying the Device Type and Device Specification, or leaving it in the Unidentified Devices Database marking it as discarded or even blocked device. Adaptable Software-based Log Consolidation and Incident Management for a Security Information Event Management SystemAdLCIM

4-5

4.3.3


The Log Collector Module can be implemented by use of a Syslog Listener. The listener listens to UDP port 514 for any incoming Syslog messages that are destined to that port. These messages are removed from their encapsulation state when they arrive to that port. The messages are sent to the Log Normalizer Module afterwards. 4.3.4


Logs from different network devices come in different formats. The Log Normalizer Module can be implemented by standardizing the format of the logs collected and storing it into the Normalized Log Database. In lieu of the standardization of logs, the Log Normalization Module can be implemented using dynamic loading. After the deployment of the AdLCIM, it is assumed that the devices included in the Normalized Log Database are limited. Dynamic loading answers the addition of devices to be used for standardization. Understanding the protocols used in classifying parts of the logs of a particular device is essential in dynamic loading. With the knowledge of the protocols and parsing of certain codes to normalize the logs without recompiling the whole software through dynamic loading answers the question of device log compatibility limitation issues. 4.3.5


There are various ways of implementing the Log Consolidator Module. It can be implemented through timestamp, data mining, artificial intelligence, logical correlation, cross correlation and inventory correlation. Consolidation of logs can be based on its timestamp. Logs that come together are grouped easily because there is a high chance that they contain the same content of message. The module can also be implemented through data mining. Data mining establishes patterns based on network behaviors and classifying which patterns are important that might recur in the future. Artificial intelligence may also be used in the implementation of the module. Since the module involves having knowledge about log patterns, resemblance and similarities, artificial intelligence may be used so that the system learns about the log it can accept. The module can also be implemented through the use of correlation techniques that are patterned from OSSIM AlienVault [25] such as cross, inventory and logical correlation. These correlation techniques summarize the logs with accuracy since the basis for consolidation comes from databases of vulnerabilities and alarms. Adaptable Software-based Log Consolidation and Incident Management for a Security Information Event Management SystemAdLCIM

4-6

The module can also be implemented with the use of two databases namely Attack Inventory Database and the Network Monitoring Database. The databases help in classifying and consolidating logs based on relationship in attacks and network monitoring standards. One approach in the implementation of the module is through the adaptation of the database schema of an undergraduate thesis at De La Salle University in 2007 called the Virtual Information Security Testing System or Epsilon [12]. The databases include operating systems and applications that have its corresponding vulnerabilities that might be useful in consolidation. Another approach can be through the existing list of attacks in the IDS/IPS that are already normalized from the Log Normalizer Module. With the help of the own lists of attacks stored in the IDS/IPS, it is easier for the AdLCIM to classify an attack event. Automatic attack list updates from the Internet can also be used. For network monitoring, the database content of PRTG can be used for its implementation [26]. It is a freeware computer system and network monitoring software application. An alert goes if there is a critical or non-resolvable attack detected such as unplugged device and power disturbance in a device. The Network Monitoring Database can also be populated by the database in the undergraduate thesis at De La Salle University in 2005 entitled Online Network Monitoring System using RMON Standards (NEMSYS Online) where there are lists of network problems, symptoms and trap logs [7]. 4.3.6


The Event Analyzer Module can be implemented by checking the Event Type ID of the consolidated logs that transformed into events in the Log Consolidator Module. An event that has an Event Type ID of 1 is a non-critical event, an Event Type ID of 2 is a critical event and an Event Type ID of 3 is an attack event. Normal events refer to day-to-day activities of a user in the network that do not harm the system and do not need any action. Attack events refer to instances where the fundamental principles of information security such as confidentiality, integrity and availability are compromised and needed to be resolved. Critical events refer to internal issues that needed to be resolved to maintain the system’s normal state 4.3.7


After logs from the IDS/IPS are elicited, there may be non-resolvable attack events that need to be responded on. The Incident Manager Module can be implemented with the features event sniping and/or shunning as an answer for the non-resolvable attack events. Adaptable Software-based Log Consolidation and Incident Management for a Security Information Event Management SystemAdLCIM

4-7

Event sniping is a security measure in wherein it terminates an attack session via a TCP reset or ICMP unreachable message, stopping the attack before real damage can occur. This feature is used when the non-resolvable attack event is found inside the network. The idea of its implementation is based from the Central Security Manager (CSM) undergraduate thesis in De La Salle University in 2004. [1] Shunning is the ability to use a network device to prevent entry to either a specific network host or to a whole network. This feature is used when the nonresolvable attack event is found outside the network. 4.3.8


After the network monitoring tool detects an alert and the critical event is passed to the Alert Manager Module, it needs to alert the user about it. The implementation of the module can be through a Short Messaging System (SMS), e-mail and changing of Alert Manager icon color in the AdLCIM’s GUI. Both SMS and e-mail are very essential ways of informing in real-time the user. The implementation can be made through automation of a Chikka program sending SMS to the user regarding the alert. The automation can also be done to send an email to the user regarding the alert. The Alert Manager icon changes color to red and starts to blink when alerts are detected in the GUI of the AdLCIM. 4.3.9


The main purpose of the Report/Recommendation Generator Module is to inform the user of what happened in the network in a specified time for possible documentation and study. One way of implementing the Report/Recommendation Generator Module is patterned with OSSIM’s report viewer. [25] It prompts the user to have options in viewing specific details in the report, such as top ten attacking hosts, events in a day and alarms in a day. It also shows reports not only in text but also in graphs. Another way of implementing the Report/Recommendation Generator Module is through adding and querying of data in the Report/Recommendation Database. When an event is classified as critical, non-critical or attack, a module responds to resolve the need of the event. After the event is resolved, the module, where the event is given action, is mandatory to update the Report/Recommendation Generator Module by filling up the Report/Recommendation Database.


4-8

The user can query desired reports based on the parameters supplied. The data queried by the module is stored in the Report/Recommendation Database. The reports can also be viewed as graphs and can be printed as well. In addition, the Report/Recommendation Generator Module can be implemented by accepting all the events that are consolidated and be given a corresponding 4.3.10 Events Updater Module The Events Updater Module generally exists to add data regarding new discoveries on attacks and alarms. It can be implemented by manually adding updates in the database. Manual updates are done by the user. There can be new attack and alert discoveries that need to be updated because neither the IDS nor the network monitoring tool is not be aware of it. Moreover, specific network policies may require alerts on events that on other networks do not need alerts.


4-9

4.4

System Design

Figure 4-3. Flowchart diagram of the Adaptable Software-based Log Consolidation and Incident Management System (AdLCIM)


4-10

4.4.1


Figure 4-4. Flowchart Diagram of the Device Identifier Module The Device Identifier Module is implemented through the use of two databases namely: Identified Devices Database and Unidentified Devices Database. As seen in Figure 4-4, when the logs are accepted by the AdLCIM, the system cannot directly accept the logs because it has to check first whether the logs come from a legitimate device in the network. The logs that need to be checked include an IP address, which is essential in device checking. The IP address is queried in the database of the Identified Devices Database. When the IP address matches in one of the IP addresses field in the database, it reports back to the module and indicates that the device is recognized and its log is ready to be collected in the Log Collector Module. The IP address of the recognized device includes a corresponding device type and device specification fields as seen in Table 4-2. The database schema of the identified devices database can be seen in Table 4-1. However, if the IP address of the device is not in the Identified Devices Database, it reports back to the module and informs that it is unrecognized. The IP address of the unrecognized device is placed in the Unidentified Devices Database. The reason for the existence of the module is to know the devices that are part of the AdLCIM screening. Moreover, there might be unscrupulous hackers who might want to flood logs using their own devices especially when they know that there is an existing AdLCIM. The database gives an identity of the devices and with this, it gives security to the AdLCIM.


4-11

Table 4-1. Database Schema of the Identified Devices Database Table

Field

Type

Device Identifier

IP Address

varchar(16)

Primary Key Y

Device Type varchar(10)

Device varchar(15) Specification

Description Identifies IP address of the device entered Identifies the type of device with the IP address Identifies the brand of device type

Table 4-2. Sample Database Contents of the Identified Devices Database IP Address 192.168.1.5 192.168.1.12 192.168.1.8 192.168.1.11 192.168.1.9

Device Type IDS Switch PC PC Firewall


Device Specification Snort Cisco Catalyst 2960 BTC HP-Windows1 HP-Windowsw2 Cisco Pix

4-12

4.4.2


Figure 4-5. Flowchart Diagram of the Device Recognizer Module As seen in Figure 4-5, the Device Recognizer Module is implemented using the created Identified Devices Database and Unidentified Devices Database. It is an extension of the Device Identifier Module. When the unrecognized device is stored in the Unidentified Devices Database as seen in Table 4-4, the user at anytime can check the entries inside the database and decide whether the unrecognized device should be added in the Identified Devices Databases as a device that is part of the network or must remain in the Unidentified Devices Database. If the user decides that the device should be added in the Identified Devices Database, the device must be supplied with a device type and a device specification. If the user decides to discard and block the IP address of the unrecognized device, it goes back to the Unidentified Devices Database. As seen on Table 4-3, the field IP Address is a data type varchar. It is the primary key for of table because the IP address of each device is unique from each other. The Device Type field is a data type varchar. The field only describes the kind of device that corresponds the IP Address field. The Device Specification is a data type varchar which gives a clearer description the type of device brand from the IP Address. The Status field is a data type varchar and it can be classified as Unidentified or Blocked.


4-13

Table 4-3. Database Schema of the Unidentified Devices Database Table

Field

Type

Device Identifier

IP Address

varchar(16)

Primary Key Y

Device Type varchar(10)

Device varchar(15) Specification Status

varchar(15)

Description Identifies IP address of the device entered Identifies the type of device with the IP address Identifies the brand of device type Identifies whether the device is unidentified or blocked

Table 4-4. Sample Database Content of the Unidentified Devices Database IP Address

Device Type

192.168.2.3 192.168.2.11 192.168.3.45

-------

4.4.3

Device Specification -------

Status Unidentified Unidentified Blocked


Figure 4-6. Flowchart Diagram of the Log Collector Module Adaptable Software-based Log Consolidation and Incident Management for a Security Information Event Management SystemAdLCIM

4-14

Figure 4-6 shows the implementation of the Log Collector Module. Logs coming from identified devices are collected. Each field is then populated automatically in their respective fields. Afterwards, logs are brought to the Log Normalizer Module. The Log Collector Module uses Syslog Listener as an implementation in the module. Request for Comments (RFC) 3164 is a memo by the Internet Engineering Task Force (IETF) stating that logs are standardized for easier collection of logs in the network. Typically, logs are in the following format based on a Syslog software. It elicits the parameters Date/Time, IP address, Facility (Kernel, User Level, Mail System, System Daemon, etc), Severity (Emergency, Alert, Critical, Error, Warning, Notice, etc) and the Message. Different devices might fill all the fields in the Syslog fields while others do not or fill data for more fields than the given. The module accepts complete, incomplete or more than the complete entries for the fields and gives the logs collected to the Log Normalizer Module for standardization of log formats. However, devices with logs that are not found in the Identified Devices Database are not recognized in this module. Table 4-5 shows the fields and sample contents of collected logs. Table 4-5. Fields and Sample Contents of the Log Collector Module Date/Time Aug 4 11:13:00

IP Address 192.168.2.3

Facility Kernel

Severity Notice

Aug 4 11:13:05

192.168.2.11

User Level

Warning

Aug 4 11:14:34

192.168.3.45

System Daemon

Critical


Message OS working properly after system shut down Anti-virus not updated Disk space less than 15%

4-15

4.4.4


Figure 4-7. Flowchart Diagram of the Log Normalizer Module Figure 4-7 shows the implementation of the Log Normalizer Module. When the collected logs are sent to the Log Normalizer Module, the module checks the logs and looks for the IP address and the device details. If the device has a normalizer class, the logs are immediately normalized and stored to the normalized log database. If the device does not have a normalizer class, a new normalizer class needs to be created and to be added to the Log Normalizer Module. The Log Normalizer Module uses dynamic loading for this module. Dynamic loading decreases the complication of updating the device brands listed in the module. It does not anymore need to recompile the whole program of the system. The user needs to manually update and recompile the whole program of the system in accepting newly discovered device brands accepted by the Device Identifier Module if dynamic loading is not implemented. In dynamic loading, the setup of the module is like creating classes in an objectoriented design since each device has its own attributes for the log collection. Each class created has conditional codes that are used to transform the logs of the device to normalize logs that follow the AdLCIM format. The process used in log normalization is called the first normal form. Relations in this process represent each sequence each of which is identified by a primary key value. First, a primary key is selected for the set of attributes of different devices. Second, the set of attributes, which repeats for each value of this primary key, is identified. Third, a relation from the attributes, which are not in the repeating group, is made. Fourth, the key of this relation that is identified in the first step is made. Fifth, the primary key for the repeating group by taking each value of the primary key identified in the previous step and identifying a unique attribute or unique attributes in the repeating group is identified. Adaptable Software-based Log Consolidation and Incident Management for a Security Information Event Management SystemAdLCIM

4-16

The Log Normalizer Module is implemented with a Log Normalizer superclass, as seen in Figure 4-8, with the fields Date/Time, IP Address, Device Type, Device Specification, Facility, Severity and Message. This superclass with the mentioned features is inherited to the devices that need to be normalized. Any additional features that must be added to the device are added to its own class. In log normalization, the effects after passing through the module include the standardization of the content fields, removing the unnecessary device log fields and translating fields to into similar formats. For instance, the high priority level for Snort is 5 while for Nessus is 1. The Log Normalizer Module’s standard for high priority is 1, which changes the high priority for Snort. The Log Normalizer Module also helps in log consolidation. Since devices are already classified from the Device Identifier Module, when these devices are passed to the Log Normalizer Module, the device is classified and it can be predicted into what module it might go. For example, if the Log Normalizer Module detects that the log comes from an IDS, there is a vast possibility that the log is an attack and should go to the Incident Manager Module. All normalized logs are put in the Normalized Log Database before the logs are transmitted to the Log Consolidator.

Figure 4-8. Unified Modeling Language (UML) Diagram of the Log Normalizer Module


4-17

4.4.5


Figure 4-9. Flowchart Diagram of the Log Consolidator Module Figure 4-9 shows the implementation of the Log Consolidator Module. It is implemented using the correlation techniques used by OSSIM AlienVault. An advantage of correlation techniques is that it reduces false positives and false negatives since its consolidation is based from established patterns already. It also narrows down possible devices and/or operating systems that are affected by certain attack events penetrating the network. The user can view all the logs before it is consolidated. The logs can be consolidated with cross, inventory and logical correlation. When the user views the logs in the Log Consolidator Module and selects a specific correlation technique to be used, it is expected that from a thousand logs shown, it is summarized into maybe half of it or more. The three correlation techniques applied by OSSIM AlienVault [25] are used in the implementation of the Log Consolidator Module. Cross correlation compares information from IDS's and vulnerability scanners, prioritizing the event in case the information is vulnerable or not to a particular attack. For instance, if Attack A only exploits Vulnerability X, therefore through cross correlation, the vulnerability scanner scans the network and reports on the vulnerabilities of the network. If the vulnerability scanner reports that Vulnerability A is on the network and the IDS detects Attack A is happening, through cross correlation, this event has a higher priority than the different events that do not interfere with the network. Inventory correlation checks if the attack affects a certain service and operating system type and version and checks if the attacked host has OS/service active, discarding the event if not. For example, Attack B only exploits a certain OS/software that is installed on the terminals. If Attack B occurs and PC 1 is known to have the OS/software that it exploits, the attack regarding PC1 is given higher priority than events that do not affect the network or specific terminal.


4-18

Logical correlation refers to logical rules use to join different small events to match a new pattern. It lets the administrator create correlation directives or logical rules to join different small events to match a new pattern. OSSIM Logical Correlation Engine allows implementing user defined patterns of any kind using hybrid sources (not only detectors but also monitors) and a recursive and hierarchical distributed architecture. In the creation of matching a new pattern, the user can access the Attack Inventory Database and the Networking Monitoring Database and use its existing entries. The user can also use the logs in the Normalized Log Database. The module is also implemented by the creation of the Attack Inventory Database and the Network Monitoring Database. The Attack Inventory contains the list of attacks with the corresponding operating system, services, application and ID. This is implemented through the adaptation of the database schema made by Epsilon [12]. This database is made for support in the correlation. The said database schema includes tables for: 1.) Attack with the fields Attack ID and its corresponding Attack Name; 2.) Operating system with the fields, Operating system ID and Operating system name; 3.) Application Table with the fields Application ID and Application Name; 4.) the combination of the Attack ID and Operating system ID; and 5.) the combination for the Application ID and Attack ID. The tables with the corresponding fields mentioned are helpful in classifying the events to be classified in the Event Analyzer Module. The Network Monitoring Database can be populated by the lists of network problems, symptoms and trap logs of the Online Networking System Using the RMON Standards (NEMSYS Online), an undergraduate thesis at De La Salle University in 2005 [7]. The database contains data used for monitoring critical logs using the database schema of Epsilon. The databases can be updated manually by the user if new attacks, alarms and network policies are made or discovered. After the logs are consolidated, an Event Type ID is assigned to each grouped log. If logs match in the Attack Inventory Database after correlation, the Event Type ID is 3. If logs match in the Network Monitoring Tool after correlation, the Event Type ID is 2. Otherwise, the Event Type ID is 1. After consolidation, there are five fields that are shown. The Event ID Number field is a unique identifier of the event that is generated after a consolidation is done. It is usually done based on patterns chosen. The Quantitative Consolidated Logs field is simply the number of logs summarized into one single event. The Consolidation Technique field is the correlation type used. The Patterned Correlated Events field is the similarities of the logs consolidated. The Event Type ID states if the event is normal, critical or attack. When the Event ID Number is pressed, all the logs under it expand showing all the logs belonging to that Event ID Number. Table 4-6 shows sample consolidated logs and how they appear.


4-19

Table 4-6. Sample Consolidated Logs with its Respective Fields in the Log Consolidator Module Event ID Number 1003 1004 1005

4.4.6

Quantitative Consolidation consolidated Technique Logs 100 Inventory 25 Logical- based on timestamp 15 Cross

Patterned Correlated Events

Event Type ID

Normal logs Low disk space

1/Normal 2/Critical

Table Rebuilding Code Execution Vulnerability (Mozilla Firefox 1.0)

3/Attack


Figure 4-10. Flowchart Diagram of the Event Analyzer Module After the logs are grouped and classified as events, logs with issues needed to be resolved must go to its respective modules. The Event Analyzer Module passes all the events to the Report/Recommendation Generator Module, as seen in Figure 4-10, whether the Event Type ID is 1, 2 or 3.


4-20

4.4.7


Figure 4-11. Flowchart Diagram of the Incident Manager Module Figure 4-11 shows the implementation of the Incident Manager Module. It is implemented through the use of event sniping and shunning. Only events that have an Event Type ID of 3 are accepted in this module. These events come mostly from an IDS/IPS. Non-resolvable attacks are first brought to the Alert Manager Module, giving notice to the user of a non-resolvable attack. Event sniping or also known as a session sniping is a direct intervention to disrupt the communication and the victim. The action is made by injecting packets to break down the connection, which triggered the response. In implementation, the packets are forged to reset the connection by sending a TCP reset bit set. The ports, source IP and sequence numbers should be in sequence with the traffic that triggered the event for the reset to take place. Shunning is the denial of access to a host suspected of an attack. In implementation, a response is to stop access to an attacker’s IP to reduce the possibility of expanding the attack to other targets within the protected environment. After the attack events are resolved the module sends log update to the Report/Recommendation Generator Module for documentation. The user, after resolving the non-resolvable attacks, also updates the Report/Recommendation Generator Module.


4-21

4.4.8


Figure 4-12. Flowchart Diagram of the Alert Manager Module The implementation of the Alert Manager Module is seen on Figure 4-12. It is implemented by showing that the Alert Manager icon in the Graphical User Interface (GUI) is changed with a blinking red color. Only events that have an Event Type ID of 2 are accepted in this module. These events come mostly from a Network Monitoring Tool. After the user is alerted with the critical events, the module sends log update to the Report/Recommendation Generator Module for documentation. The user, after resolving the critical events, also updates the Report/Recommendation Generator Module.


4-22

4.4.9


Figure 4-13. Flowchart Diagram of the Report/Recommendation Generator Module Deployment of a database called the Report/Recommendation Database is chosen in the implementation of the Report/Recommendation Generator Module as seen in Figure 4-13. After the attack and critical events are resolved, these are put in the database together with the non-critical logs with the parameters: IP address, Event Type ID, Message, Status, Date/Time, Event ID Number and Consolidation Technique. The user can query using one or more of the above mentioned parameters. Reports generated can be printed and e-mailed to the user. Graphs comparing reports in X number of days can also be generated. When one of the fields from the parameters Event Type ID, Status, Event ID Number or Consolidation Technique is chosen, the summarized reports are generated but can be expanded to show the logs in it. For the implementation of the recommendation, the user can manually give corresponding recommendations from the list of attacks and vulnerabilities in the Attack Inventory Database by Epsilon [12] and the network problems, symptoms and trap logs in the Network Monitoring Database by NEMSYS Online [7]. These recommendations are shown after the Event Analyzer passes the consolidated logs in the module and passing it to its corresponding modules so that the issues can be resolved. Table 4-7 Adaptable Software-based Log Consolidation and Incident Management for a Security Information Event Management SystemAdLCIM

4-23

shows a list of activities including normal, critical and attack events with recommendations. Table 4-7. Table of Minimum List of Activities which include Normal, Critical and Attack Events with its Corresponding Recommendation and Status Event ID Number 1000

Event Type ID 2/Critical

Message

Recommendation

Status

Error reading failover status Failover cable OK. Tini virus detected. Traceroute

Replace failover cable. None

Unresolved

1001

1/Normal

1002

3/Attack

Close port 7777

Unresolved

1003

3/Attack

Further observation of activity or connection. Correct theACL components that have the indicated error on the AAA server. None

Resolved.

1004

2/ Critical

Download ACL acl_id is empty

1005

1/Normal

Interface is up

Resolved

Unresolved

Resolved

4.4.10 Events Updater Module New event

Manually update Attack Inventory/ Network Monitoring Database

Figure 4-14. Flowchart Diagram of the Events Updater Module As seen in Figure 4-14, the Events Updater Module is implemented with the use of the Attack Inventory Database and the Network Monitoring Database. Manual updates are done by the user. Certain network policies can be established that are not found in the data supplied by the IDS/IPS or the Network Monitoring tool. The updates are put in the proper database. The updates coming from the IDS/IPS that are manually updated by the user go to the Attack Inventory Database while the updates coming from a Network Monitoring Tool go to the Network Monitoring Database. Adaptable Software-based Log Consolidation and Incident Management for a Security Information Event Management SystemAdLCIM

4-24

5.

System Implementation

The AdLCIM has implemented the modules in Chapter 4 with some deviations from the initial design discussed in Section 4.4. As previously discussed, the system is implemented using the Microsoft .NET Framework with Visual Studio C# 2005 as its programming language. The database management system used for the system implementation is MySQL. The system is implemented and deployed in a Windows platform. The device normalizers on the other hand are compiled and linked using Dynamic-link Library (.dll) files. 5.1


There are certain changes that were made in Table 4-2 for the Device Identifier Module. Additional fields, Device ID and Device Details, are added and existing fields, IP Address and Device Type, are modified. The Device ID field is added primarily for giving an identified device a unique ID, which increments every time the network administrator identifies an unidentified or added device. This field is now used as the table’s primary key. The IP Address field is replaced and renamed to Hostname. The Device Identifier Module extracts the hostname of the network device instead of the IP address. If the network device has no hostname, its IP address is then extracted. This is done to follow the format of Syslog protocol stated in RFC 3164. The Device Details field is added primarily to classify the version of the Device Specification field. The field can be used as a note or in any way to describe a certain network device such as a model number or version. The Device Type field has a drop-down button to choose from which device type a network device is. This is made for format uniformity. The network administrator can add newly discovered device types as well. Table 5-1. Fields and Sample Data in the Device Identifier Module Device ID

Hostname

Device Type

1

PlatoDaAcademy

COMPUTER

Device Specification WINDOWS


Device Details 7 5-25

5.2


There are certain changes that were made in Table 4-4 for the Device Recognizer Module. An additional field, Device Number field, is added, existing field IP Address, is edited and the Device Type, Device Specification and Status fields are removed. The Device Number field is added primarily for giving a device, subject for recognition, a unique ID, which increments every time the system detects a network device in the network. This field is now used as the table’s primary key. The IP Address field is replaced and renamed to Hostname. This field simply contains the hostname of a network device that is detected on the network. If the hostname is not detected, this field contains the IP address of a network device instead. This is done to follow the format of Syslog protocol stated in RFC 3164. The device type, device specification, device details and status are removed in the design of the module. The reason for its removal is that unidentified devices do not really have its corresponding device type, device specification and device details. The status of an unidentified device is unidentified. Therefore, a status field is no longer necessary since all devices are classified as unidentified. When the device in the Device Recognizer tab is identified, the necessary information must be supplied such as the device type, device specification and device details. Thus, when a device is identified, its device ID is automatically supplied and its entry from the Device Recognizer tab is removed. The role of the Device Recognizer Module is to classify the device and its role. Although SNMP is capable of getting device information, there are devices that have a specific purpose like an IDS or DD (Device Discoverer). The essential part of SNMP is to get other device information coming from the system itself. 5.3


There are certain changes that were made in Table 4-5 for the Log Collector Module. An additional field, Log Number, is added and certain existing fields, Facility, Severity and IPAddress, are edited. Each log is given a log number, which increments every time the Log Collector Module collects logs from different network devices. This field is used as the table’s primary key.


5-26

The Facility and Severity fields contain corresponding numbers in their fields instead of a text or worded version for those fields. The conversion of Facility and Severity numbers to text or worded versions are done later in the Log Normalizer Module. The IP Address field is replaced to Hostname. In this field, it receives the hostname of the network device. If the hostname is unavailable, it receives the IP address and the port number instead. These are done to follow the format of Syslog protocol stated in RFC 3164. Table 5-2. Syslog Format of a Windows Computer Devices COMPUTER_ WINDOWS (192.168.1.1)

Timestamp 7/3/10 10:30:36 AM

Hostname Plato_DaAcademy

Facility 6

Severity 3

Message service control manager[info] 7036 The ATKGFNEX Service service entered the running state.

When logs are received by the system, the hostname field in the Syslog is checked in the by the Device Identifier Module (see Table 5.1). Once the hostname from the Syslog matches a hostname in the Device Identifier Module then the log is stored in the Log Collector Module until it is normalized and consolidated. However, when the hostname found in the Syslog is not found in the Device Identifier Module then the log is not collected and instead, its hostname is sent to the Device Recognizer Module. In Table 5-2, a Syslog has a hostname “Plato-DaAcademy” and it is checked in the Device Identifier Module (see Table 5.1). Since the hostname “Plato-DaAcademy” is found in the Device Identifier Module then the Syslog is collected. Furthermore, the Log Collector Module also collects information that is not found in a Syslog. This information is called SNMP processing which can be elicited from identified devices. The user can collect system information from devices using the “SNMPGET” command and collecting it under the object ID “.1.3.6.1.2.1.1.” The following fields in the system branch are collected: System Description, Object ID, System Up Time, System Contact, System Name and System Location (see 3.17 for further information on SNMP). This information is helpful in discovering information regarding devices enrolled in the system. 5.4


The implementation of the Log Normalizer Module, as discussed in Section 4.4.4, remains the same. Naming conventions are given for all network devices. The naming convention is given the format devicetype_devicespec_normalizer.


5-27

When a Syslog is collected by the Log Collector Module, the hostname’s corresponding device type and device specification are both used in determining the device normalizer to be used. For example in table 5-1, the hostname “PlatoDaAcademy” has a device type “COMPUTER” and device specification “WINDOWS.” Therefore, the corresponding normalizer to be used is called “COMPUTER_WINDOWS_NORMALIZER.” Each normalizer has a compiled DLL file that is invoked whenever the normalizer is needed. The reason why normalizers are compiled separately in a DLL file is for adaptation issues. If a new device is discovered in the future then the network administrator can easily create a DLL file following the ones implemented before and compile it with proper ways on how to standardize the Syslog of the new device. This will help the administrator create a small program that can be part of the system without recompiling the whole system itself. Each DLL file of a device normalizer has its class named after the device normalizer itself. A method called “ParseSyslog” is responsible for formatting the Syslog into a standardized format. Moreover, the method called “Normalize” normalizes the Facility and Severity of the log and classifies it the Priority whether it is “High,” “Medium” or “Low” (see 3.31 for further information on calculating for Priority). The SNMP processing has its own normalization process. All the fields in the System branch are parsed also to show much simpler, concise yet useful information in device information discovery. Below are existing DLL files but are not limited to the ones used as device normalizers of the system. For future references, same device type must follow the format in logging. In Table 5-4, an example of a normalized message from an IDS can be seen. Table 5-3. Device Normalizers and its AdLCIM Log Format Device Normalizer Computer Intrusion Detection System (IDS) Device Discoverer (Network Mapper) Router Switch Firewall

AdLCIM log format 192.168.1.3:7777 service control manager[info] 7035 ADMU216D130FA7attacker_rocks The Syslog Agent service was successfully sent a stop control.

TINI, TCP, 192.168.1.1, 35747, 192.168.1.3, 7777

The Syslog Agent service was successfully sent a stop control.

1

ICMP PING [Classification: Misc activity] [Priority: 3] {ICMP} 192.168.1.102 -> 192.168.1.101

OTHERS, ICMP, 192.168.1.102, X, 192.168.1.101, X

67

snort: [1:100000:0] BACKDOOR netbus active [Classification: A Network Trojan was Detected] [Priority: 1] {TCP} 192.168.1.12:6000 -> 192.168.1.2:1345

NETBUS, TCP, 192.168.1.12, 6000, 192.168.1.2, 1345

5

Hostname: admu216d130fa7 Device Type: Computer Device Spec: Windows Hostname: dlsub994c5d5ff Device Type: IDS Device Spec: Defender Hostname: philosop-f487b3 Device Type: IDS Device Spec: Snort

Consolidated Log Count (in 20 seconds) 32

Table 6-15. Log Consolidation Testing Test Sequence

Navigation Path

Test Description

Data Input

Input Type

Expected Result

Consolidated?

Log consolidation

User is directed to

15 similar logs are sent to the

A specific network

Valid

The similar logs are

YES


6-15

Successful Attempts / Total Attempts 20 / 20 (100%)

testing

the main window.

server in a span of time.

No similar logs are sent to the server in a span of time.

device sends 15 similar logs to the server in a span of time. A specific network device does not send any similar logs to the server in a span of time.

unified and consolidated into one log.

Invalid

The log is not consolidated since no similar logs are collected.

NO

0 / 20 (0%)

In Table 6-14, the Tini backdoor is run and accessed through PuTTY. Whenever the attacker presses enter whether to execute a command or to explore the victim’s machine, a log is generated. For twenty seconds, the attacker pressed enter for 32 times thus generating 32 logs. The next device, a Windows computer’s Syslog agent was sent a stop control resulting to one log message sent to the server. The next device is an IDS and it sent a log when a hostname typed “ping 192.168.1.101 –t” in the command prompt and it continuously sent an ICMP echo request to the other machine. Each time the ping was successful, a log was sent. Since putting a “-t” to a ping results to continuous ICMP echo requests, the system has counted 67 occurrences of it for just 20 seconds. In Table 6-15, log consolidation testing is done. For the first testing, there were 15 similar logs sent to the server in a span of time. Those 15 similar logs were consolidated successfully by the system for a number of attempts. Meanwhile, on the second testing, no similar logs were sent to the server in a span of time. It is seen on the system that the consolidated log count is only ‘1’ since there were no similar logs found in a span of time. However there are occurrences where the logs are not sent in real time. It has been observed when some client computers have turned off their machines and turned it on again. Some of the logs when the computer was turned off were not sent. The only time when logs were revived and sent was when it was turned on. Thus, some logs are delayed from sending in real time. 6.8 6.8.1

Verifying the Functionality of the Log Correlation Process Procedure

This experiment tests the correlation techniques used in the implementation of the system. There are two inventories that are dynamic to be used by the system such as the Device Inventory and the Attack Inventory. The Device Inventory contains all discovered IP addresses in a LAN with its corresponding operating system. This is usually done and populated by a device discoverer such as NMAP. The Attack Inventory Adaptable Software-based Log Consolidation and Incident Management for a Security Information Event Management SystemAdLCIM

6-16

on the other hand, contains attacks that are listed and monitored by the system with its corresponding operating system where it is vulnerable from. When an attack is launched, the IDS reports to the system that an attack has been recognized. The IP address of the victim is checked from the device inventory and finds for its corresponding operating system. Afterwards, it checks the attack used and its corresponding operating system. It checks whether the operating system of the victim is the same with operating system of the attack. If it is the same, it means that the victim is vulnerable to an attack thus an action must be made. The log is raised to a priority HIGH for urgent response. However, if it is not the same then it means that the attack exists but the victim is not vulnerable to the attack. In this case, the priority for the log becomes LOW. In this test, an attacker tries to launch a Tini attack to a host with a Windows operating system and launches it again to a host with a Linux operating system. Same procedures are done to Netbus and Donald Dick attacks. 6.8.2

Results and Analysis Table 6-16. Checking Correlation from Attack and Device Inventories

Test Sequence

Navigation Path

Test Description

Data Input

Input Type

Expected Result

Resolved?

Attack launching and correlation testing

User is directed to the Incident Manager tab located at the main window.

Launch a Tini attack on a Windows victim and check whether correlation is HIGH. Launch a Netbus attack on a Windows victim and check whether correlation is HIGH. Launch a Donald Dick attack on a Windows victim and check whether correlation is HIGH. Launch a Tini attack on a Linux victim and check whether correlation is

Launch Tini on a Windows victim while running AdLCIM.

Valid

YES

Launch Netbus on a Windows victim while running AdLCIM.

Valid

The priority of the log should be HIGH and hacker cannot access victim’s directory because of event sniping. The priority of the log should be HIGH and no website is accessed because of event sniping.

YES

15 / 20 (75%)

Launch Donald Dick on a Windows victim while running AdLCIM.

Valid

The priority of the log should be LOW and no message box is shown because of event sniping.

YES

17 / 20 (85%)

Launch Tini on a Linux victim while running AdLCIM.

Valid

The priority of the log should be LOW and hacker cannot access victim’s directory.

YES

20 / 20 (100%)


6-17


LOW. Launch a Netbus attack on a Linux victim and check whether correlation is LOW. Launch a Donald Dick attack on a Linux victim and check whether correlation is LOW. Launch an unidentified attack on any victim and check correlation.

Launch Netbus on a Linux victim while running AdLCIM.

Valid

The priority of the log should be LOW and no website is accessed.

YES

20 / 20 (100%)

Launch Donald Dick on a Linux victim while running AdLCIM.

Valid

The priority of the log should be LOW and no message box is shown.

YES

20 / 20 (100%)

Launch the unidentified attack on any victim while running AdLCIM.

Invalid

The system logs the attack as OTHERS since the attack is not yet recognized and the priority of the log should be HIGH.

NO

0 / 20 (0%)

In Table 6-16, when an attacker tries to telnet to a victim on a Windows platform through port 7777, the attack is logged as HIGH priority because the victim machine is vulnerable to the Tini attack. This makes both the Attack Inventory and Device Inventory very essential. That is why it is important that both inventories are up to date and monitored from time to time. Attacking a host which is not vulnerable to such an attack like launching Tini to a Linux machine is also needed to be taken note of, although, neither an alert management nor incident management is needed. It is important as well to take note that an attacker is trying to gain access to such IP address because a Windows computer might take the IP of the Linux machine and becomes vulnerable to such attack in the future. Same is true in the case of Netbus and Donald Dick attacks. For the successful attempts percentage, the success percentage of Netbus and Donald Dick attacks are not consistent unlike Tini. Other tests suggest that some GUI backdoors are not consistently event sniped due to the fact it is the limitation of the IDS since events are not detected continuously. 6.9 6.9.1

Verifying the Functionality of the Log Consolidation Time of the Log Consolidator Module Procedure


6-18

This experiment tests whether the consolidation time feature of the log consolidator works. When a message is sent to the consolidator, it checks whether or not the log is stored already in the database for a particular duration of time. If the message is already existing in the database, the log count is updated. Otherwise it is stored in the database with a log count of “1”. After the duration of time set reaches its threshold, the storage for the messages whose log count is counted are deleted to start the new message counting again. A computer sends an ICMP echo request to another computer continuously and the IDS reports it to the system. 6.9.2

Results and Analysis Table 6-17. Consolidation Time Test

Test Sequence

Navigation Path

Test Description

Data Input

Input Type

Expected Result

Consolidated?

Consolidation of logs and consolidation time

User is directed to the main window and log consolidator time interface to view the consolidated logs.

Consolidatio n time is set to 20 seconds

Check if logging is working with consolidation time of 20 seconds.

Valid

The system consolidat es every 20 seconds.

YES


Check if logging is working with consolidation time of 30 seconds. Check if logging is working with consolidation time of 40 seconds. Check if logging is working with a consolidation time having an input of characters instead of integers.

Valid

The system consolidat es every 30 seconds. The system consolidat es every 40 seconds. The user is prompted with an error message.

YES

20 / 20 (100%)

YES

20 / 20 (100%)

NO

0 / 20 (0%)


Invalid consolidation time input

Valid

Invalid

As seen in Table 6-17, different scenarios on the log consolidation time are tested to see if the log consolidation time adjustment works. The log consolidation time is tested if the system can consolidate logs from every 20 seconds to 30 seconds. Moreover, to test further, the module is tested if the system can consolidate logs from every 30 seconds to 40 seconds. Expectedly, the logs are able to consolidate logs every 20 seconds, every 30 seconds and every 40 seconds. Adaptable Software-based Log Consolidation and Incident Management for a Security Information Event Management SystemAdLCIM

6-19


6.10 Verifying the Functionality of the Alert Manager Module 6.10.1 Procedure This experiment tests if the system is able to identify alert logs that the Incident Manager module failed to resolve. For each alert log, there are corresponding recommendations given for the network administrator. The Alert Manager Module should be able to give recommendations for alerts regarding the system. In this experiment, the Cisco switch, Defender IDS, Windows computer and Linux computer are used since there are already existing alert messages from those devices. The Cisco switch has interface set down while the Linux computer sends a Syslog message stating that a wrong password was entered in the computer. The Defender IDS sends a message stating that an ICMP message was received. The Windows computer stops some of the essential services working. Both devices produce logs and the log consolidator module should determine that those logs should go to the Alert Manager Module. When the network administrator is able to see and resolve the alert message, the alerts are set to Resolved = ‘Yes’. 6.10.2 Results and Analysis Table 6-18. Alert Messages Produced by Cisco Switch, Defender IDS, Windows Computer and Linux Computer Normalized Log OTHERS, ICMP, 192.168.1.107, X, 192.168.1.102, X Application Host Helper Service entered the stopped state. The IPsec Policy Agent entered the stopped state. Interface FastEthernet0/13, changed state to down Authentication failure

Recommendation Check device inventory for possible ICMP attack.

Device IDS_DEFENDER

Check Services and enable Application Host Helper Service.

COMPUTER_WINDOWS

Check Services and enable IPsec Policy Agent Service.

COMPUTER_WINDOWS

Check interface set interface up through console if necessary.

SWITCH_CISCO

Check device for possible dictionary attack.

COMPUTER_LINUX

Table 6-19. Scenarios that Invoke for Alert Management Test Sequence

Navigation Path

Test Description

Data Input

Input Type

Expected Result


Sent to Alert Manager?

Successful Attempts / Total 6-20

Alert log testing

User is directed to the Alert Manager tab located at the main window.

Attempts 20 / 20 (100%)

Ping is performed.

Send ICMP echo request using a host computer.

Valid

The IDS sends log to the system and adds log to Alert Manager with recommendation.

YES

User disables Windows normal services.

Disable Windows normal services and enable Alert Logs in a Windows environment.

Valid

YES

20 / 20 (100%)

User disables Windows normal services in a different subnet.

Disable Windows normal services and enable Alert Logs in a Windows environment in a different subnet. (255.255.0.0)

Valid

YES

20 / 20 (100%)

User disables Windows

Disable Windows

Valid

The following application services are shut down and Syslog agent sends a log and sends it to Alert Manager: Application Layer Gateway Service, Automatic Updates, COM+ Event System, Computer, Browser, Cryptographic Services, DHCP Client, Security Center, System Restore Service and recommendation is seen. The following application services are shut down and Syslog agent sends a log and sends it to Alert Manager: Application Layer Gateway Service, Automatic Updates, COM+ Event System, Computer, Browser, Cryptographic Services, DHCP Client, Security Center, System Restore Service and recommendation is seen. The following application

YES

20 / 20 (100%)


6-21

normal services in a different subnet.

normal services and enable Alert Logs in a Windows environment with 4 computers reporting, 2 of which are in different subnet.

User enters an invalid password three times.

Enter invalid password in Linux 3 times.

Valid

User configures an interface to be administrative ly down. User launches Tini attack.

Set switch interface down.

Valid

A Tini attack is launched.

Invalid

services are shut down and Syslog agent sends a log and sends it to Alert Manager: Application Layer Gateway Service, Automatic Updates, COM+ Event System, Computer, Browser, Cryptographic Services, DHCP Client, Security Center, System Restore Service and recommendation is seen. Linux syslogkd service sends log to the system and adds log to Alert Manager with recommendation. Cisco sends log to the system and adds log to Alert Manager with recommendation. The Tini attack is not logged on the Alert Manager.

YES

20 / 20 (100%)

YES

20 / 20 (100%)

NO

0 / 20 (0%)

Each device normalizer has a text file counterpart, found in Table 6-18, which includes all possible alert messages and its counterpart recommendation. This is open and searched by the system. If no match is found, then it is not an alert message. For the devices used like an IDS, only TCP attacks are handled by the incident management through event sniping. All other protocols such as UDP or ICMP cannot be handled by the incident management and therefore must be handled manually by the network administrator. The importance of the alert manager is seen because even though an alert is not resolvable by the system (like a switch interface is down), it can alert the network administrator on what is happening and how he could possibly resolve it through its recommendations. As seen for the Windows computer, when an application service is stopped, it is sent to the Alert Manager because that service might be crucial in the functionalities of the host computer. Same is true with a wrong password sent 3 times when accessing using the “sudo” in Linux. It can probably be an attack since the attacker seeks for a trial and error or dictionary attack to gain access to the Linux machine. Thus, it also becomes an alert. Lastly, an interface down message sent by a switch is considered Adaptable Software-based Log Consolidation and Incident Management for a Security Information Event Management SystemAdLCIM

6-22

an alert as well because the device where that interface becomes down might be a live server or a computer that needs to access the Internet or network connection. It alerts the network administrator to find for causes of the interface down and resolve problem if necessary. In Table 6-19, the alerts are tested in a same subnet and also tested in a different subnet where some computers try to do the tests using the 255.255.0.0 subnet mask. This makes the system more reliable to handle alerts in the same network but in different subnets. The network administrator lists the alerts and recommendations manually on the network devices’ respective text files. For example, the network administrator wants to add a new alert and its respective recommendation for a Cisco router, the network administrator populates that alert and recommendation at the CISCO_ROUTER.txt file. The format for populating the alert and recommendation is , . Once that is done, logs containing that alert message are now considered as an alert log. If the text files for certain network devices contain only a few alerts, the network administrator can add alerts and recommendations of his or her on choice regarding network device alerts or even alerts regarding the system and/or modules. The list of possible alerts and recommendations that the system can process can be seen on Appendix C. 6.11 Verifying the Functionality of the Incident Manager Module 6.11.1 Procedure This experiment tests if the Incident Manager Module is able to perform Event Sniping on attack logs produced by Snort. For testing, the Tini backdoor is set again in a Windows machine and the IDS should be able to detect the attack. After normalization, the attack should be seen and consolidated afterwards. When the protocol in the log is checked, and it is found to be running under TCP, the log is extracted and the destination IP and destination port are parsed. These fields are sent to the Incident Manager Module and the event sniping is invoked. The attacks were made from different timestamps, using different device computers in the network acting as hackers and victims. 6.11.2 Results and Analysis Table 6-20. Tini, Netbus and Donald Dick Results Test Sequence

Navigation Path

Test Description

Data Input

Input Type

Launch User is Launch a Tini Launch Tini Valid Adaptable Software-based Log Consolidation and Incident Management for a Security Information Event Management SystemAdLCIM

Expected Result

Event Sniped?

Tini attack

YES

Successful Attempts / Total Attempts 20 / 20 6-23

attack

directed to the main window.

attack

Launch a Netbus attack

Launch a Donald Dick attack

Launch an unidentified attack

on a Windows victim while running AdLCIM. Launch Netbus on a Windows victim while running AdLCIM. Launch Donald Dick on a Windows victim while running AdLCIM. Launch the unidentified attack on any victim while running AdLCIM.

session is terminated.

(100%)

Valid

The Netbus attack session is terminated.

YES

15 / 20 (75%)

Valid

Donald Dick attack session is terminated.

YES

17 / 20 (85%)

Invalid

The unidentified attack is not terminated.

NO

0 / 20 (0%)

Table 6-21. List of Actions Made when Tini Attack Occurred Test Sequence Tini attack launched

Navigation Path User is directed to the main window.

Test Description This test checks if the appropriate scenarios are done when Tini is launched.

Test Scenario

Expected Result

Detect attack message from IDS_SNORT_ NORMALIZER

Attack message detected

Normalize attack message

Attack message normalized Message sent to Log Consolidator Module Protocol parsed and checked if it is TCP Destination IP and port parsed and victim is event sniped

Send message to the Log Consolidator Module Parse protocol from the normalized message and check if it is TCP If protocol is TCP, parse the destination IP and port and event snipe the victim

Actual Result PASSED

PASSED PASSED

PASSED PASSED

Table 6-22. Scenarios where Event Sniping is Invoked Test

Navigation

Test

Data Input

Input


Expected

Results? 6-24

Successful

Sequence

Path

Description

Type

Result

Attacks launched with and without AdLCIM

User is directed to the main window. Hacker can access victim.

Launch a Tini attack without running the system.

Launch a Netbus attack without running the system. Launch a Donald Dick attack without running the system. Launch Tini and Netbus attacks with the system running.

Launch Tini attack to a Windows victim without running AdLCIM.

Valid

Hacker can access victim’s file directory.

YES

Launch Netbus attack to a Windows victim without running AdLCIM.

Valid

Hacker can control victim’s environment

YES

20 / 20 (100%)

Launch Donald Dick attack to a Windows victim without running AdLCIM.

Valid

A message box appears to the victim computer.

YES

20 / 20 (100%)

Launch Tini and Netbus simultaneously in a single victim Windows while running AdLCIM.

Valid

YES

18 / 20 (90%)

Launch a Tini, Netbus and Donald Dick attacks with the system running. Launch 2 Tini attacks with the system running

Launch Tini, Netbus and Donald Dick in a single victim Windows while running AdLCIM.

Valid

Both Tini and Netbus receive RST packet and connection is lost. All attacks receive RST packet and connection is lost.

YES

14 / 20 (70%)

Launch 2 Tini attacks in a single victim Windows while running AdLCIM

Valid

YES

20 / 20 (100%)

Launch Tini attack with the system running in a different subnet. Launch Netbus attack with the system running in a different subnet.

Launch Tini attack in a single victim Windows while running AdLCIM in a different subnet for victim.

Valid

Both Tini attacks receive RST packet and connection is lost. Tini attack receives RST packet and connection is lost.

YES

20 / 20 (100%)

Launch Netbus attack in a single victim Windows while running AdLCIM in a different subnet for victim.

Valid

Netbus receives RST packet and connection is lost.

YES

15 / 20 (75%)


6-25

Attempts / Total Attempts 20 / 20 (100%)

Launch Tini attack in a different subnet with the system running. Launch Netbus attack in a different subnet with the system running. Launch an unidentified attack with the system running.

Launch Tini attack in a single victim Windows while running AdLCIM in a different subnet for attacker.

Valid

Tini attack receives RST packet and connection is lost.

YES

20 / 20 (100%)

Launch Netbus attack in a single victim Windows while running AdLCIM in a different subnet for attacker.

Valid


YES

15 / 20 (75%)

Launch the unidentified attack on any victim while running AdLCIM.

Invalid


NO

0 / 20 (0%)

The logs generated by Tini, Netbus and Donald Dick are seen. Attacks were attempted and were tested on a computer running in a Windows platform. Tini, Netbus and Donald Dick sessions are terminated. The enabling of the Event Sniper in the module is responsible in terminating TCP attacks. The protocol field is parsed to check if the protocol is TCP. If the protocol is TCP, the IP address and port number are sent to the incident manager to invoke event sniping. Any other protocol cannot be resolved by the incident manager and the log is sent to the Alert Manager. In Table 6-20 and Table 6-22, there are different scenarios conducted to test whether the attacks can be resolved in different states. The basic is attacking a host computer with only 1 attacker. Multiple attackers are also tested to see if the system is capable of sniping simultaneous attacks. The test is also essential because it should handle attacks in real time. Lastly, the test also proved that the system can handle incidents in different subnets. Logically speaking, the system should be able to handle attacks in the same network even in different subnets and it proved such fact. In Table 6-21, Tini is being specifically tested. There is a list of actions to be done by the system whenever the Tini backdoor is detected by the IDS. The Tini attack log coming from the IDS is processed by the system and in the end, the Tini attack session is terminated via event sniping. The successful attempts percentage of the different attack scenarios, found in Table 6-20 and Table 6-22, vary as mentioned and explained before in Section 6.8. 6.12 Verifying the Functionality of the Report Generator Module 6.12.1 Procedure


6-26

This experiment tests the generation of the reports, based on the logs coming from different network devices, by the system. It involves querying of logs per timestamp, hostname, device type, device specification and log type. It also shows in charts the top devices that produce the largest logs per day. It also shows logs in charts in a daily basis. 6.12.2 Results and Analysis Table 6-23. Report Generation Testing Test Sequence

Navigation Path

Test Description

Data Input

Input Type

Expected Result

Reports Generated?

Reports generated based from the identified devices’ logs Reports generated based from the unidentified device’s logs

User is directed to the Report Chart tab.

User checks if report chart is automatically updated as it collects logs. User checks if report chart is automatically updated as it collects logs.

Logs from identified devices

Valid

YES

Logs from unidentified devices

Invalid

Report chart updates as it collects logs. Report chart shows nothing.

User is directed to the Report Chart tab.

NO

0 / 20 (0%)

As seen in Table 6-23, reports are only generated based on the collection of logs coming from the identified network devices. From the start, logs from the unidentified network devices are not received and collected by the system. The report chart is automatically updated in a span of time as the system collects logs. The reports are shown in a daily basis for the network administrator to see the summary of reports. 6.13 Verifying the Functionality of the Events Updater Module 6.13.1 Procedure This experiment tests if the Events Updater Module can update the Attack Inventory Database. The network administrator adds, modifies and deletes an attack and operating system in the attack_inventory table. Another part of the test is to check whether an added attack in the Attack Inventory when doing correlation and do appropriate actions afterwards. A Windows host is supposed to send a SYN Flood using NMAP to another Windows host. The IDS should be able to determine the attack and normalize it as SYN Flood so that it can be recognized by the Attack Inventory. 6.13.2 Results and Analysis Adaptable Software-based Log Consolidation and Incident Management for a Security Information Event Management SystemAdLCIM


6-27

Table 6-24. Tests and Results for the Events Updater Module Test Sequence

Navigation Path

Test Description

Data Input

Input Type

Expected Result

Database Updated?

Add attack and vulnerable OS to inventory Edit attack and vulnerable OS to inventory Delete attack and vulnerable OS to inventory Add entry with incomplete information

User is directed to the Attack Inventory tab located at the main window. User is directed to the Attack Inventory tab located at the main window. User is directed to the Attack Inventory tab located at the main window. User is directed to the Attack Inventory tab located at the main window. User is directed to the Attack Inventory tab located at the main window. User is directed to the Attack Inventory tab located at the main window.

User adds attack and vulnerable OS.

Add attack and vulnerable OS

Valid

Attack and vulnerable OS are added.

YES

User edits attack and vulnerable OS.

Edit attack and vulnerable OS

Valid

Attack and vulnerable OS are edited.

YES

20 / 20 (100%)

User deletes attack and vulnerable OS.

Delete attack and vulnerable OS

Valid

Attack and vulnerable OS are deleted.

YES

20 / 20 (100%)

User enters incomplete information.

Add OS, leave attack blank

Invalid

User is prompted to fill up both fields.

NO

0 / 20 (0%)

User enters incomplete information

Edit OS, leave attack blank

Invalid

User is prompted to fill up both fields

NO

0 / 20 (0%)

User deletes attack and vulnerable OS not found in database.

Delete OS not found in database

Invalid

User is prompted that the attack and vulnerable OS do not exist.

NO

0 / 20 (0%)

Edit entry with incomplete information Delete attack and vulnerable OS not found in database


Table 6-25. SYN Flood Attack Record Time Launched 2010-10-22 02:47:18

Attacker IP/Port

Victim IP/Port

Message

Total Log Count

172.16.4.100: 60312

172.16.4.62:705

SYN FLOOD, TCP, 172.16.4.100, 60312, 172.16.4.75, 705

675

In Table 6-24, different attacks with its other details are put in and out the database. This makes the system useful and adaptable to future attacks that are discovered and proper correlation in Attack Inventory.


6-28

In Table 6-25, the SYN Flood is one attack that is added to try whether the system is adaptable to new attacks. The attack is launched in a live network and the victim computer receives a lot of SYN packets which later on made the victim’s computer slow and no Internet access is made. When the IDS detects the SYN Flood, it sends numerous SYN Flood warnings to the system. Because there are a lot of logs continuously sent, the IDS tends to have a delay on the sending of the some other logs. Although other normal devices send their logs real time, the IDS starts to have some time delay on sending logs because it is also affected by the SYN flood. It is proven because both IDS and the victim machine sent an application log stating “The Symantec Management Client service terminated unexpectedly.” All of their anti-virus crashed and some services become slow in responding. The IDS however is able to report the number of times the SYN Flood occurred: 675 times. The reason why the IDS has detected and set 675 logs was that there were 675 SYN packets sent to the victim thus, every time an anomalous SYN packet is received, it is logged and sent to the system. These logs are all stored and shown in the system. 6.14 Verifying the Functionality of the Incident Manager Module in a Live Network 6.14.1 Procedure This experiment tests if the system’s Incident Manager through the use of Event Sniping is utilized as planned through series of injected attack packets such as whether the system can detect attacks in the same subnet with single and multiple attackers of the same or different attacks. This experiment is done in a live network environment where 6 client computers are reporting to the system including 2 IDS that are all connected to a Cisco Catalyst 2960 where port mirroring is enabled. 6.14.2 Results and Analysis Table 6-26. Scenarios where Event Sniping is Invoked in a Live Network Test Sequence

Navigation Path

Test Description

Data Input

Input Type

Expected Result

Results?

Attacks launched with and without AdLCIM



Launch Tini attack to a Windows victim without running AdLCIM.

Valid


YES

Launch a Launch Netbus Valid Netbus attack attack to a without Windows victim running the without running system. AdLCIM. Launch a Launch Donald Valid Adaptable Software-based Log Consolidation and Incident Management for a Security Information Event Management SystemAdLCIM


YES

20 / 20 (100%)

A message

YES

20 / 20 6-29


Donald Dick attack without running the system. Launch Tini and Netbus attacks with the system running. Launch a Tini, Netbus and Donald Dick attacks with the system running. Launch 2 Tini attacks with the system running

Dick attack to a Windows victim without running AdLCIM. Launch Tini and Netbus simultaneously in a single victim Windows while running AdLCIM. Launch Tini, Netbus and Donald Dick in a single victim Windows while running AdLCIM. Launch 2 Tini attacks in a single victim Windows while running AdLCIM

box appears to the victim computer. Valid

Valid

Valid

(100%)

Both Tini and Netbus receive RST packet and connection is lost. All attacks receive RST packet and connection is lost.

YES

17 / 20 (85%)

YES

15 / 20 (75%)

Both Tini attacks receive RST packet and connection is lost.

YES

20 / 20 (100%)

Testing the effectiveness and accuracy of the Incident Manager Module in a live environment, as seen in Table 6-26, is the same as testing it in a regular networking experiment without Internet connection as long as the IDS is reporting correctly. The initial problem that this test encountered was that the IDS was not reporting when the attacks were launched. There was a simple issue that was forgotten to enable: port mirroring. When the network hub was first used, all the packets were sniffed by the IDS. However, when the Cisco switch was used, no packets were received. Afterwards, the Cisco switch through access in the console interface was configured to port mirror in the port where the IDS is plugged and the logs were all sniffed and TCP-based attacks were sent RST packets. The successful attempts percentage of the different attack scenarios vary as mention and explained before in Section 6.8. 6.15 Verifying the Functionality of the Incident Manager Module in a Live Network with a Different Subnet 6.15.1 Procedure This experiment tests if the system’s Incident Manager through the use of Event Sniping is utilized as planned through series of injected attack packets such as whether the system can detect attacks in a different subnet with single and multiple attackers of the same or different attacks. This experiment is done in a live network environment where 6 client computers are reporting to the system including 2 IDS that are all connected to a Cisco Catalyst 2960 where port mirroring is enabled. Adaptable Software-based Log Consolidation and Incident Management for a Security Information Event Management SystemAdLCIM

6-30

Table 6-27. Scenarios where Event Sniping is Invoked Live Network with a Different Subnet Test Sequence

Navigation Path

Test Description

Data Input

Input Type

Expected Result

Results?

Attacks launched in a different subnet with and without AdLCIM



Launch Tini attack to a Windows victim in a different subnet without running AdLCIM.

Valid


YES

Launch a Netbus attack without running the system.

Launch Netbus attack to a Windows victim in a different subnet without running AdLCIM. Launch Donald Dick attack to a Windows victim in a different subnet without running AdLCIM. Launch Tini attack in a single victim Windows while running AdLCIM in a different subnet for victim. Launch Netbus attack in a single victim Windows while running AdLCIM in a different subnet for victim. Launch Tini attack in a single victim Windows while running AdLCIM in a different subnet for attacker. Launch Netbus

Valid


YES

20 / 20 (100%)

Valid

A message box appears to the victim computer.

YES

20 / 20 (100%)

Valid


YES

20 / 20 (100%)

Valid


YES

15 / 20 (75%)

Valid


YES

20 / 20 (100%)

Valid

Netbus

YES

14 / 20

Launch a Donald Dick attack without running the system. Launch Tini attack with the system running in a different subnet. Launch Netbus attack with the system running in a different subnet. Launch Tini attack in a different subnet with the system running. Launch


6-31


Netbus attack in a different subnet with the system running. Launch an unidentified attack with the system running.

attack in a single victim Windows while running AdLCIM in a different subnet for attacker. Launch the unidentified attack on any victim while running AdLCIM.

receives RST packet and connection is lost. Invalid


(70%)

NO

0 / 20 (0%)

6.15.2 Results and Analysis The test made in Table 6-27 is a continuation of the experiment done in 6.14. However this time, some client computers are configured to attack in different subnets. This is to prove that the system can handle and manage incidents that are in the same network of different subnets. The newly configured attackers have a subnet mask of 255.255.0.0 while the victim’s subnet is 255.255.255.0. The system is able to successfully handle the TCP-based attacks after correlation with the same accuracy and reliability as managing attacks of the same subnet. The dependency of the system’s accuracy in analyzing logs and managing incidents relies a lot with the performance of the IDS. It is notable during the testing stage that the Snort IDS is stable in reporting incidents to the system and in return, the event sniping is also stable in incident management. The successful attempts percentage of the different attack scenarios vary as mention and explained before in Section 6.8. 6.16 Verifying the Comprehensiveness, Accuracy, Stability and Usability of All the Modules in Integration Running in a Normal Live Environment through Massive Logs from Different Devices and Users 6.16.1 Procedure This experiment tests if the system can be deployed in a real normal environment wherein there are a lot of various devices of different types and various users as well in a Local Area Network. The system is set to run in the CNIS laboratory from 8:00am9:00pm in a regular class day. Since the CNIS laboratory has classes the whole day until 6:00pm, all the devices are set to send their Syslog messages to the system having an IP address of 172.16.4.100. After class hours, the laboratory set up is changed. Since the IDS cannot sniff packets not for destined for them, port mirroring should be enabled. However, the CNIS lab network is connected to a D-Link switch and such port mirroring configuration could not be established due to lack of equipment, nine devices (2 IDS, 1 main system and 6 other regular Windows clients) are placed in a Cisco Catalyst 2960 switch and another port is dedicated to give Internet connection to the devices that are part of the Cisco switch. In this setup, the IDS can sniff packets coming from Adaptable Software-based Log Consolidation and Incident Management for a Security Information Event Management SystemAdLCIM

6-32

different network devices that are connected in the Cisco switch through port mirroring. Attacks can now be recorded and managed.

Figure 6-1. Network Setup Containing AdLCIM Server with Cisco Catalyst 2960 Port Mirroring Enabled and 6 Terminals Monitored by 2 IDS 6.16.2 Results and Analysis Table 6-28. Summary of Facts Gathered in the Comprehensive Test on October 21, 2010 Standard information query Date of test Start running time of the system End running time of the system Total running duration time of the system Number of users Number of computers reporting Number of IDS reporting Switch type and specification that gives network connection in the CNIS laboratory Switch type and specification where port mirroring is enabled Total logs collected Summarized logs Attacks launched

Facts gathered October 21, 2010 2010-10-21 08:05:35am 2010-10-21 08:34:56pm 12 hours 29 minutes Approximately 60 (students in class and testers of attacks) 20 (all Windows XP operating system) 2 D-Link DES 3250TG Cisco Catalyst 2960 Switch


26,783 6,140 Tini Netbus Donald Dick Syn Flood

6-33

Table 6-29. Summary of Functions and Results of Each Module Integrated in the Comprehensive Test Test Sequence

Navigation Path

Test Description

Data Input

Input Type

Expected Result

Results?

Integration of all modules

User is directed to the main window.

User tests the Device Identifier Module.

Identify, modify or delete devices. Identify unrecognized devices

Valid

YES

User tests the Log Collector Module.

Accept Syslog messages from devices

Valid

User tests the Log Normalizer Module.

Normalize Syslog messages to standardized format through the use of normalizers in .dll files

Valid

User tests the Log Consolidator Module

Consolidate logs in pattern every 20 seconds and correlate if logs come from IDS

Valid

The system can add, modify or delete devices in the database. Unidentified devices cannot send logs and identified devices are removed from the unidentified devices table. The system accepts raw Syslog messages from various devices (19 computers, IDS, switch) and stores to database stably. The collected logs must be able to be normalized into its standardized format by checking the device type and device specifications of it in the Device Manager and matches the right normalizer by dynamically loading a .dll file. Logs of the same kind must be consolidated every 20 seconds and produce a single log. Alert text files of each device must be checked and if a potential alert, must be stored in the Alert

User tests the Device Recognizer Module.

Valid



YES

20 / 20 (100%)

YES

20 / 20 (100%)

YES

20 / 20 (100%)

YES

20 / 20 (100%)

6-34

User tests the Alert Manager Module.

Store alert messages and show not yet resolved messages.

Valid

User tests the Incident Manager Module.

Event snipe all TCP attacks that are vulnerable after correlation.

Valid

User tests the Report Recommendation Generator Module.

Update report charts for network administrator to view daily.

Valid

Manager table with its corresponding recommendation. If a log comes from an IDS, it must be checked whether the protocol is TCP for incident management. If the victim is not vulnerable to the attack, the priority should be changed to low. The system must be able to store alert logs and show not yet resolved alerts in the interface together with its recommendation. The system must be able to send RST packets to TCP attacks that are classified HIGH priority by the Log Consolidator. The system must be able to update the report charts regarding normal, alert and attack logs.

YES

20 / 20 (100%)

YES

20 / 20 (100%)

YES

20 / 20 (100%)

In Table 6-28 is the summary of this test. The system was set to run for a whole day in the CNIS lab. During the weekdays, the laboratory is busy being used by students of different levels for lecture and laboratory purposes. The system ran for the day and it proved that it was stable because all logs from morning until closing time were stored and can be analyzed. The purpose of the system was shown evidently in Table 6-29 as a network monitoring tool because all devices reported to the system for a whole day giving normal, alert and attack logs in an live environment where there are people working and there is an Internet connection. The IDS responded in real time providing potential and real attacks were given proper attention and management.


6-35

In the start of the test, all the devices reported but all were considered unidentified. After classifying all the devices, it started sending all application event logs to the system. Alert logs were also seen in the system when some services were stopped like the anti-virus Symantec for instance. Some devices were also set in a different subnet and still were able to report to the system. When attacks are launched, the IDS’s were able to detect it and the system successfully managed the incident through event sniping. 6.17 Verifying the Comprehensiveness, Accuracy, Stability and Usability of All the Modules in Integration in a Different Network Setup 6.17.1 Procedure This experiment is similar to Section 6.16, however, not in a live network environment. The setup is almost the same as Figure 6-1. The network devices added are a Cisco PIX firewall and a Cisco router. This is to test if all the devices are able to send their logs successfully to the system and test all the modules in integration.

Figure 6-2. Network Setup Containing AdLCIM Server with Cisco Catalyst 2960 Port Mirroring Enabled, Cisco Router 1841, Cisco PIX Firewall 515E and 6 Terminals Monitored by 2 IDS

6.17.2 Results and Analysis Table 6-30. Summary of Functions and Results of Each Module Integrated in the Comprehensive Test Test Sequence

Navigation Path

Test Description

Data Input

Input Type

Expected Result

Results?

Integration

User is

User tests the

Identify,

Valid

The system can

YES


Successful Attempts / Total Attempts 20 / 20 6-36

of all modules

directed to the main window.

Device Identifier Module. User tests the Device Recognizer Module.

modify or delete devices. Identify unrecognized devices

Valid

User tests the Log Collector Module.

Accept Syslog messages from devices

Valid

User tests the Log Normalizer Module.

Normalize Syslog messages to standardized format through the use of normalizers in .dll files

Valid

User tests the Log Consolidator Module

Consolidate logs in pattern every 20 seconds and correlate if logs come from IDS

Valid

add, modify or delete devices in the database. Unidentified devices cannot send logs and identified devices are removed from the unidentified devices table. The system accepts raw Syslog messages from various devices (19 computers, IDS, switch) and stores to database stably. The collected logs must be able to be normalized into its standardized format by checking the device type and device specifications of it in the Device Manager and matches the right normalizer by dynamically loading a .dll file. Logs of the same kind must be consolidated every 20 seconds and produce a single log. Alert text files of each device must be checked and if a potential alert, must be stored in the Alert Manager table with its corresponding recommendation. If a log comes from an IDS, it


(100%) YES

20 / 20 (100%)

YES

20 / 20 (100%)

YES

20 / 20 (100%)

YES

20 / 20 (100%)

6-37

User tests the Alert Manager Module.

Store alert messages and show not yet resolved messages.

Valid

must be checked whether the protocol is TCP for incident management. If the victim is not vulnerable to the attack, the priority should be changed to low. The system must be able to store alert logs and show not yet resolved alerts in the interface together with its recommendation.


YES

20 / 20 (100%)

6-38

User tests the Incident Manager Module.

Event snipe all TCP attacks that are vulnerable after correlation.

Valid

User tests the Report Recommendation Generator Module.

Update report charts for network administrator to view daily.

Valid

The system must be able to send RST packets to TCP attacks that are classified HIGH priority by the Log Consolidator. The system must be able to update the report charts regarding normal, alert and attack logs.

YES

20 / 20 (100%)

YES

20 / 20 (100%)

In Table 6-30 is a summary of the test. In the start of the test, all the devices, as well as the two additional network devices added to the setup, reported but all were considered unidentified. After classifying all the devices, it started sending all application event logs to the system. Alert logs were also seen in the system when some services were stopped like the anti-virus Symantec for instance. Some devices were also set in a different subnet and still were able to report to the system. When attacks are launched, the IDS’s were able to detect it and the system successfully managed the incident through event sniping. 6.18 Verifying the Functionality of the SNMP Processing of the System 6.18.1 Procedure Aside from Syslog messages, SNMP messages are also collected by the system. This experiment tests if the system is able to receive SNMP messages as well and go through the process of normalization and consolidation just like the Syslog messages. In order for the system to receive SNMP messages, the network devices should be configured to send SNMP messages to the server. 6.18.2 Results and Analysis Table 6-31. Collect, Normalize and Consolidate SNMP Logs Test Sequence

Navigation Path

Test Description

Data Input

Input Type

Expected Result

SNMP Logs Sent?

Receive, normalize and consolidate SNMP logs

User is directed to the main window.

A Windows computer is configured to send SNMP logs. A Cisco firewall is configured to

Send SNMP logs from Windows computer

Valid

The system is able to receive, normalize and, if possible, consolidate SNMP logs.

Yes

Send SNMP logs from Cisco firewall.

Valid

The system is able to receive, normalize and, if possible, consolidate

Yes



20 / 20 (100%)

6-39

send SNMP logs. A Cisco switch is configured to send SNMP logs A Windows computer is configured with Syslog Agent to send logs.

SNMP logs. Send SNMP logs from Cisco switch.

Valid

Send Syslog messages from Windows computer.

Invalid

The system is able to receive, normalize and, if possible, consolidate SNMP logs. The system is able to receive Syslog messages instead of SNMP logs.

Yes

20 / 20 (100%)

No

0 / 20 (0%)

As seen in Table 6-31, different network devices are configured to send SNMP messages to the server of the system. The SNMP messages are treated just as similar as the Syslog messages. SNMP messages are collected successfully by the server. Afterwards, the SNMP messages are normalized for easier viewing of logs. Lastly, the SNMP logs are consolidated if possible and classified if the log is a normal log, an alert log or an attack log.


6-40

7.

Conclusion and Recommendations 7.1

Conclusion

The system is able to perform its purpose of collecting logs from different network devices, analyze and consolidate it and determining normal, alert and attack logs. With this, it is essential to point out how the system is able to perform its purpose by proving that the objectives are met. The AdLCIM is able to accept logs, as seen in Table 6-6, from different devices that are connected to a network. These devices include Defender Intrusion Detection System (IDS), Snort IDS, client Windows (XP and 7 models) and Linux machines, Apple Time Capsule router and file server, Cisco and D-Link switch, Cisco router, Cisco PIX firewall and NMAP Device Discoverer. As long as the devices are identified, the system is able to collect logs in networks of different locations. The system is tested in different laboratories both in manually set up network in the Computer Technology Laboratory (CT-LAB) and a live normal network environment such as CNIS. The system also is able to accept logs from devices whether a hub (3-Com) or router (Linksys or Cisco), or switch (D-Link or Cisco) is used. The system can also accept logs in different subnets of the same connection. Both in a manually set up network and in a live normal network environment, the AdLCIM was tasked to receive logs for a whole day as seen in Table 6-28 and tested in Table 6-29. It was able to accept logs from different network devices no matter how vast it was and it remained stable. The importance of both the log normalizer and log consolidator was seen. The devices reported on a standardized and simpler format, which makes the network monitoring and administration easier. The essence of log consolidation was also seen because there were recurring logs that were generated a lot of times and good thing all of those were consolidated into a single log. For Section 6.12, all the consolidated logs are stored and archived in a table called alpha_logs. The only necessity in the said module is to query necessary data in the alpha_log table and show it in a Graphical User Interface (GUI). The recommendation part, however, exists for all devices that are specified in its appropriate normalizers. All alert logs must have a recommendation so that the network administrator can be able to resolve issues easier. The recommendation part of the module is also completed. During the comprehensive tests, each tester tries to invoke an alert so that it can check whether logs are classified as alert and see whether the recommendation is helpful enough. As a result, the alerts are logged in the alert manager and recommendations are seen. It is also summarized in the generated chart report classified as an alert log. Different logs are successfully gathered and classified by the system. All crucial component-related logs are considered alerts and must be recorded together with a recommendation as seen in Table 6-18 and tested in Table 6-19. All logs classified by the Adaptable Software-based Log Consolidation and Incident Management for a Security Information Event Management SystemAdLCIM

7-1

IDS are considered priority “HIGH.” After correlation of the Attack and Device Inventories, the log may be classified “LOW” if the vulnerable operating system of the attack is not equal to the corresponding operating system of the device. All priority “HIGH” logs that have TCP as its protocol is event sniped, meaning a RST packet is sent to cut the connection. Other protocols aside from TCP are considered nonresolvable and are sent to the Alert Manager Module. Other tests suggest that some GUI backdoors are not consistently event sniped due to the fact it is the limitation of the IDS since events are not detected continuously. During the comprehensive test of the system where it was run in a live normal network environment, different packet scenarios were tested using test scripts as seen and tested in Section 6-14. Attack logs were invoked by launching attacks such as Tini, Netbus, Donald Dick and SYN Flood in different times and durations. Alert logs were also forced like shutting down interfaces in a switch and stopping crucial services in client computers. The effectiveness of log classification can be evidently seen in those scenarios. Of course, normal logs were also received and consolidated as well. The system is adaptable to new devices invented or discovered just as long that it has a Syslog sending capability. It is just up to the network administrator to make device normalizers and classifying the hostname with the right device type and device specification. Overall, the system is able to perform its purpose in different scenarios and useful in network monitoring. 7.2

Recommendation

The system implemented has met its objectives per se. The system however during experimentation and implementation, has found other ways in making it more efficient and useful which is beyond its scope and limitations. 7.2.1

Recommendation for the Device Identifier Module

After the system implementation and during the experimentation, the Device Identifier Module has played a vital role in determining the devices that can send logs to the system. In this regard, it can be recommended that in the next time that the system is deployed, the network administration should probably mandate that all the identified devices use a hostname rather an IP Address. According to RFC 3164, the hostname of the device is given a higher priority of identification rather than the IP Address. Although the IP Address is also used in replacement of the hostname, it was found out that in actual system deployment, most devices use a dynamic IP Address and therefore frequent update in the Device Identifier Module is needed. Unlike if the hostnames are used, whether or not the IP Addresses are changed, the identity of the device remains the same.


7-2

7.2.2

Recommendation for the Log Normalizer Module

The Log Normalizer Module is implemented as planned. However the module can be improved by making a normalizer class that is inherited by the specific classes aside from the super normalizer class. In the current state of the module, all normalizers inherit some main functions from the super normalizer class and thus creating newly specified class for a particular device like a COMPUTER_WINDOWS_NORMALIZER or an IDS_SNORT_NORMALIZER. It is recommended to create a class that can be placed between the super normalizer class and the specific class. For example, instead of creating all the functions for the IDS_SNORT_NORMALIZER, some functions can be put in the IDS_NORMALIZER. This IDS_NORMALIZER has the normalization powers for an IDS and can be used by other normalizers even if it is not SNORT. 7.2.3

Recommendation for the Log Consolidator Module

The consolidation and correlation of the module are useful currently. But during the experimentation, there have been similar logs that are received by the system but not physically formed. There are patterns seen manually in logs generated by a certain device, but formed very differently, which make the consolidator hard to consolidate very well. Possible use of data mining might be recommended in future study for log consolidator improvements. 7.2.4

Recommendation for the Incident Manager Module

For incident management, only the TCP packets can be resolved when an attack occurs. It is therefore recommended to search for other ways on how to resolve attacks that are in another protocol like UDP or ICMP to make the system more useful.


7-3

Appendix A. Bibliography [1]

Adriano, A., Sanchez, N., Trogo, J. & Villamor, R. (2004). Central Security Manager. Published in HNICEM, Undergraduate thesis, De La Salle University, Manila, Philippines.

[2]

AdventNet. (2007). Analyzing Logs for Security Information Event Management. AdventNet Inc.

[3]

Alien Vault OSSIM. (2008). Correlation Techniques, Retrieved February 2009 from http://alienvault.com.

[4]

ArcSight. (2008). ArcSight. Retrieved November 2008 from http://www.arcsight.com.

[5]

Bellare, M. & Yee, B. (1997). Forward Integrity for Secure Audit Logs. University of California, San Diego, USA.

[6]

Beser, E. (2008). A Guide to the Perplexed Business Owner Helping Your Business Surive the Unexpected Shutdown. Ennovate Inc.

[7]

Bulanhagui, P., Redulla, G. & Tan, L. (2005). Online Network Monitoring System Using RMON Standards, NEMSYS Online, Undergraduate Thesis, De La Salle University.

[8]

Caswell, B. et al. (2003). Snort 2.0 Intrusion Detection. Syngress Publishing: Rockland, Massachusetts.

[9]

Cisco Systems Incorporated. (2006). Cisco Security Monitoring, Analysis and Response System. Cisco Systems.

[10]

Cole, E. (2008). Correlating SIM Information to Detect Insider Threats. SANS Analyst Program.

Adaptable Software-based Log Consolidation and Incident Management for a Security Information Event Management System-AdLCIM

1

[11]

Datagram SyslogServer. (2008). SyslogAgent. Retrieved April 2010 from http://syslogserver.com/syslogagent.html.

[12]

Gomez, M. & Wong, S. (2007). Virtual Information Security Testing System, EPSILON, Undergraduate thesis, De la Salle University, Manila, Philippines.

[13]

Gruschke, B. (1998). Integrated Event Management: Even Correlation using Dependency Graphs. Department of Computer Science, University of Munich, Germany.

[14]

Hellerstein, J. & Ma, S. Mining Event Data for Actionable Patterns. IBM T.J. Watson research Center Hatwthrone, New York, USA.

[15]

Iptables. TCP State Connections. Retrieved June 2010 from http://www.faqs.org/docs/iptables/tcpconnections.html.

[16]

Juniper Network. (2010). Including Priority in System Log Messages. Retrieved October 2010 from http://www.juniper.net.

[17]

Kent, K. & Souppaya, M. (2006). Guide to Computer Security Log Management. National Institute of Standards and Technology. Technology Administration U.S. Department of Commerce.

[18]

Lara, C., Kebschull, U. & Schiefer, A. (2008). Distributed and Decentralized Event Management for Embedded Systems. Department of Computer Engineering, University of Leipzig, Leipzig, Germany.

[19]

Lonvick, C. (2001). The BSD Syslog Protocol. Retrieved July 2009 from http://www.ietf.org/rfc/rfc3164.txt.

[20]

Manticore Technology Corporation. (2008). Intellitactics Security Manager. Retrieved November 2008 from http://www.intellitactics.com.


2

[21]

MIT-Xperts. (2008). iSims SI (EIT/SDT) Management System. Retrieved November 2008 from http://www.mit-experts.com/products/isims/isims.pdf.

[22]

Net-SNMP. (2007). SNMP. Retrieved November 2010 from http://www.net-snmp.org.

[23]

Nicolett, M., Proctor, P. & Williams, A. (2006). Magic Quadrant for Security Information and Event Management. Gartner RAS Core Research Note.

[24]

Nmap Security Scanner. (2010). Nmap Zenmap. Retrieved July 2010 from http://nmap.org/download.html.

[25]

OSSIM Development Team. (2008). Open Source Information Management. Retrieved November 2008 from http://www.ossim.net.

[26]

PRTG. (2009). PRTG. Retrieved July 2009 from http://www.paessler.com/prtg.

[27]

RSA Security Incorporated. (2007). Design and Implementation for Security Information Management. The Security Division of EMC.

[28]

Security Information Management Resource Guide. (2008). The Security Information Pocket Guide. Retrieved November 2008 from http://www.simbuyer.com.

[29]

Swift, D. (2006). A Practical Application of SIM/SEM/SIEM Automating Threat Identification. Sans Institute.

[30]

Tenable Network Security. (2008). Nessus. Retrieved November 2008 from http://cgi.tenablesecurity.com.

[31]

The One Software. (2009). One SysLog Manager. Retrieved July 2009 from http://www.theonesoftware.com/syslog_manager.php.


3

[32]

Vidstrom, A. NT Security. Tini. Retrieved July 2010 from http://www.ntsecurity.nu/toolbox/tini.

[33]

Webopedia. (2010). DLL. Retrieved April 2010 from http://www.webopedia.com/term/d/dll.html.

[34]

Wikipedia. (2010). Dynamic Loading. Retrieved April 2010 from http://en.wikipedia.org/wiki/dynamic_loading.


4

Appendix B. List of Devices Used for the Experiments Device Type Computer

Device Specification Windows

Router

Linux Cisco Linksys

Swtich Firewall IDS Device Discoverer File Server

Edimax D-Link Cisco Cisco Snort Defender NMAP SNMP Apple


Device Details XP 7 Ubuntu v9 1841 WRT54G E1000 BR-6475N DES 3250TG Catalyst 2960 Pix 515E 2.8.6 V1 Linux-based Net-suite Time Capsule

1

Appendix C. List of Possible Alerts and Recommendations Device Windows Computer

Linux Computer Cisco Switch

Alert Recommendation The Syslog Agent service entered Do nothing. the running state The Application Layer Gateway Turn on Application Layer Service service entered the stopped Gateway service. state The System Event Notification Turn on System Event Service service entered the stopped Notification Service service. state The Computer Browser service Turn on Computer Browser entered the stopped state service. The DHCP Client service entered Turn on DHCP Client the stopped state service. The Cryptographic Services service Turn on Cryptographic entered the stopped state Services service. The COM+ Event System service Turn on COM+ Event entered the stopped state System service. The Windows Security Center Turn on Windows Security Service has stopped Center Service service. NT AUTHORITYLOCAL Turn on DHCP Client SERVICE DHCPv4 client service service. is stopped NT AUTHORITYLOCAL Turn on DHCP Client SERVICE DHCPv6 client service service. is stopped The WinHTTP Web Proxy AutoTurn on DHCP Client Discovery Service service entered service. the stopped state authentication failure Check last user. 3 incorrect password attempts Check last user. Interface FastEthernet0/1 changed Check interface. state to down Interface FastEthernet0/1 changed Check interface. state to administratively down Line protocol on Interface Check interface. FastEthernet0/1 changed state to down


2

Cisco Router

Interface FastEthernet0/1 changed state to down Interface FastEthernet0/1 changed state to administratively down Line protocol on Interface FastEthernet0/1 changed state to down


Check interface. Check interface. Check interface.

3

Appendix D. List of Normalized Attacks from Snort and Defender IDS Snort

Defender

IDS Attack Log TINI BACKDOOR DETECTED BACKDOOR netbus active BACKDOOR donalddick v1.5b3 runtime detection SNMP AgentX/tcp request THE BACKDOOR TINI HAS BEEN DETECTED THE BACKDOOR NETBUS HAS BEEN DETECTED THE BACKDOOR DONALD DICK HAS BEEN DETECTED SYN FLOOD HAS BEEN DETECTED

Normalized Attack Log TINI


NETBUS DONALD DICK SYN FLOOD TINI NETBUS DONALD DICK

SYN FLOOD

4

Appendix E. Personnel Technical Vitae Justin David Pineda Computer Technology Department College of Computer Studies De La Salle University [email protected] Roberto Yatco Jr. Computer Technology Department College of Computer Studies De La Salle University [email protected] Miguel Alberto Gomez Computer Technology Department College of Computer Studies De La Salle University [email protected]


5

Adaptable Software-based Log Consolidation and ...

Adaptable Software-based Log Consolidation and ...

Suggest Documents

Adaptable Software-based Log Consolidation and

The Multispace adaptable building concept and ... - Adaptable Futures

Consolidation

adaptable futures: sustainable aspects of adaptable buildings

( ) and p* X ( ) is ( )log ( ) ( ) ( )log - PLOS

Pre-Consolidation and Post-Consolidation of Nigerian Banking Sector ...

modelo/model codigo / code adaptable a:/adaptable to: honda ...

Plant Consolidation

20PulsePoint Consolidation

Departmental Consolidation

Debt Consolidation

Departmental Consolidation

Departmental Consolidation

Cori, an adaptable Docker

CREATING ADAPTABLE BUSINESSES:

memory consolidation

Consolidation Sets

CONSOLIDATION BEGINS

Carbon taxation and fiscal consolidation:

Carbon taxation and fiscal consolidation:

Designing for Adaptable Learning

Supplementing Consolidation and Apportionment ...

Retail Consolidation and - Clute Institute

SAP® BusinessObjects™ PLANNING AND CONSOLIDATION ...