Esta página foi traduzida pela API Cloud Translation.

Usar tabelas de dados

Compatível com:

Google SecOps SIEM

As tabelas de dados são construções de dados com várias colunas que permitem inserir seus dados no Google Security Operations. Elas podem funcionar como tabelas de pesquisa com colunas definidas e os dados armazenados em linhas. É possível criar ou importar uma tabela de dados para sua conta do Google SecOps usando a interface do Google SecOps, a API Data Tables ou uma consulta YARA-L em regras.

Gerenciar tabelas de dados usando a interface do usuário do Google SecOps

As seções a seguir descrevem como gerenciar tabelas de dados usando a interface do usuário, incluindo como acessar as tabelas, adicionar uma nova tabela de dados e editar o conteúdo, importar dados para a tabela, adicionar linhas, separar dados usando vírgulas ou guias e como remover uma tabela de dados da sua conta.

Acessar suas tabelas de dados

Para acessar a página de tabelas de dados, acesse a barra lateral de navegação à esquerda e clique em Detecções > Tabelas de dados. Para pesquisar uma tabela de dados, digite o nome dela no campo de pesquisa na parte de cima da barra lateral.

Adicionar uma nova tabela de dados

Para adicionar uma nova tabela de dados ao Google SecOps, siga estas etapas:

Clique em add Add no canto superior direito da barra lateral.
Na caixa de diálogo Criar nova tabela de dados, dê um nome à nova tabela e (opcional) adicione uma descrição.
Clique em Criar. A nova tabela de dados aparece na janela principal e está pronta para receber dados.

Importar dados para a tabela de dados

Para adicionar dados à tabela, importe-os diretamente para o Google SecOps da seguinte maneira:

Clique em Importar dados.
Selecione um arquivo CSV padrão. Somente arquivos CSV podem ser importados para o Google SecOps.
Clique em Abrir quando estiver tudo pronto para importar os dados para a tabela.

Adicionar uma nova linha de dados à tabela de dados

Para adicionar manualmente uma nova linha de dados a uma tabela de dados, insira-a diretamente, com a primeira linha servindo como cabeçalho da tabela. Para fazer isso, siga estas etapas:

Na guia Detalhes, coloque o cursor no final de uma linha e pressione Enter.
Insira uma nova linha de dados:
1. Separe os campos de dados usando vírgulas ou tabulações.
2. Associe cada item de dados à coluna de dados adequada.
3. Ao inserir os dados de uma linha na guia Detalhes, eles são preenchidos no Editor de tabelas.

Especificar se usar vírgulas ou tabulações para separar dados

Para separar dados usando vírgulas ou tabulações, faça o seguinte:

Clique em Editar tipo de separador ao lado de Importar dados.
Na caixa de diálogo Editar tipo de separador, selecione Vírgula ou Tab no menu Separador.

Remover uma tabela de dados

Para remover uma tabela de dados:

Selecione uma tabela de dados na lista Tabelas de dados à esquerda.
Clique em Excluir.

Gerenciar tabelas de dados usando a API Chronicle

Também é possível usar os recursos REST disponíveis na API Chronicle para gerenciar tabelas de dados no Google SecOps. A API tem uma funcionalidade equivalente à interface do usuário e inclui alguns recursos adicionais que permitem gerenciar tabelas de dados com mais desempenho e escala.

Confira os recursos REST da tabela de dados:

Usar tabelas de dados no Google SecOps

Depois de importar tabelas de dados para sua instância do Google SecOps, você pode usá-las para filtrar, aprimorar e enriquecer seus dados usando regras. Este documento inclui vários exemplos na sintaxe YARA-L, que podem ser incorporados às regras do Google SecOps na sua instância. Para mais informações sobre como editar regras no Google SecOps, consulte Gerenciar regras usando o Rules Editor.

É possível usar tabelas de dados com regras das seguintes maneiras:

