Enchaînement de règles

Remarque :Cette fonctionnalité est couverte par les Conditions des offres avant disponibilité générale des conditions spécifiques du service Google Security Operations. Les fonctionnalités pré-DG (avant disponibilité générale) sont susceptibles de présenter une compatibilité limitée, et les modifications apportées à ces fonctionnalités peuvent ne pas être compatibles avec d'autres versions avant disponibilité générale. Pour en savoir plus, consultez les Consignes relatives au service d'assistance technique Google Security Operations et les Conditions spécifiques du service Google Security Operations.

Compatible avec:

Google SecOps SIEM

La chaîne de règles 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. La chaîne de règles surmonte les limites de la détection d'événements isolés en corrélant et en analysant les événements dans différentes sources de données et périodes.

Avantages de la création de chaînes de règles:

• Démasquer les attaques multi-étapes: les cyberattaques sont souvent interconnectées. La chaîne de règles permet de découvrir le récit de l'attaque en montrant les liens entre les incidents apparemment isolés. Par exemple, la chaîne de règles peut identifier l'ensemble de la séquence d'attaque, comme une violation initiale suivie d'une escalade des droits d'accès et d'une exfiltration de données.

• Taming Alert Fatigue (Maîtriser 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 consommation. Ces règles consolident et filtrent les alertes bruyantes générées par les règles de producteur, ce qui permet d'obtenir une réponse plus ciblée.

• Améliorer la précision de la détection: combinez les insights issus des événements UDM, d'autres détections de règles, d'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.

• Simplifier 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 à l'enchaînement de règles:

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

• Chaîne: série de règles où la sortie d'une règle sert d'entrée pour la règle suivante. Par exemple, dans la chaîne rule1 -> rule2 -> rule3, les détections générées par rule1 sont utilisées par rule2 pour générer de nouvelles détections, qui sont ensuite utilisées par rule3 pour générer son propre ensemble de détections.

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

• Règle de consommation: règle qui utilise des détections comme entrée dans le texte de la règle. Les règles pour les consommateurs doivent comporter une section de correspondance.

• Règle de chaînage: également appelée règle de consommation.

Concepts avancés

Règles de détection d'un seul événement

Google SecOps n'autorise pas les règles de détection d'événement unique. Cela signifie que toute règle qui utilise des détections comme source de données doit comporter une section de correspondance.

Latence de détection

Nous vous recommandons de ne lier des règles de consommateur qu'à des règles d'événement unique en raison de problèmes de planification. Les règles d'événement unique s'exécutent en quasi-temps réel. Les détections de ces règles sont donc presque toujours disponibles pour la première exécution d'une règle de consommation. Si vous créez une chaîne de règles à l'aide d'une règle multi-événements, il est possible que la règle du producteur s'exécute après la règle du consommateur, ce qui retarde la génération de détections dans la règle du consommateur.

TestRule et Retrohunt

Tester ou exécuter une recherche rétroactive sur une règle de consommation n'exécute que la règle spécifique que vous avez sélectionnée à l'aide des détections existantes. Pour exécuter une chaîne complète, vous devez démarrer les recherches RetroHunt au début de la chaîne et attendre la fin de chaque exécution avant d'exécuter la règle suivante.

L'exécution d'un test sur une règle ne persiste pas ni n'écrit les détections dans la base de données. Les règles de consommation exigent que les détections d'entrée existent dans la base de données. Par conséquent, vous ne pouvez pas tester une chaîne de règles dans une règle de test.

Créer des chaînes de règles

Vous créez des chaînes de règles à l'aide de combinaisons de règles de producteur et de règles de consommateur.

Règles pour les producteurs

Les règles de producteur constituent la base de votre chaîne. Ils identifient des événements ou des conditions spécifiques qui, combinés, indiquent une activité malveillante. Pour configurer la règle du producteur, procédez comme suit:

1. Créer une règle ou réutiliser une règle existante

2. Désactivez les alertes et définissez $risk_score sur 0 dans la section "Résultat". Cela empêche ces règles de générer des alertes individuelles ou d'affecter les scores de risque des entités. Cette configuration vous permet de hiérarchiser les alertes les plus critiques générées par les règles de consommation, 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 de chaînage.

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:
   $risk_score = 0
   $target_user = $e.target.user.userid

  condition:
    $e
}

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

Règles de chaînage

Écrire une règle qui utilise des détections est à peu près identique à une règle qui utilise 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 des 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 chaîne de règles vous permet de créer un système de détection hiérarchique. Les règles de producteur de niveau inférieur identifient les événements suspects individuels. Leur sortie est ensuite transmise à des règles de consommation ou de chaînage de niveau supérieur. Ces règles mettent en corrélation ces informations avec les données d'autres sources pour détecter les modèles d'attaques à plusieurs étapes que les règles d'événement unique pourraient manquer. Google Security Operations prend en charge jusqu'à trois niveaux de chaînage, ce qui offre un équilibre entre la sophistication de la détection et la complexité gérable.

Exemple :

• Niveau 1: les règles du producteur détectent des événements suspects individuels. Par exemple, une connexion échouée ou un accès aux fichiers inhabituel.

• Niveau 2: les règles de chaînage mettent en corrélation les détections de niveau 1. Par exemple, une tentative de connexion ayant échoué suivie d'un accès suspect aux fichiers.

• Niveau 3: les règles de chaînage 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 lorsque vous modifiez des règles de producteur

Lorsqu'une règle de producteur est mise à jour dans une chaîne de règles, une nouvelle version de la règle de producteur est créée. Cela s'applique aux mises à jour de la logique (condition, événements, résultats) et aux mises à jour des métadonnées (nom, description, gravité). Les règles pour les consommateurs continuent de fonctionner avec la nouvelle version. Il est important de tester les règles de producteur mises à jour et leurs règles de consommateur en aval pour vous assurer du comportement souhaité.