Listes de surveillance dans Microsoft Sentinel

Les watchlists dans Microsoft Sentinel aident les analystes de sécurité à corréler et à enrichir efficacement les données d’événements. Ils vous offrent un moyen flexible de gérer les données de référence, comme des listes de ressources de grande valeur ou des employés licenciés. Intégrez des watchlists à vos règles de détection, à la chasse aux menaces et aux workflows de réponse pour réduire la fatigue des alertes et répondre plus rapidement aux menaces. Cet article explique comment utiliser des watchlists dans Microsoft Sentinel, décrit les principaux scénarios et limitations, et fournit des conseils sur la création et l’interrogation de watchlists pour améliorer vos opérations de sécurité.

Utilisez des listes de surveillance dans vos requêtes de recherche, vos règles de détection, votre chasse aux menaces et vos playbooks de réponse. Les watchlists sont stockés dans votre espace de travail Microsoft Sentinel dans la Watchlist table sous forme de paires nom-valeur et mis en cache pour des performances de requête optimales.

Important

Les fonctionnalités des modèles watchlist et la possibilité de créer une watchlist à partir d’un fichier dans Azure Stockage sont actuellement en PRÉVERSION. Les conditions supplémentaires de la préversion Azure incluent des conditions juridiques supplémentaires qui s’appliquent à Azure fonctionnalités qui sont en version bêta, en préversion ou qui ne sont pas encore publiées en disponibilité générale.

Quand utiliser les watchlists

Utilisez des watchlists dans les scénarios suivants :

• Examinez les menaces en important des adresses IP, des hachages de fichiers et d’autres données provenant de fichiers de valeurs séparées par des virgules (CSV), puis utilisez des paires nom-valeur watchlist pour les jointures et les filtres dans les règles d’alerte, la chasse aux menaces, les classeurs, les notebooks et les requêtes.

• Importer des données métier comme liste de surveillance. Par exemple, importez des listes d’utilisateurs avec un accès système privilégié ou des listes d’employés licenciés. Ensuite, utilisez la watchlist pour créer des listes d’autorisation et des listes de blocage afin de détecter ou d’empêcher ces utilisateurs de se connecter au réseau.

• Réduire la fatigue des alertes. Créez des listes d’autorisation pour supprimer les alertes d’un groupe d’utilisateurs, comme les utilisateurs d’adresses IP autorisées qui effectuent des tâches qui déclenchent normalement l’alerte. Empêcher les événements bénins de devenir des alertes.

• Enrichir les données d’événement avec des combinaisons nom-valeur à partir de sources de données externes.

Limitations de la liste de surveillance

Passez en revue les limitations suivantes avant de créer des watchlists :

Restriction	Détails
Nom de la liste de surveillance et longueur de l’alias	Les noms et alias de watchlist doivent comporter entre 3 et 64 caractères. Le premier et le dernier caractères doivent être alphanumériques ; espaces, traits d’union et traits de soulignement autorisés entre.
Utilisation prévue	Utilisez des watchlists uniquement pour les données de référence. Les watchlists ne sont pas conçues pour les grands volumes de données.
Nombre maximal d’éléments de watchlist actifs	Vous pouvez avoir un maximum de 10 millions d’éléments de watchlist actifs sur toutes les watchlists d’un espace de travail. Les éléments supprimés ne comptent pas. Pour les volumes plus importants, utilisez des journaux personnalisés.
Rétention des données	Les données de la table Watchlist Log Analytics sont conservées pendant 28 jours.
Intervalle d’actualisation	Les watchlists sont actualisées tous les 12 jours, en mettant à jour le TimeGenerated champ.
Gestion inter-espaces de travail	La gestion des watchlists dans les espaces de travail à l’aide de Azure Lighthouse n’est pas prise en charge.
Taille de chargement de fichier local	Les chargements de fichiers locaux sont limités aux fichiers d’une taille maximale de 3,8 Mo.
Taille de chargement de fichier stockage Azure (préversion)	Azure Les chargements de stockage sont limités aux fichiers d’une taille maximale de 500 Mo.
Restrictions relatives aux colonnes et aux tables	Les listes de surveillance doivent respecter les restrictions de nommage des entités de Kusto Query Language (KQL) pour les colonnes et les noms.

Méthodes de création de listes de surveillance dans Microsoft Sentinel

Pour créer des watchlists dans Microsoft Sentinel, utilisez l’une des méthodes suivantes :

• Chargez un fichier à partir d’un dossier local ou à partir de votre compte stockage Azure.
• Téléchargez un modèle watchlist à partir de Microsoft Sentinel, ajoutez vos données et chargez le fichier.

Pour créer une watchlist à partir d’un fichier volumineux (jusqu’à 500 Mo), chargez le fichier dans votre compte de stockage Azure. Créez une URL de signature d’accès partagé (SAS) afin que Microsoft Sentinel puissiez récupérer les données de watchlist. Une URL SAS inclut à la fois l’URI de ressource et le jeton SAP pour une ressource, comme un fichier CSV dans votre compte de stockage. Ajoutez la watchlist à votre espace de travail dans Microsoft Sentinel.

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

