Utiliser des tableaux de données

Compatible avec :

Google SecOps SIEM

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. Les tableaux de données 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 Présentation de YARA-L 2.0.

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

Pour utiliser les tableaux 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 RBAC des données pour les tableaux de données.

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

Les sections suivantes expliquent comment gérer les tables de données à l'aide de l'interface Web. Vous y découvrirez comment accéder aux tables de données, en ajouter une, modifier son contenu, ajouter des lignes et supprimer une table de données de votre compte.

Accéder à vos tables de données

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

• Dans la barre latérale, sélectionnez Enquête > 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 Tableaux de données.

Ajouter un tableau de données

Lorsque vous ajoutez un tableau de données, vous pouvez saisir manuellement des données CSV, les coller ou importer un fichier CSV ou TSV dans le tableau de données.

Remarque : Les tableaux de données n'acceptent pas les valeurs séparées par des tabulations, sauf lors de l'importation d'un fichier TSV (valeurs séparées par des tabulations). Lorsque vous importez un fichier TSV, Google SecOps convertit les tabulations en virgules dans le tableau de données. Les champs de tableau de données ne sont pas compatibles avec les virgules (,).

Les configurations suivantes sont permanentes et ne peuvent pas être modifiées après l'enregistrement d'une table de données :

• En-têtes de colonne
• Mappage des données
• Clés primaires
• Champs répétés
• Mappage des noms de colonnes aux champs d'entité

Pour ajouter une table de données à Google SecOps :

1. Dans la barre latérale, sélectionnez Enquête > Tables de données.

2. En haut de la barre latérale Tables de données, cliquez sur add Créer.

3. Dans la boîte de dialogue Créer une table de données, donnez un nom à la table et ajoutez éventuellement une description.

4. Effectuez l'une des opérations suivantes :

   • Saisissez manuellement les données CSV ou collez-les dans la zone Texte (mode Édition).
   • Pour importer des données à partir d'un fichier CSV ou TSV dans le tableau de données :
   1. Cliquez sur Importer un fichier.
   2. Accédez au fichier et cliquez sur Ouvrir. La boîte de dialogue Importer un fichier s'ouvre.
   3. Si vous avez sélectionné un fichier TSV à l'étape précédente, procédez comme suit :
      1. Dans la liste Type de séparateur, sélectionnez Détecter automatiquement ou Tabulation.
      2. Dans la liste Démarrer l'importation à la ligne, spécifiez la ligne du fichier à partir de laquelle importer les données.
   4. Cliquez sur Import data (Importer les données).

5. Sélectionnez le mode d'édition Table et configurez les éléments suivants selon vos besoins :

   • Mapper les types de données aux colonnes du tableau de données
   • Désigner des colonnes spécifiques comme colonnes clés
   • Désigner des colonnes spécifiques pour prendre en charge les champs répétés
   • Faire correspondre les noms de colonnes aux champs d'entité (facultatif)

6. Cliquez sur Enregistrer. La nouvelle table de données s'affiche dans la barre latérale Tables de données et est prête à recevoir des données supplémentaires.

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

Lorsque vous ajoutez un tableau de données, vous pouvez mapper des types de données (chaîne, expression régulière, CIDR ou nombre) à des colonnes de 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 d'une barre verticale (|). Dans l'interface Web, si une valeur inclut une barre verticale (|), 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 :

Field_value	Field_name
altostrat.com	Nom de domaine complet
192.0.2.135	IP
charlie	userid
exemple	nom d'hôte

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.

