Pesquisar tabelas de dados

Compatível com:

Google SecOps SIEM

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 da Visão geral da YARA-L 2.0.

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 de dados (RBAC de dados). Ao atribuir escopos a uma tabela de dados, é possível controlar 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, editar o conteúdo, adicionar linhas 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, selecione Investigação > Tabelas de dados.

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

Adicionar uma nova tabela de dados

Ao adicionar uma nova tabela de dados, você pode inserir ou colar dados CSV manualmente ou importar um arquivo CSV ou TSV para a tabela.

Observação: as tabelas de dados não são compatíveis com valores separados por tabulação, exceto ao importar um arquivo de valores separados por tabulação (TSV). Ao importar um arquivo TSV, o Google SecOps converte os separadores de tabulação em separadores de vírgula na tabela de dados. Os campos da tabela de dados não aceitam vírgulas (,).

As configurações a seguir são permanentes e não podem ser modificadas depois que uma nova tabela de dados é salva:

• Cabeçalhos de colunas
• Mapeamento de dados
• Chaves primárias
• Campos repetidos
• Mapeamento de nomes de colunas para campos de entidade

Para adicionar uma nova tabela de dados ao Google SecOps, faça o seguinte:

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

2. Na parte de cima da barra lateral Tabelas de dados, clique em add Criar.

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

4. Escolha uma destas opções:

   • Insira os dados CSV manualmente ou cole-os na área Texto (modo de edição).
   • Para importar dados de um arquivo CSV ou TSV para a tabela de dados, faça o seguinte:
   1. Clique em Importar arquivo.
   2. Acesse o arquivo e clique em Abrir. A caixa de diálogo Importar arquivo será aberta.
   3. Se você selecionou um arquivo TSV na etapa anterior, faça o seguinte:
      1. Na lista Tipo de separador, selecione Detectar automaticamente ou Tabulação.
      2. Na lista Iniciar importação na linha, especifique a linha do arquivo de onde importar os dados.
   4. Clique em Importar dados.

5. Selecione o modo de edição Tabela e configure o seguinte conforme necessário:

   • Mapear tipos de dados para colunas de tabelas de dados
   • Designar colunas específicas como colunas principais
   • Designar colunas específicas para aceitar campos repetidos
   • Mapear nomes de colunas para campos de entidade (opcional)

6. Clique em Salvar. A nova tabela de dados aparece na barra lateral Tabelas de dados e está pronta para receber mais dados.

Mapear tipos de dados para colunas de tabelas de dados

Ao adicionar uma tabela de dados, é possível mapear tipos de dados (string, expressão regular, CIDR ou número) 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 uma barra vertical (|). Na interface da Web, se um valor incluir uma barra vertical (|), 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:

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, cada uma 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.

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

Designar colunas principais

Ao adicionar uma nova tabela de dados, é possível 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.

Observação: por padrão, todas as colunas são tratadas como colunas de chave, a menos que especificado de outra forma durante a criação da tabela de dados.

Observação: como combinar colunas de chave com campos repetidos

• É possível configurar uma coluna em uma tabela de dados para que os atributos key_column e repeated_values sejam definidos como true. Embora uma coluna de chave normalmente use um valor único para identificar cada linha, é possível permitir valores repetidos. Esse design acomoda cenários específicos, como uma tabela de dados com uma única coluna que precisa funcionar como chave e armazenar vários valores.
• Quando uma coluna é definida com key_column: true e repeated_values: true, a restrição de exclusividade da chave se aplica ao conjunto inteiro de valores na célula dessa coluna, e não aos elementos individuais na matriz de valores.
  Por exemplo, ["value1", "value2"] e ["value2", "value1"] são tratados como chaves exclusivas.

Designar colunas para oferecer suporte a campos repetidos

Ao adicionar uma nova tabela de dados, você pode designar colunas específicas para aceitar campos repetidos.

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

Mapear nomes de colunas para campos de entidade (opcional)

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

Observação: o mapeamento de campos de entidade para colunas é opcional e usado quando o enriquecimento de entidades é realizado. Para mais informações, consulte Enriquecer o gráfico de entidades com uma tabela de dados.

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:

Userid (mapear para entity.user.userid)	E-mail	Função (mapeamento para entity.user.attribute.role.name)
entrada para fone de ouvido	[e-mail]	administrador
tony	[e-mail]	engenheiro

É possível mapear uma coluna de 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 com as 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 nova linha a uma tabela de dados

Para adicionar uma nova linha, faça o seguinte:

1. Na guia Detalhes, selecione o modo de edição Tabela.
2. Clique com o botão direito do mouse em uma linha e selecione Adicionar linha acima.
3. Insira os dados de uma nova linha. A primeira linha é tratada como um cabeçalho de tabela. Associe cada item de dados à coluna e ao tipo de dados adequados.
4. Clique em Salvar.

Observação: as linhas são salvas em ordem aleatória na tabela de dados.

Observação: ao adicionar linhas a uma tabela com uma coluna configurada como key_column: true e repeated_values: true, lembre-se de que a exclusividade da linha é baseada no conjunto inteiro de valores na coluna de chave.

Editar uma linha em uma 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. Faça suas alterações.
3. Clique em Salvar.

Pesquisar linhas da 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 de pesquisa e clique em Pesquisar. As linhas que contêm sua string de pesquisa são exibidas.

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 estiver expirado, ele vai mostrar o tempo restante antes da expiração.

2. Clique no prazo Validade padrão da linha para mostrar a caixa de diálogo Atualizar a 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 é 1 hora. O valor máximo é de 365 dias.

4. Clique em Salvar.

Comportamento de substituição de TTL no nível da linha

As linhas herdam o TTL aplicado no nível da tabela. Você também pode definir um TTL específico para linhas individuais, e esse TTL no nível da linha tem precedência sobre o padrão no nível da tabela. Quando você adiciona uma nova linha, o TTL dela começa no momento da criação.

Excluir uma linha de tabela

Para excluir uma linha, clique com o botão direito do mouse nela e selecione Excluir linha(s).

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, faça o seguinte:

1. Selecione uma tabela de dados na lista Tabelas de dados na barra lateral.

2. Clique em Excluir.

Gerenciar tabelas de dados usando a API 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 adicionais 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 de filtro

O exemplo de API do Chronicle a seguir mostra como usar a sintaxe filter para pesquisar google.com em linhas de tabelas 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 adicionar tabelas de dados à 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 você pode incorporar 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 da 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.

• 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. 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, permitindo a filtragem de dados.

• 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 baseadas em linhas. Com essa comparação, é possível filtrar os dados. Uma comparação baseada 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. Faça a junção da tabela de dados com um evento ou entidade da UDM usando comparações baseadas em linhas ou colunas.

Comparações baseadas em linhas e colunas em tabelas de dados

Tipo de comparação	Lógica principal	Operadores comuns	Exemplo de sintaxe	Quando usar
Com base em linhas	Todas as condições precisam corresponder na MESMA linha	=, !=, >, >=, <, <=	$e.field = %table.col_a	Quando a relação entre vários valores de coluna na mesma linha é importante.
Baseado em colunas	O valor precisa estar em QUALQUER LUGAR na coluna	IN, IN regex, IN cidr	$e.field IN %table.col_b	Ao verificar a presença de um valor em um conjunto de valores em uma única coluna.

Vincule eventos da UDM a tabelas de dados usando os métodos de comparação baseado em linhas ou baseado em colunas:

Comparação baseada em linhas para vincular eventos de UDM a tabelas de dados

• Para vincular eventos do UDM a tabelas de dados usando a comparação baseada em linhas, use operadores de igualdade (=, !=, >, >=, <, <=).

  Por exemplo: $<udm_variable>.<field_path> = %<data_table_name>.<column_name>

  • Se você estiver usando várias instruções de comparação, todos os campos ou condições precisarão corresponder na mesma linha da tabela de dados.

  • Para usar operadores (como not, !=, >, >=, <, <=) na consulta, é necessário incluir pelo menos uma condição join entre os campos do UDM e as linhas da tabela de dados.

  • O Google SecOps trata qualquer regra com uma tabela de dados join como uma regra de vários eventos, que exige uma seção match na definição da regra.