Filtrar dados de eventos ou entidades do UDM usando uma tabela de dados. É possível filtrar eventos e entidades de telemetria do UDM comparando-os com entradas em uma tabela de dados.
Agrupar uma tabela de dados com um evento ou entidade. É possível vincular eventos do UDM a uma tabela de dados usando o operador de igualdade para comparação baseada em linha. Essa comparação permite filtrar os dados. Para que uma comparação baseada em linha seja avaliada como verdadeira, todas as condições na instrução precisam ser correspondidas por uma linha.
Use uma tabela de dados como uma lista de referência com várias colunas. É possível usar uma tabela de dados como uma lista de referência com várias colunas. Enquanto uma lista de referência pode acessar dados em uma única dimensão, as tabelas de dados permitem acessar dados em várias dimensões, o que possibilita a filtragem de dados.

Filtrar dados de eventos e entidades do UDM usando uma tabela de dados

É possível filtrar eventos e entidades do UDM comparando-as com entradas em uma tabela de dados.

Vincule eventos do UDM a tabelas de dados de duas maneiras:

Usar um operador de igualdade (=, !=, >, >=, <, <=) para comparação com base na linha. Por exemplo, $<udm_variable>.<field_path> = %<data_table_name>.<column_name>.
Usar a palavra-chave in para comparação com base na coluna. Por exemplo, $<udm_variable>.<field_path> in %<data_table_name>.<column_name>.

Assim como nas listas de referência, os tipos de dados compatíveis para cada coluna da tabela de dados podem ser string, regex ou CIDR.

Para usar uma coluna de tabela de dados do tipo CIDR ou uma expressão regular para comparação baseada em linha, use a seguinte sintaxe:

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

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

Para usar uma coluna de tabela de dados do tipo CIDR ou uma expressão regular para comparação com base em colunas, use a seguinte sintaxe:

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

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

Se você especificou o tipo de dados da coluna como CIDR ou expressão regular, exclua a palavra-chave cidr ou regex.

Também é possível usar o operador not com tabelas de dados. A regra de exemplo a seguir filtra entradas em que os endereços IP ($e.principal.ip) não correspondem a nenhum dos intervalos CIDR listados na coluna benign_ip em cidr_data_table:

not $e.principal.ip in cidr %cidr_data_table.benign_ip

Combinar uma tabela de dados com um evento ou entidade do UDM

É possível usar uma tabela de dados para filtrar eventos da UDM usando o operador de igualdade (=, !=, >, >=, <, <=) para comparação baseada em linha.

No exemplo a seguir, a regra YARA-L verifica se, quando um usuário faz login, o ID do usuário existe na tabela de dados (example_table). Na mesma linha da tabela de dados em que a correspondência ocorreu, ela também verifica se a conta do usuário está ativa antes do evento de login ser registrado.

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

O exemplo a seguir ilustra uma tabela de dados e dados de eventos do UDM. Com base na lógica da regra YARA-L anterior, um usuário com o ID 32452 aparece na detecção, porque o nome de host do usuário no sistema corresponde ao nome de host na tabela de dados.

Tabela de dados
uid	title	hostname
32452	RH	host1
64452	Finanças	host2
46364	TI	host3

Tabela de eventos da UDM
principal	metadata	security_result	principal
32452	USER_LOGIN	PERMITIR	host1
64589	USER_LOGIN	PERMITIR	host9
87352	USER_LOGIN	PERMITIR	host4

Usar uma tabela de dados como uma lista de referência com várias colunas

Você pode usar uma tabela de dados como uma lista de referência com várias colunas. Enquanto uma lista de referência pode acessar dados em uma única dimensão, as tabelas de dados permitem acessar dados em várias dimensões, o que possibilita a filtragem de dados.

É possível vincular eventos do UDM a uma tabela de dados usando a palavra-chave in para comparação baseada em colunas.

As tabelas de dados podem ser referenciadas como listas de referência de várias colunas usando a mesma sintaxe usada pelas listas de referência:

%&lt;data_table_name>.&lt;column_name>.

