Alert grouping mechanism

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 investigate the same security incident without the context and may lose precious time or even handle this incident in the wrong way.

The grouping mechanism configuration can be found in SOAR Settings > Advanced > Alerts Grouping.

In the General section of the page, 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). This does not apply to the following rules 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, first looks for alerts with the same source grouping identifier, and if it doesn't find any, it looks for all cases in the system with mutual entities and group alerts accordingly (and according to the cross-platform timeframe).

Note: Whether disabled or enabled, if there is a rule with Group By: Entities, it looks for all cases in the system with common entities (even if they were originally grouped by source grouping identifier).

The Rules section of the page lets you create specific rules targeting different options.
So as a basic example of grouping, 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. Google Security Operations identifies the same entity which is involved in both alerts and within the configured timeframe, and groups the second alert to the Malware Found case.

The alert grouping mechanism lets you create grouping rules controlling the exact type of alerts which are 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. For example, Phishing Alert
2. Product. For example, Cybereason EDR
3. Data Source. For example, Arcsight SIEM
4. Fallback Rule. If neither the Alert Type, nor the Product, nor the Data Source are matched, then the fallback rule is used.

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 is 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 a prebuilt 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 can be edited:

• Group By - Choose between Entities or Source Grouping Identifier (relevant for alerts coming from QRadar Connector – identifier called offense.)
• Grouping Entities (by directions) – relevant for entities only.

Create 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 following four rules. Note that the final rule is the fallback rule supplied by Google Security Operations:

Rule One: Category = Alert Type. Value = REMOTE FAIL LOGIN. Group by = Entities. Grouping Entities = DestinationAddress, DestinationUserName
Rule Two: Category = Data Source. Value = Arcsight. Group by = Entities. Grouping Entities = All Entities
Rule Three: Category = Data Source. Value = Cybereason. Group by = Entities. Grouping Entities = SourceHostName, SourceAddress, SourceUserName
Rule Four (fallback): Category = All. Value = All Alerts. Grouping Entities = All Entities

Use Case #2

An MSSP has a customer who is using the QRadar connector. The MSSP wants to use the QRadar Grouping so that they can see cases in Google Security Operations 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:

Rule One: Category = Data Source. Value = Arcsight. Group by = Entities. Grouping Entities = All Entities
Rule Two: Category = Data Source. Value = QRadar. Group by = Entities. Grouping Entities = (leave blank)
Rule Three (fallback): Category = All. Value = All Alerts. Grouping Entities = All Entities