SIEM Implementation for Global and Distributed Environments

Igor Anastasov, Danco Davcev University "Ss. Cyril and Methodius", the Faculty of Computer Science and Engineering (FCSE)

Skopje, Macedonia igoranastasov@yahoo.com; dancodavcev@gmail.com

Abstract— Today’s computer networks produce a huge amount of security log data. Handling this data is impossible without using Security Information and Event Management Systems (SIEM) to centralize the log management and increase the level of information security and data protection in the organization. SIEM collect and aggregate log data from various devices and applications through software called agents or connectors, filter uninteresting data and normalize to a proprietary format, analyses through correlation using contextual information and alert administrators in case of attack. SIEM provide proactive threat detection and real-time analysis of system activity. Handling these issues will be very hard without relying on consolidated, big data-powered SIEM. However, even having the most expensive SIEM solution, the organization should not expect the product to work great out of the box. The best SIEM solution does not guarantee success. The organization should focus on building various use cases to make their SIEM solution a success. In this paper, we propose a new model and architecture for SIEM implementation that is using multiple hierarchical SIEM Managers. The model is called “Hierarchical Managers Model”. We demonstrated how this model and architecture could be created and enabled in the leading SIEM system – ArcSight ESM [7]. We also provide examples of possible use cases that we have created and tested in our testing environment. These are meant to provide a good base starting point and should not be considered comprehensive for all situations. The use cases shown in this paper are created using the security event correlation framework from Hewlett-Packard – ArcSight ESM [7].

Index Terms—information security, computer security, event management, SIEM, log management, ArcSight ESM [7], rules, use cases, Internet of Things.

I. INTRODUCTION A log is a record of events occurring within an

organization’s systems and networks. Logs are composed of log entries; each entry contains information related to a specific event that has occurred within a system or network. Many logs within an organization contain records related to computer security. These computer security logs are generated by many sources, including security software, such as antivirus software, firewalls, and intrusion detection and prevention systems; operating systems on servers, workstations, and networking equipment; and applications.

The number, volume, and variety of computer security logs have increased greatly, which has created the need for

computer security log management—the process for generating, transmitting, storing, analyzing, and disposing of computer security log data. Log management is essential to ensuring that computer security records are stored in sufficient detail for an appropriate period of time. Routine log analyses are beneficial for identifying security incidents, policy violations, fraudulent activity, and operational problems. Logs are also useful for performing auditing and forensic analyses, supporting internal investigations, establishing baselines, and identifying operational trends and long-term problems. [2]

A fundamental problem with log management that occurs in many organizations is effectively balancing a limited quantity of log management resources with a continuous supply of log data. Log generation and storage can be complicated by several factors, including a high number of log sources; inconsistent log content, formats, and timestamps among sources; and increasingly large volumes of log data. Log management also involves protecting the confidentiality, integrity and availability of logs. Another problem with log management is ensuring that security, system, and network administrators regularly perform effective analyses of log data. To handle these data and provide an increased level of information security and centralized log management and analysis Security Information and Event Management Systems (SIEM) can be used. SIEM can help organizations that struggle with the various applicable compliance regulations and reduce the risk of intrusions into the network.

SIEM are systems that provide centralized log handling by collecting logs (primarily those related to security) from various devices and applications of a network, as well as by analyzing and storing these logs. If the system detects an attack it can react through its incident management channels, which includes alerting personnel and even initiating counter measures. A SIEM can also help an organization comply with regulations pertaining to data retention, and the latter can be helpful in cases of e-discovery (also known as litigation preparation) and forensics. The system can also, to some extent, help with network diagnostics. Other use cases include user and policy monitoring and identity management. [2]

In this paper, we propose a new model and architecture for SIEM implementation that is using multiple hierarchical SIEM Managers. The model is called “Hierarchical Managers Model”. We demonstrated how this model and architecture can

978-1-4799-3351-8/14/$31.00 ©2014 IEEE

be created and enabled in the leading SIEM system – ArcSight ESM [7].

In Section II we present the related work. The model and architecture of the log management infrastructure that we propose are given in Section III. In this section, we also propose the minimum types of devices that should be included as log sources. In Section IV we show how this model can be applied in production. We demonstrated how this model and architecture could be created and enabled in the leading SIEM system – ArcSight ESM [7]. Section V shows how use cases can be created, indicates the sources of use case scenarios and gives an example of a use case created in the ArcSight ESM [7] system.

II. RELATED WORKS Security Information and Event Management Systems and