No exemplo a seguir, os alertas são acionados para conexões de rede com combinações de porta e protocolo suspeitas. Port e protocol são colunas na tabela de dados 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
}

Mapear tipos de dados para colunas únicas da tabela de dados

Mapeie cada tipo de dados para uma única coluna da tabela de dados. Qualquer coluna que contenha valores para vários campos precisa ser dividida antes de ser usada como tabelas de dados.

No exemplo abaixo, a coluna Field_value da tabela de dados contém valores para vários campos:

Field_value	Field_name
altostrat.com	FQDN
192.0.2.135	IP
charlie	userid
exemplo	nome do host

A tabela anterior é dividida em quatro colunas, com cada coluna mapeada para apenas um tipo de campo antes de ser usada em qualquer um dos casos de uso de tabelas de dados apresentados neste documento.

FQDN	IP	Userid	Nome do host
altostrat.com	192.0.2.135	charlie	exemplo
…	…	…	…

Mapear nomes de colunas para campos de entidade

Ao criar uma tabela de dados, é possível mapear os nomes das colunas dela para campos de entidade.

Na tabela de dados de exemplo a seguir, as colunas Userid e Role são mapeadas para entity.user.userid e entity.user.attribute.role.name:

Userid (map to entity.user.userid)	E-mail	Papel (mapeie para entity.user.attribute.role.name)
jack	jack123@gmail.com	administrador
tony	tony123@gmail.com	engenheiro

A coluna Email não pode ser mapeada para o caminho de entidade entity.user.email_address, porque é um campo repetido. Não é possível mapear uma coluna de uma tabela de dados para um campo repetido.

É possível mapear uma coluna de uma tabela de dados para um campo proto de entidade usando o campo mapped_column_path do recurso DataTable.

Para colunas que não têm um caminho de entidade definido, como Email nesta tabela de exemplo, é necessário definir um tipo de dados. Assim como nas listas de referência, os tipos de dados compatíveis para tabelas de dados são string, regex e cidr.

É possível especificar colunas mapeadas e não mapeadas na tabela de dados usando a condição de mesclagem. As colunas não mapeadas vão para o campo additional da entidade (a que a tabela de dados é mesclada) como pares de chave-valor, em que a chave é o nome da coluna e o valor é o valor da linha para essa coluna.

Gravar os resultados das consultas YARA-L em tabelas de dados

É possível gravar os resultados das consultas YARA-L em uma tabela de dados. Com esse recurso, é possível criar tabelas de dados com base nos dados do Google SecOps e usá-las para filtrar e aprimorar outros dados.

Você pode usar a sintaxe de regras YARA-L para tabelas de dados para:

Defina uma sintaxe YARA-L para gravar os resultados da regra em tabelas de dados. É possível usar a mesma sintaxe para pesquisa e painéis.
Use tabelas de dados para inteligência contra ameaças, resposta a incidentes e outros casos de uso de segurança.
Verifique se os dados são consistentes com as convenções do YARA-L.

Gravar detecções e alertas em tabelas de dados usando regras

É possível usar regras YARA-L para enviar detecções e alertas para tabelas de dados.

Usando a função write_row, é possível substituir uma linha da tabela de dados com a chave correspondente na tabela de dados usando os resultados de uma regra. Se a chave não for encontrada na tabela, adicione uma nova linha.

Especifique a função write_row na seção de exportação de uma consulta YARA-L. A gravação de dados na tabela de dados precisa ser a ação final da regra. Isso garante que as variáveis de resultado sejam gravadas na tabela de dados.

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

Modificar uma tabela de dados usando YARA-L

Confira a seguir como modificar uma tabela de dados usando o YARA-L:

TableName:ip_user_domain_table (as colunas de chave da chave primária são definidas na criação)

ip_address	employee_id*	domínio
192.0.2.10	Dana	altostrat.com
192.0.2.20	Quinn	altostrat.com
192.0.2.30	Lee	cymbalgroup.com

* indica a chave primária.

