Créer des règles de détection composites

Compatible avec :

Ce document fournit un guide technique sur la création d'une règle composite dans la plate-forme Google Security Operations. Ce processus implique de connecter plusieurs règles YARA-L 2.0 pour identifier des schémas d'attaque complexes. Les détections composites sont structurées comme des règles multi-événements, tout en conservant la même syntaxe fondamentale que les règles à événement unique standards. Pour en savoir plus, consultez la présentation des détections composites.

Comprendre la structure des règles

Les règles de détection composites sont toujours des règles multi-événements et suivent la même structure et la même syntaxe qu'une règle à événement unique.

Une règle composite comporte les composants essentiels suivants :

  • Section events : définit vos entrées, c'est-à-dire les détections ou les événements spécifiques que la règle analyse.

  • Section match : spécifie comment les entrées doivent être connectées sur une période définie.

  • Section condition : contient la logique finale qui détermine si les événements joints répondent aux critères permettant de déclencher une alerte.

Définir les entrées dans la section events

La première étape de la création d'une règle de détection composite consiste à définir les entrées de la règle dans la section events. Les entrées des règles composites proviennent de collections, qui stockent les détections générées par d'autres requêtes. Google SecOps propose les deux méthodes suivantes pour accéder aux données des collections.

Faire référence au contenu de détection avec des variables ou des métabalises

Pour accéder aux données d'une détection sans faire référence aux événements UDM d'origine, vous pouvez utiliser des variables outcome, des variables match ou des balises meta. Nous vous recommandons cette approche, car elle offre une plus grande flexibilité et une meilleure compatibilité entre les différents types de règles.

