Usar tabelas de dados

As tabelas de dados são estruturas com várias colunas que permitem a inserção dos seus próprios dados no Google Security Operations. Elas podem atuar como tabelas de consulta com colunas definidas e os dados armazenados em linhas. Você pode criar ou importar uma tabela de dados para sua conta do Google SecOps usando a interface da Web do Google SecOps, a API de tabelas de dados 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 papéis de dados (RBAC de dados). Ao atribuir escopos a uma tabela de dados, você controla quais usuários e recursos podem acessar e usar essa tabela. 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, adicionar e editar o conteúdo de uma tabela, importar dados para ela, adicionar linhas, separar dados usando vírgulas ou guias e 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 Criar no canto superior direito da barra lateral.

2. Na caixa de diálogo Criar 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 à sua tabela, importe-os diretamente para o Google SecOps da seguinte forma:

1. Clique em Importar dados.

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

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

Mapear tipos de dados para colunas da tabela de dados

É possível mapear campos de dados únicos para uma coluna de dados e campos de dados repetidos para uma coluna de dados usando a interface da Web ou a API, da seguinte maneira:

• Na interface da Web e na API, separe os valores do campo de dados usando o caractere |. Na interface da Web, se um valor incluir o caractere |, ele será tratado como um valor repetido por padrão.

• Para solicitações de API, defina repeated_values como true.

Para mais informações, consulte Campos repetidos.

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

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

Designar colunas específicas como colunas de chave

Marcar uma coluna como chave identifica exclusivamente os valores nela, evita a duplicação de dados e melhora a descoberta de dados para regras e pesquisas.

Designar colunas específicas para oferecer suporte a campos repetidos

As colunas destinadas a armazenar campos de vários valores ou campos repetidos precisam ser designadas explicitamente como repetidas quando a tabela de dados é criada.

Mapear nomes de colunas para campos de entidade (opcional)

Ao criar uma tabela de dados, é possível mapear os nomes das colunas para os 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:

É 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 sem um caminho de entidade definido, como Email nesta tabela de exemplo, é necessário especificar manualmente um tipo de dados. Assim como nas listas de referência, os tipos de dados compatíveis para tabelas de dados são number, 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 a que a tabela se une. 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 linha a uma tabela de dados

Para adicionar uma nova linha, siga estas etapas:

1. Na guia Detalhes, clique com o botão direito do mouse em uma linha e selecione Adicionar linha acima.

2. Insira dados em uma nova linha, em que a primeira linha é tratada como um cabeçalho de tabela:

   1. Separe os campos de dados usando vírgulas ou guias.
   2. Associe cada item de dados à coluna correspondente.
   3. À medida que você insere os dados de uma linha na guia Detalhes, eles são preenchidos no Editor de tabelas.

Editar uma linha na tabela de dados

Para editar uma linha, faça o seguinte:

1. Clique no campo que você quer mudar. O campo fica editável.

2. Depois de fazer as mudanças, clique em Salvar.

Especifique se você quer usar vírgulas ou tabulações para separar os dados.

Para separar os dados usando vírgulas ou guias, 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.

Pesquisar linhas na tabela de dados

É possível pesquisar informações específicas em uma tabela de dados usando a interface da Web. Na guia Detalhes, digite uma string de pesquisa no campo e clique em Pesquisar. As linhas que contêm sua string de pesquisa são mostradas.

Gerenciar o TTL da linha da tabela

Para gerenciar o valor de time-to-live (TTL) das linhas da tabela, faça o seguinte:

1. Clique em Mostrar TTL por linha. Uma coluna de TTL é exibida, indicando se cada linha expirou. Se não tiver expirado, ele mostra o tempo restante antes da expiração.

2. Clique no prazo Padrão de validade da linha para mostrar a caixa de diálogo Atualizar validade padrão da linha e ajuste o TTL da linha da tabela.

3. Insira um novo valor de TTL em Horas ou Dias. O valor mínimo é de 24 horas. O valor máximo é de 365 dias.

4. Clique em Salvar.

Excluir uma linha da tabela

Para excluir uma linha, clique com o botão direito nela e selecione Excluir linhas.

Para excluir várias linhas, selecione cada uma delas. Em seguida, clique com o botão direito do mouse em qualquer linha selecionada e escolha Excluir linhas.

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 do Chronicle

Você também pode 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 extras que permitem gerenciar tabelas de dados com mais desempenho e maior escala.

Confira os recursos REST da tabela de dados:

• dataTables

• dataTableRows

• dataTableOperationErrors

Exemplo: sintaxe do filtro

O exemplo a seguir da API Chronicle mostra como usar a sintaxe filter para pesquisar google.com em linhas da tabela de dados:

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

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