A regra a seguir captura combinações exclusivas de principal.ip, principal.user.employee_id e target.domain. Ele filtra os resultados com base na prevalência do 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
}

Resultados da regra:

ip	empid	domínio
192.0.2.10	Dana	altostrat.com
192.0.2.30	Lee	examplepetstore.com
192.0.2.20	Quinn	altostrat.com

Exemplo: use write_row para gravar a saída da regra em uma tabela de dados

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,
    )
}

Exemplo: como entender o write_row

No exemplo abaixo, user e ip são chaves primárias. Cada detecção que persiste na tabela de detecções resulta em uma avaliação da chamada de função na seção de exportação da regra.

Esta é a regra:

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

Confira os dados do evento:

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
}

As seguintes detecções são retornadas:

ID da detecção	Corresponder a $user	Corresponder a $ip
0	charlie	192.0.2.135
1	charlie	192.0.2.136

A tabela de dados contém o seguinte:

user	ip
charlie	192.0.2.135
charlie	192.0.2.136

Aprimorar o gráfico de entidade com uma tabela de dados

Você pode usar tabelas de dados para adicionar, remover ou substituir as entidades apresentadas no gráfico de entidades. Use funções na seção setup da regra para indicar como a tabela de dados precisa ser mesclada, anexada ou usada para remover entidades de eventos de entidade referenciados na seção events.

Use o modelo de regra a seguir para modificar um gráfico de entidade:

rule entity_graph_template {

  meta:
    ...

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

  events:
    ...

  match:
    ...

  condition:
    ...
}

É possível usar as seguintes funções do YARA-L 2.0 para melhorar o gráfico de entidades com uma tabela de dados:

graph_override: substitui as linhas no gráfico de entidade que correspondem à condição de mesclagem com dados da tabela de dados.

Exemplo:

[graph_override](?tab=t.0#heading=h.v0fps7eke1if)
graph_append: anexa as linhas da tabela de dados às linhas no gráfico de entidades. A operação graph_append requer uma matriz que inclua uma variável de tabela de dados e uma variável de evento de entidade em vez de uma condição de mesclagem.

No exemplo abaixo, $g1 é a variável do gráfico de entidade e example_table é a tabela de dados:

graph_append [$g1, %example_table]
graph_exclude: remove as linhas no gráfico de entidade que correspondem à condição de mesclagem.

Exemplo:

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

A condição de mesclagem precisa ser uma expressão de igualdade entre a coluna da tabela de dados e o campo do gráfico de entidade. Para as funções graph_override e graph_exclude, a sintaxe para acessar uma tabela de dados é a seguinte:

<data_table_name>.<column_name>

Qualquer filtro especificado para o <entity_variable> na seção de eventos é aplicado após a melhoria com a tabela de dados.

Depois que a entidade no gráfico de entidade for enriquecida com a entidade na tabela de dados, a variável de entidade no gráfico de entidade precisará ser combinada com a entidade do UDM.

Substituir o gráfico de entidade com dados da tabela de dados

Com a função graph_override, os campos presentes no gráfico de entidade e na tabela de dados são substituídos por campos da tabela de dados. Os campos presentes no gráfico de entidade e não na tabela de dados permanecem os mesmos. Campos que não estão no gráfico de entidade, mas estão na tabela de dados, são incluídos.

Somente as colunas da tabela de dados que são mapeadas substituem as colunas do gráfico de entidade. As colunas não mapeadas são adicionadas ao campo additional do gráfico de entidade em que a tabela de dados é mesclada.

Exemplo: correspondência em uma união

No exemplo abaixo, as linhas no gráfico de entidade que correspondem à condição de mesclagem entre a coluna da tabela de dados e o campo do gráfico de entidade ($g1.graph.entity.ip = %example_table.my_ip) são substituídas pela tabela de dados.

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
}

