The Alert Grouping mechanism groups together alerts into cases in order for the Security Analyst to have a better context of issues they need to tackle.
The goal is to accentuate the importance of additional context to a security alert and avoid situations where the analysts will investigate the same security incident without the context and may lose precious time or even handle this incident in the wrong way.

The Alert Grouping mechanism allows you to create grouping rules controlling the exact type of alerts which will be grouped together into cases. The rules work on a hierarchical system whereby each incoming alert is matched against a rule in the following order:

  1. Alert Type
  2. Product
  3. Data Source

Once a rule is matched, the system stops checking. Note that if an alert matches a rule, and there is no existing case it can be grouped into, then it will be added to a new case. You cannot create two rules on the same hierarchy for the same value. For example: Data source - ArcSight can have one rule only.
In addition, the platform has an out of the box rule which cannot be deleted. This fallback rule provides a general catchall for alerts to ensure that there is always grouping in Cases. However, two options (group by, grouping entities) can be edited.

The Grouping Mechanism configuration can be found in the Settings > Advanced > Alerts Grouping to configure the settings.

In the General part of the screen, you have the following cross-platform settings:

  • Max. alerts grouped into a Case: Define the maximum number of alerts to group together into one Case (30). After the maximum number is reached, a new Case is started.
  • Timeframe for grouping alerts (in hours): Choose the number of hours with which to group the alerts for the Case (0.5-24 hours with half hour intervals supported). Note that this does NOT apply to the rules below which are grouped by Source Grouping Identifier.
  • Group entities and source grouping identifiers in the same case: When enabled, an alert that should be grouped by “source grouping identifier” according to the grouping rule, will first look for alerts with the same source grouping identifier, and if it doesn’t find any, it will look for all cases in the system with mutual entities and group alerts accordingly (and according to the cross-platform timeframe)

Note: Whether disabled / enabled, if there is a rule with group by: entities, it will look for all cases in the system with common entities (even if they were originally grouped by source grouping identifier)

The rules section allows you to create specific rules targeting different options.
So as a basic example of grouping let’s say an alert “C&C traffic” with destination host 10.1.1.13 is added at 10:00 AM to a case called “Malware Found”.
And another alert “User account changed” with the same destination host is seen at 11:00 AM. Chronicle SOAR identifies the same entity which is involved in both alerts and within the configured time frame, and groups the second alert to the “Malware Found” case.

Let’s look now at creating rules for specific use cases.

Use Case #1

An enterprise company works with 2 connectors – Arcsight and Cybereason EDR. They want to group Arcsight alerts according to both source and destination entities (Rule 1). In addition, they have two kinds of alerts ingested from the Cybereason EDR. They want to group Cybereason EDR Phishing alerts based on source entities only (Rule 2) and group Cybereason EDR Failed Login alerts based on destination entities only (Rule 3).
In order to capture this use case – they need to build the three rules as shown in the following screenshot. Note that the final rule is the fallback rule supplied by Chronicle SOAR.

Use Case #2

An MSSP has a customer who is using the QRadar connector. The MSSP wants to utilize the QRadar Grouping so that they can see cases in Chronicle SOAR in the exact same way that the customer sees their cases in QRadar (Rule 1). The MSSP has another customer who is using Arcsight and they want to group alerts by common entities and for both directions (Rule 2)
But for Phishing alerts for this customer, they want to group by the destination entities, without taking the source entities into account (Rule 3)

In order to capture this use case – they need to build the following three rules: