SIEM - Security Information and Event Management

Ruslan Rakhmetov, Security Vision

Figure 1 - SIEM evolution

Before the SIEM concept was ‘legitimised’ by Gartner analysts, it existed as two terms and, consequently, two different solutions. SEM (Security Event Management) and SIM (Security Information Management) systems were separately designed to analyse IS events ‘on the fly’ and for historical analysis and searching for anomalies ‘in the database’. In 2005, along with Gartner's analysis, the combined term SIEM was mentioned at various conferences, such as the NEbraskaCERT Conference, after which the class of solutions became widely demanded as a single window for collecting and analysing data from network devices, domain controllers, operating systems, databases and other IS and IT application systems.

Second-generation SIEM is now emerging, which is actually an amalgamation with related solutions like Threat Intelligence and Behaviour Analysis, complementing incident search with compromise indicator analysis and machine learning algorithms. IS vendors are evolving, buying adjacent solutions and delivering more functionality every year. But since TI, UBA/UEBA and other solutions exist separately, we will look at SIEM in isolation. Such a classic system is designed to monitor events, search for incidents and anomalies both in real time and retrospectively.

It is also worth noting that ‘by itself’ the class of solutions considered today cannot protect or stop something: events and incidents will continue to occur, but with a high probability will be detected quickly enough if the SIEM is configured.

Figure 2 - Problems to be solved

Let's imagine a situation where a person tries to enter someone else's house with their keys. Assuming that the key fits, as in the famous film ‘The Irony of Fate, or With Easy Steam!’ 1975, but the person had malicious intent - he can steal something. Then the IS event becomes an incident, and the owner of the house should find out about it as soon as possible.

1 Information about attempted entry can be obtained from the concierge, smart intercom, entryway camera and other sources, but each of the sources would have to be studied separately if the SIEM did not solve the first task - data normalisation and grouping. The system collectors allow to collect all events into a common format: NGFW from one vendor can report ‘deny’, another ‘discard’, a third ‘drop’, DLP from different vendors send their reports in different forms, AV adds its reports and alerts to the event stream, etc. If we imagine that a single application has the entire log of visits in a convenient format, then by analogy we can imagine the SIEM interface, where a person can easily understand what is going on.

2. The SIEM system is able to analyse the login attempts and assume, after trying unsuccessful passwords, that several events are related and perhaps someone is trying to ‘bruteforce’ the door. This is the second task of the system - correlation of events into a single chain. To solve it, the logs of your ‘door’ are analysed in real time. Correlation is a purely mathematical task, we will not go into its details and leave it to scientists. Of course, the efficiency of the system will be maximised when it contains the appropriate expertise in the form of packages from developers, so manufacturers offer them to their users.

3. In the simplest case, rules are described in RBR (Rule Based Reasoning) formats and analyse triggers, counters and possible chains of actions. For example, if a person logs into his Internet bank in Russia, and an hour later the attempt is repeated from Serbia - a fraud attempt is possible, so the bank's IS employee should be notified as soon as possible. Alerts are the third task of SIEM. When interacting with IRP systems, it is possible to implement a process related not only to alerts, but also to automatic response, when information security tools will be launched themselves and protect the user by launching EDR and two-factor authentication (or a call from the bank with an economic security officer ‘on the wire’).

4. Now let's imagine a situation without IRP or timely action of an IS specialist - there was a data leak or theft of their flat, just like in the cinema. Most likely, the real tenant will want to go to the police, court or insurance company for compensation of losses, but to do so, they need to gather more evidence. SIEM is able to provide all the necessary evidence base, solving the fourth problem. Such a set of evidence will be suitable for both internal investigations and in court.

5. Thefifth task (not quite obvious) is already solved for companies that want to develop their defences. The SIEM system itself is usually an expensive product, which requires ‘cool’ hardware to work, but everything is not as bad as it seems at first glance. When there are many incidents and the company suffers financial and reputational losses, the question of additional purchase of new protection means arises. The budget for such purchases will help to get a retrospective search and description of all incidents for the previous year. When used in this way, the system will definitely pay for itself and more.

Fig. 3 - Architecture of the SIEM-system

Architecturally, solutions of this class are organised in different ways, so we will try to collect the most general image of a possible SIEM-system.

The most important and resource-intensive is the server part of the software. It contains collectors, correlators and database. The task of the collectors is to collect data from sources and perform basic grouping, removing duplicates and making it easier for the second link to work. The correlation server is responsible for understanding incidents and sifting simple events from the overall flow. The flow of events is usually calculated in advance to optimise the load, so the sizing is described by the number of events per second (EPS). Once incidents are identified, an alert is generated either through the management console (usually web interface) or through other means of communication (the most common is corporate email). The last (not the most important) server component is the database. Its size and disc requirements depend on the depth of storage, which can be determined either by the customer or the appropriate regulator.

Information can be collected remotely by means of connection via NetBIOS, RPC, TFTP, FTP protocols. However, in this case there may be a problem with the load on the network, which is solved by the client part of the software. ‘Agents’ are installed on user hosts and significant servers, collect data locally and transmit it to the control centre on their own schedule.

In this way SIM+SEM=SIEM perform automated monitoring of events from dozens, hundreds and even thousands of different sources, normalise their reports and group them into possible incidents and notify responsible persons about them. Collected statistics and database searches enable the formation of unified processes for mitigating consequences and responding to incidents, with additional efficiency added by automation and orchestration tools.