Práticas recomendadas de pesquisa para UDM
Este documento descreve as práticas recomendadas do Google para realizar pesquisas usando a pesquisa UDM. As pesquisas UDM podem exigir recursos computacionais substanciais para serem concluídas se não forem construídas com cuidado. O desempenho também varia de acordo com o tamanho e a complexidade dos dados na sua instância do Google Security Operations.
Construção básica de uma pesquisa UDM
Cada condição precisa estar no formato udm-field operator value
.
Por exemplo:
principal.hostname = "win-server"
Otimizar o intervalo de tempo da pesquisa do UDM
Sempre tente limitar o intervalo de tempo ao mínimo necessário. As Operações de segurança do Google podem ingerir uma enorme quantidade de dados. Portanto, limitar a amplitude desses dados durante a realização de uma pesquisa pode melhorar substancialmente o desempenho da pesquisa.
Como usar expressões regulares com a pesquisa do UDM
É possível usar expressões regulares ao realizar pesquisas do UDM:
- Use
AND
,OR
eNOT
. AND
é usado na ausência dos outros operadores.- Use parênteses para modificar a ordem de precedência.
- Dependendo do tipo de campo, os operadores de campo podem incluir:
= != >= > < <=
Usar "nocase" como modificador de pesquisa
nocase
pode ser usado como um modificador para ignorar letras maiúsculas.
Por exemplo, a pesquisa a seguir é inválida:
target.user.userid = "TIM.SMITH" nocase
As expressões regulares não funcionam para campos enumerados
Não é possível usar expressões regulares para campos enumerados (campos com um intervalo de valores predefinidos), como metadata.event_type
ou network.ip_protocol
.
Por exemplo, a pesquisa a seguir é inválida:
metadata.eventtype = /NETWORK*/
No entanto, a pesquisa a seguir é válida (e se aproxima do que foi tentado acima):
(metadata.event_type = "NETWORK_CONNECTION" or metadata.event_type = "NETWORK_DHCP")
Usar qualquer um dos operadores no campo "Eventos".
Na pesquisa UDM, alguns campos são marcados como repetidos, o que significa que são listas de valores ou outros tipos de mensagens. Ao contrário da YARA-L, os campos repetidos na pesquisa UDM são sempre tratados com o operador any
por padrão, sem a opção de especificar all
na pesquisa.
Quando o operador any
é usado, o predicado é avaliado como verdadeiro se algum valor no campo repetido satisfizer a 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"
, a pesquisa vai gerar correspondências. Isso expande sua pesquisa para incluir resultados que correspondam a qualquer um dos operadores, e não a todos eles.
Cada elemento do campo repetido é tratado individualmente. Se o campo repetido for encontrado em eventos na pesquisa, os eventos sã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 será avaliado como verdadeiro se algum valor no campo repetido satisfizer a condição.
Os carimbos de data/hora usam o horário de época Unix
A correspondência dos campos de carimbo de data/hora é feita pelo horário Unix (número de segundos decorridos desde quinta-feira, 1o de janeiro de 1970, 00:00:00).
Ao pesquisar um carimbo de data/hora específico, o seguinte valor (no horário da é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"
Alguns campos são excluídos dos filtros, entre eles:
metadata.id
metadata.product_log_id
*.timestamp
Como esses campos tendem a ter valores únicos, exibi-los cria mais "ruído" do que o valor na interface de pesquisa do UDM.
Forma normal conjuntiva
A pesquisa UDM usa a forma normal conjuntiva, uma abordagem à lógica booleana que expressa fórmulas como conjunções de cláusulas com um AND ou OR. Cada cláusula conectada por uma conjunção (AND), deve ser literal ou conter uma disjunção, (OR).
Exemplo:
(A OR B) AND (C OR D)
(A OR B) AND (NOT C OR B)
As cláusulas também podem ser literais:
A OR B
A AND B
Não é possível usar A OR (B AND C)
na forma normal conjuntiva, mas é possível usar (A OR B) AND (A OR C)
.
O exemplo a seguir geraria um erro na pesquisa do UDM:
principal.hostname = "win-server" nocase OR (principal.hostname = "win-adfs" nocase AND metadata.event_type = "NETWORK_CONNECTION")
Confira a seguir um exemplo válido usando a forma normal conjuntiva em uma pesquisa do UDM:
(principal.hostname = "win-server" nocase OR principal.hostname = "win-adfs" nocase) AND (principal.hostname = "win-server" nocase OR metadata.event_type = "NETWORK_CONNECTION")
Não é possível usar NOT (A OR B)
na forma normal conjuntiva, mas é possível usar NOT A AND NOT B
.
O seguinte é inválido:
principal.hostname = "win-server" nocase AND NOT(metadata.event_type = "PROCESS_TERMINATION" OR metadata.event_type = "USER_RESOURCE_ACCESS")
O seguinte é válido:
principal.hostname = "win-server" nocase AND NOT metadata.event_type = "PROCESS_TERMINATION" AND NOT metadata.event_type = "USER_RESOURCE_ACCESS"
Não é possível usar A AND (B OR (C AND D))
na forma normal conjuntiva, mas é possível usar A AND (B OR C) AND (B OR D)
.
O seguinte é inválido:
principal.hostname = "win-server" nocase AND (metadata.event_type = "PROCESS_LAUNCH" OR (metadata.event_type = "NETWORK_CONNECTION" AND target.ip = "10.128.0.21")
O seguinte é válido:
principal.hostname = "win-server" nocase AND (metadata.event_type = "PROCESS_LAUNCH" OR metadata.event_type = "NETWORK_CONNECTION") AND (metadata.event_type = "PROCESS_LAUNCH" OR target.ip = "10.128.0.21")