Créer des analyses contextuelles

Google Security Operations vous permet d'afficher la télémétrie, le contexte des entités, les relations et les failles de manière unique dans votre compte Google Security Operations. Il fournit une contextualisation des entités pour vous permettre de comprendre à la fois les modèles de comportement dans la télémétrie et le contexte des entités concernées à partir de ces modèles.

Exemples :

• Indiquer les autorisations d'un compte sur lequel une tentative de connexion par force brute est effectuée.
• Importance des données hébergées par un élément qui est également la source de l'activité réseau sortante.

Les clients peuvent utiliser cette contextualisation pour filtrer la détection, hiérarchiser les alertes heuristiques, les trier et effectuer des investigations.

Les analystes en sécurité et les ingénieurs en détection travaillent généralement à l’élaboration d’une détection basée sur un modèle basique de télémétrie des événements (une connexion réseau sortante), ce qui crée de nombreuses détections que leurs analystes doivent trier. Les analystes tentent de rassembler une compréhension de ce qui s’est passé pour déclencher l’alerte et de l’importance de la menace.

L'analyse contextuelle intègre des fonctionnalités d'enrichissement avancées plus tôt dans le workflow de création et d'exécution de détections, ce qui vous permet de fournir les fonctionnalités supplémentaires suivantes:

