Práticas recomendadas de pesquisa

Compatível com:

Este documento descreve as práticas recomendadas do Google para usar o recurso Pesquisa no Google Security Operations. As pesquisas podem exigir muitos recursos computacionais se não forem construídas com cuidado. O desempenho também varia de acordo com o tamanho e a complexidade dos dados na instância do Google SecOps.

Usar filtros específicos em consultas para máxima velocidade e desempenho

A maneira mais eficaz de melhorar o desempenho da pesquisa é criar consultas usando campos específicos e otimizados do modelo de dados unificado (UDM, na sigla em inglês). Esses campos são otimizados para recuperação rápida, garantindo que as pesquisas sejam executadas rapidamente e usem menos recursos computacionais.

As seções a seguir listam os campos de UDM de alto desempenho para usar como filtros nas consultas.

Campos de metadados

  • metadata.event_timestamp.seconds
  • metadata.event_type
  • metadata.log_type
  • metadata.product_event_type
  • metadata.product_name
  • metadata.vendor_name

Campos principais

  • principal.application
  • principal.asset_id
  • principal.file.md5
  • principal.file.sha1
  • principal.file.sha256
  • principal.hostname
  • principal.ip
  • principal.mac
  • principal.process.file.md5
  • principal.process.file.sha1
  • principal.process.file.sha256
  • principal.process.pid
  • principal.user.email_addresses
  • principal.user.userid

Campos de origem

  • src.asset_id
  • src.hostname
  • src.ip
  • src.mac
  • src.user.userid

Campos de destino

  • target.application
  • target.asset_id
  • target.file.md5
  • target.file.sha1
  • target.file.sha256
  • target.hostname
  • target.ip
  • target.mac
  • target.process.file.md5
  • target.process.file.sha1
  • target.process.file.sha256
  • target.user.email_addresses
  • target.user.employee_id
  • target.user.userid
  • target.user.windows_sid

Campos de rede

  • network.dhcp.chaddr
  • network.dhcp.ciaddr
  • network.dhcp.client_hostname
  • network.dhcp.yiaddr
  • network.dns.answers.class
  • network.dns.answers.name
  • network.dns.answers.type
  • network.dns.questions.class
  • network.dns.questions.name
  • network.dns.questions.type
  • network.email.from
  • network.email.to
  • network.http.method

Campos de resultado de segurança

  • security_result.action
  • security_result.category
  • security_result.rule_name

Como consultar dados de entidade e contexto

Se você pesquisar tipos de registro de entidade ou contexto (como AZURE_AD_CONTEXT ou WORKSPACE_USERS) usando metadata.log_type = "<LOG_TYPE>", a pesquisa não retornará resultados, mesmo que os registros brutos estejam visíveis na pesquisa de registros brutos. Isso ocorre porque a pesquisa de UDM consulta apenas registros de eventos de UDM.

Para pesquisar dados de entidade e contexto, use a sintaxe graph:

  • Para pesquisar o tipo de registro de entidade ou contexto, consulte os campos de metadados graph. Exemplo:

    graph.metadata.event_metadata.log_type = "<LOG_TYPE>"

  • Para pesquisar campos de entidade, use o prefixo graph.entity.noun.field. Exemplo:

    graph.entity.user.email_addresses = "foo_email"

Para mais informações, consulte Realizar uma pesquisa de dados de contexto de entidade.

Criar consultas de pesquisa eficazes para desempenho

Escrever consultas otimizadas é fundamental para maximizar a velocidade e minimizar o consumo de recursos nos dados de segurança. Todas as condições de consulta precisam seguir rigorosamente esta estrutura fundamental:

udm-field operator value

Exemplo: principal.hostname = "win-server"

Como o Google SecOps pode ingerir uma grande quantidade de dados durante uma pesquisa, minimizar o período e restringir o escopo da consulta pode melhorar o desempenho da pesquisa.

Usar expressões regulares na consulta de pesquisa

É possível usar operadores lógicos e de comparação padrão ao criar consultas de pesquisa de UDM para criar expressões complexas:

  • Operadores lógicos: use AND, OR e NOT para combinar condições. AND é considerado se você omitir um operador entre duas condições.
  • Precedência do operador: use parênteses () para substituir a ordem de precedência padrão. Há um limite máximo de 169 operadores lógicos (OR, AND, NOT) que podem ser usados entre parênteses.
  • Operadores de comparação: dependendo do tipo de campo de UDM (string, número inteiro, carimbo de data/hora), os operadores de campo podem incluir: =, !=, >=, >, <, <=

O Google SecOps usa o mecanismo de expressão regular RE2.

Como alternativa, para pesquisar com eficiência um grande conjunto de valores, use as listas de referência.

Usar nocase como um modificador de pesquisa

É possível anexar o modificador nocase a uma condição de comparação de strings para tornar a pesquisa sem distinção entre maiúsculas e minúsculas, que ignora a capitalização.