• Créer des watchlists dans Microsoft Sentinel
• Schémas de watchlist intégrés
• Jeton SAS de stockage Azure

Listes de surveillance dans les requêtes pour les recherches et les règles de détection

Pour mettre en corrélation vos données de watchlist avec d’autres données Microsoft Sentinel, utilisez des opérateurs tabulaires Kusto tels que join et lookup avec la Watchlist table. Microsoft Sentinel fournit les fonctions intégrées suivantes pour vous aider à interroger les watchlists :

• _GetWatchlistAlias - retourne les alias de toutes vos watchlists
• _GetWatchlist - interroge les paires de noms et de valeurs de la liste de surveillance spécifiée

Lorsque vous créez une watchlist, vous définissez searchKey. La clé de recherche est le nom d’une colonne de votre watchlist que vous prévoyez d’utiliser comme jointure avec d’autres données ou comme objet de recherche fréquent. Par exemple, supposons que vous disposez d’une watchlist de serveur qui contient les noms de pays/régions et leurs codes de pays à deux lettres respectifs. Vous prévoyez d’utiliser fréquemment les codes de pays pour effectuer des recherches ou des jointures. Vous utilisez donc la colonne country code comme clé de recherche.

Heartbeat
| lookup kind=leftouter _GetWatchlist('mywatchlist') 
  on $left.RemoteIPCountry == $right.SearchKey

Examinons d’autres exemples de requêtes.

Supposons que vous souhaitiez utiliser une watchlist dans une règle d’analyse. Vous créez une watchlist appelée ipwatchlist avec des colonnes pour IPAddress et Location. Vous définissez IPAddress en tant que SearchKey.

IPAddress,Location
10.0.100.11,Home
172.16.107.23,Work
10.0.150.39,Home
172.20.32.117,Work

Pour inclure uniquement des événements provenant d’adresses IP dans la watchlist, vous pouvez utiliser une requête où watchlist est utilisé comme variable ou inline.

Cet exemple de requête utilise la watchlist comme variable :

  //Watchlist as a variable
  let watchlist = (_GetWatchlist('ipwatchlist') | project IPAddress);
  Heartbeat
  | where ComputerIP in (watchlist)

Cet exemple de requête utilise la liste de surveillance directement dans la requête ainsi que la clé de recherche définie pour la liste de surveillance.

  //Watchlist inline with the query
  //Use SearchKey for the best performance
  Heartbeat
  | where ComputerIP in ( 
      (_GetWatchlist('ipwatchlist')
      | project SearchKey)
  )

Pour plus d’informations sur la création de requêtes et de règles de détection avec des watchlists, consultez Générer des requêtes et des règles de détection avec des watchlists dans Microsoft Sentinel, et pour les opérateurs et instructions Kusto, consultez les articles suivants :

• opérateur où
• opérateur de projet
• opérateur lookup
• opérateur in
• let instruction

Pour plus d’informations sur KQL, consultez vue d’ensemble de Langage de requête Kusto (KQL).

Autres ressources :

• Informations de référence rapides sur KQL
• ressources d’apprentissage du langage Kusto Query Language

Dépanner les listes de surveillance pendant les incidents et résoudre les problèmes de requête

Résoudre les problèmes de disponibilité du portail ou de l’API

Si la page Watchlists est vide, se recharge en permanence, ou si les opérations sur les listes de surveillance renvoient 502 Bad Gateway ou d’autres réponses 5XX, déterminez d’abord si le problème se situe probablement du côté du service avant de modifier la configuration des listes de surveillance.

Utilisez les vérifications suivantes :

• Vérifiez si le problème affecte toutes les watchlists ou plusieurs watchlists.

• Vérifiez si le problème affecte plusieurs utilisateurs.

• Vérifiez si le problème affecte à la fois le portail Azure et l’automatisation ou les opérations basées sur l’API.

• Vérifiez si les données de la liste de surveillance sont toujours interrogeables à partir de Logs :

  _GetWatchlistAlias
  

  Si vous connaissez l’alias de la liste de surveillance, testez également :

  _GetWatchlist('watchlist-alias')
  | take 10
  

• Vérifiez Azure Service Health ainsi que les communications relatives aux incidents en cours afin d’identifier tout impact lié à Microsoft Sentinel.

• Évitez les tentatives répétées de suppression et de recréation pendant que l’incident est actif. Un portail ou une défaillance d’API n’indique pas nécessairement la perte de données de la liste de surveillance.

• Traitez un portail vide ou des opérations de création, lecture, mise à jour et suppression (CRUD) sur une liste de surveillance qui renvoient 502 ou d’autres erreurs 5XX pour plusieurs utilisateurs ou espaces de travail comme un incident de service potentiel tant que vous n’avez pas exclu un impact plus large sur la plateforme.

