Práticas recomendadas de pesquisa
Este documento descreve as práticas recomendadas da Google para usar a funcionalidade Pesquisa no Google Security Operations. As pesquisas podem exigir recursos computacionais substanciais se não forem cuidadosamente criadas. O desempenho também varia consoante o tamanho e a complexidade dos dados na sua instância do Google SecOps.
Construa consultas de pesquisa eficazes
Cada condição tem de estar no formato udm-field operator value
.
Por exemplo:
principal.hostname = "win-server"
Restrinja o intervalo de tempo da sua pesquisa
Uma vez que o SecOps da Google pode assimilar uma grande quantidade de dados durante uma pesquisa, recomendamos que minimize o intervalo de tempo para restringir o âmbito e melhorar o desempenho da pesquisa.
Use expressões regulares na consulta de pesquisa
Pode usar expressões regulares quando pesquisa dados:
- Utilizar
AND
,OR
eNOT
. AND
é assumido na ausência dos outros operadores.- Use parênteses para modificar a ordem de precedência. Existe um limite máximo de 169 operadores lógicos (
OR
,AND
eNOT
) que podem ser usados nos parênteses. - Consoante o tipo de campo, os operadores de campo podem incluir:
= != >= > < <=
Em alternativa, pode usar as listas de referência.
Use nocase
como modificador de pesquisa
nocase
pode ser usado como modificador para ignorar a capitalização.
Por exemplo, a seguinte pesquisa é inválida:
target.user.userid = "TIM.SMITH" nocase
Não use expressões regulares para campos enumerados
Não pode usar expressões regulares para campos enumerados (campos com um intervalo de valores predefinidos), como metadata.event_type
ou network.ip_protocol
.
O exemplo seguinte é uma pesquisa inválida:
metadata.eventtype = /NETWORK*/
Por outro lado, o exemplo seguinte é uma pesquisa válida:
(metadata.event_type = "NETWORK_CONNECTION" or
metadata.event_type = "NETWORK_DHCP")
Usar todos os operadores no campo Eventos
Na Pesquisa, alguns campos estão etiquetados como repetidos, o que significa que contêm uma lista de valores ou tipos de mensagens. Os campos repetidos são sempre tratados com o operador any
por predefinição (não existe nenhuma opção para especificar
all
).
Quando o operador any
é usado, o predicado é avaliado como verdadeiro se qualquer valor
no campo repetido satisfizer a condição. Por exemplo, se pesquisar
principal.ip != "1.2.3.4"
e os eventos na sua pesquisa incluírem
principal.ip = "1.2.3.4"
e principal.ip = "5.6.7.8"
, é gerada uma correspondência. Isto expande a sua pesquisa para incluir resultados que correspondem a qualquer um dos operadores, em vez de corresponderem a todos.
Cada elemento no campo repetido é tratado individualmente. Se o campo repeated for encontrado em eventos na pesquisa, os eventos são avaliados para cada elemento no campo. Isto pode causar um comportamento inesperado, especialmente quando
pesquisa através do operador !=
.
Quando usa o operador any
, o predicado é avaliado como verdadeiro se qualquer valor
no campo repetido satisfizer a condição.
As indicações de tempo usam o tempo de época Unix
Os campos de data/hora são correspondidos através do tempo de época Unix (número de segundos decorridos desde quinta-feira, 1 de janeiro de 1970, às 00:00:00).
Quando pesquisa uma indicação de tempo específica, o seguinte (em tempo epoch) é válido:
metadata.ingested_timestamp.seconds = 1660784400
A seguinte data/hora é inválida:
metadata.ingested_timestamp = "2022-08-18T01:00:00Z"
Existem determinados campos que são excluídos dos filtros, incluindo os seguintes:
metadata.id
metadata.product_log_id
*.timestamp
Como estes campos contêm frequentemente valores únicos, podem adicionar detalhes desnecessários, o que pode reduzir a eficácia da pesquisa.
Precisa de mais ajuda? Receba respostas de membros da comunidade e profissionais da Google SecOps.