Alert grouping mechanism

Supported in:

The alert grouping mechanism groups together alerts into cases, providing security analysts with better context to address issues effectively. The goal is to accentuate the importance of additional context to a security alert and avoid situations where analysts investigate the same incident without proper context, potentially wasting time or mishandling the incident.

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

The General section includes 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): Set the number of hours with which to group the alerts for the case (ranges from 0.5-24 hours in half-hour intervals). This does not apply to rules 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).

    Source Grouping Identifier alert grouping is solely based on sourceGroupIdentifier and maxAlertsInCase. It does not use a timeframe.

The Rules section lets you create specific rules targeting different grouping 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.
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, groups the second alert into 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, a phishing alert.
  2. Product: Such as Cybereason EDR.
  3. Data Source: Such as Arcsight SIEM
  4. Fallback Rule: Used when no match is found for the alert type, product, or 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 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 (for alerts coming with a pre-existing group ID attached to them from the originating system. For example, QRadar alerts have an identifier called offense, which is the group ID they belong to in QRadar.)
  • Grouping Entities (by directions): Relevant for entities only.

The Don't Group rule allows alerts to be treated independently, meaning they won't be grouped with other alerts into cases. This can be useful when a specific alert needs to investigated on its own without being linked to other cases.

For more information about excluding specific entities from alert grouping, see Create blocklist to exclude entities from alerts.

Create rules for specific use cases

Use Case #1

An enterprise company using two connectors, Arcsight and Cybereason EDR, wants to group Arcsight alerts by both source and destination entities and Cybereason EDR alerts by specific criteria:

Arcsight alerts: Group by source and destination entities.

Cybereason EDR Phishing alerts: Group by source entities only.

Group Cybereason EDR Failed Login alerts: Group by destination entities only.

In order to capture this use case – the following rules are needed. Note that the final rule is the fallback rule supplied by Google Security Operations:

Rule One:

  • Category = Data Source
  • Value = Arcsight
  • Group by = Entities
  • Grouping Entities = Source and Destination

Rule Two:

  • Category = Alert Type
  • Value = Phishing
  • Group by = Entities
  • Grouping Entities = Source (SourceHostName, SourceAddress, SourceUserName)

Rule Three:

  • Category = Alert Type
  • Value = Failed Login
  • Group by = Entities
  • Grouping Entities = Destination (DestinationAddress, DestinationUserName)

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, and wants to group alerts in the same way they appear in QRadar. They also have another customer using Arcsight, and want to group by common entities for this customer's alerts, except for phishing alerts, which should be grouped by destination entities.

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

Rule One:

  • Category = Data Source
  • Value = QRadar
  • Group by = Source Grouping Identifier
  • Grouping Entities = (leave blank)

Rule Two:

  • Category = Data Source
  • Value = Arcsight
  • Group by = Entities
  • Grouping Entities = All Entities

Rule Three:

  • Category = Alert Type
  • Value = Phishing
  • Group by = Entities
  • Grouping Entities = Destination (DestinationAddress, DestinationUserName)

Rule Four (fallback):

  • Category = All
  • Value = All Alerts
  • Grouping Entities = All Entities