Configure alert overflow

Supported in:

The alert overflow mechanism is designed to prevent system overflow and improve noise reduction when large volumes of alerts from the same environment, product, and rule are occurring in a short period of time. This mechanism helps avoid repetitive attacks, such as brute force or DDoS, from flooding the platform and database, while ensuring that the Security Operations Center (SOC) continues to function as planned.

The alert grouping mechanism works to intelligently group alerts into cases based on mutual entities and time proximity, allowing analysts to perform contextual analysis of multiple alerts in one case.
In these cases, you'll see multiple alerts in one case, and mutual entities marked in the entities list and the Explorer page.

There are two different configurations for the overflow:

Initial overflow configuration

This configuration is hard-coded in the database and defines that once more than 50 similar alerts are ingested within a 10-minute timeframe, the overflow mechanism is triggered. This is determined by the Is_Overflow method, which is configured on the connector side (added to the connector code in the IDE). Once triggered, the overflow mechanism with this default configuration.
Once triggered, an overflow case is added to the case queue, with one alert indicating the environment, product, and rule of the overflowing alert, with an overflow tag.

Second overflow configuration

This configuration defines what happens after the overflow mechanism is triggered. This can be defined in SOAR Settings > Advanced > Alerts Grouping in the Overflow section.

  • Timeframe for Overflow Case grouping (in hours): Choose the number of hours in which to group the overflow alerts for the case. This is only applied to rules which are grouped by entities only.
  • Max. alerts grouped into an Overflow Case: Define the maximum number of overflow alerts to group together into one case.

For example, 50 phishing alerts are ingested within 8 minutes. The 51st alert triggers the overflow mechanism, and an overflow case is created. Over the next three hours another 119 phishing alerts are ingested resulting in four overflow cases, each containing 30 alerts. Once the three hours are up, the system returns to the default configuration.