Règles d’analyse planifiées dans Microsoft Sentinel

De loin le type de règle d’analyse 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 leurs données cibles, révélant des bases de référence et des valeurs aberrantes 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 génère une alerte.

Cet article vous aide à comprendre comment les règles d’analyse planifiées sont générées et vous présente toutes les options de configuration et leur signification. Les informations contenues dans cet article sont utiles dans deux scénarios :

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

• Créez une règle d’analyse à partir de zéro : créez votre propre requête et votre propre règle à partir de zéro. Pour ce faire efficacement, vous devez disposer d’une connaissance approfondie de la science des données et du langage de requête Kusto.

Modèles de règle d’analyse

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

Utilisez un modèle de règle d’analyse en sélectionnant un nom de modèle dans la liste des modèles et en créant une règle basée sur celui-ci.

Chaque modèle a 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. La disponibilité signifie que la source de données est connectée et que les données sont ingérées régulièrement par son intermédiaire. Si l’une des sources de données requises n’est pas disponible, vous n’êtes pas autorisé à créer la règle, et vous pouvez également voir un message d’erreur à cet effet.

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é. Tous les détails sont automatiquement renseignés, et vous pouvez personnaliser la logique et d’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ègle, 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, sous l’onglet Modèles de règle, le modèle à partir duquel vous avez créé la règle s’affiche désormais avec la In use balise .

Les modèles de règles d’analyse sont constamment gérés par leurs auteurs, soit pour corriger les bogues, soit pour affiner la requête. Lorsqu’un modèle reçoit une mise à jour, toutes les règles basées sur ce modèle sont affichées avec la Update balise , et vous avez la possibilité de modifier ces règles pour inclure les modifications apportées au modèle. Vous pouvez également rétablir les modifications apportées à une règle à sa version d’origine basée sur un modèle. Pour plus d’informations, consultez Gérer les versions de modèles pour vos règles d’analyse planifiées dans Microsoft Sentinel.

Après vous être familiarisé avec les options de configuration de cet article, consultez Créer des règles d’analyse planifiées à partir de modèles.

Le reste de cet article explique toutes les possibilités de personnalisation de la configuration de vos règles.

Configuration des règles d’analyse

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

Nom et détails de la règle d’analyse

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

Nom: Nom de la règle telle qu’elle apparaît dans la liste des règles et dans tous les filtres basés sur des règles. Le nom doit être unique à votre 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, utilisé entre autres dans les requêtes et réponses d’API. Ce GUID n’est affecté qu’au moment de la création de la règle. Il ne s’affiche donc que lorsque vous modifiez une règle existante. Comme il s’agit d’un champ en lecture seule, il est affiché comme grisé et ne peut pas être modifié. Il n’existe pas encore lors de la création d’une règle, soit à partir d’un modèle, soit à partir de zéro.

Gravité: Une évaluation pour donner les alertes produites par cette règle. La gravité d’une activité est un calcul de l’impact négatif potentiel de l’occurrence de l’activité.

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

Les définitions de gravité pour les modèles de règles d’analyse Microsoft Sentinel sont pertinentes uniquement pour les alertes créées par les 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 cette règle. Celles-ci sont basées sur les tactiques et techniques du framework MITRE ATT&CK®.

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

Pour plus d’informations sur l’optimisation de votre couverture du paysage des menaces MITRE ATT&CK, consultez Comprendre la couverture de sécurité par l’infrastructure MITRE ATT&CK®.

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

• Sélectionnez Désactivé. La règle est créée sans exécution. Lorsque vous souhaitez que la règle s’exécute, recherchez-la dans votre onglet Règles actives et activez-la à partir de là.
• Planifiez l’exécution de la règle pour la première fois à 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 des informations contenues dans les alertes créées par cette règle et de la façon dont les informations sont organisées. Cette configuration a des effets de suivi sur ce à quoi ressemblent les incidents résultants, ainsi que sur la facilité ou la difficulté à examiner, corriger et résoudre. Il est important de rendre vos alertes aussi riches en informations que possible 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, il est judicieux de planifier et de concevoir votre requête avant d’ouvrir cet Assistant. Vous pouvez générer et tester des 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é, de sorte que vous découvrez immédiatement si vous faites des erreurs.