Por exemplo, a pesquisa a seguir ignora a distinção entre maiúsculas e minúsculas e corresponde a todas as combinações que contêm tim.smith, independentemente do caso:

target.user.userid = "TIM.SMITH" nocase

Evitar o uso de expressões regulares em campos enumerados

Não é possível usar expressões regulares ao pesquisar campos enumerados (campos com um intervalo de valores predefinidos), como metadata.event_type ou network.ip_protocol

O exemplo a seguir é uma pesquisa inválida: metadata.event_type = /NETWORK_*/

Já o exemplo a seguir é uma pesquisa válida: (metadata.event_type = "NETWORK_CONNECTION" ou metadata.event_type = "NETWORK_DHCP")

Usar todos os operadores no campo "Eventos"

Na Pesquisa, alguns campos de UDM (como principal.ip ou target.file.md5) são rotulados como repetidos, porque podem conter uma lista de valores ou tipos de mensagens em um único evento. Os campos repetidos são sempre tratados com o operador any por padrão (não há opção para especificar all).

Quando o operador any é usado, o predicado é avaliado como true se qualquer valor no campo repetido atender à condição. Por exemplo, se você pesquisar principal.ip != "1.2.3.4" e os eventos na pesquisa incluírem principal.ip = "1.2.3.4" e principal.ip = "5.6.7.8", uma correspondência será gerada. Isso expande a pesquisa para incluir resultados que correspondam a qualquer um dos operadores, em vez de corresponder a todos eles.

Cada elemento no campo repetido é tratado individualmente. Se o campo repetido for encontrado em eventos na pesquisa, os eventos serão avaliados para cada elemento no campo. Isso pode causar um comportamento inesperado, especialmente ao pesquisar usando o operador !=.

Ao usar o operador any, o predicado é avaliado como true se qualquer valor no campo repetido atender à condição.

Usar a hora de época do Unix para carimbos de data/hora ou funções YARA-L para conversão de datas

Os campos de carimbo de data/hora são correspondidos usando a hora de época do Unix (o número total de segundos que se passaram desde quinta-feira, 1º de janeiro de 1970, 00:00:00 UTC) ou é possível usar funções YARA-L para conversão de datas.

Ao pesquisar um carimbo de data/hora específico, o seguinte (na hora de época) é válido:

metadata.ingested_timestamp.seconds = 1660784400

O carimbo de data/hora a seguir é inválido:

metadata.ingested_timestamp = "2022-08-18T01:00:00Z"

Ao pesquisar um carimbo de data/hora específico, o seguinte (usando uma função YARA-L para conversão de datas) é válido:

metadata.event_type = "NETWORK_CONNECTION"
timestamp.get_date(metadata.ingested_timestamp.seconds) = "2026-03-15"

O exemplo YARA-L a seguir usa funções timestamp para verificar intervalos de tempo de ingestão:

metadata.event_type = "NETWORK_CONNECTION"
$date = timestamp.get_date(metadata.ingested_timestamp.seconds)
$date > "2026-03-15" AND $date < "2026-03-17"

Como consultar dados recém-ingeridos com carimbos de data/hora mais antigos

Não é possível pesquisar eventos recém-ingeridos que tenham um carimbo de data/hora mais antigo, a menos que você especifique o período do evento a ser consultado. Isso ocorre porque o período é baseado no carimbo de data/hora do evento analisado, em vez do carimbo de data/hora de ingestão do evento de registro bruto.

Para pesquisar eventos de UDM em registros ingeridos com carimbos de data/hora de eventos mais antigos, use a opção Todo o período para pesquisar e consultar metadata.ingested_timestamp.

Campos excluídos de filtros

Os campos a seguir são intencionalmente excluídos dos filtros de pesquisa:

  • metadata.id
  • metadata.product_log_id
  • *.timestamp

Embora esses campos contenham metadados importantes, os valores exclusivos deles introduzem alta cardinalidade e variância nas estatísticas, o que afeta negativamente o desempenho da pesquisa.

Solução de problemas

Se você receber uma mensagem de erro genérica, como "Erro: a pesquisa encontrou um erro e não foi possível carregar os dados", siga as etapas abaixo para resolver o problema. Se o erro persistir, entre em contato com o suporte ao cliente.

  • Conecte-se ao Google SecOps de uma rede diferente. Por exemplo, use uma VM na nuvem para ajudar a identificar problemas de rede.
  • Confira se as chamadas da API Chronicle são permitidas pelo firewall ou pela configuração ou política de proxy da sua organização.
  • Verifique se nenhum limite de dados está configurado para chamadas da API Search, já que as pesquisas podem retornar grandes conjuntos de dados.
  • As consultas de pesquisa podem ser executadas de forma assíncrona e podem exigir mais tempo para retornar dados. É possível conferir as pesquisas executadas anteriormente no histórico de pesquisa e selecioná-las para conferir os resultados mais tarde.

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