Partager via

Gestion du délai d’ingestion dans les règles d’analytique planifiée

  • Article

Microsoft Sentinel peut ingérer des données provenant de différentes sources, mais le temps d’ingestion de chacune peut varier selon les circonstances.

Cet article explique quel impact peut avoir le délai d’ingestion sur les règles d’analytique planifiée et comment les corriger pour combler ces écarts.

Importance du délai

Supposons par exemple que vous écriviez une règle de détection personnalisée, en définissant les champs Exécuter la requête toutes les et Rechercher les données des dernières de sorte qu’elle s’exécute toutes les cinq minutes et recherche les données des cinq dernières minutes :

Capture d’écran montrant la fenêtre Assistant règle d’analytique – Créer une règle.

Le champ Rechercher les données des dernières définit un paramètre appelé période de « rétrospection » . Dans l’idéal, lorsqu’il n’y a aucun délai, cette détection ne manque aucun événement, comme le montre le diagramme suivant :

Diagramme montrant une fenêtre de rétrospection de cinq minutes.

L’événement arrive dès qu’il est généré. Il est inclus dans la période de rétrospection.

Maintenant, supposons qu’il existe un certain délai pour votre source de données, par exemple que l’événement a été ingéré deux minutes après sa génération. Le délai est donc de deux minutes :

Diagramme montrant des fenêtres de rétrospection de cinq minutes avec un délai de deux minutes.

L’événement est généré au cours de la première période de rétrospection, mais n’est pas ingéré dans votre espace de travail Microsoft Sentinel à la première exécution. Lors de son exécution suivante, la requête planifiée ingère l’événement. Cependant, le filtre de l’heure de génération le supprime, car il s’est produit il y a plus de cinq minutes. Dans ce cas, la règle ne déclenche pas d’alerte.

Gestion du délai

Notes

Vous pouvez résoudre le problème en suivant la procédure décrite ci-dessous ou en implémentant les règles de détection en quasi-temps réel (NRT) de Microsoft Sentinel. Pour plus d’informations, consultez Détecter rapidement les menaces avec des règles d’analyse en quasi-temps réel dans Microsoft Sentinel.

Pour résoudre le problème, vous devez connaître le délai de votre type de données. Dans cet exemple, vous savez déjà qu’il est de deux minutes.

Dans le cas de vos propres données, vous pouvez déterminer le délai en utilisant la fonction Kusto ingestion_time() et en calculant la différence entre TimeGenerated et l’heure d’ingestion. Pour plus d’informations, consultez Calcul du délai d’ingestion.

Une fois que vous avez déterminé le délai, vous pouvez résoudre le problème comme suit :

  • Augmentez la période de rétrospection. L’intuition de base vous indique qu’une augmentation de la taille de la période de rétrospection est utile. Étant donné que votre période de rétrospection est de cinq minutes et votre délai de deux minutes, une période de rétrospection de sept minutes permet de résoudre ce problème. Vous pouvez par exemple la définir ainsi dans vos paramètres de règle :

    Capture d’écran montrant comment définir la fenêtre de rétrospection sur sept minutes.

    Le diagramme suivant illustre la période de rétrospection qui contient maintenant l’événement manqué :

    Diagramme montrant des fenêtres de rétrospection de sept minutes avec un délai de deux minutes.

  • Gérez la duplication. Seule l’augmentation de la période de rétrospection peut créer une duplication, car les fenêtres de rétrospection se chevauchent maintenant. Par exemple, un événement différent peut se présenter comme dans le diagramme suivant :

    Diagramme montrant comment les fenêtres de rétrospection en chevauchement créent une duplication.

    Étant donné que la valeur TimeGenerated de l’événement figure dans les deux périodes de rétrospection, l’événement déclenche deux alertes. Vous devez trouver un moyen de résoudre la duplication.

  • Associez l’événement à une période de rétrospection spécifique. Dans le premier exemple, vous avez manqué des événements, car vos données n’étaient pas ingérées lors de l’exécution de la requête planifiée. Vous avez étendu la période de rétrospection de façon à inclure l’événement, mais cela a provoqué une duplication. Vous devez associer l’événement à la fenêtre que vous avez étendue pour le contenir.

    Pour ce faire, définissez ingestion_time() > ago(5m) la place de la règle d’origine look-back = 5m. Ce paramètre associe l’événement à la première fenêtre de rétrospection. Par exemple :

    Diagramme montrant comment la restriction ago permet d’éviter la duplication.

    La restriction du temps d’ingestion découpe maintenant les deux minutes supplémentaires que vous avez ajoutées à la période de rétrospection. Dans le premier exemple, la deuxième exécution de la période de rétrospection capture maintenant l’événement :

    Diagramme montrant comment la restriction ago permet de capturer l’événement.

L’exemple de requête suivant résume la solution à appliquer pour résoudre les problèmes de délai d’ingestion :

let ingestion_delay = 2min;
let rule_look_back = 5min;
CommonSecurityLog
| where TimeGenerated >= ago(ingestion_delay + rule_look_back)
| where ingestion_time() > ago(rule_look_back)

Calcul du délai d’ingestion

Par défaut, les règles d’alerte planifiées de Microsoft Sentinel sont configurées pour présenter une période de rétrospection de cinq minutes. Toutefois, chaque source de données peut posséder son propre délai d’ingestion. Lorsque vous joignez plusieurs types de données, vous devez connaître le délai de chacun pour configurer correctement la période de rétrospection.

Le Rapport d’utilisation des espaces de travail, fourni prêt à l’emploi dans Microsoft Sentinel, comprend un tableau de bord qui indique la latence et le délai des différents types de données qui transitent dans l’espace de travail.

Par exemple :

Capture d’écran du Rapport d’utilisation des espaces de travail montrant la latence de bout en bout par table.

Étapes suivantes

Pour plus d'informations, consultez les pages suivantes :