Utiliser des tableaux de données

Les tables de données sont des structures de données multicolonnes qui vous permettent d'importer vos propres données dans Google Security Operations. Elles peuvent servir de tables de conversion avec des colonnes définies et des données stockées dans les lignes. Vous pouvez créer ou importer une table de données dans votre compte Google SecOps à l'aide de l'interface Web Google SecOps, de l'API des tables de données ou d'une requête YARA-L.

Attribuer des niveaux d'accès aux tables de données à l'aide du RBAC pour les données

Pour utiliser les tables de données, vous devez leur attribuer des niveaux d'accès à l'aide du contrôle des accès basé sur les rôles (RBAC) pour les données. En attribuant des champs d'application à un tableau de données, vous pouvez contrôler les utilisateurs et les ressources qui peuvent y accéder et l'utiliser. Pour en savoir plus, consultez Configurer le contrôle des accès basé sur les rôles pour les tables de données.

Gérer les tables de données à l'aide de l'interface Web Google SecOps

Les sections suivantes décrivent comment gérer les tableaux de données à l'aide de l'interface Web. Vous y apprendrez comment accéder à vos tableaux de données, en ajouter un et modifier son contenu, importer des données dans votre tableau, ajouter des lignes, séparer des données à l'aide de virgules ou de tabulations, et supprimer un tableau de données de votre compte.

Accéder à vos tableaux de données

Pour accéder à la page Tables de données :

• Dans la barre latérale de gauche, sélectionnez Investigation > Tables de données.

Pour trouver un tableau de données spécifique, saisissez son nom dans le champ Rechercher en haut de la barre latérale.

Ajouter un tableau de données

Pour ajouter une table de données à Google SecOps, procédez comme suit :

1. Cliquez sur add Créer en haut à droite de la barre latérale.

2. Dans la boîte de dialogue Créer une table de données, donnez un nom à la nouvelle table et, si vous le souhaitez, ajoutez une description.

3. Cliquez sur Créer. Le nouveau tableau de données s'affiche dans la fenêtre principale et est prêt à recevoir des données.

Importer des données dans votre tableau de données

Pour ajouter des données à votre tableau de données, vous pouvez les importer directement dans Google SecOps comme suit :

1. Cliquez sur Import data (Importer les données).

2. Sélectionnez un fichier CSV standard (seuls les fichiers CSV peuvent être importés dans Google SecOps).

3. Cliquez sur Ouvrir lorsque vous êtes prêt à importer les données dans votre tableau de données.

Mapper les types de données aux colonnes du tableau de données

Vous pouvez mapper des champs de données uniques à une colonne de données, et mapper des champs de données répétés à une colonne de données à l'aide de l'interface Web ou de l'API, comme suit :

• Dans l'interface Web et l'API, séparez les valeurs des champs de données à l'aide du caractère |. Dans l'interface Web, si une valeur inclut le caractère |, elle est traitée comme une valeur répétée par défaut.

• Pour les requêtes API, définissez repeated_values sur true.

Pour en savoir plus, consultez Champs répétés.

Dans l'exemple suivant, la colonne Field_value du tableau de données contient des valeurs pour plusieurs champs :

Le tableau précédent est divisé en quatre colonnes, chacune étant mappée à un seul type de champ avant de pouvoir être utilisée pour l'un des cas d'utilisation de tableau de données présentés dans ce document.

Désigner des colonnes spécifiques comme colonnes clés

Marquer une colonne comme colonne clé permet d'identifier de manière unique les valeurs de cette colonne, d'éviter la duplication des données et d'améliorer la découverte des données pour les règles et les recherches.

Désigner des colonnes spécifiques pour prendre en charge les champs répétés

Les colonnes destinées à stocker des champs à valeurs multiples ou des champs répétés doivent être explicitement désignées comme répétées lors de la création du tableau de données.

Mapper les noms de colonnes sur les champs d'entité (facultatif)

Lorsque vous créez un tableau de données, vous pouvez mapper les noms de colonnes du tableau de données aux champs entité.

Dans l'exemple de tableau de données suivant, les colonnes Userid et Role sont respectivement mappées sur entity.user.userid et entity.user.attribute.role.name :

Vous pouvez mapper une colonne de tableau de données à un champ proto d'entité à l'aide du champ mapped_column_path de la ressource DataTable.

Pour les colonnes sans chemin d'entité défini, comme Email dans cet exemple de tableau, vous devez spécifier manuellement un type de données. Comme pour les listes de référence, les types de données acceptés pour les tableaux de données sont number, string, regex et cidr.

Vous pouvez inclure des colonnes mappées et non mappées dans un tableau de données en spécifiant une condition join.