Nom de domaine complet	IP	Userid	Hostname (Nom d'hôte)
altostrat.com	192.0.2.135	charlie	exemple
…	…	…	…

Désigner les colonnes clés

Lorsque vous ajoutez une table de données, vous pouvez désigner des colonnes spécifiques comme colonnes clés.

Le fait de définir 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 de faciliter la découverte des données pour les règles et les recherches.

Remarque : Par défaut, toutes les colonnes sont traitées comme des colonnes clés, sauf indication contraire lors de la création de la table de données.

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

Lorsque vous ajoutez un tableau de données, vous pouvez 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 ajoutez un tableau de données, vous pouvez mapper les noms de colonnes du tableau de données aux champs entité.

Remarque : Le mappage des champs d'entité aux colonnes est facultatif et utilisé lorsque l'enrichissement d'entité est effectué. Pour en savoir plus, consultez Enrichir un graphique d'entités avec une table de données.

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 :

Userid (map to entity.user.userid)	E-mail	Rôle (map to entity.user.attribute.role.name)
cric	[e-mail]	administrateur
Tony	[e-mail]	ingénieur

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 :

1. Dans l'onglet Détails, sélectionnez le mode d'édition Tableau.
2. Effectuez un clic droit sur une ligne existante, puis sélectionnez Ajouter une ligne au-dessus.
3. Saisissez les données d'une nouvelle ligne. La première ligne est traitée comme un en-tête de tableau. Veillez à faire correspondre chaque élément de données à la colonne et au type de données appropriés.
4. Cliquez sur Enregistrer.

Remarque : Les lignes sont enregistrées dans un ordre aléatoire dans le tableau de données.

Modifier une ligne dans un tableau de données

Pour modifier une ligne, procédez comme suit :

1. Cliquez sur le champ que vous souhaitez modifier. Le champ devient modifiable.
2. Apportez les modifications souhaitées.
3. Cliquez sur Enregistrer.

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 du 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 Modifier 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.

Remarque : La valeur TTL appliquée au niveau de la table est héritée par les lignes. Toute modification apportée aux lignes existantes réinitialise le TTL de ces lignes. Lorsque vous ajoutez une ligne à la table, le TTL commence à partir du moment où la ligne a été créée.

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 l'une des lignes sélectionnées, 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 de la barre latérale.

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 tables 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 ajouté des tables de données à 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.

• Utiliser 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.

• Associer 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. Joignez le tableau de données à un événement ou à une entité UDM à l'aide de comparaisons basées sur les lignes ou basées sur les colonnes.

Comparaisons basées sur les lignes et les colonnes dans les tableaux de données

Type de comparaison	Logique clé	Opérateurs courants	Exemple de syntaxe	Cas d'utilisation
Basé sur les lignes	Toutes les conditions doivent correspondre dans la MÊME ligne.	=, !=, >, >=, <, <=	$e.field = %table.col_a	Lorsque la relation entre plusieurs valeurs de colonne sur la même ligne est importante.
Basé sur les colonnes	La valeur doit exister N'IMPORTE OÙ dans la colonne.	IN, IN regex, IN cidr	$e.field IN %table.col_b	Lorsque vous vérifiez la présence d'une valeur dans un ensemble de valeurs d'une même colonne.

Associez les événements UDM aux tables de données à l'aide des méthodes de comparaison basées sur les lignes ou basées sur les colonnes :

Comparaison basée sur les lignes pour associer les événements UDM aux tables de données

• Pour associer des événements UDM à des tables de données à l'aide d'une comparaison basée sur les lignes, utilisez des opérateurs d'égalité (=, !=, >, >=, <, <=).

  Par exemple : $<udm_variable>.<field_path> = %<data_table_name>.<column_name>

  • Si vous utilisez plusieurs instructions de comparaison, tous les champs ou toutes les 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 avec une table de données join comme une règle multi-événements, qui nécessite une section match dans la définition de la règle.

• Pour filtrer les données en faisant correspondre les valeurs des événements UDM aux lignes du tableau de données, utilisez la syntaxe de jointure suivante :

  • Syntaxe correcte pour une jointure :

    L'exclusion de combinaison basée sur les lignes nécessite, par exemple, une jointure left outer et une clause where vérifiant la présence de nulls.

  • Syntaxe de jointure incorrecte :

    N'encapsulez pas NOT autour de plusieurs conditions d'égalité basées sur des lignes. Cette syntaxe n'a pas pour effet d'exclure les résultats si cette combinaison est trouvée.

    Par exemple, n'utilisez pas la syntaxe suivante : NOT (field1 = %table.col1 AND field2 = %table.col2)

    En effet, la correspondance est toujours appliquée ligne par ligne. Si une ligne ne respecte pas la condition combinée interne, NOT entraîne l'évaluation de cette ligne sur true, ce qui peut inclure l'événement au lieu de l'exclure.

• 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>)
  

Comparaison basée sur les colonnes pour associer les événements UDM aux tables de données

• Pour associer des événements UDM à des tables de données à l'aide d'une comparaison basée sur les colonnes, utilisez le mot clé in.

  Par exemple : $<udm_variable>.<field_path> in %<data_table_name>.<column_name>

• Pour exclure les événements dont la valeur du champ existe dans la colonne spécifiée (par exemple, une liste noire ou une liste blanche), utilisez la syntaxe suivante : NOT (... IN %table.column)

  Par exemple : not ($evt_username in %my_data_table.username)

• Pour utiliser une colonne de type CIDR ou regex d'un tableau de données 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 qui sont des types de données CIDR ou d'expressions régulières, 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. Bien qu'une liste de référence puisse 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 le tableau 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
  

