Skip to main content

Correlation mechanisms are present only in commercial versions of RuSIEM.

Correlation is performed on the stream in real time. The stream of events is split into a correlation and saved to the database, so it does not introduce a delay between the arrival of events at the input and the saving to the database.

The events arriving at the input correlation, buffered to disk using MQ to prevent losses. Counters and triggers are also buffered. Thus, when a sudden reboot of the server or processes fails - the data will not be lost.

The correlation is carried out according to normalized data (key-value pairs have been extracted) and enriched with symptoms.

In the case of a distributed infrastructure, distributed correlation is used. Many correlation processes are combined through MQ, they exchange micro transactions among themselves without transmitting events. For example, in the central office, the rule “A virus was detected on more than 20 nodes” was created, grouped by the virus name. On Branches - the same rules, separate nodes, but a 10-node counter. If 5 nodes are detected at one branch, at the other 7 and at the third 9 - counters from all branches will be transferred to the central office and the correlation rule will work. At the same time, events are not transmitted to the central office, as is customary in the classic SIEM.

The system already contains many predefined system correlation rules. In the case of system rules, the user can disable them, copy the rule completely into the user one. Users can create their own custom correlation rules and perform any operations with them.

Any correlation rule can be disabled at any time.

Users create their own custom rules in the graphical designer without writing and knowing any code.

The output of the correlation rules are:

  • an incident assigned to users and groups with a specified topic and priority (and email notification of the incident that was scheduled)
  • e-mail notification to external recipients
  • running a script with incident values as an argument (for example, an attacker ip as argument to src.ip for blocking)
  • creating a new event with passing incident parameters as an argument

It is possible to indicate the days of the week and the time when the rule is active. For example, on weekdays from 09:00 to 20:00. If the correlation rule works at another time, it does not create an incident.

The rules are very flexible, they look like a set of logical conditions. Rules conditions can be combined with each other by logical AND / OR / NOT operators and multiple brackets. In terms of the rules can be used many different comparison operators.

The rule can be triggered by:

  • the occurrence of one event that falls under the condition
  • by the number of events in a dynamic time interval
  • by counting the unique values of the selected field (for example, "Connecting more than 60 unique ports within 60 seconds)
  • by sequence of several events (for example, "Instrumental scan" and "Successful entry" from this src.ip)
  • results of executing operator functions

In the rules there is the concept of grouping by object. Grouping serves several purposes:

  • clarifies the condition and the rule of operation
  • prevents duplicate incidents

For example, events from 10, 15, and 20 unsuccessful inputs, respectively, come from 3 hosts. We have a "More than 15 unsuccessful login attempts within 120 seconds" rule. How should the rule be?

For correctness, clarification is needed: under what name of the user, from which host. It would be foolish to just create an incident on the first 15 events received, wouldn’t it? Grouping serves as a refinement, in it we can specify one or more names of keys (fields).

For example, if the username is the same in all 15 events from the second node, and the other is on the third and we create a grouping by the user name AND src.ip, then two incidents will be generated by the second node and the third node grouped by the user name and initial ip address.

If we group only by src.ip, then in the above example, one incident will be formed, combining events from all three nodes. It does not matter that there were more events in the example specified in the rule - 15. There will be one incident, with the creation time for the first 15 events, and the remaining events will complement this incident, update its update time (the incident property).

The correlation rule has the option "Reopen the incident". If the incident was closed and after that a repeated operation occurred on the same grouping object - this option allows you to rediscover the same incident, allowing operators to pay attention to the fact that the incident occurred again and what work was carried out in the framework of the incident.