Partager via


Auditer et surveiller l’intégrité de vos règles d’analytique

Pour garantir une détection complète, ininterrompue et sans falsification des menaces dans votre service Microsoft Sentinel, surveillez la santé et l'intégrité de vos règles d'analyse. Laissez-les fonctionner de manière optimale en surveillant leurs insights d’exécution, en interrogeant les journaux d’intégrité et d’audit, et en utilisant une réexécution manuelle pour tester et optimiser vos règles.

Configurez des notifications d’événements d’intégrité et d’audit pour les parties prenantes concernées, qui peuvent ensuite prendre des mesures. Par exemple, définissez et envoyez des e-mails ou des messages Microsoft Teams, créez des tickets dans votre système de gestion de tickets, etc.

Cet article explique comment utiliser les fonctionnalités d’audit et de monitoring de l’intégrité de Microsoft Sentinel pour surveiller l’intégrité de vos règles d’analytique à partir de Microsoft Sentinel.

Pour plus d’informations sur les insights de règle et la réexécution manuelle des règles, consultez Analyser et optimiser l’exécution de vos règles d’analyse planifiées.

Résumé

  • Journaux d’intégrité des règles d’analytique dans Microsoft Sentinel :

    • Ce journal capture les événements qui enregistrent les exécutions des règles d’analytique et le résultat final de ces exécutions (réussite ou échec et raison de l’échec éventuel).
    • Le journal enregistre également, pour chaque exécution d’une règle d’analyse :
      • Nombre d’événements capturés par la requête de la règle.
      • Si le nombre d’événements a dépassé le seuil défini dans la règle, ce qui entraîne le déclenchement d’une alerte par la règle.

    Ces journaux sont collectés dans la table SentinelHealth de Log Analytics.

  • Journaux d’audit des règles d’analytique dans Microsoft Sentinel :

    • Ce journal capture les événements qui enregistrent les modifications apportées à une règle d’analyse, y compris les détails suivants :
      • Nom de la règle qui a été modifiée.
      • Quelles propriétés de la règle ont été modifiées.
      • État des paramètres de règle avant et après la modification.
      • Utilisateur ou identité qui a apporté la modification.
      • Adresse IP source et date/heure de la modification.
      • ...et bien plus.

    Ces journaux sont collectés dans la table SentinelAudit de Log Analytics.

Utiliser les tables de données SentinelHealth et SentinelAudit

Pour obtenir des données d’audit et d’intégrité à partir des tables décrites précédemment, vous devez d’abord activer la fonctionnalité d’intégrité de Microsoft Sentinel pour votre espace de travail. Pour plus d’informations, consultez Activer l’audit et le monitoring de l’intégrité dans Microsoft Sentinel.

Une fois la fonctionnalité d’intégrité activée, la table de données SentinelHealth est créée lors du premier événement de réussite ou d’échec généré pour vos règles d’automatisation et playbooks.

Présentation des événements des tables SentinelHealth et SentinelAudit

La table SentinelHealth enregistre les types d'événements relatifs à l'intégrité des règles d'analyse suivants :

  • Exécution d’une règle d’analytique planifiée.
  • Exécution d’une règle d’analytique NRT.

Pour plus d’informations, consultez Schéma des colonnes de la table SentinelHealth.

La table SentinelAudit enregistre les types d’événements d’audit de règle d’analyse suivants :

  • Création ou suppression d’une règle d’analytique.
  • Suppression d’une règle d’analytique.

Pour plus d’informations, consultez Schéma des colonnes de la table SentinelAudit.

Exécuter des requêtes pour détecter les problèmes d’intégrité

Pour obtenir de meilleurs résultats, générez vos requêtes sur les fonctions prédéfinies pour ces tables, _SentinelHealth() et _SentinelAudit() au lieu d’interroger les tables directement. Ces fonctions conservent la compatibilité descendante de vos requêtes si des modifications sont apportées au schéma des tables.

En première étape, filtrez les tables pour les données liées aux règles d’analyse. Utilise le paramètre SentinelResourceType.

_SentinelHealth()
| where SentinelResourceType == "Analytics Rule"

