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

Important

Les détections personnalisées constituent désormais le meilleur moyen de créer de nouvelles règles dans Microsoft Sentinel Microsoft Defender XDR SIEM. Les détections personnalisées vous permettent de réduire les coûts d’ingestion, d’obtenir des détections en temps réel illimitées et de bénéficier d’une intégration transparente avec Defender XDR données, fonctions et actions de correction avec le mappage automatique d’entités. Pour plus d’informations, consultez Les détections personnalisées constituent désormais l’expérience unifiée pour créer des détections dans Microsoft Defender XDR.

Bien que Microsoft Sentinel puisse ingérer des données provenant de sources de données connectées, le temps d’ingestion pour chaque source de données peut varier selon les circonstances.

Cet article décrit comment le délai d’ingestion peut impacter vos règles d’analyse planifiées et comment vous pouvez les corriger pour combler ces lacunes.

Pourquoi le retard est important

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 :

Les données de recherche du dernier champ définissent un paramètre appelé période de recherche arrière . Dans l’idéal, lorsqu’il n’y a pas de délai, cette détection ne manque aucun événement, comme illustré dans le diagramme suivant :

L’événement est reçu dès qu’il est généré et est inclus dans la période de rétrospection.

À présent, supposons qu’il y ait un certain délai pour votre source de données. Pour cet exemple, supposons que l’événement a été ingéré deux minutes après sa génération. Le délai est de deux minutes :

L’événement est généré au cours de la première période de retour en arrière, mais n’est pas ingéré dans votre espace de travail Microsoft Sentinel lors de la première exécution. La prochaine fois que la requête planifiée s’exécute, elle ingère l’événement, mais le filtre généré dans le temps supprime l’événement, car il s’est produit il y a plus de cinq minutes. Dans ce cas, la règle ne déclenche pas d’alerte.

Comment gérer le délai

Utilisez l’approche suivante pour tenir compte du retard d’ingestion dans les règles d’analytique planifiées.

Remarque

Vous pouvez soit résoudre le problème à l’aide du processus décrit ci-dessous, soit implémenter 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 (NRT) dans Microsoft Sentinel.

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

Pour vos propres données, vous pouvez comprendre le délai à l’aide de la fonction Kusto ingestion_time() et calculer la différence entre TimeGenerated et le temps d’ingestion. Pour plus d’informations, consultez Calculer le délai d’ingestion.

Après avoir déterminé le délai, vous pouvez résoudre le problème comme suit :

• Augmentez la période de rétrospection : Une intuition de base vous dit qu’augmenter la durée de la période de rétrospection aidera. Étant donné que votre période de recherche en arrière est de cinq minutes et que votre délai est de deux minutes, le fait de définir la période de retour sur sept minutes vous aidera à résoudre ce problème. Par exemple, dans vos paramètres de règle :

  

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

  

• * Gérer la duplication : Le seul fait d’augmenter la période de rétrospection peut créer des doublons, car les fenêtres de rétrospection se chevauchent désormais. Par exemple, un autre événement peut se présenter comme indiqué dans le diagramme suivant :

  

  Comme la valeur TimeGenerated de l’événement se trouve dans les deux périodes de rétroaction, 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 retour spécifique : dans le premier exemple, vous avez manqué des événements parce que vos données n’ont pas été absorbées lors de l’exécution de la requête programmé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), au lieu de la règle look-back = 5md’origine . Ce paramètre associe l’événement à la première fenêtre de retour en arrière. Par exemple :

  

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

  

L’exemple de requête suivant résume la solution pour résoudre les problèmes de retard 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)

Voir plus d’informations sur les éléments suivants utilisés dans l’exemple précédent dans la documentation Kusto :

• let instruction
• opérateur où
• ago() , fonction

Calculer le délai d’ingestion

Par défaut, les règles d’alerte programmée de Microsoft Sentinel sont configurées pour une période de rétrospection de cinq minutes. Cependant, chaque source de données peut avoir son propre délai d’ingestion individuel. Lorsque vous joignez plusieurs types de données, vous devez comprendre les différents délais pour chaque type de données afin de configurer correctement la période de recherche en arrière.

Le rapport d’utilisation de l’espace de travail, fourni dans Microsoft Sentinel prête à l’emploi, inclut un tableau de bord qui affiche la latence et les retards pour les différents types de données qui circulent dans votre espace de travail.

Par exemple :

Contenu connexe

• Créez une règle d’analyse planifiée à partir de zéro
• Personnaliser les détails de l’alerte dans Microsoft Sentinel
• Gérez les versions de modèles pour vos règles d’analyse planifiées dans Microsoft Sentinel
• Surveiller l’intégrité de vos connecteurs de données
• Heure d’ingestion des données de journal dans Azure Monitor