Configurer un regroupement d'alertes
Le mécanisme de regroupement des alertes regroupe les alertes dans des demandes, ce qui permet aux analystes de la sécurité de mieux comprendre le contexte pour résoudre efficacement les problèmes. L'objectif est de souligner l'importance d'un contexte supplémentaire pour une alerte de sécurité et d'éviter les situations où les analystes enquêtent sur le même incident sans contexte approprié, ce qui peut entraîner une perte de temps ou une mauvaise gestion de l'incident.
Vous pouvez configurer le mécanisme de regroupement des alertes dans Paramètres SOAR> Avancé > Regroupement des alertes.
La section Général inclut les paramètres multiplate-formes :
- Nombre maximal d'alertes regroupées dans un cas : définissez le nombre maximal d'alertes à regrouper dans un cas (30). Une fois le nombre maximal atteint, une nouvelle demande est créée.
- Délai de regroupement des alertes (en heures) : définissez le nombre d'heures pendant lesquelles regrouper les alertes pour la demande (entre 0,5 et 24 heures, par intervalles de 30 minutes). Cela ne s'applique pas aux règles regroupées par identifiant de regroupement des sources.
-
Regrouper les entités et les identifiants de regroupement de sources dans le même cas : lorsque cette option est activée, une alerte qui doit être regroupée par identifiant de regroupement des sources selon la règle de regroupement recherche d'abord les alertes avec le même identifiant de regroupement des sources. Si elle n'en trouve pas, elle recherche tous les cas du système avec des entités mutuelles et regroupe les alertes en conséquence (et selon la période multiplate-forme).
Le regroupement des alertes par identifiant de regroupement de sources est uniquement basé sur
sourceGroupIdentifier
etmaxAlertsInCase
. Elle n'utilise pas de période.
Règles
La section Règles vous permet de créer des règles spécifiques ciblant différentes options de regroupement.
Exemple de regroupement
Le mécanisme de regroupement des alertes vous permet de créer des règles de regroupement qui contrôlent le type exact d'alertes regroupées dans des demandes. Pour illustrer le regroupement, prenons l'exemple d'une alerte Trafic C&C avec l'hôte de destination 10.1.1.13
, qui est ajoutée à 10h00 à une fiche intitulée Logiciel malveillant détecté.
Une autre alerte, Compte utilisateur modifié, avec le même hôte de destination, est observée à 11h. Google Security Operations identifie la même entité impliquée dans les deux alertes et, dans le délai configuré, regroupe la deuxième alerte dans le cas Logiciel malveillant détecté.
Hiérarchie des règles
Les règles fonctionnent selon un système hiérarchique dans lequel chaque alerte entrante est mise en correspondance avec une règle dans l'ordre suivant :
- Type d'alerte : par exemple, une alerte de phishing.
- Produit : par exemple, Cybereason EDR.
- Source de données : par exemple, Arcsight SIEM.
- Règle de secours : utilisée lorsqu'aucune correspondance n'est trouvée pour le type d'alerte, le produit ou la source de données.
Une fois qu'une règle est mise en correspondance, le système arrête la vérification. Si une alerte correspond à une règle et qu'il n'existe aucun cas auquel la regrouper, elle est ajoutée à un nouveau cas. Vous ne pouvez pas créer deux règles dans la même hiérarchie pour la même valeur. Par exemple, la source de données ArcSight ne peut comporter qu'une seule règle.
Règle de remplacement
La plate-forme comporte une règle prédéfinie qui ne peut pas être supprimée. Cette règle de secours fournit un catchall général pour les alertes afin de garantir qu'il y ait toujours un regroupement dans les cas. Toutefois, vous pouvez modifier les options suivantes :
- Grouper par : choisissez entre Entités ou Identifiant de regroupement de sources (pour les alertes avec un ID de groupe préexistant qui leur est associé dans le système d'origine). Par exemple, les alertes QRadar ont un identifiant appelé offense, qui correspond à l'ID de groupe auquel elles appartiennent dans QRadar.)
- Regrouper des entités (par direction) : ne concerne que les entités.
Règle "Ne pas regrouper"
La règle Ne pas regrouper vous permet de traiter les alertes de manière indépendante (elles ne seront pas regroupées avec d'autres alertes dans des demandes). Cela est utile lorsqu'une alerte spécifique doit faire l'objet d'une enquête indépendante sans être associée à d'autres cas.
Pour savoir comment exclure des entités spécifiques du regroupement d'alertes, consultez Créer une liste de blocage pour exclure des entités des alertes.
Lorsque vous utilisez Regrouper les entités dans une règle, le système n'a besoin que d'une seule entité correspondante pour regrouper les alertes.
Par exemple, une règle de regroupement spécifie les entités suivantes :
- Adresse IP source
- Adresse IP de destination
- Nom d'utilisateur
Si une alerte correspond à l'une de ces entités, elle est regroupée avec un cas existant contenant cette entité, même si les autres entités ne correspondent pas.
Prenons les deux alertes suivantes :
- Alerte 1 :
Adresse IP source :192.168.1.10
Adresse IP de destination :10.0.0.5
Nom d'utilisateur :user123
- Alerte 2 :
Adresse IP source :192.168.1.10
Adresse IP de destination :10.0.0.6
Nom d'utilisateur :user456
Comme ces deux alertes ont la même adresse IP source (192.168.1.10
), elles seront regroupées dans le même cas, même si l'adresse IP de destination et le nom d'utilisateur sont différents.
Créer des règles pour des cas d'utilisation spécifiques
Les sections suivantes décrivent les cas d'utilisation pour la création de règles de regroupement d'alertes dynamiques et contextuelles.
Cas d'utilisation : regrouper les alertes par source et entité
Une entreprise qui utilise deux connecteurs, Arcsight et Cybereason EDR, souhaite regrouper les alertes Arcsight par entités source et de destination, et les alertes Cybereason EDR selon des critères spécifiques :
Alertes Arcsight : regroupez les entités sources et de destination.
Alertes d'hameçonnage Cybereason EDR : regroupez uniquement par entités sources.
Regrouper les alertes d'échec de connexion Cybereason EDR : regroupez uniquement par entités de destination.
Pour couvrir ce cas d'utilisation, créez les règles suivantes. Google SecOps fournit la règle finale en tant que règle par défaut.
Règle 1 :
- Catégorie = Source de données
- Valeur = Arcsight
- Grouper par = Entités
- Regroupement d'entités = source et destination
Règle 2 :
- Catégorie = Type d'alerte
- Valeur = Phishing
- Grouper par = Entités
- Regroupement d'entités = Source (SourceHostName, SourceAddress, SourceUserName)
Règle 3 :
- Catégorie = Type d'alerte
- Valeur = Échec de la connexion
- Grouper par = Entités
- Grouping Entities = Destination (DestinationAddress, DestinationUserName)
Règle 4 (solution de repli) :
- Category = All
- Valeur = Toutes les alertes
- Regroupement d'entités = Toutes les entités
Cas d'utilisation : logique de regroupement adaptative
Un MSSP a un client qui utilise le connecteur QRadar et souhaite regrouper les alertes de la même manière qu'elles apparaissent dans QRadar. Il a également un autre client qui utilise Arcsight et souhaite regrouper les alertes de ce client par entités communes, à l'exception des alertes de phishing, qui doivent être regroupées par entités de destination.
Pour capturer ce cas d'utilisation, créez les règles suivantes :
Règle 1 :
- Catégorie = Source de données
- Valeur = QRadar
- Regrouper par = Identifiant de la source pour le regroupement
- Regroupement d'entités = (laisser vide)
Règle 2 :
- Catégorie = Source de données
- Valeur = Arcsight
- Grouper par = Entités
- Regroupement d'entités = Toutes les entités
Règle 3 :
- Catégorie = Type d'alerte
- Valeur = Phishing
- Grouper par = Entités
- Grouping Entities = Destination (DestinationAddress, DestinationUserName)
Règle 4 (solution de repli) :
- Category = All
- Valeur = Toutes les alertes
- Regroupement d'entités = Toutes les entités
Vous avez encore besoin d'aide ? Obtenez des réponses de membres de la communauté et de professionnels Google SecOps.