Créer des analyses contextuelles

Chronicle vous permet de visualiser la télémétrie, le contexte des entités, les relations et les failles en une seule fois dans votre compte Chronicle. Il fournit un contexte d'entité pour vous permettre de comprendre à la fois les modèles de comportement en télémétrie et le contexte des entités concernées à partir de ces modèles.

Exemples :

Afficher les autorisations pour un compte sur lequel une 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 s'en servir pour le filtrage de la détection, la hiérarchisation heuristique des alertes, le tri et l'investigation.

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 de télémétrie de base des événements (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étection, ce qui vous permet de fournir les fonctionnalités supplémentaires suivantes:

Mise à disposition d'un contexte pertinent pour l'évaluation heuristique du risque contextuel des détections au moment de leur exécution plutôt qu'au moment du tri humain
Réduction du temps consacré au tri et à l'assemblage manuel des informations provenant de systèmes de sécurité informatiques 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 ne présenter que 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 dans un réseau de développement sans accès ni données sensibles, etc.)

Écrire des règles pour l'analyse contextuelle

Vous pouvez utiliser les règles de détection Engine pour rechercher des données de contexte d'entité dans votre compte Chronicle.

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

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

$eventname.[<source>].field1.field2 Dans un contexte d'entité, <source> correspond à "graph". Pour un événement UDM, <source> correspond à "udm". Si cette valeur est omise, <source> est défini par défaut sur udm.
Spécifiez les données de l'entité:

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

$e1.graph.entity.relations.relationship = "OWNS"
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 un grand nombre des mêmes types de règles pour les contextes d'entités que pour les événements UDM, y compris les suivants:

Plusieurs règles d'événement

Remarque :Toutes les règles multi-événements doivent utiliser un événement UDM. Vous pouvez définir une règle qui utilise uniquement un UDM, ou une règle qui utilise à la fois un UDM et une entité. Il est impossible de définir une règle qui n'utilise que l'élément "Entity".
Comparer des contextes d'entités à d'autres contextes d'entités
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 d'entité ne peut pas être utilisé comme tableau croisé dynamique pour une fenêtre glissante.

Contrairement à un événement UDM, le contexte d'une entité n'a pas de code temporel spécifique. Chaque enregistrement de contexte d'entité possède un intervalle de temps, entity.metadata.Interval, sur lequel le contexte de l'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 est compris 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 implicitement cette condition. Vous n'avez donc 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.
Si le contexte de l'entité change de valeur dans des buckets de jours adjacents, Chronicle tente de mettre en correspondance toutes les valeurs de contexte de l'entité et renvoie toutes les correspondances trouvées.

Exemples de règles

Rechercher des entités avec un contexte 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 de droits d'administrateur a tenté de se connecter ou de se déconnecter du système.

rule LoginLogout {
  meta:
  events:
    $log_in.metadata.event_type = "USER_LOGIN"
    $log_in.principal.user.user_display_name = $user

    $log_out.metadata.event_type = "USER_LOGOUT"
    $log_out.principal.user.user_display_name = $user

    $log_in.metadata.event_timestamp.seconds <=
     $log_out.metadata.event_timestamp.seconds

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

  match:
    $user over 2m

  condition:
    $log_in and $log_out and $context
}

Exemple de fenêtre glissante

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

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 servir de tableau croisé dynamique 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 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 de processus suspect

L'exemple suivant évalue les données de processus d'événement 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 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. <source> doit être défini sur 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 accepte une section outcome qui vous permet d'extraire plus d'informations 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 entraîner un ensemble de résultats différent.

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

Vous trouverez des informations détaillées sur l'utilisation et la syntaxe d'une section outcome dans cette section.

Section "Résultats" et déduplication / regroupement de détection

Pour les règles comportant une section de correspondance, rappelez-vous que les détections sont "regroupées par" les variables de correspondance. Les détections sont alors dédupliquées, de sorte qu'une ligne est renvoyée pour chaque ensemble unique de variables de correspondance et chaque fenêtre de temps.

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 période de temps, 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 en retard, par exemple. Voici un exemple qui illustre ce cas de figure.

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 Période de référence: [t1, t2] risk_score: 10

Détection 2 : nom d'hôte: nom d'hôte test Période de temps: [t1, t2] risk_score: 73

Étant donné que les variables de correspondance et la fenêtre de temps 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 découvrir comment Chronicle ingère des données contextuelles et enrichit les entités, consultez la page Comment Chronicle enrichit les données d'événements et d'entités.