Règles analytiques planifiées de Microsoft Sentinel

• S’applique à:

  Microsoft Sentinel in the Azure portal, Microsoft Sentinel in the Microsoft Defender portal

De loin le type de règle analytique le plus courant, les règles planifiées sont basées sur des requêtes Kusto configurées pour s’exécuter à intervalles réguliers et examiner les données brutes d’une période de « recherche arrière » définie. Les requêtes peuvent effectuer des opérations statistiques complexes sur les données cibles, révélant des bases de référence et des valeurs hors norme dans des groupes d’événements. Si le nombre de résultats capturés par la requête dépasse le seuil configuré dans la règle, la règle produit une alerte.

Cet article vous aide à comprendre comment sont générées les règles analytiques planifiées. Il vous présente toutes les options de configuration et leurs significations. Les informations contenues dans cet article sont utiles dans deux scénarios :

• Créer une règle analytique à partir d’un modèle : utilisez la logique de requête et les paramètres de planification et de recherche comme définis dans le modèle, ou personnalisez-les pour créer des règles.

• Créer une règle analytique à partir de zéro : créez vos propres requêtes et règles de bout en bout. Pour ce faire efficacement, vous devez disposer de bases approfondies sur la science des données et le langage de requête Kusto.

Important

Microsoft Sentinel est maintenant en disponibilité générale dans la plateforme d’opérations de sécurité unifiée Microsoft dans le portail Microsoft Defender. Pour en savoir plus, consultez Microsoft Sentinel dans le portail Microsoft Defender.

Modèles de règles d’analyse

Les requêtes dans les modèles de règle planifiée ont été écrites par des experts en science des données et en sécurité, chez Microsoft ou chez le fournisseur de la solution fournissant le modèle.

Pour utiliser un modèle de règle analytique, sélectionnez un nom de modèle dans la liste des modèles et créez une règle à partir de celui-ci.

Chaque modèle possède une liste de sources de données requises. Lorsque vous ouvrez le modèle, la disponibilité des sources de données est automatiquement vérifiée. En cas de disponibilité, la source de données est connectée et que les données sont régulièrement ingérées. Si l’une des sources de données requises n’est pas disponible, vous n’êtes pas autorisé à créer la règle. Un message d’erreur correspondant peut également s’afficher.

Lorsque vous créez une règle à partir d’un modèle, l’Assistant Création de règle s’ouvre en fonction du modèle sélectionné. Toutes les informations sont automatiquement renseignées et vous pouvez personnaliser la logique et les autres paramètres de règle pour mieux répondre à vos besoins spécifiques. Vous pouvez répéter ce processus pour créer d’autres règles basées sur le modèle. Lorsque vous atteignez la fin de l’Assistant Création de règles, vos personnalisations sont validées et la règle est créée. Les nouvelles règles s’affichent sous l’onglet Règles actives de la page Analytique. De même, dans l’onglet Modèles de règle, le modèle à partir duquel vous avez créé la règle apparaît maintenant avec la balise In use.

Les modèles de règles analytiques sont gérés en continu par leurs auteurs, pour corriger les bugs ou affiner la requête. Lorsqu’un modèle reçoit une mise à jour, toutes les règles basées sur ce modèle apparaissent avec la balise Update. Vous pouvez alors modifier ces règles pour y intégrer les modifications apportées au modèle. Vous pouvez également annuler les modifications apportées à une règle en rétablissant la version basée sur le modèle d’origine. Pour en savoir plus, consultez Gérer des versions de modèles pour vos règles analytiques planifiées dans Microsoft Sentinel.

Une fois que vous connaissez les options de configuration de cet article, consultez Créer des règles analytiques planifiées à partir de modèles.

Le reste de cet article décrit toutes les possibilités vous permettant de personnaliser la configuration de vos règles.

Configuration des règles analytiques

Cette section décrit les principales considérations à prendre en compte avant de commencer à configurer vos règles.

Nom et informations de la règle analytique

La première page de l’Assistant Règle analytique contient les informations de base de la règle.

Nom : nom de la règle tel qu’il apparaît dans la liste des règles et dans tous les filtres basés sur les règles. Ce nom doit être propre à l’espace de travail.

Description : description en texte libre de l’objectif de la règle.

