Optimiser les performances des règles

Compatible avec :

Ce document explique comment optimiser les performances de détection et de création de rapports.

Latence totale de détection

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 à 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 sur 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 contributifs :

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

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

  • Surveillez l'état de la source des journaux et optimisez les configurations du collecteur ou du transmetteur.
  • Pour surveiller le delta, dans YARA-L ou Data Lake, comparez les codes temporels UDM : metadata.ingested_timestamp et metadata.event_timestamp.

Latence de traitement des règles (ingestion des données à 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 votre règle YARA-L.

Facteurs contributifs :

  • Fréquence d'exécution des règles : temps quasi réel (latence la plus faible), 10 minutes, 1 heure ou match_window / 10 (pour les fenêtres de correspondance supérieures à 48 heures). Pour en savoir plus, consultez Comprendre la planification de l'exécution des règles.
  • Type et complexité des règles : les règles multi-événements nécessitent une fenêtre de correspondance pour être entièrement traitées, 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 retards. 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 lorsque cela est possible.
  • Pour les règles multi-événements, définissez la plus petite taille de fenêtre possible.

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

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

La règle YARA-L suivante identifie les cas où le delta entre le moment où un journal a été ingéré et le moment où la détection a été créée dépasse un seuil spécifique. Utilisez la règle pour identifier les goulots d'étranglement dans 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 (moment où l'activité s'est produite) à metadata.ingested_time (moment où Google SecOps a reçu le journal). 

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 cas (création de la détection à 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 des cas 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 d'accusé de réception (MTTA) suit 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 cas, optimisez le routage, l'ajustement et l'automatisation des alertes (par exemple, à l'aide de playbooks pour l'attribution automatique ou l'enrichissement) afin de passer rapidement l'alerte à l'étape de tri.

Étape suivante

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

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