Utiliser des tableaux de données
Les tables de données sont des constructions de données multicolonnes qui vous permettent de saisir vos propres données dans Google Security Operations. Ils peuvent servir de tables de référence avec des colonnes définies et les données stockées dans des lignes. Vous pouvez créer ou importer un tableau de données dans votre compte Google SecOps à l'aide de l'interface utilisateur Google SecOps, de l'API des tableaux de données ou d'une requête YARA-L dans les règles.
Gérer les tables de données à l'aide de l'interface utilisateur Google SecOps
Les sections suivantes expliquent comment gérer les tables de données à l'aide de l'interface utilisateur. Vous découvrirez comment accéder à vos tables de données, en ajouter une et en modifier le contenu, importer des données dans votre table, ajouter des lignes, séparer les données à l'aide de virgules ou d'onglets, et supprimer une table de données de votre compte.
Accéder à vos tables de données
Pour accéder à la page des tableaux de données, accédez à la barre latérale de navigation de gauche, puis cliquez sur Détections > Tableaux de données. Vous pouvez rechercher un tableau de données existant en saisissant son nom dans le champ de recherche 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:
Cliquez sur Ajouter Ajouter en haut à droite de la barre latérale.
Dans la boîte de dialogue Créer un tableau de données, attribuez un nom à la nouvelle table et ajoutez une description (facultatif).
Cliquez sur Créer. Le nouveau tableau de données s'affiche dans la fenêtre principale et est prêt à accepter des données.
Importer des données dans votre table de données
Pour ajouter des données à votre tableau de données, vous pouvez les importer directement dans Google SecOps comme suit:
Cliquez sur Import data (Importer les données).
Sélectionnez un fichier CSV standard (seuls les fichiers CSV peuvent être importés dans Google SecOps).
Cliquez sur Ouvrir lorsque vous êtes prêt à importer les données dans votre table de données.
Ajouter une ligne de données à votre tableau de données
Pour ajouter manuellement une ligne de données à un tableau de données, vous pouvez la saisir directement, la première ligne servant d'en-tête. Pour ce faire, procédez comme suit:
Dans l'onglet Détails, placez le curseur à la fin d'une ligne existante, puis appuyez sur Entrée.
Saisissez une nouvelle ligne de données:
- Séparez les champs de données à l'aide de virgules ou de tabulations.
- Assurez-vous de faire correspondre chaque élément de données à la colonne de données appropriée.
- Lorsque vous saisissez les données d'une ligne dans l'onglet Détails, elles sont renseignées dans l'éditeur de table.
Spécifier si les données doivent être séparées par des virgules ou des tabulations
Pour séparer les données à l'aide de virgules ou d'onglets, procédez comme suit:
Cliquez sur Modifier le type de séparateur à côté de Importer les données.
Dans la boîte de dialogue Modifier le type de séparateur, sélectionnez Virgule ou Tabulation dans le menu Séparateur.
Supprimer un tableau de données
Pour supprimer une table de données:
Sélectionnez une table de données dans la liste Tables de données sur la gauche.
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 offre des fonctionnalités équivalentes à l'interface utilisateur, et inclut des fonctionnalités supplémentaires qui vous permettent de gérer des tableaux de données avec plus de performances et à plus grande échelle.
Voici les ressources REST de la table de données:
Utiliser des tableaux de données dans Google SecOps
Une fois que vous avez importé des tableaux de données dans votre instance Google SecOps, vous pouvez les utiliser pour filtrer, améliorer et enrichir vos données à l'aide de règles. Ce document inclut de nombreux exemples en syntaxe YARA-L que vous pouvez intégrer aux règles Google SecOps de votre instance. Pour savoir comment modifier des règles dans Google SecOps, consultez Gérer les règles à l'aide de l'éditeur de règles.
Vous pouvez utiliser des tables de données avec des règles de plusieurs manières:
Filtrer les données d'événement ou d'entité 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.
Associez un tableau de données à un événement ou une entité. Vous pouvez associer des événements UDM à un tableau de données à l'aide de l'opérateur d'égalité pour effectuer une comparaison basée sur les lignes. Cette comparaison vous permet de filtrer les données. Pour qu'une comparaison basée sur les lignes soit évaluée comme vraie, toutes les conditions de l'instruction doivent être satisfaites par une ligne.
Utilisez 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, les tables de données vous permettent d'accéder aux données de plusieurs dimensions, ce qui permet de les filtrer.
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 deux manières:
Utilisation d'un opérateur d'égalité (
=, !=, >, >=, <, <=) pour une comparaison basée sur les lignes. Exemple :$<udm_variable>.<field_path> = %<data_table_name>.<column_name>Utilisation du mot clé
inpour une 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 compatibles pour chaque colonne de la table de données peuvent être string, regex ou CIDR.
Pour utiliser une colonne de table de données de type CIDR ou d'expression régulière 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 table de données de type CIDR ou d'expression régulière pour une comparaison basée sur les colonnes, utilisez la syntaxe suivante:
$e.principal.ip in cidr %cidr_data_table.column_name
$e.principal.hostname in regex %regex_data_table.column_name
Si vous avez spécifié le type de données de la colonne en tant que CIDR ou expression régulière, excluez le mot clé cidr ou regex.
Vous pouvez également utiliser l'opérateur not avec des tables de données. L'exemple de règle 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 cidr %cidr_data_table.benign_ip
Associer une table de données à un événement ou une entité UDM
Vous pouvez utiliser une table de données pour filtrer les événements UDM à l'aide de l'opérateur d'égalité (=, !=, >, >=, <, <=) pour effectuer une comparaison par ligne.
Dans l'exemple suivant, la règle YARA-L vérifie qu'un utilisateur se connecte et que son ID utilisateur existe dans la table de données (example_table). Dans la même ligne de la table de données où la correspondance s'est produite, elle vérifie également si le compte utilisateur est actif avant l'enregistrement de l'événement de connexion.
// Check if a user exists in a data table and the user is active for all user login events.
rule udm_join_data_table {
meta:
description = "Join data table with UDM event"
event:
$e.metadata.event_type = USER_LOGIN
$e.security_result.action = ALLOW
$e.principal.user.userid = $userid
// Event must match at least one row in the table where the uid in the table
// row is the userid for 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
}
L'exemple suivant illustre un tableau de données et des données d'événement UDM. D'après la logique de la règle YARA-L précédente, un utilisateur avec l'ID utilisateur 32452 apparaît dans la détection, car le nom d'hôte de l'utilisateur dans le système correspond au nom d'hôte dans la table 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 |
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, les tables de données vous permettent d'accéder aux données de plusieurs dimensions, ce qui permet de les filtrer.
Vous pouvez associer des événements UDM à un tableau de données à l'aide du mot clé in pour effectuer des comparaisons basées sur les colonnes.
Les tables de données peuvent être référencées en tant que listes de référence multicolonnes à l'aide de la même syntaxe que les listes de référence:
%<data_table_name>.<column_name>.
Dans l'exemple suivant, des alertes sont déclenchées pour les connexions réseau avec des combinaisons de port et de protocole suspectes. Port et protocol sont des colonnes de la table de données badApps.
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 port matches at least one value in table column port
$e.target.port in %badApps.port
// event IP matches at least 1 value in table column protocol
$e.target.network.ip in %badApps.ip
match:
$assetid over 1h
condition:
$e
}
Mappage des types de données sur les colonnes d'une table de données
Mappez chaque type de données sur une seule colonne de la table de données. Toute colonne contenant des valeurs pour plusieurs champs doit être fractionnée avant de pouvoir être utilisée comme table de données.
Dans l'exemple suivant, la colonne Field_value du tableau de données contient des valeurs pour plusieurs champs:
| Valeur_champ | Field_name |
| altostrat.com | Nom de domaine complet |
| 192.0.2.135 | IP |
| charlie | ID utilisateur |
| exemple | nom d'hôte |
Le tableau précédent est divisé en quatre colonnes, chacune ne correspondant qu'à un seul type de champ avant de pouvoir être utilisée pour l'un des cas d'utilisation des tableaux de données présentés dans ce document.
| Nom de domaine complet | Adresse IP | Userid | Hostname (Nom d'hôte) |
| altostrat.com | 192.0.2.135 | charlie | exemple |
| … | … | … | … |
Mappez les noms de colonnes sur les champs d'entité.
Lorsque vous créez une table de données, vous pouvez mapper les noms de colonne de la table de données sur des champs d'entité.
Dans l'exemple de tableau de données suivant, les colonnes Userid et Role sont mappées sur entity.user.userid et entity.user.attribute.role.name:
| Userid
(map to entity.user.userid) |
Rôle
(map to entity.user.attribute.role.name) |
|
| connecteur | jack123@gmail.com | admin |
| tony | tony123@gmail.com | ingénieur |
La colonne Email ne peut pas être mappée sur le chemin d'entité entity.user.email_address, car il s'agit d'un champ répété. Vous ne pouvez pas mapper une colonne d'un tableau de données à un champ répété.
Vous pouvez mapper une colonne d'une table de données sur un champ proto d'entité à l'aide du champ mapped_column_path de la ressource DataTable.
Pour les colonnes pour lesquelles aucun chemin d'accès à l'entité n'est défini, comme Email dans cet exemple de table, vous devez définir un type de données. Comme pour les listes de référence, les types de données compatibles pour les tableaux de données sont string, regex et cidr.
Vous pouvez spécifier des colonnes mappées et non mappées dans le tableau de données à l'aide de la condition de jointure. Les colonnes non mappées sont envoyées au champ additional de l'entité (à laquelle la table de données est jointe) sous forme de paires clé-valeur, où la clé correspond au nom de la colonne et la valeur à la valeur de ligne de cette colonne.
É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. Grâce à cette fonctionnalité, vous pouvez créer des tableaux de données à partir de vos données Google SecOps et les utiliser pour filtrer et améliorer d'autres données.
Vous pouvez utiliser la syntaxe des règles YARA-L pour les tables de données dans les cas suivants:
Définissez une syntaxe YARA-L pour écrire les résultats des règles dans des tables de données. Vous pouvez utiliser la même syntaxe pour la recherche et les tableaux de bord.
Utilisez des tables de données pour l'intelligence sur les menaces, la gestion des incidents et d'autres cas d'utilisation de la sécurité.
Assurez-vous que les données sont cohérentes avec les conventions YARA-L.
Écrire des détections et des alertes dans des tables de données à l'aide de règles
Vous pouvez utiliser des règles YARA-L pour envoyer des détections et des alertes à des tableaux de données.
À l'aide de la fonction write_row, vous pouvez écraser une ligne de table de données avec la clé correspondante dans la table de données à l'aide des résultats d'une règle. Si la clé n'est pas trouvée 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 la table de données doit être la dernière action de la règle. Cela garantit que les variables de résultat sont écrites dans la table 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 un tableau de données à l'aide de YARA-L:
TableName:ip_user_domain_table (les colonnes de clé pour la clé primaire sont définies lors de la création)
| ip_address | employee_id* | domaine |
| 192.0.2.10 | Dana | altostrat.com |
| 192.0.2.20 | Quinn | altostrat.com |
| 192.0.2.30 | Lee | cymbalgroup.com |
* correspond à la clé primaire.
La règle 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 l'target.domain:
rule unique_principal_userid_and_ip_and_target_domain_with_low_prevalence {
meta:
author = "GP"
description = "Captures unique combinations of principal.ip,
principal.user.employee_id, and target.domain where
target.domain.prevalence is less than 5"
rule_version = "1.0"
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
condition:
$e
}
Résultats de la règle:
| 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 la sortie de la règle dans une table de données
rule write_to_data_table {
meta:
author = "GP"
description = "Captures uniqueprincipal.user.employee_id, and target.domain where target.domain.prevalence is less than 5"
rule_version = "1.0"
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: Comprendre write_row
Dans l'exemple suivant, user et ip sont des clés primaires. Chaque détection qui persiste dans la table des détections génère une évaluation de l'appel de fonction dans la section d'exportation de la règle.
Voici la règle:
rule successful_logins_by_user_to_ip {
meta:
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(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:
| ID de détection | Correspondre à $user | Correspondre à $ip |
| 0 | charlie | 192.0.2.135 |
| 1 | charlie | 192.0.2.136 |
Le tableau de données contient les éléments suivants:
| Utilisateur | ip |
| charlie | 192.0.2.135 |
| charlie | 192.0.2.136 |
Enrichir le graphique des entités avec un tableau 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 des entités. Utilisez des fonctions dans la section setup de la règle pour indiquer comment la table de données doit être fusionnée, ajoutée ou utilisée pour supprimer des entités des événements d'entité référencés dans la section events.
Vous pouvez utiliser le modèle de règle suivant pour modifier un graphique d'entité:
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 des entités avec un tableau de données:
graph_override: écrasez les lignes du graphique des 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 aux lignes du graphique des entités. L'opérationgraph_appendnécessite un tableau qui inclut une variable de table de données et une variable d'événement d'entité plutôt qu'une condition de jointure.Dans l'exemple suivant,
$g1est la variable de graphique d'entité etexample_tableest la table de données:graph_append [$g1, %example_table]graph_exclude: supprimez les lignes du graphique des entités qui correspondent à la condition de jointure.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 le <entity_variable> dans la section "Événement" est appliqué après avoir été amélioré avec le tableau de données.
Une fois que l'entité du graphique des entités est enrichie de l'entité de la table de données, la variable d'entité du graphique des entités doit être jointe à l'entité UDM.
Remplacer le graphique des entités par les données d'un tableau de données
Avec la fonction graph_override, les champs présents à la fois dans le graphique des entités et dans la table de données sont remplacés par des champs de la table de données. Les champs présents dans le graphique des entités et non dans le tableau de données restent les mêmes. Les champs qui ne figurent pas dans le graphique des entités, mais qui figurent dans la table de données sont inclus.
Seules les colonnes de la table de données qui sont mappées remplacent les colonnes du graphique des entités. Les colonnes non mappées sont ajoutées au champ additional du graphique des entités sur lequel la table de données est jointe.
Exemple: Correspondance avec une seule jointure
Dans l'exemple suivant, les lignes du graphique des entités qui correspondent à la condition de jointure entre la colonne du tableau de données et le champ du graphique des entités ($g1.graph.entity.ip = %example_table.my_ip) sont remplacées par le tableau 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, "Owner") 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 de la table de données sont placées dans le champ additional du graphique des entités ($g1).
Les tableaux suivants illustrent une opération de forçage dans laquelle les lignes du graphique des entités sont enrichies lorsque le champ d'adresse IP du tableau de données correspond au champ d'adresse IP du graphique des entités.
| Graphique des entités existant | ||
| Hostname (Nom d'hôte) | Adresse IP | MAC |
| ftp01 | 10.1.1.4 | …:01 |
| www01 | 10.1.1.5 | …:02 |
| Tableau de données | |||
| Hostname (Nom d'hôte) | Adresse 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é enrichi | |||
| Hostname (Nom d'hôte) | Adresse 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 avec plusieurs jointures
Dans l'exemple suivant, les lignes du graphique des entités qui correspondent aux différentes 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 forçage dans laquelle les lignes du graphique des entités sont enrichies lorsque le champ d'adresse IP et le champ de nom d'hôte de la table de données correspondent au champ d'adresse IP et au champ de nom d'hôte du graphique des entités.
| Graphique des entités existant | ||
| Hostname (Nom d'hôte) | Adresse IP | MAC |
| ftp01 | 10.1.1.4 | …:01 |
| www01 | 10.1.1.5 | …:02 |
| Tableau de données | |||
| Hostname (Nom d'hôte) | Adresse 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é enrichi | |||
| Hostname (Nom d'hôte) | Adresse IP | MAC | Propriétaire |
| ftp01 | 10.1.1.4 | …:bb | alice |
| www01 | 10.1.1.5 | …:02 | |
Ajouter les données du tableau de données au graphique des entités
Avec la fonction graph_append, aucune condition de jointure n'est requise.
Dans l'exemple suivant, toutes les lignes de la table de données sont ajoutées aux lignes du graphique des 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
}
L'exemple de tableau suivant illustre une opération d'ajout où les lignes de la table de données sont ajoutées aux lignes du graphique des entités:
| Graphique des entités existant | ||
| Hostname (Nom d'hôte) | Adresse IP | MAC |
| ftp01 | 10.1.1.4 | …:01 |
| www01 | 10.1.1.5 | …:02 |
| Tableau de données | |||
| Hostname (Nom d'hôte) | Adresse 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é enrichi | |||
| Hostname (Nom d'hôte) | Adresse 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 des entités
Avec la fonction graph_exclude, les lignes du graphique des entités qui correspondent à la condition de jointure sont supprimées du graphique des entités.
Dans l'exemple suivant, toutes les lignes du graphique des entités qui correspondent à la condition de jointure donnée (entre la colonne de la table de données et le champ du graphique des entités) sont supprimées. Aucune ligne de la table de données n'est ajoutée au graphique des 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 des entités correspondant au champ d'adresse IP du tableau de données sont supprimées:
| Graphique des entités existant | ||
| Hostname (Nom d'hôte) | Adresse IP | MAC |
| ftp01 | 10.1.1.4 | …:01 |
| www01 | 10.1.1.5 | …:02 |
| Tableau de données | ||
| Adresse 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é enrichi | ||
| Hostname (Nom d'hôte) | Adresse IP | MAC |
| www01 | 10.1.1.5 | …:02 |
Limites
Les limites concernant le nombre d'instructions
inlors de la référence à une liste de référence dans une règle s'appliquent également aux instructionsindans une table de données.Seuls les fichiers CSV sont acceptés pour les importations.
La taille maximale d'une table de données est de 10 Go.
La limite globale maximale du volume de données dans les tables de données d'un locataire est de 1 To.
Nombre maximal d'instructions
indans une règle, avec ou sans opérateurs spéciaux: 7Nombre maximal d'instructions
inavec l'opérateurregex: 4Nombre maximal d'instructions
inavec l'opérateurcidr: 2Les espaces réservés ne sont pas autorisés dans la nouvelle section de configuration.
Les colonnes non mappées d'un tableau de données dont le type de données est défini sur
stringne peuvent être jointes qu'avec les champs de chaîne de l'événement ou de l'entité UDM.N'utilisez que des colonnes non mappées dans une table de données dont le type de données est défini sur
cidrouregexpour les adresses CIDR ou les expressions régulières.Vous ne pouvez pas mapper la colonne d'une table de données à un champ répété.
Utiliser des tableaux de données avec des règles
Les limites suivantes s'appliquent aux tables de données lorsqu'elles sont utilisées 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 contenant des tables de données.
Jointures
Contrairement aux entités et aux UDM, les tables de données n'acceptent pas les espaces réservés. Cela signifie que vous ne pouvez pas appliquer un ensemble de filtres à une table de données, la joindre à une entité UDM, puis appliquer un autre ensemble de filtres à la même table de données tout en la combinant à une autre variable d'espace réservé UDM.
Par exemple, une table de données nommée
dtavec trois colonnes:my_hostname,orgetmy_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, 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").
Sortie dans des tableaux de données
Vous ne pouvez exporter les variables de résultat que vers une table de données. Vous ne pouvez pas exporter directement le chemin d'accès aux é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 ne pouvez pas avoir plus de 20 résultats.
Les colonnes d'une table de données n'acceptent pas les valeurs répétées. Par conséquent, toutes les variables de résultat écrites dans une table de données doivent être des valeurs uniques.
Si aucune table de données n'existe, une table est créée avec le type de données de 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 sur laquelle une autre règle écrit déjà, 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 d'une règle est limité. 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 de clé non primaire seront remplacées par les nouvelles valeurs.
Vous ne pouvez appliquer qu'une seule opération d'enrichissement (
override,appendouexclude) à une seule variable de graphique d'entité.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
setupd'une règle YARA-L.
Dans l'exemple suivant, une opération de forçage est appliquée à la variable de graphique d'entité $g1 et une opération append est appliquée à la variable de graphique d'entité $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érents tableaux 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]