Normalisation du temps d’ingestion

Analyse de l’heure de la requête

Dans la vue d’ensemble d’ASIM, Microsoft Sentinel utilise à la fois le temps de requête et la normalisation du temps d’ingestion pour tirer parti des avantages de chacun d’eux.

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

  • Conservation du format d’origine : la normalisation de l’heure 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.
  • Éviter le 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 les données d’origine et normalisées.
  • Développement plus facile : étant donné que les analyseurs de temps de requête présentent une vue des données et ne modifient pas les données, 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 résolus lorsqu’un problème est détecté et que le correctif est appliqué aux données existantes.

Analyse du temps d’ingestion

Bien que les analyseurs de temps de requête ASIM soient optimisés, l’analyse du temps de requête peut ralentir les requêtes, en particulier sur les jeux de données volumineux.

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

Les données normalisées peuvent être stockées dans les 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 qui n’est pas identique, offre également les avantages en termes de performances de la normalisation du temps d’ingestion.

Actuellement, ASIM prend en charge les tables normalisées natives suivantes comme destination pour la normalisation de l’heure d’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 l’heure d’ingestion et de la normalisation du temps de requête

Les requêtes doivent toujours utiliser les analyseurs d’unification de l’heure de requête, par exemple _Im_Dns pour tirer parti de la normalisation du temps de requête et de l’heure d’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 de temps de 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.

L’analyseur stub présente une vue de la requête appelante qui ajoute à la table native ASIM :

  • Alias : afin de ne pas gaspiller le stockage sur des 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 telles que EventSchema. L’analyseur stub ajoute ces champs. La table normalisée ASIM est partagée par de nombreuses sources, et les analyseurs de temps d’ingestion peuvent modifier leur version de sortie. Par conséquent, les champs tels que 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. Bien que les tables natives ASIM n’ont pas besoin d’analyseurs de filtrage 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 les problèmes plus rapidement. 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 indiqué dans Gérer les analyseurs. Utilisez l’analyseur stub pour la table native, comme l’analyseur de stub de table native DNS et son équivalent de filtrage, comme point de départ. Si votre table est semi-normalisée, utilisez l’analyseur stub pour effectuer l’analyse et la normalisation supplémentaires nécessaires.

En savoir plus sur l’écriture d’analyseurs dans Développement d’analyseurs ASIM.

Implémentation de la normalisation du temps d’ingestion

Pour normaliser les 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 DCR dépend de la méthode utilisée pour ingérer les données. Pour plus d’informations, consultez l’article Transformer ou personnaliser des données au moment de l’ingestion dans Microsoft Sentinel.

Une requête de transformation KQL est le cœur d’une DCR. La version KQL utilisée dans les DCR est légèrement différente de la version utilisée ailleurs dans Microsoft Sentinel pour prendre en charge les exigences du traitement des événements de pipeline. Par conséquent, vous devez modifier n’importe quel analyseur au moment de la requête pour l’utiliser dans une DCR. Pour plus d’informations sur les différences et sur la conversion d’un analyseur au moment de la requête en analyseur au moment de l’ingestion, consultez les limitations de DCR KQL.

Prochaines étapes

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

  • Last updated on