Corrélation des alertes et fusion des incidents dans le portail Microsoft Defender

Cet article explique comment le portail Microsoft Defender agrège et met en corrélation les alertes qu’il collecte à partir de toutes les sources qui les produisent et les envoient au portail. Il explique comment Defender crée des incidents à partir de ces alertes et comment il continue à surveiller leur évolution, en fusionnant les incidents si la situation le justifie. Pour en savoir plus sur les alertes et leurs sources, et sur la façon dont les incidents ajoutent de la valeur dans le portail Microsoft Defender, consultez Incidents et alertes dans le portail Microsoft Defender.

Création d’incidents et corrélation des alertes

Lorsque les alertes sont générées par les différents mécanismes de détection dans le portail Microsoft Defender, comme décrit dans Incidents et alertes dans le portail Microsoft Defender, elles sont placées dans des incidents nouveaux ou existants selon la logique suivante :

• Si l’alerte est suffisamment unique dans toutes les sources d’alerte dans un laps de temps particulier, Defender crée un incident et y ajoute l’alerte.
• Si l’alerte est suffisamment liée à d’autres alertes (provenant de la même source ou d’une source à l’autre) dans un laps de temps particulier, Defender ajoute l’alerte à un incident existant.

Les critères utilisés par le portail Defender pour mettre en corrélation les alertes dans un seul incident font partie de sa logique de corrélation interne propriétaire. Cette logique est également responsable de l’attribution d’un nom approprié au nouvel incident.

Corrélation et fusion des incidents

Les activités de corrélation du portail Defender ne s’arrêtent pas lorsque des incidents sont créés. Defender continue de détecter les points communs et les relations entre les incidents et entre les alertes entre les incidents. Lorsque plusieurs incidents sont jugés suffisamment similaires, Defender fusionne les incidents en un seul incident.

Critères de fusion des incidents

Le moteur de corrélation de Defender fusionne les incidents lorsqu’il reconnaît les éléments communs entre les alertes dans des incidents distincts, en fonction de sa connaissance approfondie des données et du comportement d’attaque. Voici quelques-uns de ces éléments :

• Entités : ressources telles que les utilisateurs, les appareils, les boîtes aux lettres et autres
• Artefacts : fichiers, processus, expéditeurs d’e-mails et autres
• Intervalles de temps
• Séquences d’événements qui pointent vers des attaques multiphases, par exemple, un événement de clic d’e-mail malveillant qui suit de près la détection d’un e-mail d’hameçonnage.

Résultats du processus de fusion

Lorsque plusieurs incidents sont fusionnés, aucun incident n’est créé pour les absorber. Au lieu de cela, le contenu d’un incident est migré vers l’autre incident, et l’incident abandonné dans le processus est automatiquement fermé. L’incident abandonné n’est plus visible ou disponible dans le portail Defender, et toute référence à celui-ci est redirigée vers l’incident consolidé. L’incident abandonné et fermé reste accessible dans Microsoft Sentinel Portail Azure. Le contenu des incidents est géré de la manière suivante :

• Les alertes contenues dans l’incident abandonné y sont supprimées et ajoutées à l’incident consolidé.
• Toutes les balises appliquées à l’incident abandonné y sont supprimées et ajoutées à l’incident consolidé.
• Une Redirected balise est ajoutée à l’incident abandonné.
• Les entités (ressources, etc.) suivent les alertes auxquelles elles sont liées.
• Les règles d’analyse enregistrées comme impliquées dans la création de l’incident abandonné sont ajoutées aux règles enregistrées dans l’incident consolidé.
• Actuellement, les commentaires et les entrées du journal d’activité dans l’incident abandonné ne sont pas déplacés vers l’incident consolidé.

Pour afficher les commentaires et l’historique des activités de l’incident abandonné, ouvrez l’incident dans Microsoft Sentinel dans le Portail Azure. L’historique des activités inclut la fermeture de l’incident, ainsi que l’ajout et la suppression d’alertes, d’étiquettes et d’autres éléments liés à la fusion d’incidents. Ces activités sont attribuées à l’identité Microsoft Defender XDR - corrélation d’alerte.

Lorsque les incidents ne sont pas fusionnés

Même lorsque la logique de corrélation indique que deux incidents doivent être fusionnés, Defender ne fusionne pas les incidents dans les circonstances suivantes :

• L’un des incidents a un status « Fermé ». Les incidents résolus ne sont pas rouverts.
• Les deux incidents éligibles à la fusion sont attribués à deux personnes différentes.
• La fusion des deux incidents augmenterait le nombre d’entités dans l’incident fusionné au-dessus du maximum autorisé de 50 entités par incident.
• Les deux incidents contiennent des appareils appartenant à différents groupes d’appareils, tels que définis par le organization.
  (Cette condition n’est pas appliquée par défaut ; elle doit être activée.)

Corrélation manuelle

Bien que Microsoft Defender utilise déjà des mécanismes de corrélation avancés, vous pouvez décider différemment si une alerte donnée appartient à un incident particulier ou non. Dans ce cas, vous pouvez dissocier une alerte d’un incident et la lier à un autre. Chaque alerte doit appartenir à un incident, de sorte que vous pouvez lier l’alerte à un autre incident existant ou à un nouvel incident que vous créez sur place.

Étapes suivantes

Pour en savoir plus sur la hiérarchisation et la gestion des incidents, consultez les articles suivants :

• Gérer les incidents dans Microsoft Defender

Voir aussi

• La puissance des incidents dans Microsoft Defender XDR
• À l’intérieur Microsoft Defender XDR : Corrélation et consolidation des attaques en incidents