Usar tabelas de dados

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 da Web do Google SecOps, a API Tables ou uma consulta YARA-L.

Atribuir escopos a tabelas de dados usando o RBAC de dados

Para usar tabelas de dados, é necessário atribuir escopos a elas usando o controle de acesso baseado em função (RBAC, na sigla em inglês). Ao atribuir escopos a uma tabela de dados, você pode controlar quais usuários e recursos podem acessá-la e usá-la. Para mais informações, consulte Configurar o RBAC de dados para tabelas de dados.

Gerenciar tabelas de dados usando a interface da Web do Google SecOps

As seções a seguir descrevem como gerenciar tabelas de dados usando a interface da Web, incluindo como acessar as tabelas, adicionar uma nova 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 Tabelas de dados, faça o seguinte:

• Na barra lateral esquerda, selecione Investigação > Tabelas de dados.

Para encontrar uma tabela de dados específica, na parte de cima da barra lateral, insira o nome dela no campo Pesquisar.

Adicionar uma nova tabela de dados

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

1. Clique em add Add no canto superior direito da barra lateral.

2. Na caixa de diálogo Criar nova tabela de dados, dê um nome à nova tabela e, se quiser, adicione uma descrição.

3. 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:

1. Clique em Importar dados.

2. Selecione um arquivo CSV padrão. Somente arquivos CSV podem ser importados para o Google SecOps.

3. Clique em Abrir quando estiver tudo pronto para importar os dados para a tabela.

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:

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.

Associar nomes de colunas a campos de entidade (opcional)

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, respectivamente:

A coluna Email não pode ser mapeada para entity.user.email_address porque é um campo repetido. As colunas da tabela de dados precisam ser mapeadas apenas para campos de valor único (não repetidos).

É possível mapear uma coluna da 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 incluir colunas mapeadas e não mapeadas em uma tabela de dados especificando uma condição join.

As colunas não mapeadas são armazenadas no campo additional da entidade com que a tabela é mesclada. Eles são adicionados como pares de chave-valor, em que key é o nome da coluna e value é o valor da linha correspondente.

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:

1. Na guia Detalhes, mantenha o cursor sobre o final de uma linha e pressione Enter.

2. 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 dados de uma linha na guia Detalhes, eles são preenchidos no Editor de tabelas.

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

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

1. Clique em grid_view Editar tipo de separador ao lado de Importar dados.

2. Na caixa de diálogo Editar tipo de separador, selecione Vírgula ou Tabulação no menu Separador.

Remover uma tabela de dados

Para remover uma tabela de dados:

1. Selecione uma tabela de dados na lista Tabelas de dados à esquerda.

2. 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 pode replicar todos os recursos disponíveis na interface da Web e inclui alguns recursos adicionais que permitem gerenciar tabelas de dados com mais desempenho e escala.

Confira os recursos REST da tabela de dados:

• dataTables

• dataTableRows

• dataTableOperationErrors

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, melhorar e enriquecer seus dados usando consultas YARA-L. Este documento inclui vários exemplos na sintaxe YARA-L, que podem ser incorporados ao Google SecOps.

É possível usar tabelas de dados com consultas YARA-L na Pesquisa e nas regras. As tabelas de dados podem ser usadas 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.

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

• 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ções baseadas em linhas. Essa comparação permite filtrar os dados. Uma comparação baseada em linha é avaliada como true somente se todas as condições na instrução corresponderem a uma única linha na tabela 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. O exemplo de consulta a seguir filtra as 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 %data_table.benign_ip

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. Embora uma lista de referência possa acessar dados em uma única dimensão (uma coluna), as tabelas de dados oferecem suporte a várias colunas, permitindo que você filtre e acesse dados em várias dimensões.

É possível vincular eventos do UDM a uma tabela de dados usando a palavra-chave in para comparação baseada em colunas, permitindo que você compare valores em um campo específico do UDM com valores em uma única coluna da tabela de dados.

No exemplo abaixo, os alertas são acionados para conexões de rede que correspondem a combinações suspeitas de port e protocol. A tabela de dados badApps contém duas colunas: port e protocol. A regra é acionada quando os dois valores de um evento do UDM correspondem a uma linha na tabela de dados.

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

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