Les colonnes non mappées sont stockées dans le champ additional de l'entité à laquelle la table est associée. Elles sont ajoutées sous forme de paires clé/valeur, où key correspond au nom de la colonne et value à la valeur de ligne correspondante.

Ajouter une ligne à un tableau de données

Pour ajouter une ligne, procédez comme suit :

1. Dans l'onglet Détails, effectuez un clic droit sur une ligne existante, puis sélectionnez Ajouter une ligne au-dessus.

2. Saisissez les données d'une nouvelle ligne, en considérant que la première ligne est un en-tête de tableau :

   1. Séparez les champs de données à l'aide de virgules ou de tabulations.
   2. Veillez à faire correspondre chaque élément de données à la colonne de données appropriée.
   3. Lorsque vous saisissez des données dans l'onglet Détails, elles s'affichent dans l'éditeur de table.

Modifier une ligne dans votre tableau de données

Pour modifier une ligne, procédez comme suit :

1. Cliquez sur le champ que vous souhaitez modifier. Le champ devient alors modifiable.

2. Une fois les modifications effectuées, cliquez sur Enregistrer.

Indiquez si vous souhaitez utiliser des virgules ou des tabulations pour séparer les données.

Pour séparer les données à l'aide de virgules ou de tabulations :

1. Cliquez sur grid_view Modifier le type de séparateur à côté de Importer des données.

2. Dans la boîte de dialogue Modifier le type de séparateur, sélectionnez Virgule ou Tabulation dans le menu Séparateur.

Rechercher des lignes dans un tableau de données

Vous pouvez rechercher des informations spécifiques dans un tableau de données à l'aide de l'interface Web. Dans l'onglet Détails, saisissez une chaîne de recherche dans le champ de recherche, puis cliquez sur Rechercher. Les lignes contenant votre chaîne de recherche s'affichent.

Gérer la valeur TTL des lignes de tableau

Pour gérer la valeur TTL (Time To Live) des lignes de tableau, procédez comme suit :

1. Cliquez sur Afficher la valeur TTL par ligne. Une colonne TTL s'affiche, indiquant si chaque ligne a expiré. Si elle n'a pas expiré, le temps restant avant l'expiration s'affiche.

2. Cliquez sur le délai d'expiration par défaut des lignes pour afficher la boîte de dialogue Mettre à jour le délai d'expiration par défaut des lignes et ajuster le TTL des lignes du tableau.

3. Saisissez une nouvelle valeur TTL en heures ou en jours. La valeur minimale est de 24 heures. La valeur maximale est de 365 jours.

4. Cliquez sur Enregistrer.

Supprimer une ligne d'un tableau

Pour supprimer une ligne, effectuez un clic droit dessus, puis sélectionnez Supprimer la ou les lignes.

Pour supprimer plusieurs lignes, sélectionnez chacune d'elles. Ensuite, effectuez un clic droit sur une ligne sélectionnée, puis choisissez Supprimer la ou les lignes.

Supprimer un tableau de données

Pour supprimer un tableau de données :

1. Sélectionnez une table de données dans la liste Tables de données à gauche.

2. Cliquez sur Supprimer.

Gérer les tables de données à l'aide de l'API Chronicle

Vous pouvez également utiliser les ressources REST disponibles dans l'API Chronicle pour gérer les tables de données dans Google SecOps. L'API peut répliquer toutes les fonctionnalités disponibles dans l'interface Web et inclut des fonctionnalités supplémentaires qui vous permettent de gérer les tableaux de données avec plus de performances et à plus grande échelle.

Voici les ressources REST des tableaux de données :

• dataTables

• dataTableRows

• dataTableOperationErrors

Exemple : syntaxe de filtre

L'exemple d'API Chronicle suivant montre comment utiliser la syntaxe filter pour rechercher google.com dans les lignes du tableau de données :

curl -X GET -H "Authorization: Bearer $(gcloud auth print-access-token)" -H "Content-Type: application/json" https://staging-chronicle.sandbox.googleapis.com/v1alpha/projects/{$PROJECT}/locations/${REGION}/instances/${INSTANCE}/dataTables/${DATA_TABLE_NAME}/dataTableRows?filter=google.com

Utiliser des tables de données dans Google SecOps

Une fois que vous avez importé des tables de données dans votre instance Google SecOps, vous pouvez les utiliser pour filtrer, améliorer et enrichir vos données à l'aide de requêtes YARA-L. Ce document inclut de nombreux exemples de syntaxe YARA-L que vous pouvez intégrer à Google SecOps.

Vous pouvez utiliser des tables de données avec des requêtes YARA-L dans la recherche et les règles. Vous pouvez utiliser les tableaux de données de différentes manières :