Para usar uma coluna não mapeada (por exemplo, "Proprietário") da tabela de dados, use uma instrução equivalente para $g1.graph.entity.owner = "alice" is $g1.graph.additional.fields["Owner"] = "alice". Isso ocorre porque todas as colunas não mapeadas da tabela de dados vão para o campo additional do gráfico de entidade ($g1).

As tabelas a seguir ilustram uma operação de substituição em que as linhas no gráfico de entidade são enriquecidas quando o campo IP na tabela de dados corresponde ao campo IP no gráfico de entidade.

Gráfico de entidade atual
Nome do host	IP	MAC
ftp01	10.1.1.4	…:01
www01	10.1.1.5	…:02

Tabela de dados
Nome do host	IP	MAC	Proprietário
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

Gráfico de entidade enriquecida
Nome do host	IP	MAC	Proprietário
ftp01	10.1.1.4	…:bb	Alice
www01	10.1.1.5	…:02
h3	10.1.1.4	…:ee	Doug

Exemplo: correspondência em várias junções

No exemplo abaixo, as linhas no gráfico de entidade que correspondem às várias condições de mesclagem ($g1.graph.entity.ip = %example_table.my_ip e $g1.graph.entity.hostname = %example_table.my_hostname) são substituídas pela tabela de dados.

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
}

As tabelas a seguir ilustram uma operação de substituição em que as linhas do gráfico de entidade são enriquecidas quando o campo IP e o campo de nome de host na tabela de dados correspondem ao campo IP e ao campo de nome de host no gráfico de entidade.

Gráfico de entidade atual
Nome do host	IP	MAC
ftp01	10.1.1.4	…:01
www01	10.1.1.5	…:02

Tabela de dados
Nome do host	IP	MAC	Proprietário
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

Gráfico de entidade enriquecida
Nome do host	IP	MAC	Proprietário
ftp01	10.1.1.4	…:bb	Alice
www01	10.1.1.5	…:02

Anexar dados da tabela de dados ao gráfico de entidade

Com a função graph_append, nenhuma condição de mesclagem é necessária.

No exemplo a seguir, todas as linhas na tabela de dados são anexadas às linhas no gráfico de entidade.

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
}

A tabela de exemplo a seguir ilustra uma operação de adição em que as linhas da tabela de dados são anexadas às linhas no gráfico de entidades:

Gráfico de entidade atual
Nome do host	IP	MAC
ftp01	10.1.1.4	…:01
www01	10.1.1.5	…:02

Tabela de dados
Nome do host	IP	MAC	Proprietário
10.1.1.4	…:01	Alice
10.1.1.6	…:cc	bob
10.1.1.7	…:dd	Chris
10.1.1.4	…:ee	Doug

Gráfico de entidade enriquecida
Nome do host	IP	MAC	Proprietário
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

Use graph_exclude para remover linhas do gráfico de entidade

Com a função graph_exclude, as linhas no gráfico de entidade que correspondem à condição de mesclagem são removidas do gráfico de entidade.

No exemplo a seguir, todas as linhas no gráfico de entidade que correspondem à condição de mesclagem (entre a coluna da tabela de dados e o campo do gráfico de entidade) são removidas. Nenhuma linha da tabela de dados é adicionada ao gráfico de entidade.

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
}

As tabelas a seguir ilustram uma operação de exclusão em que as linhas do gráfico de entidade que correspondem ao campo IP da tabela de dados são removidas:

Gráfico de entidade atual
Nome do host	IP	MAC
ftp01	10.1.1.4	…:01
www01	10.1.1.5	…:02

Tabela de dados
IP	MAC	Proprietário
10.1.1.4	…:bb	Alice
10.1.1.6	…:cc	bob
10.1.1.7	…:dd	Chris

Gráfico de entidade enriquecida
Nome do host	IP	MAC
www01	10.1.1.5	…:02

Limitações