Si vous le souhaitez, vous pouvez filtrer davantage la liste sur un type particulier de règle d’analytique. Pour cela, utilisez le paramètre SentinelResourceKind.

| where SentinelResourceKind == "Scheduled"

# OR

| where SentinelResourceKind == "NRT"

Voici quelques exemples de requêtes pour vous aider à commencer :

  • Rechercher des règles qui sont « désactivées automatiquement » :

    _SentinelHealth()
    | where SentinelResourceType == "Analytics Rule"
    | where Reason == "The analytics rule is disabled and was not executed."
    
  • Comptez les règles et les exécutions qui ont réussi ou échoué, par raison :

    _SentinelHealth()
    | where SentinelResourceType == "Analytics Rule"
    | summarize Occurrence=count(), Unique_rule=dcount(SentinelResourceId) by Status, Reason
    
  • Recherchez les règles qui ont été supprimées :

    _SentinelAudit()
    | where SentinelResourceType =="Analytic Rule"
    | where Description =="Analytics rule deleted"
    
  • Recherchez les activités sur les règles, par nom de règle et nom d’activité :

    _SentinelAudit()
    | where SentinelResourceType =="Analytic Rule"
    | summarize Count= count() by RuleName=SentinelResourceName, Activity=Description
    
  • Recherchez les activités sur les règles, par nom de l’appelant (l’identité qui a effectué l’activité) :

    _SentinelAudit()
    | where SentinelResourceType =="Analytic Rule"
    | extend Caller= tostring(ExtendedProperties.CallerName)
    | summarize Count = count() by Caller, Activity=Description
    

Consultez plus d’informations sur les éléments suivants utilisés dans les exemples précédents dans la documentation Kusto :

Pour découvrir plus d’informations sur KQL, consultez Vue d’ensemble du langage de requête Kusto (KQL).

Autres ressources :

Règles planifiées

Lorsqu’une règle de planification échoue, elle est retentée cinq fois plus sur la même fenêtre. La règle ne passe pas outre la fenêtre et ne manque pas une alerte tant qu’au moins une des six tentatives réussit.

L’échec dans l’une des six tentatives indique un délai dans le déclenchement de l’alerte. La requête suivante calcule le délai exact :

_SentinelHealth()
| where SentinelResourceType == @"Analytics Rule" 
| where SentinelResourceKind == "Scheduled"
| extend startTime = todatetime(ExtendedProperties["QueryStartTimeUTC"]), executionStart = todatetime(ExtendedProperties["executionStart"])
| extend delay = datetime_diff('minute', startTime, executionStart)

Pour identifier des échecs complets (autrement dit, une fenêtre ignorée), utilisez la requête suivante :

_SentinelHealth()| where SentinelResourceType == @"Analytics Rule" 
| where SentinelResourceKind == "Scheduled"
| where Status != "Success"
| extend startTime = tostring(ExtendedProperties["QueryStartTimeUTC"])
| summarize failuresByStartTime = count() by startTime, SentinelResourceId
| where failuresByStartTime == 6
| summarize count() by SentinelResourceId

Cette requête recherche les exécutions de règles d'analytique planifiées où aucun des six réessais n'a réussi. Vous pouvez identifier une nouvelle tentative en examinant l’heure de début de la fenêtre de la règle, car les nouvelles tentatives examinent toujours l’heure de début d’origine. Cette requête vous donne le nombre de fenêtres ignorées pour chaque règle analytique. Nous nous attendons à ce que les fenêtres ignorées soient rares. Si vous voyez que vous avez des règles d'analyse de données avec des fenêtres ignorées, utilisez les requêtes pour comprendre la raison de l'échec de ces règles spécifiques et le tableau des raisons d'échec et des mesures d'atténuation pour les corriger.

Règles NRT

Le mécanisme de nouvelle tentative pour les règles NRT se comporte différemment des règles planifiées. Si une règle ne parvient pas à s’exécuter, le système considère également la fenêtre ayant échoué dans la prochaine exécution (une minute plus tard). Ce comportement continue jusqu'à 60 échecs (une heure).

