How to configure the alert overflow mechanism

Supported in:

The alert overflow mechanism was designed to prevent system overflow and improve noise reduction, when lots of alerts from the same environment, product and rule are occurring in a short period of time. For example, making sure repetitive attacks such as brute force or DDoS don't flood the platform and DB and the SOC can continue functioning as it should.

The alert grouping mechanism was designed to intelligently group alerts into cases, by mutual entities and time proximity, and help the analyst to perform contextual analysis of multiple alerts in one case.
This means you would 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.

The initial overflow 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 in the connector side (added to the connector code in the IDE) and which triggers 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, and an overflow tag.

The second overflow 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 is then shunted off into an overflow case.
Over the next three hours another 119 phishing alerts are ingested. This means that four overflow cases are created. Each case containing 30 alerts. Once the three hours are up, we go back to default status.