Détections composites

Compatible avec :

La détection composite vous permet d'interconnecter des règles de sorte que la sortie d'une règle serve d'entrée pour une autre règle. Cette fonctionnalité vous permet de créer des règles plus complexes et flexibles. En corrélant et en analysant les événements dans différentes sources de données et périodes, la détection composite surmonte les limites de la détection d'événements isolés.

Avantages de la détection composite

  • Démasquer les attaques en plusieurs étapes : les cyberattaques sont souvent multifacettes et interconnectées. La détection composite permet de révéler le scénario d'attaque en associant des incidents apparemment isolés. Par exemple, une règle composite peut identifier l'ensemble de la séquence d'attaque, comme une intrusion initiale, suivie d'une élévation des privilèges et d'une exfiltration de données.

  • Réduire la fatigue liée aux alertes : hiérarchisez les menaces critiques et réduisez la fatigue liée aux alertes en implémentant des règles de consommateur. Ces règles regroupent et filtrent les alertes bruyantes générées par les règles d'entrée, ce qui permet d'obtenir une réponse plus ciblée. Vous pouvez ainsi hiérarchiser les incidents à fort impact et minimiser la fatigue liée aux alertes.

  • Améliorer la précision de la détection : combinez les insights provenant des événements UDM, d'autres détections de règles, des informations sur les entités, des résultats UEBA et des tableaux de données pour créer une logique de détection précise.

  • Simplification de la logique complexe : décomposez les scénarios de détection complexes en règles gérables, interconnectées et réutilisables pour simplifier le développement et la maintenance.

Termes et concepts liés à la détection composite

  • Détection : résultat d'une règle, également appelé alerte.

  • Composite : série de règles interconnectées où la sortie d'une règle sert d'entrée pour la suivante. Par exemple, dans la séquence de règles composites rule1 -> rule2 -> rule3, les détections générées par rule1 sont transmises à rule2, qui les traite pour générer de nouvelles détections. rule3 utilise ensuite ces détections pour produire son résultat final.

  • Règle d'entrée : règle dont les détections sont utilisées comme entrée pour une autre règle. N'importe quelle règle peut servir de règle d'entrée. Aucune désignation spécifique n'est requise. Les règles d'entrée utilisent des entités et des événements comme entrée. Elles n'utilisent pas les détections comme entrée.

  • Règle composite : règle qui utilise des détections comme entrée dans le texte de la règle. Les règles composites doivent comporter une section match.

Concepts avancés

Règles de détection à événement unique

Google SecOps n'autorise pas les règles composites à événement unique. Cela signifie que toute règle qui utilise des détections comme source d'entrée doit comporter une section match.

Latence de détection

En raison du comportement de planification, nous vous recommandons de ne composer des règles composites que sur des règles d'entrée à événement unique. Les règles à événement unique s'exécutent quasiment en temps réel. Leurs détections sont donc généralement disponibles au moment où la règle composite s'exécute. Si une règle composite dépend d'une règle multi-événements en tant qu'entrée, il existe un risque que la règle d'entrée s'exécute après l'exécution planifiée de la règle composite. Cela peut entraîner des retards ou des détections manquées dans la règle composite.

TestRule et Retrohunt

Si vous testez ou exécutez une analyse rétroactive sur une règle composite, seule la règle spécifique que vous avez sélectionnée est exécutée à l'aide des détections existantes. Pour exécuter l'ensemble du composite, vous devez démarrer manuellement les analyses rétroactives à partir de la première règle de la séquence, attendre la fin de chaque exécution, puis passer à la règle suivante.

L'exécution d'un test sur une règle ne conserve ni n'écrit les détections dans la base de données. De plus, les règles composites nécessitent que les détections d'entrée existent dans la base de données.

L'exécution d'un test sur une règle ne conserve ni n'écrit les détections dans la base de données. Étant donné que les règles composites nécessitent que les détections d'entrée existent dans la base de données pour fonctionner, vous ne pouvez pas utiliser TestRule pour valider une règle composite.

Créer des règles composites

Vous créez des règles composites en combinant des règles d'entrée et des règles composites.

Règles de saisie

Les règles d'entrée sont la base de votre règle composite. Ils détectent des événements ou des conditions spécifiques qui, combinés, indiquent une activité malveillante. Pour configurer une règle d'entrée :

  1. Créez une règle ou réutilisez-en une existante.

  2. Désactivez les alertes. Cela empêche ces règles d'entrée de générer des alertes individuelles. Cette configuration vous permet de hiérarchiser les alertes les plus critiques générées par les règles composites, qui évaluent l'ensemble de la chaîne d'événements.

  3. Utilisez la section outcome pour définir les variables accessibles aux règles d'enchaînement.

