Real-time analysis of security incidents with SIEM
Security Information and Event Management (SIEM) solutions help organizations with threat detection, regulatory compliance and incident management in IT security in general.
Structure of a SIEM
SIEM solutions primarily collect and analyse data from various security events, data from other IT events and information for further context-related evaluation. For this purpose they offer the collection and storage of event and log data, their normalization, correlation and analysis as well as log management. Classic SIEM solutions usually fail to provide advanced analysis with the greatest possible degree of automation, supported by methods from the field of Artificial Intelligence (AI/KI), usually by means of machine learning. This is exactly where highly exciting use cases for access analytics arise. This ranges from the detection of threat scenarios in IAM or PAM systems, the mitigation of attacks by the IAM to the automation of IAM processes.
The previous diagram gives an insight into the system components of a SIEM. The lower part of the graphic shows all external event sources. This includes the data/events of all connected systems. The SIEM system first stores and standardizes all data available to it and creates a timeline if necessary. Thus, the data can also be used for forensic analysis. The external event sources (some are received passively, some are collected actively by agents) are analyzed, classified and checked for business relevance (data enrichment) by the data collectors. These steps are important to put the data into a company-specific context (network areas, departments, etc.).
In the upper part of the graphic the individual system components of a SIEM are listed. All these components communicate bidirectionally with the message bus, thus implementing the principle of “near real time”, i.e. availability of all events & alarms almost in real time for all components of the SIEM system.
- The “correlation” is a fixed set of rules that the system uses to generate alarms or inform employees by email. This set of rules represents the use cases that are relevant for a company (from regulatory requirements or best practice)
- The “UEBA component” contains machine learning models. These models learn processes, create peer groups and detect when there are deviations from “normal behavior”. If there are such deviations, an alarm is generated. Such an alarm is treated in the same way as an alarm from a correlation.
- A SIEM needs a “ticket system” or a connection to the company’s own ticket system to handle incidents in a controlled way. This can exist in the SIEM or an existing ticket system can be connected.
- All events and alarms are stored centrally in the “data memory”. There are SIEM systems that have several data memories, some of which are hierarchically structured. The GUI interface, reports and other components access the data memory via the message bus, e.g. to enable searches for current events or reports.
- With the “automated actions”, IAM systems or other systems can be directly connected or addressed.
Workflow of a SIEM
A SIEM system per se offers no advantages without qualified staff to monitor the system and intervene in the event of non-autonomous response actions. This is generally referred to as a SOC (Security Operation Center).
The workflow of a SIEM consists of four basic processes:
- Collect,
- Recognize,
- Examine and
- Respond.
The system receives a number of events. These are collected, standardized and centrally created in SIEM. The SIEM checks all events and triggers alarms for defined events or event combinations, which are sent to a responsible employee for investigation. The employee collects evidence, supported by the system, and creates a timeline in which all actions are displayed. This process is automated in some SIEM tools. Based on the created timeline, it is possible to judge whether it is an attack or normal/allowed behavior. Afterwards, attacks can be reacted to manually or automatically.
