Présentation de l'analyse contextuelle

Compatible avec :

Google SecOps vous permet d'afficher la télémétrie, le contexte des entités, les relations et les failles sous forme d'une seule détection dans votre compte Google SecOps. 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 sur 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 priorisation 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 base de télémétrie d'événement (une connexion réseau sortante), ce qui crée de nombreuses détections que leurs analystes doivent trier. Les analystes tentent de comprendre ce qui s'est passé pour déclencher l'alerte et l'ampleur 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 la détection. Vous pouvez ainsi fournir les fonctionnalités supplémentaires suivantes :

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

Écrire des règles pour l'analyse contextuelle

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

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

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

    $eventname.[<source>].field1.field2 Pour un contexte d'entité, <source> est défini sur "graph". Pour un événement UDM, <source> est défini sur "udm". Si elle est omise, la valeur par défaut de <source> 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 affirmations 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 pour les contextes d'entité comme pour les événements UDM, y compris les suivants :

  • Plusieurs règles d'événement

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

  • Comparer les 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

Contrairement à un événement UDM, un contexte d'entité ne comporte pas de code temporel spécifique. Chaque enregistrement de contexte d'entité comporte un intervalle de temps (entity.metadata.interval) pendant lequel le contexte d'entité est valide. Cet intervalle de temps ne peut pas être une limite de jour et peut avoir n'importe quelle durée.

Un événement UDM ne sera corrélé à un enregistrement de contexte d'entité que si son code temporel 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és pour les détections. Le moteur de détection l'applique implicitement. Vous n'avez donc pas besoin de le spécifier comme 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 période spécifiée.
  • S'il existe des buckets de jours adjacents où la valeur du contexte d'entité change, Google SecOps tente de trouver une correspondance pour toutes les valeurs du contexte d'entité et renvoie toutes les correspondances trouvées.

Exemples de règles

Rechercher des entités avec le contexte administrateur

La règle suivante recherche les entités qui sont également associées à des droits d'administrateur. Il recherche les moments où une personne 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 coulissante

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 coulissante suivant n'est pas valide. Le contexte d'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é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.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 processus d'événement UDM par rapport aux données de contexte d'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 d'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. La valeur <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 d'une règle. Vous pouvez également utiliser différents qualificatifs pour le même événement.

Section "Résultat"

Le moteur de détection est compatible avec 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 par rapport à chaque détection. Si une règle génère N détections, chacune d'elles peut entraîner un ensemble de résultats différents.

Vous trouverez un exemple de règle utilisant la section outcome dans Règle avec sélection du résultat.

Pour en savoir plus sur l'utilisation et la syntaxe d'une section outcome, consultez la section sur les résultats.

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

Pour les règles comportant une section de correspondance, les détections sont "regroupées par" les variables de correspondance. Cela permet de dédupliquer les détections, 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, 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 de données reçues en retard, par exemple. Voici un exemple qui illustre ce cas.

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

Cette règle génère 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 identiques pour la détection 1 et la détection 2, elles sont dédupliquées. Vous ne verrez donc qu'une seule détection, même si la variable de résultat risk_score est différente.

Étapes suivantes

Pour savoir comment Google SecOps ingère les données contextuelles et enrichit les entités, consultez Comment Google SecOps enrichit les données d'événements et d'entités.

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