Log Management have become a hot research topic in the recent years. A fundamental problem with log management that occurs in many organizations is effectively balancing a limited quantity of log management resources with a continuous supply of log data. Log generation and storage can be complicated by several factors, including a high number of log sources; inconsistent log content, formats, and timestamps among sources; and increasingly large volumes of log data. [2]

Several works have addressed the Log Management and SIEM as fundamental parts of an information security management system.

The [2] seeks to assist organizations in understanding the need for sound computer security log management. It provides practical, real-world guidance on developing, implementing, and maintaining effective log management practices throughout an enterprise. The guidance in this publication covers several topics, including establishing log management infrastructures, and developing and performing robust log management processes throughout an organization. The publication presents log management technologies from a high-level viewpoint, and it is not a step-by-step guide to implementing or using log management technologies.

The [1] presents the detection capability of the leading Security Information Event Management (SIEM) system from ArcSight [7], which, overall, provides a monitoring solution that complements perimeter defenses and provides the industrial control systems security operator a significantly improved level of situational awareness for a variety of attacks against control systems. This paper presents an integrated system using the examples of a so-called network traversal attack. Such attacks are of particular importance in infrastructure systems because of the layered architectures of such systems.

The [3] gives an overview of a data mining field & security information event management system.

[4] Suggests a framework for attack modeling and security evaluation in Security Information and Event Management systems. It is supposed that the common approach to attack modeling and security evaluation is based on modeling a malefactor’s behavior, generating a common attack graph,

calculating different security metrics and providing risk analysis procedures.

The [5] discusses the possibilities of applying the ontological approach for implementation of the data repository of SIEM systems for distributed networks of Internet enabled objects. Based on the analysis of existing SIEM systems and standards, the choice of ontological approach is made, an example of the ontological data model of vulnerabilities is presented, a hybrid architecture of the ontological repository is proposed and the issues of developing and testing the repository for attack modeling and secure evaluation tasks are discussed.

The [6] presents and describes one of the market’s SIEM systems – ArcSight ESM [7]. [6] introduces the underlying concepts behind the operation of ArcSight ESM, and provides a roadmap to the tools available in ArcSight Manager depending on your role in security operations.

The [8] proposes the architecture of the visualization component for the Security Information and Event Management (SIEM) system. The suggested architecture of the visualization component allows incorporating different visualization technologies and extending easily the application functionality.

[9] is proposing a new architecture for Forensic Storage of Events in Critical Infrastructures. Experimental tests show the performance of this architecture and the high resilience in faulty situations, i.e. when some nodes are under attack.

The main advantage of the hierarchical architecture that we propose in our work is that it is easily extendable and scalable by adding an additional regional SIEM implementation. This architecture is good for big organizations where the event sources are located in multiple data centers and/or regions. Our architecture is recommended for global and/or distributed environments where there is a need for high event throughputs or customer data are located throughout the world or country.

III. MODEL AND ARCHITECTURE This Section presents the architecture of a leading log

management infrastructure ArcSight ESM and how its components interact with each other. The main contribution of this Section is the model and architecture for SIEM implementation entitled “Hierarchical Manager Model” that we propose.

The infrastructure for the ArcSight EMS [7] log management system uses three design layers and is comprised of:

The first layer –devices that generate original logs e.g. sources of logs.

The second layer is composed of centralized systems (multiple servers) that are collecting the original logs from the log sources. The role of the centralized systems is to consolidate and store the logs in the log storage.

The third layer is the monitoring layer. It is composed by the user devices that are used to monitor and review

the logs. Also, the role of the third layer is to manage the servers from the second layer.

In the following figure, the architecture – of the ArcSight ESM [7] system is shown:

Figure 1. Architecture of an ArcSight SIEM system

In this paper, we propose an extension to this architecture

named “Hierarchical Managers Architecture”. The architecture consists of a central SIEM server, similar to the model given above. The difference in our model is that the central SIEM server acts as a parent and communicates with intermediary SIEM servers (called Child Managers), instead of communicating with the Log sources directly. Each Child Manager collects data from some of the Log sources, typically from a specific region or location. The regional child nodes collect and store data, then normalize events before passing them along to the central SIEM server for aggregation, correlation, and reporting. Raw event data remains on the local child for forensic purposes.