Os limites no número de instruções in ao referenciar uma lista de referência em uma regra também se aplicam a instruções in em uma tabela de dados.
Somente arquivos CSV são aceitos para envios.
O tamanho máximo de uma tabela de dados é de 10 GB.
O limite máximo agregado de volume de dados em tabelas de dados em um locatário é de 1 TB.
Número máximo de instruções in em uma regra, com ou sem operadores especiais: 7
Número máximo de instruções in com o operador regex: 4
Número máximo de instruções in com o operador cidr: 2
Os marcadores de posição não são permitidos na nova seção de configuração.
As colunas não mapeadas de uma tabela de dados com o tipo de dados definido como string só podem ser agrupadas com campos de string do evento ou da entidade do UDM.
Use apenas colunas não mapeadas em uma tabela de dados com um tipo de dados definido como cidr ou regex para CIDR ou expressão regular.
Não é possível mapear a coluna de uma tabela de dados para um campo repetido.

Usar tabelas de dados com regras

As limitações a seguir se aplicam às tabelas de dados quando usadas com regras:

Frequência de execução

A frequência de execução em tempo real não é compatível com regras com tabelas de dados.

Mesclagens

Ao contrário das entidades e do UDM, as tabelas de dados não são compatíveis com marcadores de posição. Isso significa que não é possível aplicar um conjunto de filtros a uma tabela de dados, mesclar com uma entidade do UDM e aplicar um conjunto diferente de filtros à mesma tabela de dados e mesclar com outra variável de marcador de posição do UDM.
Por exemplo, uma tabela de dados chamada dt com três colunas: my_hostname, org e my_email, e com a seguinte regra:

events:
$e1.principal.hostname =  %dt.my_hostname
%dt.org ="hr"

$e2.principal.email =  %dt.my_email
%dt.org !="hr"

Primeiro, todos os filtros em uma tabela de dados são aplicados, e depois as linhas filtradas da tabela de dados são mescladas com a UDM. Nesse caso, uma tabela de dados vazia é associada a e1 e e2 porque os dois filtros na tabela de dados dt se contradizem (%dt.org ="hr" and %dt.org !="hr").

Saída para tabelas de dados

Só é possível exportar variáveis de resultado para uma tabela de dados. Não é possível exportar colunas de caminho de evento ou tabela de dados diretamente.
As listas de colunas precisam incluir as colunas de chave primária das tabelas de dados.
Não é possível ter mais de 20 resultados.
As colunas da tabela de dados não aceitam valores repetidos. Portanto, todas as variáveis de resultado gravadas em uma tabela de dados precisam ser valores únicos.
Se uma tabela de dados não existir, uma nova tabela será criada com o tipo de dados de string padrão para todas as colunas, seguindo a ordem especificada.
Apenas uma regra pode gravar em uma tabela de dados por vez. Se uma regra tentar gravar em uma tabela de dados que outra regra já está gravando, a compilação da regra vai falhar.
Não há garantia de que uma regra de produtor possa adicionar linhas a uma tabela de dados antes de uma regra de consumidor para essa tabela de dados começar.
Uma regra tem um limite no número de linhas de resultados. Um limite de 10.000 linhas se aplica ao resultado e aos dados persistidos. O mesmo limite se aplica às tabelas de dados. Uma única execução de regra pode gerar no máximo 10.000 linhas em uma tabela de dados.
Se uma linha com a mesma chave primária já existir na tabela de dados, as colunas de chave não primária serão substituídas pelos novos valores.
Só é possível aplicar uma única operação de enriquecimento (override, append ou exclude) a uma única variável de gráfico de entidade.
Cada operação de enriquecimento pode ser realizada usando apenas uma tabela de dados.
É possível definir no máximo duas operações de enriquecimento de qualquer tipo na seção setup de uma regra YARA-L.

No exemplo abaixo, uma operação de substituição é aplicada à variável $g1 do gráfico de entidade, e uma operação append é aplicada à variável $g2 do gráfico de entidade.

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

No exemplo anterior, a mesma tabela de dados (table1) é usada para melhorar diferentes gráficos de entidade. Você também pode usar tabelas de dados diferentes para melhorar os diferentes gráficos de entidade, da seguinte maneira:

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