ID : GUID de la règle en tant que ressource Azure, notamment utilisé dans les requêtes et les réponses des API. Ce GUID est attribué uniquement lorsque la règle est créée. Il s’affiche uniquement lorsque vous modifiez une règle existante. Ce champ est en lecture seule : il apparaît grisé et ne peut pas être modifié. Il n’existe pas encore lorsque vous créez une règle (avec un modèle ou à partir de zéro).

Gravité : classement en lien avec l’émission des alertes générées par cette règle. La gravité d’une activité revient à calculer l’impact négatif potentiel de l’occurrence de l’activité.

Gravité	Description
Informational	Aucun impact sur votre système, mais les informations peuvent indiquer les prochaines étapes planifiées par un acteur de menace.
Faible	L’impact immédiat serait minimal. Un acteur de menace doit probablement effectuer plusieurs étapes avant d’atteindre un impact sur un environnement.
Moyenne	L’acteur de menace pourrait avoir un impact sur l’environnement avec cette activité, mais il serait limité dans l’étendue ou nécessiterait une activité supplémentaire.
Activité	L’activité identifiée fournit à l’acteur de menace un accès étendu pour effectuer des actions sur l’environnement ou est déclenchée par un impact sur l’environnement.

Les valeurs par défaut au niveau de gravité ne sont pas une garantie de niveau d’impact actuel ou environnemental. Personnaliser les détails de l’alerte pour personnaliser la gravité, les tactiques et d’autres propriétés d’une instance donnée d’une alerte avec les valeurs des champs pertinents d’une sortie de requête.

Les définitions de gravité des modèles de règles d’analytique Microsoft Sentinel sont pertinentes uniquement pour les alertes créées par des règles d’analyse. Pour les alertes ingérées à partir d’autres services, la gravité est définie par le service de sécurité source.

MITRE ATT&CK : spécification des tactiques et techniques d’attaque représentées par les activités capturées par la règle. Ces dernières sont basées sur les tactiques et les techniques de l’infrastructure MITRE ATT&CK®.

Les tactiques et techniques MITRE ATT&CK définies ici dans la règle s’appliquent aux alertes qu’elle génère. Elles s’appliquent également aux incidents créés à partir de ces alertes.

Pour en savoir plus sur la façon d’optimiser votre couverture du paysage des menaces MITRE ATT&CK, consultez Comprendre la couverture de sécurité de l’infrastructure MITRE ATT&CK®.

État : Lorsque vous créez la règle, son État est activé par défaut, ce qui signifie qu’il s’exécute immédiatement après sa création. Si vous ne souhaitez pas qu’elle s’exécute immédiatement, deux options s’offrent à vous :

• Sélectionnez Désactivé, et la règle est créée sans être exécutée. Lorsque vous souhaitez que la règle soit exécutée, recherchez-la dans l’onglet Règles actives, puis activez-la à partir de là.
• Planifiez la première exécution de la règle à une date et une heure spécifiques. Cette méthode est actuellement en PRÉVERSION. Consultez Planification des requêtes plus loin dans cet article.

Requête de règle

Il s’agit de l’essence de la règle : vous décidez quelles informations contiennent les alertes créées par la règle et comment celles-ci sont organisées. Cette configuration s’accompagne d’effets de suivi concernant l’apparence des incidents connexes, ainsi que la simplicité ou la difficulté que représentent leur examen, leur correction et leur résolution. Il est important d’enrichir au maximum vos alertes avec des informations et de rendre ces informations facilement accessibles.

Affichez ou entrez la requête Kusto qui analyse les données de journal brutes. Si vous créez une règle à partir de zéro, mieux vaut planifier et concevoir votre requête avant d’ouvrir l’assistant. Vous pouvez générer et tester vos requêtes dans la page Journaux.

Tout ce que vous tapez dans la fenêtre de requête de règle est instantanément validé. Vous savez donc instantanément si vous avez fait des erreurs.

Meilleures pratiques pour les requêtes de règles analytiques

• Nous recommandons d’utiliser un analyseur Advanced Security Information Model (ASIM) comme source de requête plutôt qu’une table native. Cela garantit la compatibilité de la requête avec toutes les sources de données concernées (actuelles et futures) plutôt qu’avec une seule source de données.

• La requête doit comporter 1 à 10 000 caractères, et ne doit pas contenir « search * » ou « union * ». Vous pouvez utiliser des fonctions définies par l’utilisateur pour contourner la limitation de longueur de la requête, car une seule fonction peut remplacer des dizaines de lignes de code.