The advantages in this model is that it can make data management challenges easier to implement by distributing the load among a greater number of engines, and it reduces the network overhead by only passing a subset of the captured data to the parent for correlation and analysis. Data storage, backup, and processing are much easier on smaller data sets. Furthermore, construction of reports can be distributed across multiple nodes, which is important for very large data sets.

The primary point of this “Hierarchical Managers Model” is that the parent and child Managers each take on different responsibilities. Alerting, filtering, normalization, reporting, and anything else having to do with policy enforcement are responsibilities of the Child Managers. Correlated events are forwarded from each Child Manager to the Global Manager for global correlation. All rules, filters and lists logic are done at the child level. The role of the Parent Managers is to collect all

correlated events from all regional instances. The Parent Manager and its monitoring layer will be used for case handling.

Given this model, we propose that the organizations should have separate Security Operation Centers (SOC) for all regional SIEM implementations and one global SOC for the Parent SIEM implementation. Analysts will use global or regional monitoring layers to access the SIEM Manager.

The architecture of the model that we propose is shown in the following Figure 2:

Figure 2. Hierarchical Managers Architecture

The log managers, which are responsible for collecting logs, their consolidation and storing in the data warehouses, are composed of three servers. The log database is installed on the first server. The actual Log Manager, which is responsible for managing the agents or connectors that are collecting the logs from the devices, is installed on the second server. The Manager is also responsible for storing the logs into the log database. The third server is doing the actual collecting of the logs using the installed connector (agent). The difference with the Child and Parent Managers is that the Parent Manager communicates only with Child Managers, so they are functioning like connectors to the Parent Manager.

The main advantage of this architecture is that it is easily extendable and scalable by adding an additional regional SIEM implementation. This architecture is good for big organizations where the event sources are located in multiple datacenters and/or regions.

Given the proposed architecture of the SIEM implementation, the next step is to choose the devices that will generate logs in the first layer of all Child SIEM solutions in this architecture.

In the first layer, we suggest that the organizations should include as log sources at least the following devices and types of their logs that are generated:

Domain controllers – all servers that are domain controllers in the domain of the organization. Classes and types of logs that should be generated are displayed in the following table:

Policy Setting Audit account logon events Success, Failure Audit account management Success, Failure Audit directory service access Success, Failure

Audit logon events Success, Failure Audit object access Success, Failure Audit policy change Success, Failure Audit privilege use Success Audit process tracking Success Audit system events Success, Failure

Databases – the database servers that store the testing and production databases from the core organizational applications. The definition for the trace files should include the following options TRACE_FILE_ROLLOVER and SHUTDOWN_ON_ERROR.

E-mail servers – servers that enable the electronic mail communication. The class of logs that should be generated is the default exchange message logging.

Intrusion Detection and Prevention System – a system for detection and avoidance of network attacks. The classes of logs that should be included as a log sources are all logs that are generated from all sensors of the system.

Firewall system. Classes of logs that need to be generated are: Accept, Authorize, Block, Bypass, De-authorize, Decrypt, Encrypt, Inspect, Key Install, Login, Monitor Only, Quarantine, Reject, Replace Malicious Code, and VPN Routing.

Network devices – all routers and switches in the network of the organization should be enabled as a log sources. Classes of logs that need to be generated are level 6 (informational). Logs of all network devices are provided by the central syslog server.

Logs from the Antivirus system. Administrators of all devices listed above are responsible

for ensuring that the defined levels of log classes and the logs are generated and available to the log management system.

IV. EXPERIMENTAL RESULTS In this Section we will present our experimental results of

the testing of architecture presented in the preceding Section. We have created an environment with one Global Manager connected with two Regional Managers. The logs from the connector are sent to the each Regional manager through the Internet. Virtual servers are installed at the connector side on each regional implementation, where all regional connectors are installed. The communication between regional connectors and the manager is shown in the following Figure 3.

Figure 3. Communication between regional connectors and Manager

Even having the most expensive SIEM solution and architecture, the organization should not expect the product to work great out of the box. The best SIEM solution does not guarantee success. The organization should focus on building various use cases to make its SIEM solution a success. The organizations should collect only the logs that they need. Provided below are examples of possible use cases that we have created and tested in our testing environment. These are meant to provide a good base starting point and should not be considered comprehensive for all situations. The use cases shown in the following figures are created using the security event correlation framework from Hewlett-Packard – ArcSight ESM [7].

From the domain controllers we have created the following set of “use cases”, shown in the Figure 4.

Figure 4. Domain Controller “use cases”

From the connector that is collecting logs from the E-mail servers, the created set of possible use cases are presented in Figure 5.