Bonnes pratiques pour les requêtes de règle d’analyse

• Nous vous recommandons d’utiliser un analyseur ASIM (Advanced Security Information Model) comme source de requête, au lieu d’utiliser une table native. Cela permet de s’assurer que la requête prend en charge toute source de données ou famille de sources de données actuelle ou future, plutôt que de s’appuyer sur une seule source de données.

• La longueur de la requête doit être comprise entre 1 et 10 000 caractères et ne peut pas contenir «search * » ou «union * ». Vous pouvez utiliser des fonctions définies par l’utilisateur pour surmonter la limitation de la longueur de 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 dans la fenêtre de requête Log Analytics n’est pas prise en charge.

• Lorsque vous utilisez la bag_unpack fonction dans une requête, si vous projetez les colonnes en tant que champs à l’aide de «project field1 » et que la colonne n’existe pas, la requête échoue. Pour éviter que cela ne se produise, vous devez projeter la colonne comme suit :

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

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

• Langage de requête Kusto dans Microsoft Sentinel
• Guide de référence rapide KQL
• Bonnes pratiques pour les requêtes Langage de requête Kusto

Amélioration de l’alerte

Si vous souhaitez que vos alertes fassent apparaître leurs résultats afin qu’elles puissent être immédiatement visibles dans les incidents, suivies et examinées de manière appropriée, utilisez la configuration d’amélioration des alertes pour exposer toutes les informations importantes dans les alertes.

Cette amélioration de l’alerte présente l’avantage supplémentaire de présenter les résultats d’une manière facilement visible et accessible.

Il existe trois types d’améliorations d’alerte que vous pouvez configurer :

• Mappage d’entités
• Détails personnalisés
• Détails de l’alerte (également appelés contenu dynamique)

Mappage d’entités

Les entités sont les joueurs de chaque côté de toute histoire d’attaque. L’identification de toutes les entités d’une alerte est essentielle 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 aux champs dans les résultats de votre requête. Ce mappage intègre les entités identifiées dans le champ Entités de votre schéma d’alerte.

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

Détails personnalisés

Par défaut, seules les entités et métadonnées d’alerte sont visibles dans les incidents sans explorer les événements bruts dans les résultats de la requête. Pour donner à d’autres champs des résultats de votre requête une visibilité immédiate dans vos alertes et incidents, définissez-les comme des détails personnalisés. Microsoft Sentinel intègre ces détails personnalisés dans le champ ExtendedProperties de vos alertes, ce qui les affiche à l’avance dans vos alertes et dans tous les incidents créés à partir de ces alertes.

Pour en savoir plus sur la présentation des détails personnalisés et obtenir des instructions complètes, consultez Détails des événements personnalisés Surface dans les alertes dans 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 individuelle. 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 inclure un nom d’utilisateur ou une adresse IP figurant dans l’alerte.

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

Planification des requêtes

Les paramètres suivants déterminent la fréquence d’exécution de votre règle planifiée et la période qu’elle examine chaque fois qu’elle s’exécute.

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

• L’intervalle de requête doit être inférieur ou égal à la période de recherche différée. Si elle est plus courte, les périodes de requête se chevauchent, ce qui peut entraîner une duplication des résultats. Toutefois, la validation de la règle ne vous permet pas de définir un intervalle plus long que la période de recherche différée, car cela entraînerait des lacunes dans votre couverture.

Le paramètre Démarrer l’exécution, désormais en préversion, vous permet de créer une règle avec status Activé, mais de retarder sa première exécution jusqu’à une date et une heure prédéterminées. Ce paramètre est utile si vous souhaitez chronoérer l’exécution de vos règles en fonction du moment où les données sont censées être ingérées à partir de la source ou du moment où vos analystes SOC commencent leur journée de travail.

