Usar 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 pesquisa 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 Visão geral do 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 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, 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). Quando você importa 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 mudadas depois que uma nova tabela de dados é salva:

• Cabeçalhos de coluna
• 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 tabela de dados, dê um nome à tabela e, se quiser, adicione uma descrição.

4. Escolha uma destas opções:

   • Insira ou cole os dados CSV na área Texto (modo de edição).
   • Faça o seguinte para importar dados de um arquivo CSV ou TSV para a tabela de dados:
   1. Clique em Importar arquivo.
   2. Acesse o arquivo e clique em Abrir. A caixa de diálogo Importar arquivo é 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 em que os dados serão importados.
   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 da tabela de dados
   • Designar colunas específicas como colunas principais
   • Designar colunas específicas para oferecer suporte a 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 da tabela 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, 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.

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

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.

Designar colunas para oferecer suporte a campos repetidos

Ao adicionar uma nova tabela de dados, você pode 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 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 entidade é 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 (mapeamento para entity.user.userid)	E-mail	Papel (mapeamento para entity.user.attribute.role.name)
entrada	[e-mail]	administrador
tony	[e-mail]	engenheiro

É 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, 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 à 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.

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 vai ficar editável.
2. Faça suas alterações.
3. Clique em Salvar.

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 tempo 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 é de 24 horas. O valor máximo é de 365 dias.

4. Clique em Salvar.

Observação: o TTL aplicado no nível da tabela é herdado pelas linhas. Qualquer atualização em linhas atuais redefine o TTL dessa linha. Quando você adiciona uma nova linha à tabela, o TTL começa a partir do ponto em que a linha foi criada.

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, 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 do 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 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 de 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 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 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 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

  É possível 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, possibilitando a filtragem de dados.

• Combinar uma tabela de dados com um evento ou uma 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. Mescle a tabela de dados com um evento ou uma entidade da UDM usando comparações baseadas em linhas ou em 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 da 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, inclua pelo menos uma condição join entre os campos da 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 da UDM com linhas na tabela de dados, considere a seguinte sintaxe de junção:

  • Sintaxe de junção 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, incluindo potencialmente 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ão), 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 uma 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

É possível 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
  

Mesclagens baseadas em linhas entre uma tabela de dados e um evento ou entidade do 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 na 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 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 entidade do 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.

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

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

  Tabela de dados
  uid	title	hostname
  32452	RH	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 em 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)

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:

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

  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 não é compatível com 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 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.

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:

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

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

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 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 entidade 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 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, não é necessário ter 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.

Observação: não há remoçã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.

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

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:

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

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 vírgulas (,).

• 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 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 tabela: 10.000 linhas.

• Limite máximo de tamanho para upload de arquivos na criação de tabelas 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 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.

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 do UDM, as tabelas de dados não são compatíveis com 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 uni-la a uma entidade do 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 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.

• 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 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 no máximo 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.

• 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 do início de uma regra de consumidor para essa tabela.

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

• Quando você atualiza uma linha, os novos valores de todas as colunas sem chave substituem os antigos. As atualizações, incluindo a adição de uma nova linha, levam aproximadamente cinco minutos para ficarem disponíveis para consulta.

Limitações para o enriquecimento de entidades com base 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 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 $g1 do gráfico de entidades, e uma operação append é aplicada à variável $g2 do gráfico de entidades.

    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]

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:

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

• Uma única execução de consulta pode gerar um máximo de 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 seis por minuto por cliente.

• O suporte à API não está disponível para operações de tabela de dados relacionadas à pesquisa.

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

• 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 compatível: 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, não é possível fazer 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.