• L’utilisation de fonctions ADX pour créer des requêtes Azure Data Explorer à l’intérieur de la fenêtre de requête Log Analytics n’est pas prise en charge.

• Quand vous utilisez la fonction bag_unpack dans une requête, si vous projetez les colonnes sous forme de champs en utilisant « project field1 » et que la colonne n'existe pas, la requête échoue. Pour éviter ce problème, vous devez projeter la colonne de la façon suivante :

  project field1 = column_ifexists("field1","")

Pour plus d’informations sur la création de requêtes Kusto, consultez Langage de requête Kusto dans Microsoft Sentinel et Meilleures pratiques pour les requêtes en langage de requête Kusto.

Amélioration des alertes

Pour que vos alertes génèrent des résultats manifestes permettant de les détecter immédiatement en cas d’incident, de les suivre et de les examiner comme il se doit, utilisez la configuration d’amélioration des alertes pour que toutes les informations importantes soient visibles dans les alertes.

L’amélioration des alertes offre l’avantage supplémentaire de présenter les résultats d’une manière facilement visible et accessible.

Vous pouvez configurer trois types d’amélioration des alertes :

• Mappage d’entités
• Détails personnalisés
• Détails des alertes (également appelés « contenu dynamique »)

Mappage d’entités

Les entités correspondent aux acteurs de chaque côté d’une attaque. Il est essentiel d’identifier toutes les entités d’une alerte pour détecter et examiner les menaces. Pour vous assurer que Microsoft Sentinel identifie les entités dans vos données brutes, vous devez mapper les types d’entités reconnus par Microsoft Sentinel sur des champs de vos résultats de requête. Ce mappage intègre les entités découvertes dans le champ Entités du schéma d’alerte.

Pour en savoir plus sur le mappage d’entités et bénéficier d’instructions complètes, consultez Mapper des champs de données vers des entités dans Microsoft Sentinel.

Détails personnalisés

Par défaut, seules les entités et les métadonnées d’alerte apparaissent dans les incidents (sans explorer les événements bruts des résultats de la requête). Pour que d’autres champs des résultats de requête bénéficient d’une visibilité instantanée sur vos alertes et incidents, définissez-les en tant que détails personnalisés. Microsoft Sentinel intègre ces détails personnalisés au champ ExtendedProperties de vos alertes. De ce fait, ils apparaissent en tête de vos alertes et dans chaque incident créé à partir de celles-ci.

Pour en savoir plus sur la présentation des détails personnalisés et bénéficier d’instructions complètes, consultez Présenter des détails personnalisés dans les alertes Microsoft Sentinel.

Détails de l’alerte

Ce paramètre vous permet de personnaliser les propriétés d’alerte standard en fonction du contenu des différents champs de chaque alerte. Ces personnalisations sont intégrées au champ ExtendedProperties de vos alertes. Par exemple, vous pouvez personnaliser le nom ou la description de l’alerte pour y inclure un nom d’utilisateur ou une adresse IP.

Pour en savoir plus sur la personnalisation des détails des alertes et bénéficier d’instructions complètes, consultez Personnaliser les détails des alertes dans Microsoft Sentinel.

Remarque

Dans la plateforme d’opérations de sécurité unifiée, le moteur de corrélation Defender XDR est uniquement responsable des incidents de nommage. Par conséquent, tous les noms d’alertes que vous avez personnalisés peuvent être remplacés lorsque des incidents sont créés à partir de ces alertes.

Planification de la requête

Les paramètres suivants déterminent la fréquence d’exécution de votre règle planifiée, ainsi que la durée d’examen à chaque exécution.

Setting	Comportement
Exécuter la requête toutes les	Contrôle l’intervalle de requête, la fréquence à laquelle la requête s’exécute.
Rechercher les données des derniers	Détermine la période de recherche arrière à savoir la période couverte par la requête.

• La plage autorisée pour ces deux paramètres est comprise entre 5 minutes et 14 jours.

• L’intervalle de requête doit être plus court ou égal à la période de recherche arrière. S’il est plus court, les périodes de requête se chevauchent, ce qui peut entraîner une duplication des résultats. La validation de la règle ne permet pas de définir un intervalle au-delà de la période de recherche arrière, car cela entraîne des failles de couverture.