Figure 5 Use cases from E-mail sever

Network devices and servers generate a lot of log data. Inspecting and reading all the logs that are generated from these devices is virtually impossible. We suggest building the following use case scenarios for these types of log sources, shown in the Figure 6.

Figure 6. Network monitoring “use cases”

The use cases for monitoring organizations’ servers are presented in the following Figure 7.

Figure 7. Monitoring regional servers

As we have suggested in Section III, the database servers where the testing and production databases from the core organizational applications are stored, should be included as a log sources in the SIEM implementation. We suggest building at least this set of use cases for monitoring most critical databases, shown in Figure 8.

Figure 8. Monitoring critical databases

V. BUILDING USE CASES Use case development is a complete process and not merely

a simple task. Any organization or company has different high level business, compliance, regulatory and security requirements. Because the requirements and regulation can change during the time, more and more use cases can be created and implemented in the SIEM solution.

Internal policies, procedures and audit reports are good sources for creation of the use cases. For example, organization’s “E-mail usage policy” has a rule that says that users cannot automatically forward internal email externally from the organization. This is a good starting point for creating a SIEM use case. It can be implemented as a correlation rule that fires when these two events are generated:

1. Event 1 – Inbound email, where the sender domain is from the company’s domain.

2. Event 2 – Outgoing email where following conditions are met:

a. Message subject is same as the subject of the message from Event 1, but starts with “FW:” at the beginning.

b. Source user that sends second message is the same as the user that receives first message.

c. Destination user from the second message is not in the company’s domain.

d. Second message is sent after the first message.

The following Figure 9 represents the above rule implemented in the ArcSight SIEM solution.

Figure 9 Rule “Internal email forwarded externally from the

organization”

VI. CONCLUSION In this work, we propose a new model and architecture for

SIEM implementation based on multiple hierarchical Managers. We have demonstrated how this model and architecture can be created and enabled in the leading SIEM system – ArcSight ESM [7]. We have presented our experimental results of testing the proposed architecture. We have also provided examples of possible use cases that we have created and tested in our testing environment. This presents a good base starting point and it should not be considered comprehensive for all situations. Finally, we have shown how internal requirements and regulations of each organization can be good sources for creating of the use cases in the SIEM

implementation. We have provided an example of the creation of such a rule.

REFERENCES [1] Linda Briesemeister, Steven Cheung, Ulf Lindqvist, Alfonso

Valdes, “Detection, Correlation, and Visualization of Attacks Against Critical Infrastructure Systems”, Eighth Annual Conference on Privacy, Security and Trust in Ottawa, Ontario, Canada, August 2010, pp. 15 – 22.

[2] Karen Kent, Murugiah Souppaya, “Guide to Computer Security Log Management”, Recommendations of the National Institute of Standards and Technology (NIST) Special Publication 800-92, September 2006.

[3] Mrs.Anita Rajendra Zope, Prof. D.R.Ingle, “Event Correlation in Network Security to Reduce False Positive”, 2012 International Journal of Computer Science & Communication Networks,Vol 3(3), 2012, pp.182-186.

[4] Igor Kotenko, Andrey Chechulin, “Common Framework for Attack Modeling and Security Evaluation in SIEM Systems”, Green Computing and Communications (GreenCom), 2012 IEEE International Conference, November 2012, pp. 94 - 101.

[5] Igor Kotenko, Olga Polubelova and Igor Saenko, “The Ontological Approach for SIEM Data Repository Implementation”, Green Computing and Communications (GreenCom), 2012 IEEE International Conference, November 2012, pp.761 - 766.

[6] ESM 101: Concepts for ArcSight ESM™ v5.0 SP2 May, 2010 [7] ArcSight ESM “5.0” “Software” “2010”

http://www8.hp.com/us/en/software-solutions/software.html?compURI=1340712, “HP”

[8] Evgenia Novikova and Igor Kotenko, “Analytical Visualization Techniques for Security Information and Event Management”, Parallel, Distributed and Network-Based Processing (PDP), 2013 21st Euromicro International Conference, February 2013, pp.519 – 525.

[9] Muhammad Afzaal, Cesario Di Sarno, Luigi Coppolino, Salvatore D’Antonio and Luigi Romano, “A Resilient Architecture for Forensic Storage of Events in Critical Infrastructures”, High-Assurance Systems Engineering (HASE), 2012 IEEE 14th International Symposium, October 2012, pp.48 – 55.