• Mettre le contexte pertinent à disposition pour une notation heuristique basée sur le contexte des risques des détections au moment de l'exécution de la détection plutôt qu'au stade de tri manuel
• Réduction du temps consacré au tri et au regroupement manuel des informations provenant de systèmes de sécurité IT disparates (consoles EDR, journaux de pare-feu/proxy, contexte CMDB et IAM, résultats d'analyse des failles)
• Permettre aux analystes et aux ingénieurs en détection de filtrer des clusters entiers de menaces qui peuvent être attendues ou présenter peu ou pas de danger pour l'entreprise (tests de logiciels malveillants dans un environnement de bac à sable, vulnérabilités et activités anormales sur un réseau de développement sans données sensibles ni accès, etc.)

Écrire des règles pour l'analyse contextuelle

Vous pouvez utiliser les règles de détection du moteur pour rechercher des données de contexte d'entité dans votre compte Google Security Operations.

Pour rechercher des données de contexte d'entité, procédez comme suit:

1. Spécifiez une source à l'aide de l'udm ou de l'entité.

   $eventname.[<source>].field1.field2 Pour un contexte d'entité, <source> correspond à "graph". Pour un événement UDM, <source> est "udm". Si cette valeur est omise, la valeur par défaut de <source> est udm.

2. Spécifiez les données de l'entité:

   $e1.graph.entity.hostname = "my-hostname"

   $e1.graph.entity.relations.relationship = "OWNS"

3. Spécifiez les données d'événement UDM. Les instructions suivantes sont équivalentes.

   $e1.udm.principal.asset_id = "my_asset_id"

   $e1.principal.asset_id = "my_asset_id"

Vous pouvez créer de nombreux types de règles similaires pour les contextes d'entité que pour les événements UDM, y compris les suivants:

• Règles d'événement multiples

  Remarque :Toutes les règles multi-événements doivent utiliser un événement UDM. Vous pouvez créer une règle qui n'utilise que l'UDM, ou une règle qui utilise à la fois l'UDM et l'entité. Il est impossible de définir une règle qui n'utilise que l'objet Entity.

• Comparer des contextes d'entité à d'autres contextes d'entité

• Comparer des contextes d'entité aux événements UDM

• Champs répétés dans les contextes d'entité

• Fenêtres coulissantes

• Calculer un score de risque pour les détections

  Remarque :Le contexte de l'entité ne peut pas être utilisé comme pivot pour une fenêtre glissante.

Contrairement à un événement UDM, un contexte d'entité n'a pas de code temporel spécifique. Chaque enregistrement de contexte d'entité possède un intervalle de temps, entity.metadata.interval, au cours duquel le contexte d'entité est valide. Cet intervalle de temps ne peut pas être une limite quotidienne et peut avoir n'importe quelle durée.

Un événement UDM n'est corrélé à un enregistrement de contexte d'entité que si l'horodatage de l'événement UDM se situe dans l'intervalle de temps de l'enregistrement de contexte d'entité. Si cette condition n'est pas remplie, l'UDM et l'entité ne sont pas évaluées pour les détections. Le moteur de détection applique implicitement ce comportement, et vous n'avez pas besoin de la spécifier en tant que condition dans une règle.

• Lorsque vous comparez des événements UDM à un contexte d'entité avec fenêtrage, un contexte d'entité représente une valeur constante sur une fenêtre spécifiée.
• S'il existe des buckets de jours adjacents pour lesquels le contexte de l'entité change de valeur, Google Security Operations tente d'établir une correspondance avec toutes les valeurs de contexte d'entité et renvoie toutes les correspondances trouvées.

Exemples de règles

Recherche d'entités dans le contexte d'un administrateur

La règle suivante recherche les entités qui sont également liées à des droits d'administrateur. Cet outil recherche les moments où un utilisateur disposant de droits d'administrateur a tenté de se connecter au système ou de s'en déconnecter.

rule LoginLogout {
  meta:
  events:
    ($log_inout.metadata.event_type = "USER_LOGIN" or  $log_inout.metadata.event_type = "USER_LOGOUT")
    $log_inout.principal.user.user_display_name = $user

    $context.graph.entity.user.user_display_name = $user
    $context.graph.entity.resource.attribute.roles.type = "ADMINISTRATOR"

  match:
    $user over 2m

  condition:
    $log_inout and $context
}

Exemple de fenêtre glissante

L'exemple de fenêtre glissante suivant est valide.

rule Detection {
  meta:
  events:
    $e1.graph.entity.hostname = $host
    $e2.udm.principal.hostname = $host

  match:
    // Using e2 (a UDM event) as a pivot.
    $host over 3h after $e2

  condition:
    $e1 and $e2
}

Exemple de fenêtre glissante non valide

L'exemple de fenêtre glissante suivant n'est pas valide. Le contexte de l'entité ne peut pas être utilisé comme pivot pour une fenêtre glissante.

rule Detection {
  meta:
  events:
    $e1.graph.entity.hostname = $host
    $e2.udm.principal.hostname = $host

  match:
    // Attempting to use $e1 (an entity context) as a pivot. Invalid.
    $host over 3h after $e1

  condition:
    $e1 and $e2
}

Exemple de connexion utilisant la section "Résultats"

L'exemple suivant utilise la section outcome afin de calculer un score de risque pour la détection.

rule Detection {
  meta:
  events:
    $auth.metadata.event_type = "USER_LOGIN"
    $auth.metadata.vendor_name = "Acme"
    $auth.metadata.product_name = "Acme SSO"
    $auth.target.user.userid = $user
    $auth.target.user.termination_date.seconds > 0

    $auth.metadata.event_timestamp.seconds >
       $context.graph.entity.user.termination_date.seconds

    $context.graph.metadata.vendor_name = "Microsoft"
    $context.graph.metadata.product_name = "Azure Active Directory"
    $context.graph.metadata.entity_type = "USER"
    $context.graph.entity.user.userid = $user
    $context.graph.entity.user.termination_date.seconds > 0

  match:
    $user over 15m

  outcome:
    $risk_score = max(
        if ( $auth.metadata.event_type = "USER_LOGIN", 50) +
        if (
            $context.graph.entity.user.title = "Remote" nocase or
            $context.graph.entity.user.title = "Temp" nocase or
            $context.graph.entity.user.title = "Vendor" nocase, 40) +
        if ( $context.graph.entity.user.title = "Legal" nocase, 10)
    )

  condition:
    $auth and $context
}

Exemple de lancement d'un processus suspect

L'exemple suivant évalue les données de traitement d'événements UDM par rapport aux données de contexte IOC stockées en tant que contexte d'entité.

rule ProcessLaunch {
  meta:
  events:
    $ioc.graph.metadata.vendor_name = "ACME"
    $ioc.graph.metadata.product_name = "IOCs"
    $ioc.graph.metadata.entity_type = "FILE"
    $ioc.graph.entity.file.sha256 = $hash

    $process.metadata.event_type = "PROCESS_LAUNCH"
    $process.principal.hostname = $hostname
    (
        not $process.target.process.file.sha256 = "" and
        $process.target.process.file.sha256 = $hash
    )

  match:
    $hash over 15m

  condition:
    $ioc and $process
}

Qualificatifs supplémentaires pour le contexte de l'entité

Pour créer une variable d'événement qui utilise un contexte d'entité, vous devez fournir un <source> après le nom de l'événement. L'<source> doit être graph.

Le modèle suivant fait référence à un contexte d'entité:

• $e.graph.entity.hostname

Notez qu'il existe deux méthodes équivalentes pour faire référence à un événement UDM:

• $u.udm.principal.asset_id
• $u.principal.asset_id

Vous pouvez combiner tous ces qualificatifs dans le texte des règles. Vous pouvez également utiliser différents qualificatifs pour le même événement.

Section "Résultats"

Le moteur de détection accepte une section outcome qui vous permet de récupérer plus d'informations à partir d'une règle. La logique définie dans la section outcome est évaluée pour chaque détection. Si une règle génère N détections, chacune d'elles N peut entraîner un ensemble de résultats différent.

Pour consulter un exemple de règle utilisant la section outcome, cliquez ici.

Pour en savoir plus sur l'utilisation et la syntaxe d'une section outcome, consultez cette section.

Section "Résultats" et déduplication / regroupement des détections

Pour les règles comportant une section de correspondance, n'oubliez pas que les détections sont "regroupées par" les variables de correspondance. Cela entraîne la déduplication des détections, de sorte qu'une ligne est renvoyée pour chaque ensemble unique de variables de correspondance et période.

Les variables de résultat sont ignorées lors de cette déduplication. Par conséquent, s'il existe deux détections différentes avec les mêmes valeurs pour les variables de correspondance et la fenêtre temporelle, mais avec des valeurs différentes pour les variables de résultat, elles seront dédupliquées et vous ne verrez qu'une seule détection. Cela peut se produire lorsqu'une détection a été créée en raison d'un retard de données, par exemple. Voici un exemple illustrant ce cas.

rule ExampleOutcomeRule {
  ...
  match:
    $hostname over <some window>
  outcome:
    $risk_score = <some logic here>
  ...
}

Cette règle donne les correspondances suivantes:

Détection 1 : nom d'hôte : nom d'hôte test : fenêtre temporelle : [t1, t2] score de risque : 10

Détection 2 : nom d'hôte : nom d'hôte test : fenêtre temporelle : [t1, t2] score de risque : 73

Étant donné que les variables de correspondance et la fenêtre temporelle sont les mêmes pour la détection 1 et la détection 2, elles sont dédupliquées et vous ne verrez qu'une seule détection, même si la variable de résultat, "risk_score", est différente.

Étapes suivantes

Pour savoir comment Google Security Operations ingère des données contextuelles et enrichit les entités, consultez la page Comment Google Security Operations enrichit les données d'événement et d'entité.