Le paramètre Démarrer l’exécution (désormais en PRÉVERSION) permet de créer une règle avec l’état Activé, et de reporter sa première exécution à une date et une heure prédéfinies. Ce paramètre est utile si vous souhaitez planifier l’exécution de vos règles au moment où les données doivent être ingérées à partir de la source ou lorsque vos analystes SOC démarrent leur journée de travail.

Setting	Comportement
Automatiquement	La règle s’exécute pour la première fois immédiatement après avoir été créée, puis à l’intervalle défini dans le paramètre Exécuter chaque requête.
À un moment précis (préversion)	Définissez une date et une heure pour la première exécution de la règle. Après quoi, elle s’exécutera à l’intervalle défini dans le paramètre Exécuter la requête toutes les.

• Le délai Démarrer l’exécution doit être compris entre 10 minutes et 30 jours après la création (ou l’activation) de la règle.

• La ligne de texte sous le paramètre Démarrer l’exécution (avec l’icône d’informations à gauche) résume les paramètres de planification et de recherche de requête actuels.

  

Remarque

Délai d'ingestion

Pour tenir compte de la latence qui peut se produire entre la génération d’un événement à la source et son ingestion dans Microsoft Sentinel et pour assurer une couverture complète sans duplication de données, Microsoft Sentinel exécute les règles d’analyse planifiées avec un retard de cinq minutes par rapport à l’heure planifiée.

Pour plus d’informations, consultez Gérer le délai d’ingestion dans les règles d’analyse planifiée.

Seuil d’alerte

En nombre réduit, la plupart des types d’événements de sécurité sont ordinaires, voire attendus. En grand nombre, ils sont le signe d’une menace. En grand nombre et à différentes échelles, ils peuvent indiquer plusieurs types de menaces. Par exemple, l’échec de deux ou trois tentatives de connexion en l’espace d’une minute révèle qu’un utilisateur ne se souvient pas de son mot de passe. En revanche, l’échec de cinquante tentatives en une minute peut indiquer une attaque d’origine humaine, et l’échec d’un millier de tentatives est probablement le signe d’une attaque automatisée.

Selon le type d’activité que votre règle tente de détecter, vous pouvez définir un nombre minimal d’événements (résultats de requête) nécessaires pour déclencher une alerte. Ce seuil s’applique séparément (et non collectivement) à chaque exécution de la règle.

Vous pouvez également définir ce seuil sur un nombre maximal de résultats ou sur un nombre précis.

Regroupement d'événements

Vous pouvez gérer le regroupement d’événements dans alertes de deux façons :

• Regrouper tous les événements dans une seule alerte : il s’agit du paramètre par défaut. La règle génère une alerte à chaque exécution, tant que la requête retourne plus de résultats que le seuil d’alerte décrit dans la section précédente. Cette alerte unique répertorie tous les événements retournés dans les résultats de la requête.

• Déclencher une alerte pour chaque événement : la règle génère une alerte pour chaque événement (résultat) renvoyé par la requête. Ce mode est utile si vous souhaitez que les événements s’affichent individuellement ou si vous souhaitez les regrouper selon certains paramètres (par utilisateur, nom d’hôte ou autre critère). Vous pouvez définir ces paramètres dans la requête. |

Les règles d’analytique peuvent générer jusqu’à 150 alertes. Si l’option Regroupement des événements est définie sur Déclencher une alerte pour chaque événement et que la requête de la règle renvoie plus de 150 événements, les 149 premiers événements génèrent chacun une alerte unique (pour 149 alertes) et la 150e alerte résume l’ensemble des événements renvoyés. En d’autres termes, la 150e alerte correspond à ce qui serait généré si l’option Regroupement des événements avait été définie sur Regrouper tous les événements dans une seule alerte.

Le paramètre Déclencher une alerte pour chaque événement peut générer un problème dans lequel les résultats de la requête semblent manquants ou diffèrent de ceux attendus. Pour plus d’informations sur ce scénario, consultez Résolution des problèmes liés aux règles analytiques dans Microsoft Sentinel | Problème : aucun événement n’apparaît dans les résultats de requête.

Suppression

Pour interrompre la règle pendant un certain temps après qu’elle a généré une alerte, définissez le paramètre Arrêter l’exécution de la requête une fois l’alerte générée sur Activé. Vous devez alors affecter la valeur correspondant à la durée d’arrêt de la requête (à savoir 24 heures au maximum) au paramètre Arrêter l’exécution de la requête pendant.