Jointures basées sur les lignes entre une table de données et un événement ou une entité UDM

Vous pouvez associer des événements UDM à un tableau 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 une table de données join comme une règle multi-événements, qui nécessite une section match correspondante 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.

• Les espaces réservés sont acceptés pour les tableaux de données dans la section event d'une requête, mais ils doivent être associés à un événement ou à une entité UDM.

  L'exemple suivant utilise une colonne de tableau de données de type string.

  • Cet exemple de requête YARA-L vérifie si un événement de connexion utilisateur correspond à une ligne dans example_table.

  • L'une des conditions est que le user ID existe dans le example_table.

  • Les deux conditions doivent correspondre à la même ligne dans example_table 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 :

// Check if user exists in a data table and is active in all user login events.
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 data table 
// where the uid in the data table row is the userid on the event 
// and the active date in the same data 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 data table 
// where the uid in the data table row is the userid on the event 
// and the active date in the same data table row is before the event timestamp

%example_table.uid = $userid
$e.principal.hostname = %example_table.hostname

• L'exemple suivant illustre la façon dont une table de données et des données d'événement UDM fonctionnent ensemble.

  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.

  Tableau de données
  uid	title	hostname
  32452	RH	host1
  64452	Finance	host2
  46364	IT	host3

  Tableau des événements UDM
  principal	metadata	security_result	principal
  32452	USER_LOGIN	AUTORISER	host1
  64589	USER_LOGIN	AUTORISER	host9
  87352	USER_LOGIN	AUTORISER	host4

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

Vous pouvez écrire les résultats des requêtes YARA-L dans une table 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 le renseignement 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 tables 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)

Adresse IP	employee_id*	domaine
192.0.2.10	Dana	altostrat.com
192.0.2.20	Quinn	altostrat.com
192.0.2.30	Lee	cymbalgroup.com

* indique la clé primaire.

Remarque : La clé primaire peut être une combinaison de plusieurs colonnes, bien qu'il s'agisse d'une seule colonne dans cet exemple.

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 :

ip	empid	domaine
192.0.2.10	Dana	altostrat.com
192.0.2.30	Lee	examplepetstore.com
192.0.2.20	Quinn	altostrat.com

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 d'é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 :

  ID de détection	Correspondance $user	Correspondance $ip
  0	charlie	192.0.2.135
  1	charlie	192.0.2.136

  La table de données contient les éléments suivants :

  Utilisateur	ip
  charlie	192.0.2.135
  charlie	192.0.2.136

Remarque : Si vous cliquez sur Exécuter le test dans l'éditeur de règles pour vérifier une règle, les exemples de données ne sont pas conservés dans le tableau de données.

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

  Remarque : Cette fonctionnalité n'est pas disponible dans les règles.

  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 un 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, y être ajoutée ou être utilisée pour supprimer des entités de ces événements.

Remarque : Cette fonctionnalité n'est pas compatible avec la recherche.

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.

  Par 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 la table 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)

  Il est impossible de mapper les colonnes de tableau de données sur des 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.

  Par 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 le tableau de données sont remplacés par les champs du tableau 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 placé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.

