Présentation des données analytiques contextuelles

Compatible avec :

Google SecOps SIEM

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 par ces modèles.

Exemples :

• Affichage des autorisations d'un compte pour lequel une tentative de connexion par force brute est en cours.
• Importance des données hébergées par un composant qui est également la source de l'activité réseau sortante.

Les clients peuvent utiliser cette contextualisation pour le filtrage des détections, la hiérarchisation des alertes heuristiques, le tri et l'investigation.

Les analystes de sécurité et les ingénieurs de détection s'efforcent généralement de créer une détection sur un modèle de télémétrie d'événements de base (une connexion réseau sortante), créant ainsi 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:

• Mise à disposition d'un contexte pertinent pour l'attribution d'un score de risque contextuel basé sur des heuristiques au moment de l'exécution des détections plutôt qu'au stade du 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 les analyses contextuelles

Vous pouvez utiliser les règles de Detection Engine 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> est "graph". Pour un événement UDM, <source> est "udm". En cas d'omission, la balise <source> la valeur par défaut est udm.

2. Spécifiez les données d'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 d'avoir une règle qui n'utilise que l'entité.

• 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é ne comporte 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 être de n'importe quelle durée.

Un événement UDM n'est corrélé à un enregistrement de contexte d'entité que lorsque le Le code temporel de l'événement UDM se situe dans l'intervalle de temps du contexte de l'entité enregistrer. Si cette condition n'est pas remplie, l'UDM et l'entité ne sont pas évalués pour les détections. Le moteur de détection applique cela de manière implicite et vous n'avez pas besoin de le spécifier comme condition dans une règle.

• Lorsque vous comparez des événements UDM à un contexte d'entité avec une fenêtre, un contexte d'entité représente une valeur constante sur une période spécifiée.
• S'il existe des buckets de jour 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. Il recherche les moments où un utilisateur disposant des droits d'administrateur a tenté de se connecter ou de se déconnecter du système.

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 à l'aide de la section "Résultat"

L'exemple suivant utilise la section outcome pour 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 de processus suspect

L'exemple suivant évalue les données de traitement des é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 ajouter 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ésultat"

Le moteur de détection prend en charge une section outcome qui vous permet d'obtenir 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 des N détections peut aboutissent à un ensemble de résultats différent.

Vous trouverez un exemple de règle qui utilise la section outcome sur cette page.

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

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

Pour les règles ayant une section de correspondance, n'oubliez pas que les détections sont "regroupées par" la des variables de correspondance. Les détections sont ainsi dédupliquées, de sorte qu'une ligne est renvoyée pour chaque ensemble unique de variables de correspondance et de fenêtre temporelle.

Les variables de résultat sont ignorées lors de cette déduplication. Ainsi, si il existe deux détections différentes avec les mêmes valeurs pour les variables de correspondance et la période, mais avec des valeurs différentes pour les variables de résultat, celles-ci et une seule détection. Cela peut se produire, par exemple, lorsqu'une détection a été créée en raison de données arrivées en retard. Voici un exemple : qui illustre 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 : hostname: test-hostname time window: [t1, t2] risk_score: 10

Détection 2 : hostname: test-hostname time window: [t1, t2] risk_score: 73

Étant donné que les variables de correspondance et la période 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.

Étape suivante

Pour en savoir plus sur la façon dont Google Security Operations ingère les données contextuelles et enrichit les entités, consultez Comment Google Security Operations enrichit les données sur les événements et les entités.