Étant donné qu’une défaillance d’une exécution spécifique ne reflète qu’un délai d’une minute, ne examinez pas les défaillances uniques. Utilisez plutôt la requête suivante pour surveiller le délai de chaque règle analytique :

_SentinelHealth()
| where SentinelResourceKind == "NRT"
| extend startTime = todatetime(ExtendedProperties["QueryStartTimeUTC"]), endTime = todatetime(ExtendedProperties["QueryEndTimeUTC"]), alertsCreated = toint(ExtendedProperties["AlertsGeneratedAmount"])
| where alertsCreated == 0 
| extend ruleDelay = datetime_diff('minute', endTime, startTime)
| project TimeGenerated, ruleDelay, SentinelResourceId
| render timechart

Vous pouvez également définir une règle d’analyse pour déclencher des alertes sur des retards significatifs (par exemple, si une règle NRT a un délai de plus de 10 minutes).

États, erreurs et étapes suggérées

Pour l’exécution d’une règle d’analytique planifiée ou l’exécution de la règle d’analytique NRT, vous pouvez voir l’un des états et descriptions suivants :

  • Réussite : la règle a été exécutée avec succès, générant des <n> alertes.

  • Réussite : la règle s’est exécutée correctement, mais n’a pas atteint le seuil (<n>) requis pour générer une alerte.

  • Échec : ces descriptions expliquent l’échec de la règle et ce que vous pouvez faire à leur sujet.

    Description Correction
    Une erreur de serveur interne s’est produite lors de l’exécution de la requête.
    L’exécution de la requête a dépassé le délai.
    Une table référencée dans la requête n’a pas été trouvée. Vérifiez que la source de données appropriée est connectée.
    Une erreur de sémantique s’est produite pendant l'exécution de la requête. Essayez de réinitialiser la règle analytique en la modifiant et en l’enregistrant (sans modifier les paramètres).
    Une fonction appelée par la requête a été nommée avec un mot réservé. Supprimez ou renommez la fonction.
    Une erreur de syntaxe s’est produite pendant l'exécution de la requête. Essayez de réinitialiser la règle analytique en la modifiant et en l’enregistrant (sans modifier les paramètres).
    L’espace de travail n’existe pas.
    Cette requête utilise trop de ressources système et a été empêchée de s’exécuter. Passez en revue la règle d’analyse et réglez-la. Consultez notre vue d’ensemble sur le Langage de requête Kusto et la documentation sur les meilleures pratiques.
    Une fonction appelée par la requête n’a pas été trouvée. Vérifiez que toutes les fonctions appelées par la requête existent dans votre espace de travail.
    L’espace de travail utilisé dans la requête n’a pas été trouvé. Vérifiez que tous les espaces de travail référencés dans la requête existent.
    Vous ne disposez pas des autorisations nécessaires pour exécuter cette requête. Essayez de réinitialiser la règle analytique en la modifiant et en l’enregistrant (sans modifier les paramètres).
    Vous ne disposez pas des autorisations d’accès à une ou plusieurs des ressources référencées dans la requête.
    La requête a fait référence à un chemin de stockage introuvable.
    L’accès à un chemin de stockage a été refusé à la requête.
    Plusieurs fonctions de même nom sont définies dans cet espace de travail. Supprimez ou renommez la fonction redondante, puis redéfinissez la règle en la modifiant et en l’enregistrant.
    Cette requête n’a retourné aucun résultat.
    Plusieurs jeux de résultats dans cette requête ne sont pas autorisés.
    Les résultats de la requête contiennent un nombre incohérent de champs par ligne.
    L’exécution de la règle a été différée en raison de la lenteur d’ingestion des données.
    L’exécution de la règle a été différée en raison de problèmes temporaires.
    L’alerte n’a pas été enrichie en raison de problèmes temporaires.
    L’alerte n’a pas été enrichie en raison de problèmes de mappage d’entités.
    < nombre> d’entités ont été supprimées dans l’alerte <nom> en raison de la limite de taille des alertes (32 Ko).
    < nombre> d’entités ont été supprimées dans l’alerte <nom> en raison de problèmes de mappage d’entités.
    La requête a retourné <nombre> événements, ce qui dépasse la <limite> maximale de résultats autorisés pour les règles <type de règle> dans le cas d’une configuration de regroupement des événements d’alerte par ligne. Une alerte par ligne a été générée pour les <limite-1> premiers événements et une alerte agrégée supplémentaire a été générée pour prendre en compte tous les événements.
    - <nombre> = nombre d’événements retournés par la requête
    - <limite> = actuellement 150 alertes pour les règles planifiées, 30 pour les règles NRT
    - <type de règle> = planifiée ou NRT

