Pesquisar tabelas de dados

Compatível com:

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 controle de acesso baseado em funçã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.

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

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 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).
    • 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 em que a importação de dados vai começar.
    4. Clique em Importar dados.

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

  6. Clique em Salvar. A nova tabela de dados é mostrada 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.

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.

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
(mapeado para entity.user.userid)		 E-mail Função
(mapeamento para entity.user.attribute.role.name)
conector jack123@gmail.com administrador
tony tony123@gmail.com 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.

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 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 aparece, 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 é 1 hora. O valor máximo é de 365 dias.

  4. Clique em Salvar.

Comportamento de substituição de TTL no nível de 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 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 performance e escalonamento.

Confira os recursos REST da tabela de dados:

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 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 baseadas 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 métodos de comparação baseados em linhas ou baseados em colunas:

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

  • 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

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

Mesclagens 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 da 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 vinculada 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.

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

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

  • 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

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.

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 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 Corresponder $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

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

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

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

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

  • 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

Use 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 (STANDARD)
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 de 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 da 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 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 usam 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.

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

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

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

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

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

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

  • A renomeação não é compatível com a plataforma ou a 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.