• Filtrer les données d'événements ou d'entités UDM à l'aide d'un tableau de données Vous pouvez filtrer les événements et les entités de télémétrie UDM en les comparant aux entrées d'un tableau de données.

• Utilisez un tableau de données comme liste de référence à plusieurs colonnes. Vous pouvez utiliser un tableau de données comme liste de référence multicolonne. Alors qu'une liste de référence peut accéder aux données d'une seule dimension, les tableaux de données vous permettent d'accéder aux données de plusieurs dimensions, ce qui permet de filtrer les données.

• Associez un tableau de données à un événement ou une entité. Vous pouvez associer des événements UDM à une table de données à l'aide de l'opérateur d'égalité (=) pour les comparaisons basées sur les lignes. Cette comparaison vous permet de filtrer les données. Une comparaison basée sur les lignes est évaluée comme true uniquement si toutes les conditions de l'instruction correspondent à une seule ligne du tableau de données.

Filtrer les données d'événements et d'entités UDM à l'aide d'un tableau de données

Vous pouvez filtrer les événements et les entités UDM en les comparant aux entrées d'un tableau de données.

Associez les événements UDM aux tables de données de l'une des manières suivantes :

• Utilisation d'un opérateur d'égalité (=, !=, >, >=, <, <=) pour la comparaison basée sur les lignes. Exemple :$<udm_variable>.<field_path> = %<data_table_name>.<column_name>

