Créer et personnaliser des règles analytiques dans Microsoft Sentinel

• 7 minutes

Une fois que vous avez connecté vos sources de données à Microsoft Sentinel, créez des règles d’analyse personnalisées pour faciliter la détection des menaces et comportements anormaux au sein de votre environnement.

Les règles d’analytique recherchent des événements ou des ensembles d'événements spécifiques au sein de votre environnement, vous préviennent lorsque certains seuils ou conditions d'événements sont atteints, génèrent des incidents que votre centre des opérations de sécurité (SOC) doit trier et examiner et répondent aux menaces grâce à des processus de suivi et de correction automatisés.

Créer une règle d’analytique personnalisée avec une requête planifiée

1. Dans le menu de navigation de Microsoft Sentinel, sélectionnez Analyse.

2. Sur la barre d'action du haut de l'écran, sélectionnez +Créer, puis Règle de requête planifiée. Cela entraîne l’ouverture de l’Assistant de règle analytique.

Assistant de règle analytique - Onglet Général

• Entrez un Nom unique et une Description.
• Dans le champ Tactiques et techniques, vous pouvez choisir les catégories d’attaque en fonction desquelles la règle doit être classifiée. Elles sont basées sur les tactiques et les techniques de l’infrastructure MITRE ATT&CK .
• Les incidents créés à partir d’alertes qui sont détectées par des règles mappées aux tactiques et techniques MITRE ATT&CK héritent automatiquement du mappage de la règle.
• Choisissez la Gravité d'alerte qui convient.
  • d’informations . 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.
  • Moyen. 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.
  • Élevé. 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 du 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.
  
• Quand vous créez la règle, son État est Activé par défaut. Cela signifie qu’elle va s’exécuter dès que vous aurez fini de la créer. Si vous ne souhaitez pas qu’elle s’exécute immédiatement, sélectionnez Désactivé. Dans ce cas, la règle est ajoutée à votre onglet Règles actives, à partir duquel vous pouvez l’activer quand vous en avez besoin.

Définir la logique de requête de règle et configurer les paramètres

Sous l'onglet Définir la logique de la règle, vous pouvez soit écrire une requête directement dans le champ Requête de règle, soit créer la requête dans l'espace de travail Log Analytics, puis la copier et la coller ici.

• Les requêtes sont écrites en langage de requête Kusto (KQL).
• L'exemple illustré dans cette capture d'écran interroge la table SecurityEvent pour afficher un type d'événements de connexion Windows ayant échoué.

Voici un autre exemple de requête qui vous prévient lorsqu'un nombre anormal de ressources est créé dans Activité Azure.

Kusto

AzureActivity

| où OperationNameValue == « MICROSOFT. COMPUTE/VIRTUALMACHINES/WRITE » ou OperationNameValue == « MICROSOFT.RESOURCES/DEPLOYMENTS/WRITE »

| où ActivityStatusValue == « Succeeded »

| make-series dcount(ResourceId) default=0 sur EventSubmissionTimestamp in range(ago(7d), now(), 1d) par l’Appelant

Meilleures pratiques en matière de requête de règle :

• 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 limite de longueur de requête.
  
• 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.
  
• Lorsque vous utilisez la fonction bag_unpack dans une requête, si vous projetez les colonnes en tant que champs avec 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","")
    

Enrichissement des alertes

• Utilisez la section de configuration Mappage d’entités pour mapper les paramètres de vos résultats de requête à des entités reconnues par Microsoft Sentinel. Les entités enrichissent les résultats des règles (alertes et incidents) avec des informations essentielles qui constituent la base de tout processus d'investigation et des actions correctives ultérieures. Il s’agit également des critères selon lesquels vous pouvez regrouper des alertes en incidents dans l’onglet Paramètres d’incident.
• Utilisez la section de configuration Détails personnalisés pour extraire les éléments des données d'événement de votre requête et les faire apparaître dans les alertes produites par cette règle, ce qui vous donne une visibilité immédiate sur le contenu des événements dans vos alertes et incidents.
  
