Résolution des problèmes liés aux règles d’analyse dans Microsoft Sentinel

Cet article explique comment traiter certains problèmes qui peuvent survenir lors de l’exécution de règles d’analyse planifiées dans Microsoft Sentinel.

Problème : Aucun événement n’apparaît dans les résultats de la requête

Lorsque le regroupement d’événements est défini pour déclencher une alerte pour chaque événement, les résultats de requête affichés ultérieurement peuvent sembler manquants ou différents de ceux attendus. Par exemple, vous pouvez afficher les résultats d’une requête ultérieurement lors de l’examen d’un incident connexe, et dans le cadre de cette investigation, vous décidez de revenir aux résultats précédents de cette requête.

Les résultats sont automatiquement enregistrés avec les alertes. Toutefois, si les résultats sont trop volumineux, aucun résultat n’est enregistré et aucune donnée n’apparaît lors de l’affichage des résultats de la requête.

Dans les cas où il y a un retard d’ingestion ou si la requête n’est pas déterministe en raison de l’agrégation, le résultat de l’alerte peut être différent du résultat affiché en exécutant la requête manuellement.

Pour résoudre ce problème, lorsqu’une règle a ce paramètre de regroupement d’événements, Microsoft Sentinel ajoute le champ OriginalQuery aux résultats de la requête. Voici une comparaison du champ Requête existant et du nouveau champ :

En d’autres termes, le champ OriginalQuery se comporte comme le champ Requête se comporte sous le paramètre de regroupement d’événements par défaut.

Problème : une règle planifiée n’a pas pu s’exécuter ou apparaît avec AUTO DISABLED ajouté au nom

Il est rare qu’une règle de requête planifiée ne s’exécute pas, mais cela peut se produire. Microsoft Sentinel classe les défaillances à l’avance comme temporaires ou permanentes, en fonction du type spécifique de l’échec et des circonstances qui y ont conduit.

Échec temporaire

Une défaillance temporaire se produit en raison d’une circonstance qui est temporaire et qui revient rapidement à la normale, à quel moment l’exécution de la règle réussit. Voici quelques exemples de défaillances que Microsoft Sentinel classifie comme temporaires :

• Une requête de règle prend trop de temps à s’exécuter et expire.
• Problèmes de connectivité entre les sources de données et Log Analytics, ou entre Log Analytics et Microsoft Sentinel.
• Toute autre défaillance nouvelle et inconnue est considérée comme temporaire.

En cas d’échec temporaire, Microsoft Sentinel tente de réexécuter la règle après des intervalles prédéterminés et toujours croissants, jusqu’à un point. Après cela, la règle ne s’exécute à nouveau qu’à l’heure planifiée suivante. Une règle n’est jamais automatiquement dissurable en raison d’un échec temporaire.

Échec permanent : règle automatiquement dissible

Une défaillance permanente se produit en raison d’un changement dans les conditions qui permettent à la règle de s’exécuter, qui sans intervention humaine ne peut pas revenir à leur ancien status. Voici quelques exemples de défaillances classées comme permanentes :

• L’espace de travail cible (sur lequel la requête de règle a fonctionné) a été supprimé.
• La table cible (sur laquelle la requête de règle a fonctionné) a été supprimée.
• Microsoft Sentinel a été supprimé de l’espace de travail cible.
• Une fonction utilisée par la requête de règle n’est plus valide ; il a été modifié ou supprimé.
• Les autorisations d’accès à l’une des sources de données de la requête de règle ont été modifiées (voir l’exemple).
• L’une des sources de données de la requête de règle a été supprimée.

En cas de nombre prédéterminé d’échecs permanents consécutifs, du même type et sur la même règle, Microsoft Sentinel cesse d’essayer d’exécuter la règle et effectue également les étapes suivantes :

1. Désactive la règle.
2. Ajoute les mots « AUTO DISABLED » au début du nom de la règle.
3. Ajoute la raison de l’échec (et la désactivation) à la description de la règle.

Vous pouvez facilement déterminer la présence de règles autodissibles en triant la liste de règles par nom. Les règles autodisables se trouvent en haut de la liste ou à proximité.

Les responsables SOC doivent veiller à case activée régulièrement la liste des règles pour la présence de règles autodisables.

Défaillance permanente en raison d’un drainage des ressources

Un autre type d’échec permanent se produit en raison d’une requête mal construite qui fait que la règle consomme des ressources informatiques excessives et risque d’épuiser les performances de vos systèmes. Lorsque Microsoft Sentinel identifie une telle règle, elle effectue les trois étapes mentionnées pour les autres types d’échecs permanents : désactive la règle, ajoute « AUTO DISABLED » au nom de la règle et ajoute la raison de l’échec à la description.

Pour réactiver la règle, vous devez résoudre les problèmes de la requête qui entraînent l’utilisation d’un trop grand nombre de ressources. Pour plus d’informations, reportez-vous aux rubriques suivantes :

• Meilleures pratiques relatives aux requêtes - Documentation Kusto
• Optimiser les requêtes de journal dans Azure Monitor
• ressources d’apprentissage Langage de requête Kusto

Échec permanent en raison d’une perte d’accès entre les abonnements/locataires

Un exemple particulier de défaillance permanente peut se produire en raison d’une modification des autorisations sur une source de données (voir la liste) concerne le cas d’un fournisseur de solutions de sécurité Microsoft (MSSP) ou tout autre scénario où les règles d’analyse interrogent des abonnements ou des locataires.

Lorsque vous créez une règle d’analytique, un jeton d’autorisations d’accès est appliqué à la règle et enregistré avec elle. Ce jeton garantit que la règle peut accéder à l’espace de travail qui contient les tables référencées par la requête de la règle, et que cet accès est conservé même si le créateur de la règle perd l’accès à cet espace de travail.

Il existe toutefois une exception : lorsqu’une règle est créée pour accéder aux espaces de travail dans d’autres abonnements ou locataires, comme ce qui se passe dans le cas d’un MSSP, Microsoft Sentinel prend des mesures de sécurité supplémentaires pour empêcher l’accès non autorisé aux données client. Les informations d’identification de l’utilisateur qui a créé la règle sont appliquées à ces types de règles, au lieu d’un jeton d’accès indépendant. Lorsque l’utilisateur n’a plus accès à l’autre locataire, la règle cesse de fonctionner.

Si vous utilisez Microsoft Sentinel dans un scénario inter-abonnements ou inter-locataires, et si l’un de vos analystes ou ingénieurs perd l’accès à un espace de travail particulier, toutes les règles créées par cet utilisateur cesseront de fonctionner. Vous recevrez un message de surveillance de l’intégrité concernant l'« accès insuffisant à la ressource », et la règle sera automatiquement dissible selon la procédure décrite précédemment.

Prochaines étapes

Pour plus d’informations, reportez-vous aux rubriques suivantes :

• Tutoriel : Examiner les incidents avec Microsoft Sentinel
• Naviguer et examiner les incidents dans Microsoft Sentinel - Préversion
• Classifier et analyser des données à l’aide d’entités dans Microsoft Sentinel
• Tutoriel : Utiliser des playbooks avec des règles d’automatisation dans Microsoft Sentinel

Apprenez également à partir d’un exemple d’utilisation de règles d’analyse personnalisées lors de la surveillance de Zoom avec un connecteur personnalisé.