• L’heure d’exécution de début doit être comprise entre 10 minutes et 30 jours après l’heure de création (ou d’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 actuels de planification et de recherche arrière des requêtes.

  

Seuil d’alerte

De nombreux types d’événements de sécurité sont normaux ou même attendus en petit nombre, mais sont le signe d’une menace en plus grand nombre. Différentes échelles de grands nombres peuvent signifier différents types de menaces. Par exemple, deux ou trois tentatives de connexion ayant échoué en l’espace d’une minute sont le signe qu’un utilisateur ne se souvient pas d’un mot de passe, mais 50 en une minute peuvent être le signe d’une attaque humaine, et un millier est probablement 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. Le seuil s’applique séparément à chaque exécution de la règle, et non collectivement.

Le seuil peut également être défini sur un nombre maximal de résultats ou un nombre exact.

Regroupement d’événements

Il existe deux façons de gérer le regroupement d’événements en alertes :

• Regroupez tous les événements en une seule alerte : Il s’agit de la valeur par défaut. La règle génère une alerte unique chaque fois qu’elle s’exécute, à condition que la requête retourne plus de résultats que le seuil d’alerte spécifié expliqué dans la section précédente. Cette alerte unique résume tous les événements retournés dans les résultats de la requête.

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

Les règles d’analyse peuvent générer jusqu’à 150 alertes. Si le regroupement d’événements est défini sur Déclencher une alerte pour chaque événement et que la requête de la règle retourne 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écapitule l’ensemble des événements retournés. En d’autres termes, la 150e alerte correspond à ce qui aurait été généré si le regroupement d’événements avait été défini sur Regrouper tous les événements en une seule alerte.

La section Requête de l’alerte est différente dans chacun de ces deux modes. Dans le mode Regrouper tous les événements en une seule alerte , l’alerte retourne une requête qui vous permet de voir tous les événements qui ont déclenché l’alerte. Vous pouvez explorer les résultats de la requête pour voir les événements individuels. Dans déclencher une alerte pour chaque mode d’événement , l’alerte retourne un résultat codé en base64 dans la zone de requête. Copiez et exécutez cette sortie dans Log Analytics pour décoder le base64 et afficher l’événement d’origine.

Le paramètre Déclencher une alerte pour chaque événement peut provoquer un problème où les résultats de la requête semblent manquants ou différents que prévu. Pour plus d’informations sur ce scénario, consultez Résolution des problèmes liés aux règles d’analyse dans Microsoft Sentinel | Problème : Aucun événement n’apparaît dans les résultats de la requête.

Suppression

Si vous souhaitez que cette règle cesse de fonctionner pendant un certain temps après la génération d’une alerte, activez le paramètreArrêter l’exécution de la requête après la génération de l’alerte. Ensuite, vous devez définir Arrêter l’exécution de la requête pour sur la durée pendant laquelle la requête doit cesser de s’exécuter, jusqu’à 24 heures.

Simulation des résultats

L’Assistant Règle d’analytique vous permet de tester son efficacité en l’exécutant sur le jeu de données actuel. Lorsque vous exécutez le test, la fenêtre Simulation des résultats affiche un graphique des résultats que la requête aurait générés au cours des 50 dernières fois qu’elle aurait été exécutée, selon 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, qui est déterminé par la planification des requêtes que vous avez définie.

Voici à quoi peut ressembler la simulation des résultats pour la requête dans la capture d’écran précédente. 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 graphique.

Si vous constatez que votre requête déclenche des alertes trop nombreuses ou trop fréquentes, vous pouvez tester les paramètres de planification et de seuil et réexécuter la simulation.

Paramètres d’incident

Indiquez si Microsoft Sentinel transforme les alertes en incidents actionnables.

La création d’incident est activée par défaut. Microsoft Sentinel crée un incident unique distinct à partir de chaque alerte générée par 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 ultérieure), définissez-la sur Désactivé.

Si vous souhaitez qu’un seul incident soit créé à partir d’un groupe d’alertes, au lieu d’une pour chaque alerte, consultez la section suivante.

Regroupement d’alertes

Indiquez si 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 avez la possibilité de regrouper plusieurs alertes en un seul incident.

L’incident est créé uniquement une fois que toutes les alertes ont été générées. Toutes les alertes sont ajoutées à l’incident immédiatement après sa création.

