2021/03/11 • 4 min read

What is Security Information and Event Management? (SIEM)

Every day we hear on articles or on the news about cybersecurity attacks targeted at companies. Nowadays there is no company that works without access to the Internet and because of that the whole company is exposed to the virtual world.

So, with that in mind, it is fundamental that companies become more aware of cybersecurity attacks and vulnerabilities present on equipment, applications, and services used daily.

For that it is mandatory to define standards that oppose these problems in a way that mitigates them in a quick and effective way. Besides the standards it is necessary to use tools that support automation for the security workload.

Tools like antivirus, firewalls and IDS/IP are important for the prevention of security incidents but when it comes to detection, containment, and investigation SIEMs are the tool to go for.


What is a SIEM? 

The term SIEM (Security Information and Event Management) defined by Nicolett and Willliams in 2005 comes from combining two concepts:

  • Security Information Management (SIM)is a log storage, analyser and reporting system that focus on cybersecurity threats found on those logs.
  • Security Event Management (SEM) – is a security event processing system which aggregates, correlates, and notifies events through security systems like antivirus, firewalls, and Intrusion Detection Systems (IDS). It can also process authentication events, SNMP traps, server logs, database logs, etc. 

The introduction of a SIEM  allowed that the identification of anomalies, vulnerabilities and security incidents were easily achieved through aggregation and correlation of historical log data and real-time security events.


Architecture of a SIEM 

A SIEM is a system divided into multiple steps that work in a linear way, which means that a step is always dependent on the previous step. This way, in case of a step failure, all the following steps will fail. Basically, a SIEM is divided into six fundamental steps as displayed in Figure 1.

Figure 1 – SIEM’s Architecture (source: Security Information and Event Management (SIEM) Implementation )



Source Device

The source device is the first part of a SIEM architecture. Source devices can be a device, an application or any type of data that can be stored and then processed by a SIEM. The most common logs retrieved from source devices are:

  • operating systems logs that show any interactions with the system;
  • appliance logs, representing logs from routers, switches, among others;
  • application logs, detailing every interaction performed within the application scope.


Log Collection

The Log Collection phase represents the actual extraction of logs from the source devices. This can be done in two different ways. The Push Method is an extraction method that involves sending logs from the source device to a receptor on the SIEM side. The most common way is to redirect the svslog from a machine to a receptor on the SIEM side.

In the Pull Method, on the other hand, the connection with the source device to get the logs is initiated by the SIEM. The SIEM connects to a network pathway where the logs are stored from a source device  and retrieves them directly to the SIEM. This method presents as a disadvantage due to the need to get the logs periodically, instead of obtaining them in real time, like in the Push Method.


Parsing Normalization

The Parsing Normalization phase consists in a standardization of the obtained logs. The normalization allows the SIEM to comprehend and analyse the logs entries. It also facilitates the human understanding of the obtained logs contents.


Rule/Correlation Engine

The Rule/Correlation Engine phase is characterized by two sub-phases:

  • In the Rule Engine sub-phase, the rules are defined and applied on the normalized logs, conditioning the SIEM alerts. For example, if a user authenticates to a machine with “root” access, it is possible to create a rule that checks for this event and triggers  an alert.
  • The Correlation Engine sub-phase correlates all the events associated with alerts created by the rule engine, being dependent from the rule engine. For example, in a brute force attack, the correlation engines will gather all the login attempts events and associate them with a brute force alert created by the SIEM.


Log Storage

The Log Storage phase stores all the SIEM processed logs, so they can be accessed in case of need. The processed logs can be stored in three different ways: database, text file or binary file. The most common way to store logs is in databases, such as Oracle, MySQL, etc. The disadvantage of this method is the additional administration needed.

The storage of the logs in a text file has the advantage to be presented in a human readable format. However, the storage of logs in text files requires a delimiter between the log’s parameters. This method is not the most effective due to scalability issues.

Binary files are bond exclusive to the SIEM, used when there is not a need of external access to the logs. They represent an advantage in scalability due to fast read/write operations and memory usage.



The monitoring is the final phase of a SIEM’s architecture. In this phase, SIEM interacts with stored logs representing the obtained information in an interface. The interface can be web or applicational, using it to manage a SIEM, allowing a unique vision of the environment.

The monitoring phase facilitates the user’s investigation of incidents allowing for a faster Mean Time To Resolve (MTTR).


The future for SIEMs

SIEMs exist for quite a while, dating back to 2005 when the first SIEM concept was presented, and it has not changed its architecture and implementation methods for quite a while. Without a doubt it has its share of problems, from a high number of false positives to the complex maintenance and operation.

Cyberthreats have evolved quite rapidly throughout the years and with that SIEMs need to keep up with these changes. Legacy SIEMs cannot keep up with the amounts of data needed to be processed by today’s standards. So next-generation SIEMs are capable of a better detection of cyberthreats through the usage of AI and machine learningQRadar SIEM is a great example of this using its AI module, QRadar Advisor, it provides real-time learning capabilities to automatically investigate and qualify security incidents and advise analysts on the nature and extent of an incident.

Next-gen SIEMs are also capable of handling and storing large amounts of data due to modern lake technology such as Amazon S3, Hadoop or ElasticSearch. This is a big improvement compared to the legacy SIEMs when they used text files or specific binary files that were only possible to be accessed by the SIEM itself.


SIEM as a Security “Big Eye”

The introduction of SIEMs revolutionized the way to detect, contain and investigate security incidents becoming a mandatory tool to be used in a security incident response plan. Using a SIEM provides a unique view of the infrastructure on a security aspect, regarding overall vulnerabilities, on-going attack events and incidents, network activity, and it provides reporting for these features for an easier analysis and understanding of the current status of the infrastructure security. Using a SIEM also improves the mean time to detect (MTTD) and mean time to repair (MTTR) of security incidents, reducing it a lot when comparing with manual methodologies of security incidents detections and investigations.


If you are interested in other security articles, you can check our articles on PenTest: Information Gathering and Scanning or Vulnerability Analysis and Exploitation.

Go back to the blog posts list