Optimiser les performances de détection et de signalement

Compatible avec :

Ce document explique comment optimiser les performances de détection et de reporting.

Latence de détection totale

Pour un centre des opérations de sécurité (SOC), le temps moyen total de détection (MTTD) correspond à la somme des délais dans le pipeline de sécurité. Pour mesurer et réduire précisément le MTTD, vous devez suivre trois composants principaux :

Latence d'ingestion des journaux (création des journaux à l'ingestion des données)

La latence d'ingestion des journaux correspond au temps écoulé entre le moment où l'événement de sécurité s'est produit dans le système source (metadata.event_timestamp) et le moment où le journal a été ingéré et analysé avec succès dans Google Security Operations (metadata.ingested_time).

Facteurs contribuant :

  • Problèmes liés au collecteur ou au transmetteur (par exemple, les files d'attente ou la limitation du réseau).
  • Problèmes d'analyse des sources de journaux (par exemple, retards dans la normalisation UDM).

Pour réduire la latence d'ingestion des journaux, procédez comme suit :

  • Surveillez l'état des sources de journaux et optimisez les configurations des collecteurs ou des transmetteurs.
  • Pour surveiller le delta, comparez les codes temporels UDM dans YARA-L ou Data Lake : metadata.ingested_timestamp par rapport à metadata.event_timestamp.

Latence de traitement des règles (de l'ingestion des données à la création de la détection)

La latence de traitement des règles correspond au temps écoulé entre l'ingestion des données et le moment où le moteur de détection crée une alerte (detection.creation_time). Ce composant est fortement affecté par la configuration de vos règles YARA-L.

Facteurs contributifs :

  • Fréquence d'exécution des règles : quasi en temps réel (recommandé), 10 minutes, 1 heure ou 24 heures. Plus la fréquence est élevée, plus la latence de traitement minimale est élevée. Pour en savoir plus, consultez Définir la fréquence d'exécution.
  • Type et complexité de la règle : les règles multi-événements nécessitent une fenêtre de correspondance pour être traitées entièrement, ce qui impose une latence inhérente. Les règles composites qui s'appuient sur d'autres détections non en temps réel introduisent également des délais. Pour en savoir plus, consultez Détections composites.

Pour réduire la latence de traitement des règles, procédez comme suit :

  • Utilisez des règles à événement unique s'exécutant en temps quasi réel, si possible.
  • Pour les règles multi-événements, définissez la taille de fenêtre la plus petite possible.

Pour en savoir plus, consultez Exemples de requêtes YARA-L 2.0 pour les tableaux de bord.

Règle YARA-L permettant de surveiller la latence de traitement des règles

La règle YARA-L suivante identifie les instances où le delta entre l'heure à laquelle un journal a été ingéré et l'heure à laquelle la détection a été créée dépasse un seuil spécifique. Utilisez la règle pour identifier les goulots d'étranglement qui affectent les performances de votre pipeline de détection.

Déployez cette règle dans votre environnement de test pour établir une référence pour vos sources de journaux.

Vous pouvez exporter ces résultats vers un tableau de bord pour visualiser les tendances de latence pour différents types de journaux.

La règle compare metadata.event_timestamp (date et heure de l'activité) à metadata.ingested_time (date et heure de réception du journal par Google SecOps). 

rule rule_processing_latency_monitor {
  meta:
    author = "SecOps Engineering"
    description = "Alerts when the gap between ingestion and detection creation is greater than 15 minutes."
    severity = "Low"

  events:
    $event.metadata.event_timestamp.seconds = $event_ts
    $event.metadata.ingested_time.seconds = $ingest_ts
    
    // Calculate the delta in seconds
    $latency_delta = $ingest_ts - $event_ts

    // Threshold: 900 seconds (15 minutes)
    $latency_delta > 900

  match:
    $event.metadata.log_type over 1h

  outcome:
    $max_latency = max($latency_delta)
    $log_source = array_distinct($event.metadata.log_type)

  condition:
    $event
}

Latence d'accusé de réception des demandes (de la création de la détection à l'attribution à un analyste)

Cette section ne concerne pas les clients qui utilisent la plate-forme autonome Google SecOps SIEM.

La latence d'accusé de réception d'une alerte correspond au temps écoulé entre la détection qui crée une alerte et l'accusé de réception de l'alerte par un analyste pour le tri dans le composant SOAR.

La métrique temps moyen de reconnaissance (MTTA, Mean Time To Acknowledge) permet de suivre spécifiquement l'efficacité de l'équipe SOC pour répondre à une alerte générée.

  • Pour réduire la latence d'accusé de réception des demandes, optimisez le routage, le réglage et l'automatisation des alertes (par exemple, en utilisant des playbooks pour l'attribution ou l'enrichissement automatiques) afin de passer rapidement à l'étape du triage.

Étapes suivantes

  • Pour savoir comment les relectures de règles (également appelées exécutions de nettoyage) gèrent les données et les mises à jour du contexte qui arrivent tardivement, et comment cela affecte les métriques MTTD, consultez Comprendre les relectures de règles et le MTTD.
  • Pour en savoir plus sur les délais de détection des règles dans Google SecOps, les facteurs qui y contribuent, le dépannage et les techniques permettant de réduire les délais, consultez Comprendre les délais de détection des règles.

Vous avez encore besoin d'aide ? Obtenez des réponses de membres de la communauté et de professionnels Google SecOps.