Utiliser le classeur d’audit et de surveillance de l’intégrité

  1. Pour rendre le classeur disponible dans votre espace de travail, installez la solution de classeur à partir du hub de contenu Microsoft Sentinel :

    1. Dans le portail Microsoft Sentinel, sélectionnez Hub de contenu (préversion) dans le menu Gestion du contenu.

    2. Dans le hub de contenu, saisissez health dans la barre de recherche, puis sélectionnez Analytics Health & Audit parmi les solutions de classeur (sous Autonome dans les résultats).

      Capture d’écran de la sélection du classeur Analytics Health dans le hub de contenu.

    3. Sélectionnez Installer dans le volet d’informations, puis Enregistrer qui s’affiche à sa place.

  2. Lorsque la solution indique qu’elle est installée, sélectionnez Classeurs dans le menu Gestion des menaces.

    Capture d’écran de l’indication que la solution de classeur Analytics Health a été installée à partir du hub de contenu.

  3. Dans la galerie Classeurs, sélectionnez l’onglet Modèles, saisissez health dans la barre de recherche, puis sélectionnez Analytics Health & Audit parmi les résultats.

    Capture d’écran de la sélection du classeur Analytics Health dans la galerie de modèles.

  4. Sélectionnez Enregistrer dans le volet d’informations pour créer une copie modifiable et utilisable du classeur. Une fois la copie créée, sélectionnez Afficher le classeur enregistré.

  5. Une fois dans le classeur, sélectionnez d’abord l’abonnement et l’espace de travail que vous souhaitez afficher (ils peuvent déjà être sélectionnés), puis définissez TimeRange pour filtrer les données en fonction de vos besoins. Utilisez le bouton bascule Afficher l’aide pour afficher une explication à l’emplacement du classeur.

    Capture d’écran de l’onglet Vue d’ensemble du classeur Analytics Rule Health.

Ce classeur comporte trois sections à onglets :

Onglet Overview

L’onglet Vue d’ensemble affiche les résumés d’intégrité et d’audit :

  • Résumés d’intégrité de l’état des exécutions de règle d’analyse dans l’espace de travail sélectionné : nombre d’exécutions, réussites et échecs, et détails des événements d’échec.
  • Résumés d’audit des activités sur les règles d’analyse dans l’espace de travail sélectionné : nombre d’activités dans le temps, nombre d’activités par type et nombre d’activités de différents types par règle.

Onglet d’intégrité

L’onglet Santé vous permet d’explorer des événements de santé spécifiques.