• Para filtrar dados comparando valores de eventos do UDM com linhas na tabela de dados, considere a seguinte sintaxe de junção:

  • Sintaxe de mesclagem correta:

    A "exclusão de combinação" baseada em linhas exige, por exemplo, uma junção left outer e uma cláusula where que verifica nulls.

  • Sintaxe de junção incorreta:

    Não coloque NOT em várias condições de igualdade baseadas em linhas. Essa sintaxe não tem o efeito "excluir se esta combinação for encontrada".

    Por exemplo, não use esta sintaxe: NOT (field1 = %table.col1 AND field2 = %table.col2)

    Isso ocorre porque a correspondência ainda é aplicada linha por linha. Se qualquer linha falhar na condição combinada interna, o NOT fará com que a avaliação dessa linha seja true, possivelmente incluindo o evento em vez de excluí-lo.

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

Comparação baseada em colunas para vincular eventos da UDM a tabelas de dados

• Para vincular eventos da UDM a tabelas de dados usando a comparação baseada em colunas, use a palavra-chave in.

  Por exemplo: $<udm_variable>.<field_path> in %<data_table_name>.<column_name>

• Para filtrar eventos em que o valor do campo existe na coluna especificada (por exemplo, uma lista de bloqueio ou de permissões), use esta sintaxe: NOT (... IN %table.column)

  Por exemplo: not ($evt_username in %my_data_table.username)

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

• Também é possível 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. Embora uma lista de referência possa acessar dados em uma única dimensão (uma coluna), as tabelas de dados aceitam várias colunas, permitindo filtrar e acessar 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. Assim, você pode comparar valores em um campo específico do UDM com 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 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
  

Junções baseadas em linhas entre uma tabela de dados e um evento ou entidade da 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 correspondentes 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 precisam corresponder na mesma linha da tabela de dados.

Você precisa 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 uma seção match correspondente 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.

• Os marcadores de posição são compatíveis com tabelas de dados na seção event de uma consulta, mas precisam estar conectados a um evento ou uma entidade de UDM.

• O exemplo a seguir usa uma coluna de tabela de dados do tipo string.

  • Este exemplo de consulta YARA-L verifica se um evento de login do usuário corresponde a uma linha em example_table.

    • Uma condição é que o user ID exista no example_table.
    • As duas condições precisam corresponder à mesma linha em example_table para que a regra seja acionada.

  • Exemplo de regra:

    // Check if user exists in a data table and is active in all user login events.
    rule udm_join_data_table {
    
    meta:
      description = "Join data table with UDM event"
    
    events:
      $e.metadata.event_type = "USER_LOGIN"
      $e.security_result.action = "ALLOW"
      $e.principal.user.userid = $userid
    
    // Event must match at least 1 row in the data table 
    // where the uid in the data table row is the userid on the event 
    // and the active date in the same data table row is before the event timestamp.
    %example_table.uid = $userid
    $e.principal.hostname = %example_table.hostname
    
    match:
      $userid over 1h
    
    condition:
      $e
    }
    

  • 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 data table 
    // where the uid in the data table row is the userid on the event 
    // and the active date in the same data table row is before the event timestamp
    
    %example_table.uid = $userid
    $e.principal.hostname = %example_table.hostname
    

• O exemplo a seguir ilustra como uma tabela de dados e 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.

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

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

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

Observação: essa funcionalidade só está disponível em regras e na pesquisa.

Com a função write_row, é possível substituir uma linha da tabela de dados pela 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.

Observação: o comportamento de write_row com colunas de chave é afetado pela configuração repeated_values. Se uma coluna de chave também tiver repeated_values: true, a correspondência de linhas será baseada em todo o conjunto de valores na coluna de chave.

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.

• Exemplo

  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
  

• Exemplo: exportar resultados da pesquisa para uma tabela de dados

  events:
    $e.metadata.event_type = "USER_LOGIN"
    $e.security_result.action = "ALLOW"
  
  outcome:
    $user = $e.principal.user.userid
    $ip = $e.target.ip[0] // Assuming target.ip is an array
    $timestamp = $e.metadata.event_timestamp.seconds
  
  export:
    // Write to the data table named 'successful_logins'
    %successful_logins.write_row(
      user: $user,          // Maps $user variable to 'user' column
      ip: $ip,              // Maps $ip variable to 'ip' column
      first_seen: $timestamp // Maps $timestamp variable to 'first_seen' column
    )
  