Simulation des résultats

L’Assistant Règle analytique permet de tester son efficacité en l’exécutant sur le jeu de données actuel. Lorsque vous exécutez le texte, la fenêtre Simulation des résultats affiche un graphique des résultats qui auraient été générés par la requête au cours des 50 dernières exécutions, conformément à la planification actuellement définie. Si vous modifiez la requête, vous pouvez réexécuter le test pour mettre à jour le graphique. Le graphique montre le nombre de résultats sur la période définie, laquelle est déterminée par la planification que vous avez définie pour la requête.

Voici à quoi peut ressembler la simulation des résultats pour la requête de la capture d’écran ci-dessus. Le côté gauche est l’affichage par défaut, et le côté droit est ce que vous voyez lorsque vous pointez sur un point dans le temps sur le graphe.

Si vous constatez que la requête déclenche un trop grand nombre d’alertes ou des alertes trop fréquentes, vous pouvez essayer de modifier les paramètres de planification et de seuil et relancer la simulation.

Paramètres de l’incident

Choisissez si Microsoft Sentinel doit transformer les alertes en incidents exploitables.

La création d’incidents est activée par défaut. Microsoft Sentinel crée un incident unique spécifique pour chaque alerte que génère la règle.

Si vous ne souhaitez pas que cette règle entraîne la création d’incidents (par exemple, si cette règle vise uniquement à collecter des informations pour une analyse future), affectez-lui la valeur Désactivé.

Important

Si vous avez intégré Microsoft Sentinel à la plateforme d’opérations de sécurité unifiée, Microsoft Defender XDR est responsable de la création d’incidents. Néanmoins, si vous souhaitez que Defender XDR crée des incidents pour cette alerte, vous devez laisser ce paramètre Activé. Defender XDR prend l’instruction définie ici.

Vous ne devez pas le confondre avec le type de règle analytique Sécurité Microsoft qui crée des incidents pour les alertes générées avec les services Microsoft Defender. Ces règles sont automatiquement désactivées lorsque vous intégrez Microsoft Sentinel à la plateforme d’opérations de sécurité unifiée.

Si vous souhaitez créer un incident unique à partir d'un groupe d'alertes, au lieu d'en créer un seul par alerte, consultez la section suivante.

Regroupement des alertes

Choisissez la façon dont les alertes sont regroupées dans les incidents. Par défaut, Microsoft Sentinel crée un incident pour chaque alerte générée. Vous pouvez aussi préférer regrouper plusieurs alertes dans un même incident.

L’incident n’est créé que lorsque toutes les alertes ont été générées. Toutes les alertes s’ajoutent à l’incident immédiatement après sa création.

150 alertes peuvent être regroupées au sein d'un même incident. Si plus de 150 alertes sont générées par une règle qui les regroupe dans un incident unique, un nouvel incident est généré avec les mêmes détails que l’incident d’origine, et les alertes excédentaires sont regroupées dans le nouvel incident.

Pour regrouper les alertes, définissez le paramètre de regroupement des alertes sur Activé.

Voici plusieurs options à prendre en compte pour regrouper les alertes :

• Délai d’exécution : par défaut, les alertes créées jusqu’à cinq heures après l’ajout de la première alerte dans un incident sont ajoutées au même incident. Après cinq heures, un nouvel incident est créé. Vous pouvez modifier cette période comme vous le souhaitez, de cinq minutes à sept jours.

• Critères de regroupement : choisissez comment déterminer les alertes incluses dans le groupe. Le tableau suivant présente les différentes options :

  Option	Description
  Regrouper les alertes en un seul incident si toutes les entités correspondent	Les alertes sont regroupées si elles partagent des valeurs identiques pour chacune des entités mappées définies plus haut. Il s'agit du paramètre recommandé.
  Regrouper toutes les alertes déclenchées par cette règle en un seul incident	Toutes les alertes générées par cette règle sont regroupées même si elles ne partagent pas de valeurs identiques.
  Regrouper les alertes en un seul incident si les entités et les détails sélectionnés correspondent	Les alertes sont regroupées si elles partagent des valeurs identiques pour toutes les entités mappées, les détails des alertes et les détails personnalisés que vous avez sélectionnés pour ce paramètre. Lorsque vous sélectionnez cette option, vous devez choisir les entités et les détails dans les listes déroulantes qui s’affichent. Vous pouvez utiliser ce paramètre si vous souhaitez, par exemple, créer des incidents distincts en fonction des adresses IP source ou cible, ou si vous préférez regrouper des alertes qui correspondent à une entité et une gravité particulières. Remarque : lorsque vous sélectionnez cette option, vous devez avoir au moins une entité ou un détail sélectionné pour la règle. Dans le cas contraire, la validation de la règle échoue et la règle n’est pas créée.