Capture d’écran de sélection de l’onglet Health dans le classeur Analytics Health.

  • Filtrez les données de la page entière en fonction de l’état (réussite ou échec) et du type de règle (planifié ou NRT).
  • Consultez les tendances des exécutions de règles réussies et ayant échoué (en fonction du filtre d’état) sur la période sélectionnée. Vous pouvez modifier l’affichage du graphique de tendance pour voir un sous-ensemble de l’intervalle de temps d’origine. Capture d’écran des exécutions de règle d’analyse au fil du temps dans le classeur Analytics Health.
  • Filtrez le reste de la page par motif.
  • Consultez le nombre total d’exécutions pour toutes les règles d’analyse, affichées proportionnellement par état dans un graphique à secteurs.
  • Voici un tableau montrant le nombre de règles d’analyse uniques exécutées, réparties par type de règle et état.
    • Sélectionnez un état pour filtrer les graphiques restants pour cet état.
    • Effacez le filtre en sélectionnant l’icône Effacer la sélection (qui ressemble à une icône Annuler) dans le coin supérieur droit du graphique. Capture d’écran du nombre d’exécutions de règles par état et type dans le classeur Analytics Health.
  • Consultez chaque état, avec le nombre de motifs possibles de cet état. (Seules les raisons représentées dans les processus durant la période de temps sélectionnée sont affichées.)
    • Sélectionnez un état pour filtrer les graphiques restants pour cet état.
    • Effacez le filtre en sélectionnant l’icône Effacer la sélection (qui ressemble à une icône Annuler) dans le coin supérieur droit du graphique. Capture d’écran du nombre de motifs uniques par état dans le classeur Analytics Health.
  • Ensuite, consultez la liste de ces motifs, avec le nombre total d’exécutions de règle combinées et le nombre de règles uniques qui ont été exécutées.
    • Sélectionnez un motif pour filtrer les graphiques suivants pour ce motif.
    • Effacez le filtre en sélectionnant l’icône Effacer la sélection (qui ressemble à une icône Annuler) dans le coin supérieur droit du graphique. Capture d’écran des exécutions de règle par motif unique dans le classeur Analytics Health.
  • Après cela, il s’agit d’une liste des règles d’analyse uniques exécutées, avec les derniers résultats et courbes de tendance de leur réussite et de leur échec (selon l’état sélectionné pour filtrer la liste).
    • Sélectionnez une règle pour explorer au niveau du détail et afficher une nouvelle table avec toutes les exécutions de cette règle (dans la période sélectionnée).
    • Effacez la table en sélectionnant l’icône Effacer la sélection (qui ressemble à une icône Annuler) dans le coin supérieur droit du graphique. Capture d’écran d’une liste d’exécutions d’une règle unique, avec l’état et les courbes de tendance dans un classeur Analytics Health.
  • Si vous sélectionnez une règle dans la liste, une nouvelle table présente les détails de l'état de santé pour la règle sélectionnée. Capture d’écran d’une liste d’exécutions d’une règle d’analyse sélectionnée dans le classeur Analytics Health.

Onglet Audit

L’onglet Audit vous permet d’accéder à des événements d’audit particuliers.

Capture d’écran de la sélection de l’onglet Audit dans le classeur Analytics Health.

  • Filtrez les données de page entières par type de règle d’audit (planifié/Fusion).
  • Consultez les tendances de l’activité auditée sur les règles d’analyse pour la période sélectionnée. Vous pouvez modifier l’affichage du graphique de tendance pour voir un sous-ensemble de l’intervalle de temps d’origine. Capture d’écran de l’activité d’audit en tendance dans le classeur Analytics Health.
  • Consultez le nombre d’événements audités, répartis par activité et par type de règle.
    • Sélectionnez une activité pour filtrer les graphiques suivants pour cette activité.
    • Effacez le filtre en sélectionnant l’icône Effacer la sélection (qui ressemble à une icône Annuler) dans le coin supérieur droit du graphique. Capture d’écran du nombre d’événements d’audit par activité et type dans le classeur Analytics Health.
  • Consultez le nombre d’événements audités par nom de règle.
    • Sélectionnez un nom de règle pour filtrer le tableau suivant pour cette règle, puis pour explorer et afficher une nouvelle table avec toute l’activité de cette règle (dans le délai sélectionné). (Voir après la capture d’écran suivante.)
    • Effacez le filtre en sélectionnant l’icône Effacer la sélection (qui ressemble à une icône Annuler) dans le coin supérieur droit du graphique. Capture d’écran des événements audités par nom de règle et appelant dans le classeur Analytics Health.
  • Consultez le nombre d’événements audités par appelant (l’identité qui a effectué l’activité).
  • Si vous avez sélectionné un nom de règle dans le graphique précédent, un autre tableau apparaît montrant les activités auditées sur cette règle. Sélectionnez la valeur qui apparaît sous forme de lien dans la colonne ExtendedProperties pour ouvrir un panneau latéral affichant les modifications apportées à la règle. Capture d’écran de l’activité d’audit de la règle sélectionnée dans le classeur Analytics Health.

Étapes suivantes