Créer des analyses contextuelles

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 de détection unique dans votre compte Google SecOps. Il fournit une contextualisation des entités pour vous permettre de comprendre à la fois les schémas de comportement dans la télémétrie et le contexte des entités concernées par ces schémas.

Exemples :

  • Affichage des autorisations d'un compte sur lequel une connexion par force brute est tentée.
  • Importance des données hébergées par un élément qui est également la source d'une 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 schéma de base de télémétrie d'événement (une connexion réseau sortante), en créant de nombreuses détections que leurs analystes peuvent trier. Les analystes tentent de comprendre ce qui s'est passé pour déclencher l'alerte et 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 la détection, ce qui vous permet de fournir les fonctionnalités supplémentaires suivantes :

  • Mettre à disposition un contexte pertinent pour la notation des risques contextuels des détections basée sur l'heuristique des détections au moment de l'exécution de la détection plutôt qu'à l'étape du tri humain
  • Réduire le temps consacré au tri et à la combinaison manuelle d'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 de bac à sable, failles et activités anormales dans 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 des règles du moteur de détection pour rechercher des données contextuelles d'entité dans votre compte Google SecOps.

Pour rechercher des données contextuelles 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 « graph ». Pour un événement UDM, <source> est 'udm'. Si aucune valeur n'est spécifiée, 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 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 :

  • Règles multi-événements

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

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

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

  • Fenêtres glissantes

  • Calculer un score de risque pour les détections

Contrairement à un événement UDM, un contexte d'entité n'a pas d'horodatage 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 peut ne pas être 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 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é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 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 dans lesquels le contexte d'entité change de valeur, Google SecOps tente de faire correspondre toutes les valeurs de contexte d'entité et de renvoyer toutes les correspondances trouvées.

Exemples de règles

Rechercher des entités avec un contexte d'administrateur

La règle suivante recherche les entités qui sont également liées aux droits d'administrateur privilèges. Elle 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 "outcome"

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 contextuelles 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
}

Qualificateurs 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. Le <source> doit être graph.

Le schéma 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 qualificateurs dans le texte de la règle. Vous pouvez également utiliser différents qualificateurs pour le même événement.

Section "outcome"

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 des N détections 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.

Vous trouverez une utilisation et une syntaxe détaillées d'une section outcome dans la section "outcome".

Section "outcome" et déduplication / regroupement des détections

Pour les règles comportant une section de correspondance, rappelez-vous 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 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 arrivées 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 fenêtre temporelle sont identiques 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 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énement et d'entité

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