• Si un flux de travail Logic Apps qui appelle des opérations de liste de surveillance commence à renvoyer 502 Bad Gateway ou des échecs temporaires similaires, vérifiez l’état du service Microsoft Sentinel avant de supposer que le problème est causé par les autorisations du connecteur ou la configuration du flux de travail. Les échecs d’automatisation peuvent apparaître comme des erreurs d’accès ou de passerelle génériques lors d’un incident de service watchlist, même lorsque l’identité et la configuration du flux de travail ne sont pas modifiées.

Lors d’un incident de service, la première validation la plus sûre consiste à confirmer si les watchlists sont toujours interrogeables. Si l’accès aux requêtes échoue également, capturez l’horodatage, l’opération et le code d’état HTTP avant d’ouvrir une demande de support.

Comprendre le comportement de rétention et d’actualisation

La valeur de rétention de 28 jours ne signifie pas qu’une liste de surveillance devient inutilisable après 28 jours.

Les listes de surveillance restent disponibles jusqu’à ce que vous les supprimiez. La valeur de rétention s’applique aux enregistrements de la table Log Analytics watchlist sous-jacente, tandis que le service watchlist actualise les données de la liste de surveillance à intervalle périodique. Étant donné que la liste de surveillance est actualisée régulièrement, elle reste interrogeable au fil du temps, sauf si vous la supprimez ou un autre problème affecte la disponibilité.

Cette distinction est importante lorsque vous planifiez des analyses à long terme ou vérifiez si une liste de surveillance doit toujours apparaître dans les résultats de la requête.

Résoudre les problèmes de listes de surveillance qui n’affichent aucune ligne après leur création

Si une liste de surveillance est créée avec succès, mais que le portail ou _GetWatchlist() ne retourne aucune ligne, passez en revue les contraintes d’ingestion de l’espace de travail dans le cadre de la résolution des problèmes.

• Vérifiez que la liste de surveillance a été créée dans l’espace de travail attendu.

• Interrogez la liste de surveillance par alias :

  _GetWatchlist('watchlist-alias')
  | take 10
  

• Passez en revue la configuration de l’espace de travail Log Analytics pour connaître les limites d’ingestion, y compris la limite quotidienne.

• Si l’espace de travail a atteint sa limite quotidienne, autorisez l’ingestion à reprendre, puis validez à nouveau la liste de surveillance.

Un résultat de ligne nulle n’indique pas toujours que la définition de la liste de surveillance est manquante. Les limites d’espace de travail associées à l’ingestion peuvent affecter le moment où les données watchlist sont visibles dans l’espace de travail.

Résolution des problèmes de divergence entre le comportement du plan de gestion et celui des requêtes

L’accès aux requêtes et l’accès à la gestion peuvent se comporter différemment lors d’un problème de service temporaire.

Dans certains cas, vous pouvez toujours interroger des watchlists avec _GetWatchlistAlias ou _GetWatchlist() même lorsque l’expérience du portail, les opérations de modification ou d’autres actions de plan de gestion sont temporairement indisponibles. Si les résultats de la requête sont retournés, mais que le portail est vide ou que les mises à jour de watchlist échouent, validez l’intégrité du service avant de supposer que la watchlist a été supprimée ou que son schéma a été modifié.

Une requête KQL réussie indique que les données de la liste de surveillance peuvent toujours être disponibles dans l’espace de travail même si l’expérience de gestion est détériorée.

Résoudre les problèmes liés aux résultats de requête vides ou partiels

Important

Les résultats de la requête watchlist peuvent être affectés par l’intervalle de temps de requête et par les filtres appliqués dans la requête environnante.

Les listes de surveillance sont actualisées à intervalles réguliers, et les fonctions de requête renvoient l’état actuel des listes de surveillance à partir des données sous-jacentes des listes de surveillance. Si vous appliquez une plage globale de dates et d’heures trop étroite ou d’autres filtres restrictifs lors du dépannage, la requête peut exclure des enregistrements nécessaires pour renvoyer le contenu attendu de la liste de surveillance. Dans ce cas, _GetWatchlist() peut sembler renvoyer des résultats vides ou partiels, même si la liste de surveillance existe toujours.

Lorsque vous résolvez les problèmes de résultats vides inattendus :

• Vérifiez que vous interrogez le bon alias de liste de surveillance.
• Supprimez ou élargissez l’étendue de temps au niveau de la requête.
• Réexécutez la requête et comparez les résultats.

Pour les scénarios qui dépendent de l’étendue datetime au niveau de la requête, utilisez un intervalle de temps suffisamment large pour inclure le cycle d’actualisation de la liste de surveillance.

Contenu connexe

• Créer des watchlists dans Microsoft Sentinel
• Gérer les watchlists dans Microsoft Sentinel