Présentation des données analytiques contextuelles

Compatible avec:

Google SecOps vous permet de consulter la télémétrie, le contexte des entités, les relations et les failles sous la 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 tendances comportementales dans la télémétrie et le contexte de ces entités affectées à partir de ces tendances.

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 comprendre ce qui s'est passé pour déclencher l'alerte et l'importance de la menace.

Les analyses contextuelles intègrent des fonctionnalités d'enrichissement avancées plus tôt dans le workflow d'écriture et d'exécution de la détection, ce qui vous permet de fournir les fonctionnalités supplémentaires suivantes:

  • Mise à disposition d'un contexte pertinent pour l'évaluation du risque contextuel basée sur des heuristiques des détections au moment de leur exécution plutôt qu'au stade du tri manuel
  • Réduction du temps passé à trier et à assembler manuellement les 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 groupes entiers de menaces qui peuvent être attendues ou qui représentent peu ou pas de danger pour l'entreprise (tests de logiciels malveillants dans un environnement bac à sable, failles et activités anormales dans un réseau de développement sans données ni accès sensibles, etc.)

Écrire des règles pour les analyses contextuelles

Vous pouvez utiliser des 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 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". 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 pour les contextes d'entité comme vous le feriez pour les événements UDM, y compris les suivants:

  • Plusieurs règles d'événement

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

  • 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é n'a pas de code temporel spécifique. Chaque enregistrement de contexte d'entité possède un intervalle de temps, entity.metadata.interval, pendant lequel le contexte d'entité est valide. Cet intervalle de temps ne doit pas nécessairement correspondre à une limite de jour et peut avoir n'importe quelle durée.

Un événement UDM n'est corrélé à un enregistrement de contexte d'entité que lorsque le code temporel 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é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.
  • Si des buckets de jours adjacents où le contexte de l'entité change de valeur, Google SecOps tente de faire correspondre toutes les valeurs du contexte de l'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 des 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 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 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 à 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.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
}

Qualifiers 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. 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 de la règle. 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 d'elles peut entraîner un ensemble de résultats différent.

Vous trouverez un exemple de règle qui utilise la section outcome sous Règle avec sélection de résultat.

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

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

Pour les règles comportant une section de correspondance, n'oubliez pas que les détections sont "groupées par" les 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 deux détections différentes présentent les mêmes valeurs pour les variables de correspondance et la période, mais 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, 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 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 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 SecOps ingère les données contextuelles et enrichit les entités, consultez Comment Google SecOps enrichit les données d'événement et d'entité.