L'exemple de règle de producteur suivant détecte les échecs de connexion.

rule failed_login {
  meta:

  events:
    $e.metadata.event_type = "USER_LOGIN"
    any $e.security_result.action = "BLOCK"

  outcome:
   $target_user = $e.target.user.userid

  condition:
    $e
}

Cette règle identifie les connexions bloquées et fournit l'utilisateur associé.

Règles composites

Écrire une règle qui utilise des détections est presque identique à une règle qui utilise l'UDM, sauf que la source et les champs disponibles sont différents. Pour faire référence à un champ de détection, utilisez le mot clé detection comme source : $eventname.detection.field1.field2.

Les sous-champs disponibles sous la source detection se trouvent dans la ressource de collection.

Voici les champs courants dans les collections :

  • $d.detection.detection.rule_id

  • $d.detection.detection.detection_fields["match_var_name"]

  • $d.detection.detection.outcomes["outcome_name"]

L'exemple de règle suivant détecte les connexions sans MFA, l'énumération et l'exfiltration.

rule login_enumeration_exfiltration {
    meta:
description = "Detects when a user logs in without multifactor authentication (MFA) and then performs enumeration and exfiltration"
        rule_name = "Login Without MFA, Enumeration, Exfiltration"
        severity = "High"

    events:
     // Detection with name "Console Login Without MFA"
        // The affected user is saved as $target_user
        $login_without_mfa.detection.detection.rule_name = /Console Login Without MFA/
        $target_user = $login_without_mfa.detection.detection.outcomes["target_user"]

     // Any detection with a rule name containing 'enumeration'
     // The user performing enumeration is the user that logged in without mfa
        $enumeration.detection.detection.rule_name = /enumeration/ nocase
        $enumeration.detection.detection.outcomes["principal_users"] = $target_user

     // Any detection with the mitre tactic 'TA0010' (Exfiltration)
     // The user performing exfiltration is the user that logged in without mfa
        $exfiltration.detection.detection.rule_labels["tactic"] = "TA0010"
        $exfiltration.detection.detection.outcomes["principal_users"] = $target_user

    match:
     // Looks for detections over a 24 hour period
        $target_user over 24h

    condition:
     // All 3 must occur for a single user
        $login_without_mfa and $enumeration and $exfiltration
}

Détections hiérarchiques

La détection composite vous permet de créer un système de détection hiérarchique. Les règles d'entrée de niveau inférieur identifient les événements suspects isolés. Les règles composites de niveau supérieur consomment ensuite la sortie de ces règles d'entrée pour établir des corrélations dans le temps, entre les entités et entre les sources de données. Cette approche permet de corréler ces informations avec des données provenant d'autres sources afin de détecter des schémas d'attaque en plusieurs étapes que les règles à événement unique pourraient manquer.

Google Security Operations accepte jusqu'à trois niveaux de composition, ce qui permet d'équilibrer la logique de détection approfondie et la complexité gérable.

Exemple :

  • Niveau 1 : les règles d'entrée détectent les événements suspects individuels. Par exemple, les événements de connexion ayant échoué ou les accès inhabituels à des fichiers.

  • Niveau 2 : Les règles composites mettent en corrélation les détections de niveau 1. Par exemple, des événements de connexion ayant échoué suivis d'un accès suspect à des fichiers.

  • Niveau 3 : Les règles composites de niveau supérieur combinent les détections de niveau 2 et d'autres données pour une détection encore plus sophistiquée. Par exemple, une détection de niveau 2 concernant l'authentification et une détection de niveau 2 concernant la posture de sécurité de l'appareil utilisé.

Éléments à prendre en compte lors de la création de règles composites

Lorsque vous mettez à jour une règle d'entrée utilisée dans une ou plusieurs règles composites, le système crée automatiquement une nouvelle version de cette règle d'entrée. Cela s'applique à la fois aux mises à jour de la logique (condition, events, outcomes) et aux mises à jour des métadonnées (nom, description, gravité). Les règles composites continuent de fonctionner avec la nouvelle version. Nous vous recommandons de tester les règles d'entrée mises à jour et leurs règles composites en aval pour vous assurer du comportement souhaité.

Limites

Les règles composites présentent les limites suivantes.

Règles de détection uniquement et score de risque des entités

Les règles de détection uniquement (celles qui n'utilisent que des données de détection comme source, et non des données d'événement ou d'entité) ne contribuent pas au score de risque des entités. Tout score de risque défini pour une règle de détection uniquement s'applique uniquement aux détections créées par cette règle. Elle ne contribuera à aucun score de risque global des entités.

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