• Utilisation du mot clé in pour la comparaison basée sur les colonnes. Par exemple, $<udm_variable>.<field_path> in %<data_table_name>.<column_name>.`

Comme pour les listes de référence, les types de données acceptés pour chaque colonne de tableau de données peuvent être number, string, regex ou CIDR.

Pour utiliser une colonne de type number d'un tableau de données pour les comparaisons et les jointures basées sur les colonnes, utilisez la syntaxe suivante. Cet exemple recherche les événements incluant target.port 8080.

%table.number_field = target.port
%table.number_field = 8080
target.port in %table.number_field

Pour utiliser une colonne de tableau de données de type CIDR ou regex pour une comparaison basée sur les lignes, utilisez la syntaxe suivante :

net.ip_in_range_cidr($e.principal.ip, %<data_table_name>.<column_name>)

re.regex($e.principal.hostname, %<data_table_name>.<column_name>)

Pour utiliser une colonne de tableau de données de type CIDR ou regex pour une comparaison basée sur une colonne, utilisez la syntaxe suivante :

$e.principal.ip in cidr %cidr_data_table.column_name

$e.principal.hostname in regex %regex_data_table.column_name

Lorsque vous comparez des colonnes de tables de données dont les types de données sont des expressions régulières ou des adresses CIDR, les mots clés cidr et regex sont facultatifs. Vous pouvez également utiliser l'opérateur not avec les tables de données. L'exemple de requête suivant filtre les entrées dont les adresses IP ($e.principal.ip) ne correspondent à aucune des plages CIDR listées dans la colonne benign_ip de cidr_data_table :

not $e.principal.ip in %data_table.benign_ip

Utiliser un tableau de données comme liste de référence multicolonne

Vous pouvez utiliser un tableau de données comme liste de référence multicolonne. Alors qu'une liste de référence peut accéder aux données d'une seule dimension (une colonne), les tableaux de données acceptent plusieurs colonnes, ce qui vous permet de filtrer et d'accéder aux données de plusieurs dimensions.

Vous pouvez associer des événements UDM à une table de données à l'aide du mot clé in pour la comparaison basée sur les colonnes. Cela vous permet de faire correspondre les valeurs d'un champ UDM spécifique à celles d'une seule colonne de la table de données.

Dans l'exemple suivant, le tableau de données badApps contient deux colonnes : hostname et ip. La requête fait correspondre les deux valeurs (valeur basée sur le champ UDM et valeur basée sur la table de données, toutes deux de type chaîne) de manière indépendante.

Exemple de règle :

rule udm_in_data_table {
meta:
  description = "Use data table as multicolumn reference list"
events:
$e.metadata.event_type = "NETWORK_CONNECTION"
$e.security_result.action = "ALLOW"
$e.target.asset.asset_id = $assetid
     
// Event hostname matches at least one value in table column hostname.
$e.target.hostname in %badApps.hostname
    
// Event IP matches at least one value in table column ip.
$e.target.ip in %badApps.ip
match:
$assetid over 1h

condition:
$e
}

Exemple de recherche :

events:
    $e.metadata.event_type = "NETWORK_CONNECTION"
    $e.security_result.action = "ALLOW"
    $e.target.asset.asset_id = $assetid
  
    // Event hostname matches at least one value in table column hostname.
    $e.target.hostname in %badApps.hostname
     
    // Event IP matches at least one value in table column ip.
    $e.target.ip in %badApps.ip

Associer une table de données à un événement ou une entité UDM

Vous pouvez associer des événements UDM à une table de données à l'aide d'opérateurs d'égalité et de comparaison (=, !=, >, >=, <, <=) pour effectuer des comparaisons basées sur les lignes. Cette approche vous permet de filtrer les données en faisant correspondre les valeurs des événements UDM aux lignes du tableau de données. Si vous utilisez plusieurs instructions de comparaison, tous les champs ou conditions doivent correspondre à la même ligne du tableau de données.

Pour utiliser des opérateurs (tels que not, !=, >, >=, <, <=) dans votre requête, vous devez inclure au moins une condition join entre les champs UDM et les lignes du tableau de données. Google SecOps traite toute règle comportant un tableau de données join comme une règle multi-événements, ce qui vous oblige à inclure également une section match dans la définition de la règle.

Lorsqu'une jointure a lieu, les lignes du tableau de données associé sont visibles dans la recherche. Pour en savoir plus, consultez Afficher les lignes d'un tableau de données dans la recherche.

L'exemple suivant utilise une colonne de tableau de données de type string. Cette requête YARA-L vérifie si un événement de connexion utilisateur correspond à une ligne dans example_table en confirmant que user ID existe dans le tableau. Les deux conditions doivent correspondre à la même ligne du tableau de données pour que la règle se déclenche.

// Check if a user exists in a data table and that the user is active for all user login events.

Exemple de règle :

rule udm_join_data_table {
meta:
    description = "Join data table with UDM event"
events:
$e.metadata.event_type = "USER_LOGIN"
$e.security_result.action = "ALLOW"
$e.principal.user.userid = $userid

// Event must match at least 1 row in the table where the uid in the table
// row is the userid on the event and the active date in the same table
// row is before the event timestamp
%example_table.uid = $userid
$e.principal.hostname = %example_table.hostname

match:
$userid over 1h

condition:
$e
}

Exemple de recherche :

events:
$e.metadata.event_type = "USER_LOGIN"
$e.security_result.action = "ALLOW"
$e.principal.user.userid = $userid

// Event must match at least 1 row in the table where the uid in the table
// row is the userid on the event and the active date in the same table
// row is before the event timestamp
%example_table.uid = $userid
$e.principal.hostname = %example_table.hostname

L'exemple suivant illustre le fonctionnement combiné d'un tableau de données et de données d'événement UDM. En fonction de la logique de la requête YARA-L précédente, un utilisateur avec user ID 32452 apparaît dans la détection en tant que hostname de l'utilisateur provenant du système et correspond au hostname dans le tableau de données.

Écrire les résultats des requêtes YARA-L dans des tables de données

Vous pouvez écrire les résultats des requêtes YARA-L dans un tableau de données. Cette fonctionnalité vous permet de créer des tables de données à partir de vos données Google SecOps et de les utiliser pour filtrer et améliorer d'autres données.

Vous pouvez utiliser la syntaxe d'écriture des requêtes YARA-L pour les éléments suivants :

• Définissez la syntaxe YARA-L pour écrire les résultats de requête dans des tables de données.

• Utilisez des tableaux de données pour les renseignements sur les menaces, la réponse aux incidents et d'autres cas d'utilisation liés à la sécurité.

• Les données doivent être conformes à la syntaxe et aux conventions YARA-L.

Écrire des détections et des alertes dans des tableaux de données à l'aide de YARA-L

Vous pouvez utiliser une requête YARA-L pour envoyer des détections et des alertes à des tables de données.

La fonction write_row vous permet d'écraser une ligne de tableau de données avec la clé correspondante dans le tableau de données à l'aide des résultats d'une règle. Si la clé est introuvable dans le tableau, ajoutez plutôt une ligne.

Spécifiez la fonction write_row dans la section d'exportation d'une requête YARA-L. L'écriture de données dans le tableau de données doit être la dernière action de la requête. Les variables de résultat sont alors écrites dans le tableau de données.

export:
  %<data_table_name>.write_row(
  data_table_column_x_name: <value>,
  data_table_column_y_name: <value>,
  ...,
  ...,
  data_table_column_z_name: <value>
)
// depending on the key column(s), the rows will be updated for existing keys 
and appended for new keys

Modifier une table de données à l'aide de YARA-L

L'exemple suivant montre comment modifier une table de données à l'aide de YARA-L :

TableName : ip_user_domain_table (les colonnes clés de la clé primaire sont définies lors de la création)

* indique la clé primaire.

La requête suivante capture les combinaisons uniques de principal.ip, principal.user.employee_id et target.domain. Il filtre les résultats en fonction de la prévalence de target.domain :

events:
    $e.principal.ip = $principal_ip
    $e.principal.user.employee_id = $principal_user_employee_id
    $e.target.domain.name = $target_domain
    $e.target.domain.prevalence.day_count < 5

// To run this query as a rule, add Condition Section here 
// condition:$e

Résultats de la requête :

Exemple : Utiliser write_row pour écrire le résultat d'une requête dans une table de données

Exemple de règle :

rule udm_write_data_table {
meta:
    description = "Writeto data table"
events:
  $e.principal.user.employee_id = $principal_user_employee_id
  $e.target.domain.name = $target_domain
  $e.target.domain.prevalence.day_count < 5

outcome:
  $hostname = $target_domain
  $principal_emp_id = $principal_user_employee_id
 
condition:
  $e

export:
  %ips_with_hostnames.write_row(
      employeeid:$principal_emp_id,
      hostname:$hostname
  )
}

Exemple de recherche :

events:
  $e.principal.user.employee_id = $principal_user_employee_id
  $e.target.domain.name = $target_domain
  $e.target.domain.prevalence.day_count < 5

outcome:
  $hostname = $target_domain
  $principal_emp_id = $principal_user_employee_id

export:
  %ips_with_hostnames.write_row(
      employeeid:$principal_emp_id,
      hostname:$hostname
  )

Exemple : Comprendre write_row

Dans l'exemple suivant, user et ip sont utilisées comme clés primaires. Chaque détection qui persiste dans la table des détections entraîne une évaluation de l'appel de fonction dans la section d'exportation de la requête.

Exemple de règle :

rule udm_write_data_table {
meta:
    description = "Write data table"
events:
    $e.metadata.event_type = "USER_LOGIN"
    all $e.security_result.action != "BLOCK"
    all $e.security_result.action != "UNKNOWN_ACTION"

    $user = $e.principal.user.userid
    $ip = $e.target.ip
    $ts = $e.metadata.event_timestamp.seconds

match:
    $user, $ip over 1h

outcome:
    $first_seen = min($ts)

condition:
    $e

export:
    %successful_logins.write_row(user:$user, ip:$ip)
}

Exemple de recherche :

events:
    $e.metadata.event_type = "USER_LOGIN"
    all $e.security_result.action != "BLOCK"
    all $e.security_result.action != "UNKNOWN_ACTION"

    $ts = $e.metadata.event_timestamp.seconds

outcome:
    $user = $e.principal.user.userid
    $ip = $e.target.ip[0]

export:
    %successful_logins.write_row(user:$user, ip:$ip)

Voici les données de l'événement :

metadata: {
  event_type: USER_LOGIN
  event_timestamp: { seconds: 1283299200 }
}
principal: {
  user: {
    userid: "charlie"
  }
}
target: {
  ip: ["192.0.2.135", "192.0.2.136"]
}
security_result: {
  action: ALLOW
}

Les détections suivantes sont renvoyées lorsque cette requête est exécutée en tant que règle :

Le tableau de données contient les éléments suivants :

La requête de recherche suivante illustre la prise en charge de l'écriture de valeurs scalaires dans les tables de données.

events:
    $e.metadata.event_type = "NETWORK_CONNECTION"

export:
  %summary_table.write_row(col_name: $e.metadata.product_name, Vendor_name: $e.metadata.vendor_name)

Enrichir le graphique d'entités avec une table de données

Vous pouvez utiliser des tableaux de données pour ajouter, supprimer ou remplacer les entités présentées dans le graphique d'entités à partir de règles. Utilisez les fonctions de la section setup de la règle pour indiquer comment la table de données doit être fusionnée avec les événements d'entité référencés dans la section events, ajoutée à ces événements ou utilisée pour supprimer des entités de ces événements.

Vous pouvez utiliser le modèle de règle suivant pour modifier un graphique d'entités :

rule entity_graph_template {

  meta:
    ...

  setup:
    // import the data table into entity graph
    <enrichment_keyword> <join_condition>

  events:
    ...

  match:
    ...

  condition:
    ...
}

Vous pouvez utiliser les fonctions YARA-L 2.0 suivantes pour améliorer le graphique d'entités avec un tableau de données :

• graph_override : Écrasez les lignes du graphique d'entités qui correspondent à la condition de jointure avec les données de la table de données.

  Exemple :

  [graph_override](?tab=t.0#heading=h.v0fps7eke1if)

• graph_append : ajoute les lignes du tableau de données à celles du graphique d'entités. L'opération graph_append nécessite un tableau qui inclut une variable de tableau de données et une variable d'événement d'entité plutôt qu'une condition de jointure.

  Dans l'exemple suivant, $g1 est la variable du graphique d'entités et example_table est le tableau de données :

  graph_append [$g1, %example_table]

  Pour la fonction append, les tables de données doivent inclure les colonnes suivantes pour valider l'entité :

  • start_time (mappé à metadata.interval.start_time.seconds)

  • end_time (mappé à metadata.interval.end_time.seconds)

  Les colonnes de tableau de données ne peuvent pas être mappées aux champs de métadonnées à l'aide de l'interface Web. Pour les cas d'utilisation append, les tables de données doivent être créées à l'aide de l'API Chronicle (https://cloud.google.com/chronicle/docs/reference/rest/v1alpha/projects.locations.instances.dataTables/create).

• graph_exclude : supprime les lignes du graphique d'entités qui correspondent à la condition join.

  Exemple :

  [graph_exclude](?tab=t.0#heading=h.o0qbb5paki6g)

La condition de jointure doit être une expression d'égalité entre la colonne de la table de données et le champ du graphique d'entités. Pour les fonctions graph_override et graph_exclude, la syntaxe permettant d'accéder à une table de données est la suivante :

<data_table_name>.<column_name>

Tout filtre spécifié pour <entity_variable> dans la section "Événement" est appliqué après son enrichissement avec le tableau de données.

Une fois l'entité du graphique d'entités enrichie avec l'entité de la table de données, la variable d'entité du graphique d'entités doit être associée à l'entité UDM.

Remplacer le graphique d'entités par des données issues d'une table de données

Avec la fonction graph_override, les champs présents à la fois dans le graphique d'entités et dans la table de données sont remplacés par les champs de la table de données. Les champs présents dans le graphique d'entités et non dans le tableau de données restent les mêmes. Les champs qui ne sont pas présents dans le graphique d'entités, mais qui le sont dans le tableau de données, sont inclus.

Seules les colonnes de la table de données qui sont mappées remplacent les colonnes du graphique d'entités. Les colonnes non mappées sont ajoutées au champ additional du graphique d'entités auquel la table de données est jointe.

Exemple : Correspondance sur une seule jointure

Dans l'exemple suivant, les lignes du graphique d'entités qui correspondent à la condition de jointure entre la colonne de la table de données et le champ du graphique d'entités ($g1.graph.entity.ip = %example_table.my_ip) sont remplacées par la table de données.

rule rule_override {
  meta:
    description = "Override entity context with data table before joining with UDM event"

  setup:
    //Rows in the entity graph that match the join condition are overridden by the data table
    graph_override ($g1.graph.entity.ip = %example_table.my_ip)

  events:
    $e.metadata.event_type = "NETWORK_CONNECTION"
    $e.security_result.action = "ALLOW"

    // Filter will be applied after graph is overridden by data table
    $g1.graph.entity.hostname = "ftp01"

    // Accessing unmapped columns
    $g1.graph.additional.fields["Owner"] = "alice"

    // Joining the UDM event with the enriched entity graph
    $e.target.ip = $iocip
    $g1.graph.entity.ip = $iocip

  match:
    $iocip over 1h

  condition:
    $e and $g1
}

Pour utiliser une colonne non mappée (par exemple, "Propriétaire") de la table de données, utilisez une instruction équivalente pour $g1.graph.entity.owner = "alice" is $g1.graph.additional.fields["Owner"] = "alice". En effet, toutes les colonnes non mappées du tableau de données sont insérées dans le champ additional du graphique d'entités ($g1).

Les tableaux suivants illustrent une opération de remplacement dans laquelle les lignes du graphique d'entités sont enrichies lorsque le champ "Adresse IP" du tableau de données correspond au champ "Adresse IP" du graphique d'entités.

Exemple : Correspondance avec plusieurs jointures

Dans l'exemple suivant, les lignes du graphique d'entités qui correspondent aux multiples conditions de jointure ($g1.graph.entity.ip = %example_table.my_ip et $g1.graph.entity.hostname = %example_table.my_hostname) sont remplacées par la table de données.

rule rule_override {
meta:
    description = "Override Entity context with Data Table before joining with UDM event"
setup:
  // example with more than one condition
  graph_override ($g1.graph.entity.ip = %example_table.my_ip and
  $g1.graph.entity.hostname = %example_table.my_hostname) 
events:
  $e.metadata.event_type = "NETWORK_CONNECTION"
  $e.security_result.action = "ALLOW"

  // Filter will be applied after graph is overridden by data table
  $g1.graph.entity.hostname = "ftp01"

  // joining the UDM event with the enriched entity graph
  $e.target.ip = $iocip
  $g1.graph.entity.ip = $iocip

match:
  $iocip over 1h

condition:
  $e and $g1
}

Les tableaux suivants illustrent une opération de remplacement dans laquelle les lignes du graphique d'entités sont enrichies lorsque le champ "Adresse IP" et le champ "Nom d'hôte" du tableau de données correspondent au champ "Adresse IP" et au champ "Nom d'hôte" du graphique d'entités.

Ajouter des données de la table de données au graphique d'entités

Avec la fonction graph_append, aucune condition de jointure n'est requise.

Dans l'exemple suivant, toutes les lignes du tableau de données sont ajoutées aux lignes du graphique d'entités.

rule rule_append {
meta:
  description = "Data table append entity"
   
setup:
  graph_append [$g1, %example_table]

events:
    // filter UDM events
  $e.metadata.event_type = "NETWORK_CONNECTION"
  $e.security_result.action = "ALLOW"

  // Join the filtered UDM events with the enriched graph
  $e.target.ip = $iocip
  $g1.graph.entity.ip = $iocip

match:
  $iocip over 1h

condition:
  $e and $g1
}

Le tableau suivant illustre une opération d'ajout dans laquelle les lignes de la table de données sont ajoutées aux lignes du graphique d'entités :

Utiliser graph_exclude pour supprimer des lignes du graphique d'entités

Avec la fonction graph_exclude, les lignes du graphique d'entités qui correspondent à la condition de jointure sont supprimées du graphique d'entités.

Dans l'exemple suivant, toutes les lignes du graphique d'entités qui correspondent à la condition de jointure donnée (entre la colonne de la table de données et le champ du graphique d'entités) sont supprimées. Aucune ligne du tableau de données n'est ajoutée au graphique d'entités.

rule rule_exclude {

    meta:
    setup:
      graph_exclude ($g1.graph.entity.ip = %example_table.ip)

    events:
        $e.metadata.event_type = "NETWORK_CONNECTION"
        $e.security_result.action = "ALLOW"
        $e.target.ip = $iocip
        $g1.graph.entity.ip = $iocip

    match:
        $iocip over 1h

    condition:
        $e and $g1
}

Les tableaux suivants illustrent une opération d'exclusion dans laquelle les lignes du graphique d'entités qui correspondent au champ "Adresse IP" de la table de données sont supprimées :

Limites

• Nombre maximal de tables de données pour un compte Google SecOps : 1 000.

• Seul le type de fichier CSV est accepté pour les importations.

• Les limites concernant le nombre d'instructions in lors du référencement d'une liste de référence dans une requête s'appliquent également aux instructions in dans un tableau de données.

• Nombre maximal d'instructions in dans une requête : 10

• Nombre maximal d'instructions in dans une requête pour les colonnes de type de données String et Number : 7

• Nombre maximal d'instructions in avec des opérateurs d'expression régulière : 4

• Nombre maximal d'instructions in avec des opérateurs CIDR : 2

• Nombre maximal de colonnes par tableau de données : 1 000.

• Nombre maximal de lignes par tableau de données : 10 millions.

• La limite globale maximale du volume de données dans les tables de données d'un compte est de 1 To.

• Limite d'affichage maximale des lignes de tableau de données dans la vue de l'éditeur de texte et de tableau sur une page Web : 10 000 lignes

• Nombre maximal de lignes lors de l'importation d'un fichier dans un nouveau tableau de données sur la page Web : 10 000 lignes

• Taille maximale des fichiers importés pour la création de tables de données à partir de l'API : 1 Go

• Les espaces réservés ne sont pas autorisés dans la section de configuration.

• Les colonnes non mappées d'une table de données dont le type de données est défini sur string ne peuvent être jointes qu'à des champs de chaîne d'événement UDM ou d'entité UDM.

• N'utilisez que des colonnes non mappées dans un tableau de données dont le type de données est défini sur cidr ou regex pour CIDR ou une expression régulière.

• Recherches dans les tableaux de données : les caractères génériques d'expression régulière ne sont pas acceptés et les termes de recherche sont limités à 100 caractères.

Jointures

• Il n'est pas possible de récupérer tous les exemples d'événements pour les détections lorsque vous utilisez des jointures de tables de données avec des événements.

• Contrairement aux entités et à l'UDM, les tables de données ne sont pas compatibles avec les espaces réservés. Cela signifie que vous ne pouvez pas :

  • Appliquez un ensemble de filtres à un tableau de données et joignez-le à une entité UDM.

  • Appliquez un ensemble de filtres différent à la même table de données tout en la joignant à un autre espace réservé UDM.

  Par exemple, une table de données nommée dt avec trois colonnes (my_hostname, org et my_email) et la règle suivante :

  events:
  $e1.principal.hostname =  %dt.my_hostname
  %dt.org ="hr"
  
  $e2.principal.email =  %dt.my_email
  %dt.org !="hr"
  

Tous les filtres d'un tableau de données sont appliqués en premier, puis les lignes filtrées du tableau de données sont jointes à l'UDM. Dans ce cas, une table de données vide est jointe à e1 et e2, car les deux filtres de la table de données dt se contredisent (%dt.org ="hr" and %dt.org !="hr").

Utiliser des tableaux de données avec des règles

Les limites suivantes s'appliquent aux tableaux de données lorsqu'ils sont utilisés avec des règles.

Fréquence d'exécution

La fréquence d'exécution en temps réel n'est pas compatible avec les règles comportant des tables de données.

Sortie vers des tableaux de données

• Les modificateurs any et all ne sont pas acceptés pour les colonnes de champs répétés dans les tables de données.

• L'indexation de tableaux n'est pas compatible avec les colonnes de champs répétés dans les tableaux de données.

• Vous ne pouvez exporter que des variables de résultat vers une table de données. Vous ne pouvez pas exporter directement les colonnes de chemin d'événement ni de tableau de données.

• Les listes de colonnes doivent inclure les colonnes de clé primaire pour les tables de données.

• Vous ne pouvez pas avoir plus de 20 résultats.

• Si une table de données n'existe pas, une table est créée avec le type de données chaîne par défaut pour toutes les colonnes, en suivant l'ordre spécifié.

• Une seule règle peut écrire dans une table de données à la fois. Si une règle tente d'écrire dans une table de données dans laquelle une autre règle est déjà en train d'écrire, la compilation de la règle échoue.

• Il n'est pas garanti qu'une règle de producteur puisse ajouter des lignes à une table de données avant le début d'une règle de consommateur pour cette table de données.

• Une règle est limitée en nombre de lignes de résultats. Une limite de 10 000 lignes s'applique aux résultats et aux données persistantes. La même limite s'applique aux tables de données : une seule exécution de règle peut générer un maximum de 10 000 lignes dans une table de données.

• Si une ligne avec la même clé primaire existe déjà dans le tableau de données, les colonnes sans clé primaire seront remplacées par les nouvelles valeurs.

Enrichissement des entités à partir de tables de données

• Vous ne pouvez appliquer qu'une seule opération d'enrichissement (override, append ou exclude) à une seule variable de graphique d'entités.

• Chaque opération d'enrichissement ne peut être effectuée qu'à l'aide d'une seule table de données.

• Vous pouvez définir un maximum de deux opérations d'enrichissement de n'importe quel type dans la section setup d'une règle YARA-L.

Dans l'exemple suivant, une opération de remplacement est appliquée à la variable de graphique d'entités $g1 et une opération append est appliquée à la variable de graphique d'entités $g2.

    setup:
    graph_override($g1.graph.entity.user.userid = %table1.myids)
    graph_append [$g2, %table1]

Dans l'exemple précédent, le même tableau de données (table1) est utilisé pour améliorer différents graphiques d'entités. Vous pouvez également utiliser différentes tables de données pour améliorer les différents graphiques d'entités, comme suit :

    setup:
    graph_override($g1.graph.entity.user.userid = %table1.myids)
    graph_append [$g2, %table2]

Utiliser des tableaux de données avec la recherche

Les limites suivantes s'appliquent aux tableaux de données lorsqu'ils sont utilisés avec la recherche.

• Vous ne pouvez pas exécuter de requêtes de recherche sur les tables de données à l'aide de l'API Chronicle. Vous ne pouvez exécuter des requêtes de recherche que depuis l'interface Web.

• Une seule exécution de requête peut générer un maximum d'un million de lignes dans une table de données ou 1 Go, selon la limite atteinte en premier.

• La sortie de recherche vers un tableau de données ignore les lignes d'événements si elles dépassent 5 Mo.

• L'enrichissement d'entités n'est pas compatible avec la recherche.

• Les tables de données ne sont pas disponibles pour les clients utilisant des clés de chiffrement gérées par le client (CMEK).

• Les écritures sont limitées à six par minute et par client.

• L'assistance pour les API n'est pas disponible.

• Les requêtes statistiques ne sont pas compatibles avec les jointures de tables de données.

• Les tables de données et les jointures de tables de données ne sont compatibles qu'avec les événements UDM, et non avec les entités.

  Compatible : %datatable1.column1 = %datatable2.column1 Non compatible : graph.entity.hostname = %sample.test

• Vous ne pouvez pas inclure de variable match dans une requête de statistiques dans la section export.

  Par exemple, les éléments suivants ne sont pas acceptés :

  match:
      principal.hostname
  export:
      %sample.write_row(
      row: principal.hostname
    )

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