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

Cet article explique comment gérer certains problèmes qui peuvent survenir avec l’exécution des règles analytiques planifiées dans Microsoft Sentinel.

Problème : Aucun événement ne s’affiche dans les résultats de la requête

Quand le regroupement d’événements est défini pour déclencher une alerte pour chaque événement, les résultats de la requête consultés par la suite peuvent être apparemment manquants ou différents. Par exemple, vous affichez les résultats d’une requête ultérieurement lors de l’examen d’un incident associé et, dans le cadre de cette enquête, 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 grands, ils ne sont pas enregistrés et aucune donnée n’apparaît quand vous consultez une nouvelle fois les résultats de la requête.

Quand il y a un retard d’ingestion ou si la requête n’est pas déterministe en raison d’une 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 entre le champ Query existant et le nouveau champ :

Nom du champ	Contient	L’exécution de la requête dans ce champ a pour résultat…
Requête	L’enregistrement compressé de l’événement qui a généré cette instance de l’alerte.	L’événement qui a généré cette instance de l’alerte, limité à 10 kilo-octets.
OriginalQuery	La requête d’origine telle qu’elle est écrite dans la règle analytique.	L’événement le plus récent dans la période d’exécution de la requête, qui correspond aux paramètres définis par la requête.

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

Problème : Une règle planifiée n'a pas été exécutée, ou le préfixe AUTO DISABLED (Désactivée automatiquement) a été ajouté à son nom

Bien que cela soit rare, une règle de requête planifiée peut échouer. Microsoft Sentinel classe les échecs comme passagers ou permanents, en fonction de leur type et des circonstances qui y ont conduit.

Échec passager

Une défaillance transitoire se produit en raison d’une circonstance temporaire et revient rapidement à la normale, auquel point l’exécution de la règle réussit. Voici quelques exemples d’échecs classés comme passagers par Microsoft Sentinel :

• La requête d'une règle met 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.
• Tous les autres échecs nouveaux et inconnus sont considérés comme passagers.

En cas d’échec passager, Microsoft Sentinel essaie à nouveau d’exécuter la règle à intervalles prédéterminés et toujours croissants, jusqu’à un certain point. Passé ce stade, la règle ne se réexécute qu'à la prochaine heure planifiée. Une règle n’est jamais désactivée automatiquement en raison d’une défaillance transitoire.

Défaillance permanente : désactivation automatique de la règle

Une défaillance permanente se produit suite à une modification des conditions qui permettent à la règle de s’exécuter. Sans intervention humaine, celle-ci ne peut pas revenir à son ancien état. Voici quelques exemples d'échecs classés comme permanents :

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

Dans le cas d’un 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 ce qui suit :

1. Il désactive la règle.
2. Il ajoute le préfixe « AUTO DISABLED » (Désactivée automatiquement) au nom de la règle.
3. Il ajoute la raison de l'échec (et de la désactivation) à la description de la règle.

La présence de règles désactivées automatiquement peut facilement être déterminée en triant la liste des règles par nom. Les règles désactivées automatiquement se trouvent dans le haut de la liste.

Les gestionnaires SOC doivent régulièrement rechercher la présence de règles désactivées automatiquement dans la liste des règles.

Échec permanent en raison d’un drainage des ressources

Un autre type d’échec permanent se produit en raison d’une requête générée de manière incorrecte qui entraîne une consommation excessive des ressources de calcul et risque d’épuiser les performances de vos systèmes. Lorsque Microsoft Sentinel identifie une telle règle, il effectue les trois étapes mentionnées pour les autres types de défaillances permanentes : désactive la règle, ajoute « AUTO DISABLED » au nom de la règle et ajoute la raison de la défaillance à la description.

Pour réactiver la règle, vous devez résoudre les problèmes dans la requête qui entraînent l’utilisation d’un trop grand nombre de ressources. Consultez les articles suivants afin de connaître les meilleures pratiques pour optimiser vos requêtes Kusto :

• Meilleures pratiques relatives aux requêtes : Azure Data Explorer
• Optimiser les requêtes de journal dans Azure Monitor

Consultez également Ressources utiles pour utiliser le Langage de requête Kusto dans Microsoft Sentinel pour obtenir une aide supplémentaire.

Échec permanent en raison d’une perte d’accès entre les abonnements/tenants (clients/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), dans le cas d’un fournisseur de solution de sécurité Microsoft (MSSP), ou tout autre scénario où les règles analytiques interrogent des abonnements ou des locataires.

Lorsque vous créez une règle d’analyse, 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.

Toutefois, il existe une exception : lorsqu’une règle est créée pour accéder à des espaces de travail dans d’autres abonnements ou tenants (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. Ces types de règles se voient appliquer les informations d’identification de l’utilisateur qui a créé la règle, 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 entre 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 cessent de fonctionner. Vous recevez un message de surveillance de l’intégrité concernant l’« accès insuffisant à la ressource » et la règle est désactivée automatiquement conformément à la procédure décrite précédemment.

Étapes suivantes

Pour plus d'informations, consultez les pages suivantes :

• Tutoriel : Examiner les incidents avec Microsoft Sentinel
• Naviguer et examiner des incidents dans Microsoft Sentinel – Préversion
• Classer et analyser les données à l’aide d’entités dans Microsoft Sentinel
• Didacticiel : utiliser des règles d’automatisation dans Microsoft Sentinel

De même, apprenez à partir de l’exemple comment utiliser les règles d’analytique lors de la supervision Zoom avec un connecteur personnalisé.