• Utilisez la section de configuration Détails de l’alerte pour remplacer les valeurs par défaut des propriétés de l’alerte par les détails des résultats de la requête sous-jacente. Les détails de l’alerte vous permettent, par exemple, d’afficher l’adresse IP ou le nom de compte d’un attaquant dans le titre même de l’alerte, afin qu’il apparaisse dans votre file d’attente d’incidents, ce qui vous donne une image plus complète et plus claire de votre contexte de menaces.

• Les alertes dont la taille est supérieure à 64 Ko sont tronquées. Au fur et à mesure que les entités sont identifiées, elles sont ajoutées à l’alerte une par une jusqu’à ce que la taille de l’alerte atteigne 64 Ko, et toutes les entités restantes sont supprimées de l’alerte.
  
• Les autres enrichissements d’alerte contribuent également à la taille de l’alerte.
  
• Pour réduire la taille de votre alerte, utilisez l’opérateur project-away dans votre requête pour supprimer tout champ inutile. (Envisagez également l’opérateur project si vous ne devez conserver que quelques champs.)
  

Planification des requêtes et seuil d'alerte

• Dans la section Planification de la requête, définissez les paramètres suivants :

• Définissez le paramètre Exécuter la requête tou(te)s les pour définir la fréquence d'exécution de la requête (au maximum, toutes les 5 minutes ou au minimum, tous les 14 jours).
• Définissez le paramètre Rechercher les données des derniers pour déterminer la période des données couvertes par la requête. Par exemple, la requête peut porter sur les 10 dernières minutes de données ou sur les 6 dernières heures de données. Le maximum est de 14 jours.
• Pour le nouveau paramètre Démarrer l’exécution (dans Préversion) :
  • Laissez-le défini sur Automatiquement continuer le comportement d’origine : la règle s’exécute pour la première fois immédiatement après sa création et ensuite en fonction de l’intervalle défini dans le paramètre Exécuter la requête tou(te)s les.
  • Basculez le commutateur vers À un moment spécifique si vous souhaitez déterminer quand
  • la règle s’exécute en premier, au lieu de l’exécuter immédiatement. Choisissez ensuite la date à l’aide du sélecteur du calendrier et entrez l’heure au format de l’exemple illustré.

Les exécutions ultérieures de la règle se produisent à l’intervalle spécifié après la première exécution.

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.

Intervalles entre les requêtes et période de recherche arrière

Ces deux paramètres sont indépendants l’un de l’autre, jusqu’à un certain point. Vous pouvez exécuter une requête sur un court intervalle qui couvre une période plus longue que l’intervalle (en ayant en fait des requêtes qui se chevauchent), mais vous ne pouvez pas exécuter une requête sur un intervalle qui dépasse la période de couverture, sinon vous avez des écarts dans la couverture globale des requêtes.

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.

Utilisez la section Seuil d'alerte pour définir le niveau de sensibilité de la règle. Par exemple, affectez la valeur Est supérieur à au paramètre Générer une alerte quand le nombre de résultats de la requête, puis entrez le nombre 1000 pour que la règle génère une alerte uniquement si la requête retourne plus de 1000 résultats à chaque exécution. Ce champ est obligatoire. Par conséquent, si vous ne souhaitez pas définir de seuil (en d'autres termes, si vous souhaitez que votre alerte enregistre chaque événement), entrez 0 dans le champ numérique.

Configurer les paramètres de création d’incident

Sous l’onglet Paramètres des incidents, vous pouvez choisir si et comment Microsoft Sentinel doit transformer les alertes en incidents actionnables. Si vous ne changez pas cet onglet, Microsoft Sentinel crée un seul incident distinct à partir de chaque alerte. Vous pouvez choisir de ne pas créer d’incident ou de regrouper plusieurs alertes en un seul incident en changeant les paramètres de cet onglet.

Paramètres de l’incident

Dans la section Paramètres des incidents, le paramètre Créer des incidents à partir d’alertes déclenchées par cette règle analytique est Activé par défaut, ce qui signifie que Microsoft Sentinel crée un incident distinct à partir de chaque alerte déclenché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 future), affectez-lui la valeur Désactivé.
• 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

