Alert Grouping -Overflow case

[vanitharaj1208]

if alert grouping criteria is set to

• Grouping Condition: XYZ Rule Name and User
• Overflow Condition: Max 100 Alerts
• Grouping Duration: 24 hours

Event Breakdown:

1. 9:30 AM - 50 Alerts for User ABC
   • 30 Alerts moved to Case XYZ
   • 20 Alerts moved to Overflow Case
   • Balance for Overflow: 80
2. 9:45 AM - 50 Alerts for User ABC
   • All 50 Alerts moved to Overflow Case
   • Balance for Overflow: 30
3. 10:00 AM - 10 Alerts for User ABC
   • All 10 Alerts moved to Overflow Case
   • Balance for Overflow: 20
4. 10:15 AM - 500 Alerts for User ABC
   • 20 Alerts moved to Overflow Case
   • Overflow threshold exceeded
   • Balance for Overflow: 0
   • Remaining Alerts: 480

Question:

What happens to the remaining 480 alerts when the overflow threshold is exceeded? How does the system handle these alerts, and what are the possible actions taken?

[f3rz]

Hi @vanitharaj1208, they will be created within overflow cases. 

So if you configured your overflow case to have 30 alerts maximum attached to it, you will have 16 Overflow Cases fulfilled with overflowed alerts (480). 

[vanitharaj1208]

So if overflow case is set to max alerts to 100, i will have 4 overflow each case filled with 100 alerts and 1 overflow case with 80 alerts . 

but when im doing testing , we run retro hunt and get alerts in the range of 200-300 alerts. But what we are observing is only 70-80% of the alerts are creating a case on SOAR side. So we wanted an explanation of the behaviour we are observing, is it some kind of suppression mechanism being triggered and is there a limit to the case creation rate.

[f3rz]

@vanitharaj1208 most likely, it is happening because of connector level overflow that basically skips alerts. I recommend you examine connector logs for overflow in them. 

[vanitharaj1208]

can you explain a bit more

[f3rz]

@vanitharaj1208 Overflow mechanisms exist in data processing and sometimes at the connector level. 

If it creates Overflow Cases at the data processing level when overflow happens on the connector level, it notifies you in the logs that overflow is detected, identifying which alerts to skip from ingestion completely without creating Overflow Cases. 

Moreover, some of the connectors have the option to turn off connector-level Overflow (which skips alerts). For example, in Exchange Mail Connector v2 with OAuth Authentication:

https://cloud.google.com/chronicle/docs/soar/marketplace-integrations/exchange#exchange-mail-connect...

To validate if connector has overflow mechanism in its code you can search for is_overflowed in connector code in the IDE. 

[vanitharaj1208]

Hi @f3rz ,

Thank you for reply,

During Overflow case Scenario, we observed some cases were not created (Skipped)as shown in below screenshots.

When clicked on the alert name of those, we can see it says "This alert is managed in the SIEM. You can update or close the alert directly here."

Questions:

1. Why  alerts were skipped from ingestion completely without creating Overflow Cases. 
2. what is meant by "This alert is managed in the SIEM. You can update or close the alert directly here"

[f3rz]

@vanitharaj1208 

1. Most likely because you have "Disable Overflow" parameter turned off in the Chronicle Alerts Connector settings.
2. This means that your environment is a SecOps (SIEM + SOAR under single UI). 

I recommend you to check further with Support via Support Case. 

[vanitharaj1208]

2. This means that your environment is a SecOps (SIEM + SOAR under single UI).  ---- no , its separate

[f3rz]

@vanitharaj1208 since this message is from SIEM UI and it is not secops, I believe it is unrelated to overflow. 

[vanitharaj1208]

@f3rz actually it was related to overflow cases