Partage via

Normalisation au moment de l’ingestion

  • Article

Analyse au moment de la requête

Comme expliqué dans la vue d’ensemble d’ASIM, Microsoft Sentinel utilise la normalisation à la fois au moment de la requête et au moment de l’ingestion pour tirer parti des avantages de chacune de ces opérations.

Pour utiliser la normalisation au moment de la requête, utilisez les analyseurs d’unification au moment de la requête, comme _Im_Dns dans vos requêtes. La normalisation à l’aide de l’analyse au moment de la requête présente plusieurs avantages :

  • Conservation du format d’origine : la normalisation au moment de la requête ne nécessite pas de modification des données, ce qui permet de conserver le format de données d’origine envoyé par la source.
  • Prévention du stockage en double potentiel : étant donné que les données normalisées ne sont qu’une vue des données d’origine, il n’est pas nécessaire de stocker à la fois les données d’origine et les données normalisées.
  • Développement facilité : étant donné que les analyseurs au moment de la requête présentent une vue des données sans les modifier, ils sont faciles à développer. Le développement, le test et la correction d’un analyseur peuvent tous être effectués sur des données existantes. En outre, les analyseurs peuvent être corrigés lorsqu’un problème est détecté, et le correctif s’applique aux données existantes.

Analyse au moment de l’ingestion

Alors que les analyseurs ASIM au moment de la requête sont optimisés, l’analyse au moment de la requête peut ralentir les requêtes, en particulier sur les jeux de données volumineux.

L’analyse au moment de l’ingestion permet de transformer les événements en un schéma normalisé au moment où ils sont ingérés dans Microsoft Sentinel, et de les stocker dans un format normalisé. L’analyse au moment de l’ingestion est moins flexible et les analyseurs sont plus difficiles à développer, mais comme les données sont stockées dans un format normalisé, elle offre de meilleures performances.

Les données normalisées peuvent être stockées dans des tables normalisées natives de Microsoft Sentinel, ou dans une table personnalisée qui utilise un schéma ASIM. Une table personnalisée qui a un schéma proche d’un schéma ASIM, mais pas identique, offre également les avantages de la normalisation au moment de l’ingestion en termes de performances.

Actuellement, ASIM prend en charge les tables normalisées natives suivantes comme destination de la normalisation au moment de l’ingestion :

L’avantage des tables normalisées natives est qu’elles sont incluses par défaut dans les analyseurs d’unification ASIM. Les tables normalisées personnalisées peuvent être incluses dans les analyseurs d’unification, comme indiqué dans Gérer les analyseurs.

Combinaison de la normalisation au moment de l’ingestion et de la normalisation au moment de la requête

Les requêtes doivent toujours utiliser les analyseurs d’unification au moment de la requête, comme _Im_Dns, pour tirer parti de la normalisation à la fois au moment de la requête et au moment de l’ingestion. Les tables normalisées natives sont incluses dans les données interrogées à l’aide d’un analyseur stub.

L’analyseur stub est un analyseur au moment de la requête qui utilise comme entrée la table normalisée. Étant donné que la table normalisée ne nécessite pas d’analyse, l’analyseur stub est efficace.

Le parseur de stub présente une vue à la requête appelante qui s'ajoute à la table native ASIM :

  • Alias : pour ne pas gaspiller du stockage en cas de valeurs répétées, les alias ne sont pas stockés dans les tables natives ASIM et sont ajoutés au moment de la requête par les analyseurs stub.
  • Valeurs constantes : comme les alias, et pour la même raison, les tables normalisées ASIM ne stockent pas non plus de valeurs constantes comme EventSchema. L’analyseur stub ajoute ces champs. La table normalisée ASIM est partagée par de nombreuses sources, et les analyseurs au moment de l’ingestion peuvent changer leur version de sortie. Par conséquent, les champs comme EventProduct, EventVendor et EventSchemaVersion ne sont pas constants et ne sont pas ajoutés par l’analyseur stub.
  • Filtrage : l’analyseur stub implémente également le filtrage. Alors que les tables natives ASIM n’ont pas besoin de filtrer les analyseurs pour obtenir de meilleures performances, le filtrage est nécessaire pour prendre en charge l’inclusion dans l’analyseur d’unification.
  • Mises à jour et correctifs : l’utilisation d’un analyseur stub permet de résoudre plus rapidement les problèmes. Par exemple, si les données ont été ingérées de manière incorrecte, une adresse IP n’a peut-être pas été extraite du champ de message pendant l’ingestion. L’adresse IP peut être extraite par l’analyseur stub au moment de la requête.

Lorsque vous utilisez des tables normalisées personnalisées, créez votre propre analyseur stub pour implémenter cette fonctionnalité, et ajoutez-le aux analyseurs d’unification, comme décrit dans Gérer les analyseurs. Comme point de départ, utilisez l’analyseur stub pour la table native, par exemple l’analyseur stub de table native DNS et son équivalent de filtrage. Si votre table est semi-normalisée, utilisez l’analyseur stub pour effectuer l’analyse et la normalisation supplémentaires nécessaires.

Découvrez-en plus sur l’écriture d’analyseurs dans Développement d’analyseurs ASIM.

Implémentation de la normalisation au moment de l’ingestion

Pour normaliser des données au moment de l’ingestion, vous devez utiliser une règle de collecte de données (DCR). La procédure d’implémentation de la règle DCR dépend de la méthode utilisée pour ingérer les données. Pour plus d’informations, reportez-vous à l’article Transformer ou personnaliser les données au moment de l’ingestion dans Microsoft Sentinel.

Une requête de transformation KQL est la base d’une règle DCR. La version KQL utilisée dans les règles de collecte de données (DCR) est légèrement différente de la version utilisée ailleurs dans Microsoft Sentinel pour répondre aux exigences du traitement des événements de pipeline. Par conséquent, vous devez modifier tout analyseur au moment de la requête pour l’utiliser dans une règle DCR. Pour plus d’informations sur les différences et sur la façon de convertir un analyseur au moment de la requête en analyseur au moment de l’ingestion, consultez les limitations KQL des règles de collecte de données (DCR).

Étapes suivantes

Pour plus d'informations, consultez les pages suivantes :