• Filtre dados de eventos ou entidades da UDM usando uma tabela de dados. É possível filtrar eventos e entidades de telemetria da UDM comparando-os com entradas em uma tabela de dados.

• Usar uma tabela de dados como uma lista de referência de várias colunas. Você pode usar uma tabela de dados como uma lista de referência de várias colunas. Uma lista de referência pode acessar dados em uma única dimensão, mas as tabelas de dados permitem acessar dados em várias dimensões, possibilitando a filtragem.

• Unir uma tabela de dados a um evento ou entidade. É possível vincular eventos da UDM a uma tabela de dados usando o operador de igualdade (=) para comparações com base em linhas. Com essa comparação, é possível filtrar os dados. Uma comparação com base em linhas será 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 da UDM usando uma tabela de dados

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

Vincule eventos UDM a tabelas de dados de uma das seguintes maneiras:

• Usar um operador de igualdade (=, !=, >, >=, <, <=) para comparação com base em linhas. Por exemplo, $<udm_variable>.<field_path> = %<data_table_name>.<column_name>.

• Usando a palavra-chave in para comparação baseada em colunas. 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 number, string, regex ou CIDR.

Para usar uma coluna de tabela de dados do tipo number em comparações e junções baseadas em colunas, use a seguinte sintaxe. Este exemplo pesquisa eventos que incluem target.port 8080.

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

Para usar uma coluna de tabela de dados do tipo CIDR ou regex para uma comparação baseada em linhas, 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 regex para comparação baseada 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

Ao comparar colunas em tabelas de dados que são tipos de dados CIDR ou de expressão regular, as palavras-chave cidr e regex são opcionais. Você também pode usar o operador not com tabelas de dados. A consulta 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 %data_table.benign_ip

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

Você pode usar uma tabela de dados como uma lista de referência de várias colunas. Uma lista de referência pode acessar dados em uma única dimensão (uma coluna), mas as tabelas de dados aceitam várias colunas, permitindo filtrar e acessar dados em várias dimensões.

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

No exemplo a seguir, a tabela de dados badApps contém duas colunas: hostname e ip. A consulta corresponde aos dois valores (com base no campo do UDM e na tabela de dados, ambos do tipo string) de forma independente.

Exemplo de regra:

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
}

Exemplo de pesquisa:

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

Combinar uma tabela de dados com um evento ou entidade UDM

É possível vincular eventos da UDM a uma tabela de dados usando operadores de igualdade e comparação (=, !=, >, >=, <, <=) para fazer comparações com base 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 ou condições precisarão corresponder à mesma linha da tabela de dados.

É necessário incluir pelo menos uma condição join entre os campos da UDM e as linhas da tabela de dados para usar operadores (como not, !=, >, >=, <, <=) na consulta. O Google SecOps trata qualquer regra com uma tabela de dados join como uma regra de vários eventos, que exige que você também inclua uma seção match na definição da regra.

Quando um agrupamento acontece, as linhas da tabela de dados vinculados ficam visíveis na Pesquisa. Para mais informações, consulte Ver linhas da tabela de dados na Pesquisa.

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. As duas condições precisam corresponder na mesma linha da tabela de dados para que a regra seja acionada.

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

Exemplo de regra:

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

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

match:
$userid over 1h

condition:
$e
}

Exemplo de pesquisa:

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

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

O exemplo a seguir ilustra como uma tabela de dados e os dados de eventos da 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 no sistema e corresponde ao hostname na tabela de dados.

Gravar resultados de 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.

É possível usar a sintaxe de gravação de consultas YARA-L para o seguinte:

• Defina a sintaxe YARA-L para gravar resultados de consultas 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.

• Os dados precisam estar em conformidade com a sintaxe e as convenções da YARA-L.

Escrever detecções e alertas em tabelas de dados usando YARA-L

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

Com a função write_row, é possível substituir uma linha de tabela de dados pela chave correspondente 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 faz com 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 YARA-L:

TableName:ip_user_domain_table (as colunas de chave para a 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

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

Resultados da consulta:

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

Exemplo de regra:

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

Exemplo de pesquisa:

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
  )

Exemplo: como entender "write_row"

No exemplo a seguir, 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.

Exemplo de regra:

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

Exemplo de pesquisa:

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)

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 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.product_name, Vendor_name: $e.metadata.vendor_name)

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

É possível 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 deve ser mesclada, anexada ou usada para remover entidades de eventos de entidade referenciados na seção events.

Você pode usar 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:
    ...
}

Você pode usar as seguintes funções do YARA-L 2.0 para melhorar o gráfico de entidades com uma tabela de dados:

• graph_override: substitua as linhas no gráfico de entidades que correspondem à condição de junção com dados da tabela de dados.

  Exemplo:

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