Dans la section Regroupement des alertes, si vous souhaitez qu’un seul incident soit généré à partir d’un groupe de jusqu’à 150 alertes similaires ou récurrentes, définissez l’option Regrouper les alertes déclenchées par cette règle analytique en un seul incident par sur Activé, puis définissez les paramètres suivants.

• Limiter le groupe aux alertes créées dans la période de temps sélectionnée : Déterminez le délai d’exécution dans lequel les alertes similaires ou récurrentes vont être regroupées. Toutes les alertes correspondantes dans ce délai d’exécution génèrent collectivement un incident ou un ensemble d’incidents (en fonction des paramètres de regroupement ci-dessous). Les alertes situées en dehors de ce délai d’exécution génèrent un incident ou un ensemble d’incidents distinct.
• Regrouper les alertes déclenchées par cette règle analytique en un seul incident par : Choisissez la base sur laquelle les alertes sont regroupées :

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 (spécifiées sous l’onglet Définir la logique de la règle ci-dessus). 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 d’alerte et les détails personnalisés, sélectionnés dans les listes déroulantes respectives. 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 un champ ou un type d’entité 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 les incidents correspondants fermés : Si un incident a été résolu et fermé et que, par la suite, une autre alerte est générée, qui devrait être associée à cet incident, définissez ce paramètre sur Activé si vous voulez que l’incident fermé soit rouvert, ou laissez-le défini sur Désactivé si vous voulez que l’alerte crée un autre incident.

• L’incident n’est créé qu’une fois que toutes les alertes ont été générées. Toutes les alertes seront ajoutées à l’incident immédiatement après sa création.
• 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.

Définir des réponses automatisées et créer la règle

Dans l’onglet Réponses automatisées, vous pouvez utiliser des règles d’automatisation pour définir des réponses automatisées afin qu’elles se produisent lors de l’un des trois types d’occasions :

1. Lorsqu’une alerte est générée par cette règle d’analytique.
2. Lorsqu’un incident est créé avec des alertes générées par cette règle d’analytique.
3. Lorsqu’un incident est mis à jour avec des alertes générées par cette règle d’analytique.

La grille affichée sous Règles d’automatisation affiche les règles d’automatisation qui s’appliquent déjà à cette règle d’analyse (en vertu de celle-ci répondant aux conditions définies dans ces règles). Vous pouvez modifier l’un de ces éléments en sélectionnant les points de suspension à la fin de chaque ligne. Vous pouvez également créer une règle d’automatisation.

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 le faire pour les incidents ainsi que pour les alertes individuelles.

• Sous Automatisation des alertes (classique) en bas de l’écran, vous verrez tous les playbooks que vous avez configurés pour qu’ils s’exécutent automatiquement lorsqu’une alerte est générée à l’aide de l’ancienne méthode.
  • Depuis juin 2023, vous ne pouvez plus ajouter de playbooks à cette liste. Les guides opérationnels déjà répertoriés ici vont continuer à s’exécuter jusqu’à ce que cette méthode soit déconseillée, à compter de mars 2026.
  • Si vous en avez encore des guides opérationnels répertoriés ici, vous devez plutôt créer une règle d’automatisation basée sur le déclencheur d’alerte créé et appeler le guide opérationnel à partir de là. 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.

Sélectionnez Examiner et créer pour examiner tous les paramètres de votre nouvelle règle d'alerte. Lorsque le message « Validation réussie » s’affiche, sélectionnez Créer.

Afficher la règle et sa sortie

• Vous trouverez votre règle personnalisée nouvellement créée (de type « Planifiée ») dans le tableau sous l’onglet Règles actives de l’écran Analyses. Dans cette liste, vous pouvez activer, désactiver ou supprimer chaque règle.
• Pour afficher les résultats de vos règles d’analyse créées, accédez à la page Incidents, où vous pouvez ensuite trier des incidents, les examiner, puis corriger les menaces.
• Vous pouvez mettre à jour la requête de règle pour exclure les faux positifs.