Par exemple, plusieurs règles peuvent stocker une chaîne (telle qu'une URL, un nom de fichier ou une clé de registre) dans une variable outcome commune si vous recherchez cette chaîne dans différents contextes. Pour accéder à cette chaîne à partir d'une règle composite, commencez par detection et recherchez les informations pertinentes à l'aide d'éléments de la ressource Collection.

Exemple : Supposons qu'une règle de détection génère les informations suivantes :

  • Variable de résultat : dest_domain = "cymbal.com"

  • Champ UDM : target.hostname = "cymbal.com"

Dans la règle composite, vous pouvez accéder à ces données à l'aide des chemins suivants :

  • detection.detection.variables["dest_domain"].string_val pour accéder à la variable de résultat dest_domain.

  • detection.collection_elements.references.event.target.hostname pour accéder au champ UDM target.hostname.

  • detection.time_window.start_time.seconds pour accéder à l'horodatage de début de la détection.

L'API Collection et l'API SecurityResult permettent d'accéder aux deux éléments suivants :

  • Métadonnées de détection et valeurs de résultat (detection.detection)
  • Événements UDM sous-jacents provenant des règles référencées (collection_elements)

Faire référence au contenu de détection avec un ID ou un nom de règle

Vous pouvez faire référence à une règle par son nom ou son ID. Nous vous recommandons cette approche lorsque votre logique de détection dépend de règles spécifiques et que vous souhaitez réduire les données analysées aux seuls résultats de ces règles. Faire référence aux règles pertinentes par leur nom ou leur ID améliore les performances et évite les délais d'attente en réduisant les données analysées. Par exemple, vous pouvez interroger directement des champs tels que target.url ou principal.ip à partir d'une détection précédente connue.

  • Faire référence à une règle par son ID (recommandé) : utilisez le champ detection.detection.rule_id pour faire référence à une règle par son ID. Vous trouverez l'ID de la règle dans son URL dans Google SecOps. Les règles générées par l'utilisateur ont des ID au format ru_UUID, tandis que les détections organisées ont des ID au format ur_UUID. Exemple :

    detection.detection.rule_id = "ru_e0d3f371-6832-4d20-b0ad-1f4e234acb2b"

  • Faire référence à une règle par son nom : utilisez le champ detection.detection.rule_name pour faire référence à une règle par son nom. Vous pouvez spécifier le nom exact de la règle ou utiliser une expression régulière pour le faire correspondre. Exemple :

    • detection.detection.rule_name = "My Rule Name"
    • detection.detection.rule_name = "/PartOfName/"

Joindre des entrées dans la section match

Pour connecter des détections, des événements ou des entités associés dans une règle composite, définissez la section match à l'aide de variables définies dans la section events. Ces variables peuvent inclure des libellés de règles, des variables de résultat, des variables de correspondance, des champs de détection ou des éléments de collection.

Pour en savoir plus sur la syntaxe, consultez la section Syntaxe de la section "Match".

Règles composites : intervalles de temps et fenêtres de saut

Les règles composites font correspondre les détections et les événements à un intervalle de temps plutôt qu'à un point unique dans le temps. Elles correspondent à une fenêtre de saut composite si la fenêtre de temps de détection d'entrée chevauche cette fenêtre de saut (par exemple, si l'activité était active pendant cette période).

Une seule détection peut déclencher plusieurs alertes si elle s'étend sur la limite entre des fenêtres de saut adjacentes (en raison des retards de pipeline, ces correspondances historiques apparaissent plus tard). Plus précisément, une fenêtre de saut de règle composite déclenche une correspondance si la fenêtre de temps de détection d'entrée (WindowStart à WindowEnd) chevauche la fenêtre de saut.

Exemple :

  1. Une règle composite comporte des fenêtres de saut de 60 minutes : Saut 1 (18h58 - 19h58) et Saut 2 (19h58 - 20h58).
  2. Une détection de producteur en amont a une fenêtre de 19h57:54 à 20h56:54 (durée de 59 minutes).
  3. Étant donné que la fenêtre du producteur a commencé à 19h57:54 (6 secondes avant la fin du saut 1) et s'est terminée à 20h56:54 (pendant le saut 2), elle chevauche les deux fenêtres de saut.
  4. Cela déclenche deux détections composites (une pour le saut 1 et une pour le saut 2), ce qui permet d'éviter les faux négatifs. Si la règle du producteur ne correspond pas au chevauchement, la détection qui se chevauche partiellement n'est pas prise en compte pour le saut 1 ni pour le saut 2, et la corrélation entre la détection et les autres événements est manquée.

Pour en savoir plus et obtenir des exemples sur la façon de spécifier des fenêtres de saut, consultez la section Fenêtres de saut.

Définir la section condition

Définissez la section condition pour évaluer les résultats de la section match. Si la condition est true, une alerte est générée. Pour en savoir plus sur la syntaxe, consultez la section Syntaxe de la section "Condition".

Appliquer des techniques avancées aux règles composites

Cette section explique comment appliquer des techniques avancées lors de la création de règles composites.

Combiner des événements et des détections

Les règles composites peuvent combiner plusieurs sources de données, y compris des événements UDM, des données de graphique d'entités et des champs de détection. Les consignes suivantes s'appliquent :

  • Utiliser des variables distinctes par source : attribuez des variables d'événement uniques à chaque source de données (par exemple, $e pour les événements, $d pour les détections), où la source de données inclut des événements, des entités et des détections.

  • Joindre des sources sur un contexte partagé : connectez des sources de données à l'aide de valeurs communes, telles que des ID utilisateur, des adresses IP ou des noms de domaine dans les conditions de votre règle.

  • Définir une fenêtre de correspondance : incluez toujours une clause match avec une fenêtre de temps ne dépassant pas 48 heures.

Exemple : combiner des événements et des détections

rule CheckCuratedDetection_with_EDR_and_EG {
  meta:
    author = "noone@cymbal.com"
  events:
    $d.detection.detection.rule_name = /SCC: Custom Modules: Configurable Bad Domain/
    $d.detection.collection_elements.references.event.network.dns.questions.name = $domain
    $d.detection.collection_elements.references.event.principal.asset.hostname = $hostname

    $e.metadata.log_type = "LIMACHARLIE_EDR"
    $e.metadata.product_event_type = "NETWORK_CONNECTIONS"
    $domain = re.capture($e.principal.process.command_line, "\\s([a-zA-Z0-9.-]+\\.[a-zA-Z0-9.-]+)$")
    $hostname = re.capture($e.principal.hostname, "([^.]*)")

    $prevalence.graph.metadata.entity_type = "DOMAIN_NAME"
    $prevalence.graph.metadata.source_type = "DERIVED_CONTEXT"
    $prevalence.graph.entity.hostname = $domain
    $prevalence.graph.entity.domain.prevalence.day_count = 10
    $prevalence.graph.entity.domain.prevalence.rolling_max <= 5
    $prevalence.graph.entity.domain.prevalence.rolling_max > 0

  match:
    $hostname over 1h

  outcome:
    $risk_score = 80
    $CL_target = array($domain)

  condition:
    $e and $d and $prevalence
}

Créer des détections composites séquentielles

Les détections composites séquentielles identifient des schémas d'événements associés où la séquence de détections est importante, comme une détection de tentative de connexion par force brute, suivie d'une connexion réussie. Ces schémas peuvent combiner plusieurs détections de base, des événements UDM bruts ou les deux.

Pour créer une détection composite séquentielle, vous devez appliquer cet ordre dans votre règle. Pour appliquer la séquence attendue, utilisez l'une des méthodes suivantes :

  • Fenêtres glissantes : définissez la séquence de détections à l'aide de fenêtres glissantes dans vos conditions match.

  • Comparaisons d'horodatages : comparez les horodatages des détections dans la logique de votre règle pour vérifier qu'elles se produisent dans l'ordre sélectionné.

Exemple : détections composites séquentielles

events:
    $d1.detection.detection.rule_name = "fileEvent_rule"
    $userid = $d1.detection.detection.variables["user"].string_val
    $hostname = $d1.detection.detection.variables["hostname"].string_val

    $d2.detection.detection.rule_name = "processExecution_rule"
    $userid = $d2.detection.detection.variables["user"].string_val
    $hostname = $d2.detection.detection.variables["hostname"].string_val

    $d3.detection.detection.rule_name = "networkEvent_rule"
    $userid = $d3.detection.detection.variables["user"].string_val
    $hostname = $d3.detection.detection.variables["hostname"].string_val

$d3.detection.collection_elements.references.event.metadata.event_timestamp.seconds > $d2.detection.collection_elements.references.event.metadata.event_timestamp.seconds

  match:
    $userid over 24h after $d1

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