• Rouvrir un incident : si un incident a été résolu et fermé, et qu’une autre alerte devant être associée à cet incident est générée par la suite, définissez ce paramètre sur Activé pour rouvrir l’incident fermé, ou laissez-le défini sur Désactivé pour que l’alerte crée un autre incident.

  L’option permettant de rouvrir un incident fermé n’est pas disponible si vous avez intégré Microsoft Sentinel à la plateforme d’opérations de sécurité unifiée.

Réponse automatisée

Microsoft Sentinel permet de définir des réponses automatisées quand :

• Une alerte est générée par la règle analytique.
• Un incident est créé à partir d’une alerte générée avec la règle analytique.
• Un incident est mis à jour par une alerte générée avec la règle analytique.

Pour en savoir plus sur les différents types de réponses pouvant être conçus et automatisés, consultez Automatiser la gestion des menaces dans Microsoft Sentinel avec des règles d’automatisation.

Sous le titre Règles d’automatisation, l’assistant affiche une liste des règles d’automatisation déjà définies dans l’ensemble de l’espace de travail et dont les conditions s’appliquent à la règle analytique. Vous pouvez modifier l’une de ces règles ou créer une règle d’automatisation qui s’applique uniquement à la règle analytique.

Utilisez des règles d’automatisation pour effectuer le triage de base, l’affectation, le flux de travail et la fermeture des incidents.

Automatisez des tâches plus complexes et appelez des réponses de systèmes distants pour corriger les menaces en appelant des playbooks à partir de ces règles d’automatisation. Vous pouvez appeler les guides opérationnels pour les incidents et les alertes individuelles.

• Pour plus d’informations et pour obtenir des instructions sur la création de playbooks et de règles d’automatisation, consultez Automatisation des réponses aux menaces.

• Pour plus d’informations sur les cas où il convient d’utiliser le déclencheur créé d’alerte, le déclencheur mis à jour d’incident ou le déclencheur créé d’alerte, consultez Utiliser des déclencheurs et actions dans les playbooks Microsoft Sentinel.

• Sous le titre Automatisation des alertes (classique), vous pouvez consulter une liste des guides opérationnels configurés pour s’exécuter automatiquement avec une ancienne méthode pour les éléments déconseillés en mars 2026. Vous ne pouvez rien ajouter à cette liste. Tous les guides opérationnels répertoriés ici doivent disposer de règles d’automatisation créées, en fonction du déclencheur créé par l’alerte pour appeler les guides opérationnels. Une fois cette opération terminée, sélectionnez les points de suspension à la fin de la ligne du playbook répertorié ici, puis Supprimer. Pour obtenir des instructions complètes, consultez Migrer vos playbooks déclencheurs d’alerte Microsoft Sentinel vers des règles d’automatisation.

Étapes suivantes

Lorsque vous utilisez des règles analytiques Microsoft Sentinel pour détecter les menaces de votre environnement, vous devez activer toutes les règles associées à vos sources de données connectées pour garantir une couverture de sécurité complète pour votre environnement.

Pour automatiser l’activation des règles, envoyez des règles à Microsoft Sentinel via d’API et PowerShell, même si cela nécessite des efforts supplémentaires. Lorsque vous utilisez l’API ou PowerShell, vous devez d’abord exporter les règles vers JSON avant de les activer. L’API ou PowerShell peuvent être utiles lors de l’activation de règles dans plusieurs instances de Microsoft Sentinel avec des paramètres identiques dans chaque instance.

Pour plus d’informations, consultez l’article suivant :

• Exporter et importer des règles analytiques vers et depuis des modèles ARM
• Résoudre les problèmes liés aux règles d’analytique dans Microsoft Sentinel
• Naviguer et examiner les incidents dans Microsoft Sentinel
• 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é.