Graphique d'entités existant
Hostname (Nom d'hôte)	IP	MAC
ftp01	10.1.1.4	…:01
www01	10.1.1.5	…:02

Tableau de données
Hostname (Nom d'hôte)	IP	MAC	Propriétaire
ftp01	10.1.1.4	…:bb	alice
h1	10.1.1.6	…:cc	bob
h2	10.1.1.7	…:dd	chris
h3	10.1.1.4	…:ee	doug

Graphique d'entités enrichi
Hostname (Nom d'hôte)	IP	MAC	Propriétaire
ftp01	10.1.1.4	…:bb	alice
www01	10.1.1.5	…:02
h3	10.1.1.4	…:ee	doug

Exemple : Correspondance sur 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 d'adresse IP et le champ de nom d'hôte du tableau de données correspondent au champ d'adresse IP et au champ de nom d'hôte du graphique d'entités.

Graphique d'entités existant
Hostname (Nom d'hôte)	IP	MAC
ftp01	10.1.1.4	…:01
www01	10.1.1.5	…:02

Tableau de données
Hostname (Nom d'hôte)	IP	MAC	Propriétaire
ftp01	10.1.1.4	…:bb	alice
h1	10.1.1.5	…:cc	bob
h2	10.1.1.6	…:dd	chris
h3	10.1.1.4	…:ee	doug

Graphique d'entités enrichi
Hostname (Nom d'hôte)	IP	MAC	Propriétaire
ftp01	10.1.1.4	…:bb	alice
www01	10.1.1.5	…:02

Ajouter des données du tableau 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.

Remarque : Les lignes ajoutées au graphique d'entités ne sont pas dédupliquées. Cela signifie que si une ligne est présente à la fois dans le graphique d'entités et dans le tableau de données, les deux lignes sont présentes dans le graphique d'entités enrichi.

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 :

Graphique d'entités existant
Hostname (Nom d'hôte)	IP	MAC
ftp01	10.1.1.4	…:01
www01	10.1.1.5	…:02

Tableau de données
IP	MAC	Propriétaire
10.1.1.4	…:01	alice
10.1.1.6	…:cc	bob
10.1.1.7	…:dd	chris
10.1.1.4	…:ee	doug

Graphique d'entités enrichi
Hostname (Nom d'hôte)	IP	MAC	Propriétaire
ftp01	10.1.1.4	…:01
www01	10.1.1.5	…:02
	10.1.1.4	…:bb	alice
	10.1.1.6	…:cc	bob
	10.1.1.7	…:dd	chris
	10.1.1.4	…:ee	doug

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" du tableau de données sont supprimées :

Graphique d'entités existant
Hostname (Nom d'hôte)	IP	MAC
ftp01	10.1.1.4	…:01
www01	10.1.1.5	…:02

Tableau de données
IP	MAC	Propriétaire
10.1.1.4	…:bb	alice
10.1.1.6	…:cc	bob
10.1.1.7	…:dd	chris

Graphique d'entités enrichi
Hostname (Nom d'hôte)	IP	MAC
www01	10.1.1.5	…:02

Limites

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

• Les tableaux de données n'acceptent que les données CSV. Les tables de données n'acceptent les valeurs séparées par des tabulations que lorsque vous ajoutez une table de données et importez un fichier TSV (valeurs séparées par des tabulations).

• Les champs de tableau de données ne sont pas compatibles avec les virgules (,).

• 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 pour les colonnes de type de données String et Number : 7.

• Nombre maximal d'instructions in avec des opérateurs d'expressions régulières : 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 maximale du volume de données agrégées dans les tables de données d'un compte est de 1 To.

• La limite d'affichage des lignes de tableau de données dans la vue de l'éditeur de texte et de tableau sur une page Web est de 10 000 lignes.

• La taille maximale des fichiers importés pour la création de tables de données est de 10 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'avec 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 des expressions régulières ne sont pas acceptés et les termes de recherche sont limités à 100 caractères.

Limites pour les jointures de tables de données dans les règles

Les limites suivantes s'appliquent aux jointures de tables de données dans les règles.

• Il n'est pas possible d'extraire 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 entraîne les limites suivantes :

  • Vous ne pouvez pas appliquer un ensemble de filtres à un tableau de données et le joindre à une entité UDM.

  • Vous ne pouvez pas appliquer un autre ensemble de filtres à la même table de données lorsque vous la joignez à 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 avec 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, les filtres contradictoires (%dt.org ="hr" and %dt.org !="hr") de la table dt entraînent la création d'une table de données vide, qui est ensuite jointe à e1 et e2.

Limites de l'utilisation 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.

Limites de la 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 tableaux de données.

Limites pour les sorties vers les tables de données

• Les modificateurs any et all ne sont pas acceptés pour les colonnes de champs répétés dans les tableaux 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 chemins d'événements ni les colonnes du tableau de données.

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

• Vous pouvez définir jusqu'à 20 résultats.

• Si une table de données n'existe pas, une table est créée avec le type de données string 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.

• Le nombre de lignes de résultats est limité pour une même règle. Une limite de 10 000 lignes s'applique aux résultats,aux données persistantes et aux tableaux de données.

• Lorsque vous mettez à jour une ligne, les nouvelles valeurs de toutes les colonnes non clés remplacent les anciennes. Toute modification, y compris l'ajout d'une ligne, prend environ cinq minutes avant d'être disponible pour les requêtes.

Limites de l'enrichissement d'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 utiliser qu'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 override 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, la même table de données (table1) est utilisée 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]

Limites de l'utilisation 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. Les requêtes ne sont acceptées que via l'interface Web.

• Une seule exécution de requête peut générer un maximum de 1 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 utilisateurs de clés de chiffrement gérées par le client (CMEK).

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

• L'assistance API n'est pas disponible pour les opérations sur les tableaux de données liées à la recherche.

• 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 la section export d'une requête statistique.

  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.