Jusqu’à 150 alertes peuvent être regroupées en un seul incident. Si plus de 150 alertes sont générées par une règle qui les regroupe en un seul incident, un nouvel incident est généré avec les mêmes détails d’incident que l’original, et les alertes excédentaires sont regroupées dans le nouvel incident.

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

Il existe quelques options à prendre en compte lors du regroupement des alertes :

• Période : Par défaut, les alertes créées jusqu’à 5 heures après la première alerte d’un incident sont ajoutées au même incident. Après 5 heures, un nouvel incident est créé. Vous pouvez modifier cette période en n’importe où entre 5 minutes et sept jours.

• Critères de regroupement : Choisissez comment déterminer les alertes qui sont incluses dans le groupe. Le tableau suivant présente les choix possibles :

  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 précédemment. 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 aucune valeur identique.
  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 de l’alerte et les détails personnalisés que vous sélectionnez pour ce paramètre. Choisissez les entités et les détails dans les listes déroulantes qui s’affichent lorsque vous sélectionnez cette option. Vous pouvez utiliser ce paramètre si, par exemple, vous souhaitez créer des incidents distincts en fonction des adresses IP source ou cible, ou si vous souhaitez regrouper des alertes qui correspondent à une entité et à une gravité spécifiques. Remarque : Lorsque vous sélectionnez cette option, au moins une entité ou un détail doit être sélectionné pour la règle. Sinon, la validation de la règle échoue et la règle n’est pas créée.

• Réouverture des incidents : si un incident a été résolu et fermé et qu’une autre alerte qui doit appartenir à cet incident est générée ultérieurement, définissez ce paramètre sur Activé si vous souhaitez que l’incident fermé soit rouvert et laissez désactivé si vous souhaitez que la nouvelle alerte crée un incident.

  L’option permettant de rouvrir les incidents fermés n’est pas disponible si vous avez intégré Microsoft Sentinel au portail Defender.

Réponse automatisée

Microsoft Sentinel vous permet de définir des réponses automatisées pour qu’elles se produisent dans les cas suivants :

• Une alerte est générée par cette règle d’analyse.
• Un incident est créé à partir des alertes générées par cette règle d’analyse.
• Un incident est mis à jour avec des alertes générées par cette règle d’analyse.

Pour en savoir plus sur les différents types de réponses qui peuvent être conçues et automatisées, consultez Automatiser la réponse aux 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 sur l’ensemble de l’espace de travail, dont les conditions s’appliquent à cette règle d’analyse. Vous pouvez modifier l’une de ces règles existantes ou créer une règle d’automatisation qui s’applique uniquement à cette règle d’analyse.

Utilisez des règles d’automatisation pour effectuer le triage de base, l’affectation, le workflow 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 des playbooks pour les incidents ainsi que pour 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 Automatiser les réponses aux menaces.

• Pour plus d’informations sur l’utilisation du déclencheur créé par incident, du déclencheur d’incident mis à jour ou du déclencheur créé par l’alerte, consultez Utiliser des déclencheurs et des actions dans Microsoft Sentinel playbooks.

• Sous le titre Automatisation des alertes (classique), vous pouvez voir une liste de playbooks configurés pour s’exécuter automatiquement à l’aide d’une ancienne méthode qui sera dépréciée en mars 2026. Vous ne pouvez rien ajouter à cette liste. Tous les playbooks répertoriés ici doivent avoir des règles d’automatisation créées, basées sur le déclencheur d’alerte créé, pour appeler les playbooks. Après cela, sélectionnez les points de suspension à la fin de la ligne du playbook répertorié ici, puis sélectionnez Supprimer. Pour obtenir des instructions complètes, consultez Migrer vos playbooks Microsoft Sentinel déclencheurs d’alerte vers des règles d’automatisation.

Étapes suivantes

Lorsque vous utilisez des règles d’analyse Microsoft Sentinel pour détecter les menaces dans votre environnement, veillez à 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 l’API et PowerShell, même si cela nécessite plus d’efforts. Lorsque vous utilisez l’API ou PowerShell, vous devez d’abord exporter les règles au format JSON avant d’activer les règles. L’API ou PowerShell peut vous aider 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, reportez-vous aux rubriques suivantes :

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