Modificar uma tabela de dados usando YARA-L

Veja como modificar uma tabela de dados usando o YARA-L:

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

Endereço IP	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.

Observação: a chave primária pode ser uma combinação de várias colunas, embora seja uma única coluna neste exemplo.

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:

• Exemplo

  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:

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: 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 de eventos:

  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:

  ID da detecção	Corresponder a $user	Match $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

  Observação: se você clicar em Executar teste no Editor de regras para verificar uma regra, os dados de exemplo não vão permanecer na tabela de dados.

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

  Observação: isso é indisponível em regras.

  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 em um gráfico de entidades com base em 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 dos eventos de entidade referenciados na seção events.

Observação: esse recurso não é compatível com a Pesquisa.

Você pode usar o modelo de regra a seguir para modificar um gráfico de entidade:

• Modelo de regra

  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 entidades que correspondem à condição de junção com dados da tabela de dados.

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

  Não é possível mapear colunas de tabelas de dados para campos de metadados usando a interface da Web. Para casos de uso do append, as tabelas de dados precisam ser criadas usando a API Chronicle (https://docs.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.

  Por 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 entidade em que a tabela de dados é mesclada.

Exemplo: correspondência em uma única mesclagem

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.

• Exemplo

  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 (digamos, "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 acontece porque todas as colunas não mapeadas da tabela de dados vão para o campo additional do gráfico de entidades ($g1).

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

Gráfico de entidades 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 entidades enriquecido
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 a seguir, 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.

• Exemplo

  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 os campos de IP e de nome do host na tabela de dados correspondem aos campos de IP e de nome do host no gráfico de entidade.

Gráfico de entidades 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 entidades enriquecido
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 entidades

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

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

Observação: não há eliminação de duplicação das linhas anexadas ao gráfico de entidades. Isso significa que, se uma linha estiver presente no gráfico de entidades e na tabela de dados, as duas linhas estarão presentes no gráfico de entidades enriquecido.

• Exemplo

  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:

Gráfico de entidades 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	…:01	alice
10.1.1.6	…:cc	bob
10.1.1.7	…:dd	chris
10.1.1.4	…:ee	doug

Gráfico de entidades enriquecido
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

Usar graph_exclude para remover linhas do gráfico de entidades

Com a função graph_exclude, as linhas no gráfico de entidade 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.

• Exemplo

  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:

Gráfico de entidades 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 entidades enriquecido
Nome do host	IP	MAC
www01	10.1.1.5	…:02

Limites de taxa de API

As seguintes cotas de consultas por minuto (QPM) são aplicadas por projeto e usuário ao chamar os endpoints da API REST da tabela de dados e da linha da tabela de dados do Google SecOps:

Recurso	Operação de API	Limite de taxa (PADRÃO)
DataTables	CreateDataTable (data_table/create_requests)	60 QPM
DataTables	GetDataTable (data_table/get_requests)	120 QPM
DataTables	ListDataTables (data_table/list_requests)	120 QPM
DataTables	UpdateDataTable (data_table/update_requests)	60 QPM
DataTables	DeleteDataTable (data_table/delete_requests)	60 QPM
DataTableRows	CreateDataTableRow (data_table_row/create_requests)	60 QPM
DataTableRows	GetDataTableRow (data_table_row/get_requests)	120 QPM
DataTableRows	ListDataTableRows (data_table_row/list_requests)	120 QPM
DataTableRows	UpdateDataTableRow (data_table_row/update_requests)	60 QPM
DataTableRows	DeleteDataTableRow (data_table_row/delete_requests)	60 QPM
DataTableRows	BulkCreateDataTableRows (síncrono / assíncrono)	30 QPM
DataTableRows	BulkReplaceDataTableRows (síncrono / assíncrono)	30 QPM
DataTableRows	BulkUpdateDataTableRows (síncrono / assíncrono)	10 QPM
DataTableRows	BulkDeleteDataTableRows (síncrono / assíncrono)	30 QPM
DataTableRows	BulkGetDataTableRows (data_table_row/bulk_get_requests)	120 QPM

Limitações

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

• As tabelas de dados só aceitam dados CSV. As tabelas de dados só aceitam valores separados por tabulação ao adicionar uma nova tabela de dados e importar um arquivo de valores separados por tabulação (TSV).

• Os campos da tabela de dados não aceitam caracteres de vírgula (,).

• 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 para colunas com tipo de dados String e Number: 10.

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

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

• Número máximo de instruções = (JOIN): 10.

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

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

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

• Volume máximo de dados em uma tabela de dados: 10 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 um evento ou 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.

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

Limitações para junções de tabelas de dados em regras

As seguintes limitações se aplicam às junções de tabelas de dados em regras.

• 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 da UDM, as tabelas de dados não aceitam marcadores de posição. Isso leva às seguintes limitações:

  • Não é possível aplicar um conjunto de filtros a uma tabela de dados e mesclá-lo com uma entidade UDM.

  • Não é possível aplicar 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 de dados são unidas ao UDM. Nesse caso, os filtros contraditórios (%dt.org ="hr" and %dt.org !="hr") na tabela dt resultam em uma tabela de dados vazia, que é unida a e1 e e2.

Limitações ao usar tabelas de dados com regras

As seguintes limitações se aplicam às tabelas de dados quando usadas com regras.

Limitações para a frequência de execução

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

Limitações para saída em tabelas de dados

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

• O 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 caminhos de eventos ou colunas da tabela de dados diretamente.

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

• É possível ter até 20 resultados.

• Se uma tabela de dados não existir, uma nova será criada com o tipo de dados string padrão para todas as colunas, seguindo a ordem especificada.

• No máximo cinco regras podem gravar em uma tabela de dados simultaneamente.

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

• Uma única regra tem um limite no número de linhas de resultado. Um limite máximo de 10.000 linhas se aplica ao resultado,aos dados persistidos e às tabelas de dados.

• Quando você atualiza uma linha, os novos valores de todas as colunas não principais substituem os antigos. Qualquer atualização, incluindo a adição de uma nova linha, leva aproximadamente cinco minutos para ficar disponível para consulta.

Limitações do enriquecimento de entidades com tabelas de dados

• Você pode aplicar apenas uma operação de enriquecimento (override, append ou exclude) a uma única variável de gráfico de entidade.

• Cada operação de enriquecimento só pode usar 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 override é aplicada à variável de gráfico de entidade $g1, e uma operação append é aplicada à variável de gráfico de entidade $g2.

• none 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. Também é possível usar tabelas de dados diferentes para aprimorar os diferentes gráficos de entidade, da seguinte maneira:

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

Limitações ao usar tabelas de dados com a Pesquisa

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

• 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 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 usuários de chaves de criptografia gerenciadas pelo cliente (CMEK).

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

• As tabelas de dados e as junções de tabelas de dados só são compatíveis com eventos da UDM, não com entidades.

  Compatível: %datatable1.column1 = %datatable2.column1

  Não aceito: graph.entity.hostname = %sample.test

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

  Por exemplo, o seguinte é indisponível:

    match:
        principal.hostname
    export:
        %sample.write_row(
        row: principal.hostname
      )
  
  

Limitações ao renomear ou excluir tabelas de dados com a API Chronicle ou o Terraform

• Não é possível renomear pela plataforma ou pela API.
• Não é possível excluir uma tabela de dados (pela plataforma ou pela API) se ela for referenciada por uma regra.
• No Terraform, renomear uma tabela de dados aciona uma operação de exclusão e recriação. Se a tabela de dados for referenciada por uma regra, essa operação vai falhar porque a API bloqueia a exclusão da tabela antiga.
• Risco de perda de dados no Terraform: mesmo que uma tabela de dados não seja referenciada por uma regra, renomeá-la usando o Terraform resulta em perda permanente de dados. O Terraform destrói a tabela atual e a substitui por uma nova tabela vazia que não retém nenhum dado da original.
• Solução alternativa recomendada:
  • Crie uma tabela de dados com o novo nome.
  • Atualize as regras para começar a usar a nova tabela de dados.
  • Exclua a tabela de dados antiga.

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