• graph_append: anexe as linhas da tabela de dados às linhas no gráfico de entidades. A operação graph_append exige 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 junção.

  No exemplo a seguir, $g1 é a variável de 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)

  Não é possível mapear colunas da tabela de dados 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 do 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 junção 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 depois do refinamento com a tabela de dados.

Depois que a entidade no gráfico de entidades é enriquecida com a entidade na tabela de dados, a variável de entidade no gráfico de entidades precisa ser unida à entidade do UDM.

Substituir o gráfico de entidades 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 entidades, 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 entidades em que a tabela de dados é unida.

Exemplo: correspondência em uma única junção

No exemplo a seguir, as linhas no gráfico de entidades que correspondem à condição de junção entre a coluna da tabela de dados e o campo do gráfico de entidades ($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 de IP na tabela de dados corresponde ao campo de IP no gráfico de entidade.

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

No exemplo a seguir, as linhas no gráfico de entidades que correspondem às várias condições de junção ($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 entidades são enriquecidas quando o campo de IP e o campo de nome do host na tabela de dados correspondem ao campo de IP e ao campo de nome do host no gráfico de entidades.

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

Com a função graph_append, não é necessário usar uma condição de junção.

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

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 adicionadas às linhas no gráfico de entidades:

Use graph_exclude para remover linhas do gráfico de entidades

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

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

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 de IP da tabela de dados são removidas:

Limitações

• Número máximo de tabelas de dados para uma conta do Google SecOps: 1.000.

• Somente o tipo de arquivo CSV é aceito para uploads.

• Os limites no número de instruções in ao referenciar uma lista de referência em uma consulta também se aplicam a instruções in em uma tabela de dados.

• Número máximo de instruções in em uma consulta: 10

• Número máximo de instruções in em uma consulta para colunas de tipo de dados String e Number: 7

• Número máximo de instruções in com operadores de expressão regular: 4

• Número máximo de instruções in com operadores CIDR: 2

• Máximo de colunas por tabela de dados: 1.000.

• Máximo de linhas por tabela de dados: 10 milhões.

• Limite agregado máximo de volume de dados em todas as tabelas de dados de uma conta: 1 TB.

• Limite máximo de exibição na página da Web para linhas da tabela de dados na visualização do editor de texto e de tabela: 10.000 linhas

• Limite máximo de linhas ao fazer upload de um arquivo para uma nova tabela de dados na página da Web: 10.000 linhas

• Limite máximo de tamanho de upload de arquivo para criação de tabela de dados pela API: 1 GB

• Não é permitido usar marcadores de posição na 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 unidas a campos de string de eventos ou entidades 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.

• Pesquisas na tabela de dados: caracteres curinga de expressão regular não são aceitos, e os termos de pesquisa são limitados a 100 caracteres.

Mesclagens

• Não é possível buscar todas as amostras de eventos para detecções ao usar junções de tabelas de dados com eventos.

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

  • Aplique um conjunto de filtros a uma tabela de dados e junte-a a uma entidade UDM.

  • Aplique um conjunto diferente de filtros à mesma tabela de dados enquanto a une a outro marcador de posição da 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"
  

Todos os filtros em uma tabela de dados são aplicados primeiro, e depois as linhas filtradas da tabela são unidas ao UDM. Nesse caso, uma tabela de dados vazia é unida 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 seguintes limitações 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 que usam tabelas de dados.

Saída para tabelas de dados

• Os modificadores any e all não são compatíveis com colunas de campos repetidos em tabelas de dados.

• A indexação de matrizes não é compatível com colunas de campos repetidos em tabelas de dados.

• Só é possível exportar variáveis de resultado para uma tabela de dados. Não é possível exportar diretamente colunas de caminho de evento ou tabela de dados.

• As listas de colunas precisam incluir as colunas de chave primária para tabelas de dados.

• Você pode ter no máximo 20 resultados.

• 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 que uma regra de consumidor para essa tabela de dados seja iniciada.

• Uma regra tem um limite no número de linhas de resultados. Um limite de 10.000 linhas é aplicado aos resultados e aos dados persistentes. 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 que não são de chave primária serão substituídas pelos novos valores.

Enriquecimento de entidades com 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 a seguir, uma operação de substituição é aplicada à variável de gráfico de entidade $g1, e uma operação append é aplicada à variável de gráfico de entidade $g2.

    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 entidades. Você também pode usar diferentes tabelas de dados para melhorar os gráficos de entidades, da seguinte forma:

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

Usar tabelas de dados com a Pesquisa

As seguintes limitações 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 vier primeiro.

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

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

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

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

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

• As consultas de estatísticas não são compatíveis com junções de tabelas de dados.

• A tabela de dados e a junção de tabelas de dados só são compatíveis com eventos da UDM, não com entidades.

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

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

  Por exemplo, não é possível usar o seguinte:

  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.