É possível vincular eventos da UDM a uma tabela de dados usando operadores de igualdade (=, !=, >, >=, <, <=) para realizar comparações baseadas em linhas. Essa abordagem permite filtrar dados comparando valores de eventos do UDM com linhas na tabela de dados. Se você estiver usando várias instruções de comparação, todos os campos precisam corresponder na mesma linha da tabela de dados.

O exemplo a seguir usa uma coluna de tabela de dados do tipo string. Essa consulta YARA-L verifica se um evento de login do usuário corresponde a uma linha em example_table confirmando que o user ID existe na tabela. Para acionar a regra, as duas condições precisam corresponder na mesma linha da tabela de dados.

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

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 como uma tabela de dados e os dados de eventos do UDM funcionam juntos. Com base na lógica da consulta YARA-L anterior, um usuário com user ID 32452 aparece na detecção como o hostname do usuário do sistema e corresponde ao hostname na tabela de dados.

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 gravação de consulta YARA-L para:

• Defina a sintaxe YARA-L para gravar os resultados da consulta em tabelas de dados.

• 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 a YARA-L

É possível usar uma consulta 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 consulta. 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)

* indica a chave primária.

A consulta 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:

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 consulta:

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

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 usados como 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 consulta.

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)

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 detecções a seguir são retornadas quando essa consulta é executada como uma regra:

A tabela de dados contém o seguinte:

A consulta de pesquisa a seguir ilustra o suporte oferecido na Pesquisa para gravar valores escalares em tabelas de dados.

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

export:
    %summary_table.write_row(col_name: &e.metadata.id)
        "Event_Count":$e.metadata.id, 
    )

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 das regras. 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]

  Para a função append, as tabelas de dados precisam incluir as seguintes colunas para validar a entidade:

  • start_time (mapeado para metadata.interval.start_time.seconds)

  • end_time (mapeado para metadata.interval.end_time.seconds)

  As colunas da tabela de dados não podem ser mapeadas para campos de metadados usando a interface da Web. Para casos de uso de append, as tabelas de dados precisam ser criadas usando a API Chronicle (https://cloud.google.com/chronicle/docs/reference/rest/v1alpha/projects.locations.instances.dataTables/create).

• graph_exclude: remove as linhas no gráfico de entidade que correspondem à condição join.

  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 entidades. 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. Os 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.

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.

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:

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 abaixo, 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:

Limitações

• Os limites no número de instruções in ao fazer referência a uma lista de referência em uma consulta 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 consulta, 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.

Mesclagens

• Ao contrário das entidades e do UDM, as tabelas de dados não aceitam 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").

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.

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

Enriquecimento de entidades em tabelas de dados

• Só é possível aplicar uma 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]

Usar tabelas de dados com a Pesquisa

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

• Não é possível executar consultas de pesquisa em tabelas de dados usando a API Chronicle. Só é possível executar consultas de pesquisa na interface da Web.

• Uma única execução de consulta pode gerar no máximo 1 milhão de linhas para uma tabela de dados ou 1 GB, o que ocorrer primeiro.

• A saída da pesquisa para uma tabela de dados pula linhas de eventos se elas excederem 5 MB.

• Somente o tipo de dados de string é aceito.

• O enriquecimento de entidades não é compatível com a Pesquisa.

• As tabelas de dados não são compatíveis com chaves de criptografia gerenciadas pelo cliente (CMEK).

• As gravações são limitadas a 6 por minuto por cliente.

• O suporte para a API não está disponível.

• As consultas de estatísticas não são compatíveis com mesclagens de tabelas de dados.

• A tabela de dados e a mesclagem de tabelas de dados têm suporte apenas para eventos do UDM, não para entidades.

  Compatível: %datatable1.column1 = %datatable2.column1 Incompatível: graph.entity.hostname = %sample.test

• Não é possível incluir uma variável match na consulta de estatísticas na seção export.

  Por exemplo, o seguinte não é aceito: none match: principal.hostname export: %sample.write_row( row: principal.hostname )

Precisa de mais ajuda? Receba respostas de membros da comunidade e profissionais do Google SecOps.