Aplicar junções em pesquisas e painéis

Compatível com:

As junções ajudam a correlacionar dados de várias fontes para fornecer mais contexto para uma investigação. Ao vincular eventos, entidades e outros dados relacionados, é possível investigar cenários de ataques complexos e visualizar tendências.

Este documento explica como usar a operação de junção no campo Pesquisa e nos painéis do painel do Google SecOps. Ele aborda os tipos de junção compatíveis, os casos de uso e as práticas recomendadas.

Principais conceitos de junções

Para criar uma junção, conecte fontes de dados usando variáveis de marcador de posição compartilhadas ou instruções de igualdade explícitas (por exemplo, $e1.hostname = $e2.hostname). Ao definir uma junção na seção match de uma consulta baseada em estatísticas, use variáveis de marcador de posição.

Os exemplos a seguir mostram como vincular fontes de dados usando dois campos com um sinal de igual (=) e uma variável de marcador de posição compartilhada.

  • Exemplo 1: junção implícita usando variáveis de marcador

    events:
  // Assign a value from the first event to the placeholder variable $user
  $user = $e1.principal.user.userid

  // The second assignment creates an implicit join, linking $e2 to $e1
  // where the user ID is the same.
  $user = $e2.principal.user.userid

match:
  $user over 1h

condition:
  $e1 and $e2

  • Exemplo 2: junção explícita usando igualdade e marcadores de posição

    $e1.principal.ip = $ip
$e1.metadata.event_type = "USER_LOGIN"
$e1.principal.hostname = $host

$e2.target.ip = $ip
$e2.principal.hostname = "altostrat"
$e2.target.hostname = $host

match:
  $ip, $host over 5m

Os exemplos nesta seção demonstram a sintaxe usada na Pesquisa.

Por padrão, as consultas na Pesquisa não diferenciam maiúsculas de minúsculas.

Junção de evento a evento

  • Uma junção de evento a evento conecta dois eventos diferentes do Modelo de dados universal (UDM). A consulta de exemplo a seguir vincula um evento USER_LOGIN a outro para encontrar o nome do host (altostrat) com que o usuário interagiu, com base em um endereço IP comum:

    $e1.principal.ip = $ip
$e1.metadata.event_type = "USER_LOGIN"

$e2.target.ip = $ip
$e2.principal.hostname = "altostrat"

match:
  $ip over 5m

Junção de evento e ECG

  • Uma junção de evento e ECG conecta um evento da UDM a uma entidade do Entity Context Graph (ECG). A consulta de exemplo a seguir encontra um evento NETWORK_CONNECTION e um ASSET do gráfico de entidades que compartilham o mesmo nome de host em uma janela de uma hora:

    events:
  $e1.metadata.event_type = "NETWORK_CONNECTION"
  $g1.graph.metadata.entity_type = "ASSET"
  $e1.principal.asset.hostname = $g1.graph.entity.asset.hostname
  $x = $g1.graph.entity.asset.hostname

match:
  $x over 1h

condition:
  $e1 and $g1

Junção de evento e tabela de dados

  • Uma junção de evento e tabela de dados conecta eventos do UDM a entradas em uma tabela de dados personalizada. Isso é útil para verificar dados de eventos ao vivo em relação a uma lista definida pelo usuário, como endereços IP maliciosos ou agentes de ameaças conhecidos. A consulta de exemplo a seguir une eventos NETWORK_CONNECTION com uma tabela de dados para encontrar conexões que envolvem endereços IP específicos dessa lista:

    $ip = %DATATABLE_NAME.COLUMN_NAME
$ip = $e1.principal.ip
$e1.metadata.event_type = "NETWORK_CONNECTION"

match:
  $ip over 1h

Usar a cláusula IN com tabelas de dados

Também é possível usar a cláusula in para verificar se um valor de campo existe em uma coluna da tabela de dados. Essa sintaxe é compatível com todas as fontes de dados (por exemplo, ioc.type in %abc.type) e oferece uma maneira conveniente de filtrar eventos com base em listas de referência sem definir variáveis de marcador de posição explícitas para a junção.

Casos de uso comuns

Esta seção lista algumas maneiras comuns de usar junções.

Detectar roubo e uso de credenciais

Objetivo: encontrar instâncias em que um usuário faz login com sucesso e depois exclui rapidamente um arquivo crítico do sistema. Isso pode sugerir um sequestro de conta ou atividade interna maliciosa.

Tipo de junção: junção de evento com evento

Descrição: essa consulta conecta dois eventos distintos que não são suspeitos por si só, mas se tornam altamente suspeitos quando ocorrem juntos. Primeiro, ele procura um evento USER_LOGIN e depois um evento FILE_DELETION. Eles são unidos pelo user.userid comum com uma janela de tempo curta.

  • Consulta de detecção de roubo de credenciais

    // Event 1: A user successfully logs in
$e1.metadata.event_type = "USER_LOGIN"
$e1.security_result.action = "ALLOW"
$e1.principal.user.userid = $user

// Event 2: The same user deletes a critical file
$e2.metadata.event_type = "FILE_DELETION"
$e2.target.file.full_path = /etc\/passwd|C:\\Windows\\System32\\/
$e2.principal.user.userid = $user

match:
  $user over 10m

condition:
  $e1 and $e2

Identificar conexões arriscadas de recursos essenciais

Objetivo: enriquecer os dados da rede em tempo real com informações de recursos para encontrar conexões de saída de servidores que não deveriam se comunicar com domínios externos de baixa prevalência (por exemplo, um servidor de banco de dados de produção).

Tipo de junção: junção de evento e ECG

Descrição: uma única conexão de rede com um domínio raro pode não ser de alta prioridade. No entanto, essa consulta aumenta a importância do evento ao associá-lo ao gráfico de contexto de entidade (ECG, na sigla em inglês). Ele procura especificamente eventos NETWORK_CONNECTION que vêm de recursos rotulados como "Servidor de banco de dados crítico" no gráfico de entidades.

  • Consulta de conexões arriscadas

    events:
  $e.metadata.event_type = "NETWORK_CONNECTION"
  $e.target.domain.prevalence.day_count <= 5

  $asset.graph.metadata.entity_type = "ASSET"
  $asset.graph.entity.asset.labels.value = "Critical Database Server"

  $e.principal.asset.hostname = $asset.graph.entity.asset.hostname
  $host = $e.principal.asset.hostname

match:
  $host over 1h

condition:
  $e and $asset

Buscar IOCs de agentes de ameaças

Objetivo: pesquisar ativamente indicadores de comprometimento (IoCs) verificando todas as consultas DNS ativas em uma lista de domínios conhecidos por serem usados por um agente de ameaças específico.

Tipo de junção: junção de tabela de dados e evento

Descrição: sua equipe de inteligência contra ameaças mantém uma tabela de dados chamada ThreatActor_Domains que lista domínios maliciosos. Essa consulta une todos os eventos NETWORK_DNS_QUERY em tempo real com essa tabela de dados. Ela mostra imediatamente qualquer instância em que um host na sua rede tenta resolver um domínio da sua lista de inteligência contra ameaças.

  • Consulta de busca de IOCs de agentes de ameaças

    // Datatable: Get the list of malicious domains
$domain = %DATATABLE_NAME.COLUMN_NAME

// Event: A DNS query is made
$e.metadata.event_type = "NETWORK_DNS"
$e.network.dns.questions.name = $domain

match:
  $domain over 5m

condition:
  $e

Junções em painéis

Os painéis oferecem suporte a uma variedade maior de fontes de dados e janelas de correlação mais longas do que na Pesquisa. Ao contrário das consultas SQL padrão, a YARA-L 2.0 não usa instruções JOIN explícitas. Em vez disso, ela conecta fontes de dados correlacionando variáveis de marcador de posição compartilhadas ou usando consultas de várias etapas.

Diferenciação entre maiúsculas e minúsculas

As consultas do painel diferenciam maiúsculas de minúsculas. Para fazer uma junção ou pesquisa sem diferenciação de maiúsculas e minúsculas em um painel, use o modificador nocase.

Fontes de dados compatíveis

Nos painéis, é possível unir dados de combinações compatíveis de fontes de dados. Nem todas as combinações de fontes de dados podem ser unidas em uma única consulta.

Toda referência de dados em uma consulta de painel de vários origens precisa incluir o qualificador de prefixo YARA-L (por exemplo, $u1), não apenas os campos unidos. Isso permite que o sistema identifique corretamente a propriedade do campo em fontes de dados sobrepostas.

Combinações de junção compatíveis

As junções permitem correlacionar eventos da UDM, contexto de entidade e tabelas de dados em dashboards integrados. Para manter a performance do sistema, revise as combinações compatíveis e os limites técnicos nesta seção antes de criar suas consultas.

  • Evento do UDM para evento do UDM (vários eventos)
  • Evento da UDM para contexto da entidade
  • Evento do UDM para tabela de dados

  • Histórico de caso a caso: essa combinação é estritamente limitada a exatamente uma fonte case e uma fonte case_history. Não é possível incluir outras fontes de dados nessa junção.

Para informações sobre limites e proteções, consulte Limitações e restrições técnicas.

Exemplo: junção de caso e case_history

É possível correlacionar os metadados do caso com a atividade histórica usando o ID exclusivo do caso.

  • O exemplo a seguir une as fontes de dados case e case_history para contar o número total de ações históricas de cada caso de alta prioridade.

      // 1. Establish the Join using a shared placeholder variable ($case_id)
  $h.case_history.case_response_platform_info.case_id = $case_id
  $c.case.response_platform_info.response_platform_id = $case_id

  // 2. Apply Filters
  $c.case.priority = "PRIORITY_HIGH"

  // 3. Group the correlated data by the Case ID
  match:
    $case_id

  // 4. Calculate the selected metrics to display on the dashboard
  outcome:
    $case_name = array_distinct($c.case.display_name)
    $total_historical_actions = count($h.case_history.case_activity)

Caso de uso avançado: cálculo do MTTR

Para métricas mais complexas, como tempo médio para resolução (MTTR) ou tempo médio para fechamento (MTTC), use uma consulta de várias etapas. Isso permite calcular a duração de cada caso individual na primeira etapa e, em seguida, calcular a média dessas durações globalmente no bloco de resultados finais.

  • A consulta a seguir calcula o tempo médio para fechar casos (em minutos) em todos os casos no "Ambiente padrão".

    stage stage1 {
  // 1. Establish the Join
  $h.case_history.case_response_platform_info.case_id = $case_id
  $c.case.response_platform_info.response_platform_id = $case_id

  // 2. Filter by specific environment
  $c.case.environment = "Default Environment"

  // 3. Group by Case ID to process per case
  match:
    $case_id

  // 4. Calculate the Time to Close (TTC) for each case individually
  outcome:
    $case_close_time = max(if($h.case_history.case_activity = "CLOSE_CASE", $h.case_history.event_time.seconds, 0))
    $status = array_distinct($h.case_history.case_activity)

    // Subtract the very first event time (creation) from the close time
    $TTC = $case_close_time - min($h.case_history.event_time.seconds)

  // 5. Filter to ensure the case has a complete lifecycle
  condition:
    arrays.contains($status, "CREATE_CASE") and
    arrays.contains($status, "CLOSE_CASE")
}

// 6. Global Aggregation: Calculate the Mean (Average) across all processed cases
outcome:
  $case_count = count($stage1.case_id)
  $MTTC = (math.round(avg($stage1.TTC) / 60))

Práticas recomendadas

Para otimizar a performance das suas consultas de junção e garantir que elas sejam processadas de maneira eficiente, siga estas práticas recomendadas para filtrar eventos e gerenciar o escopo da pesquisa.

Use filtros específicos para reduzir o número de eventos

As consultas de junção podem consumir muitos recursos porque combinam vários resultados.

  • Filtros amplos e gerais podem causar falhas nas consultas, às vezes após um longo atraso. Por exemplo:

    • target.ip != ""

    • metadata.event_type = "NETWORK_CONNECTION" (se esse tipo de evento for muito comum no seu ambiente)

  • Recomendamos combinar filtros gerais com mais específicos para reduzir o número total de eventos que a consulta precisa processar. Um filtro amplo como target.ip != "" deve ser combinado com filtros mais específicos para melhorar o desempenho da consulta. Por exemplo:

    $e1.metadata.log_type = $log
$e1.metadata.event_type = "USER_LOGIN"
$e1.target.ip != ""

$e2.metadata.log_type = $log
$e2.principal.ip = "10.0.0.76"
$e2.target.hostname != "altostrat"

match:
$log over 5m

Se a consulta ainda estiver lenta, reduza o período geral dela (por exemplo, de 30 dias para uma semana).

Para mais informações, consulte Práticas recomendadas da YARA-L.

Limitações e restrições técnicas

As limitações e os limites a seguir se aplicam ao usar junções na Pesquisa e nos painéis.

Janela de correspondência e limites de consulta

A janela de correspondência define o período específico em que os eventos são correlacionados. Isso é diferente do período da pesquisa selecionado na interface do usuário.

A pesquisa é otimizada para investigações rápidas ou em tempo real em períodos mais curtos.

Limite de consulta Uso
Até 48 horas (algumas consultas podem oferecer suporte a períodos mais longos). Correlacionar eventos em investigações rápidas.

Limites nos painéis

Os painéis oferecem suporte a análises históricas de longo prazo.

Tipo de mesclagem Limite de consulta Uso
UDM para UDM e UDM para entidade 31 dias Consultas de telemetria de alto volume.
Case-to-CaseHistory 90 dias Consultas de rastreamento do ciclo de vida.
Outras configurações compatíveis Até 365 dias Substituição para fontes não UDM ou baseadas em métricas (por exemplo, métricas de ingestão).

Limites de fontes de dados e tabelas

O número máximo de fontes de dados e tabelas que podem ser combinadas em uma única consulta depende de você estar usando a Pesquisa ou painéis.

Restrições de pesquisa

  • É possível usar no máximo dois eventos de UDM por consulta.
  • É possível usar no máximo um evento de ECG por consulta.
  • É possível usar no máximo duas tabelas de dados por consulta.
  • Não é possível unir uma tabela de dados diretamente a uma tabela de contexto de entidade. É necessário usar um evento da UDM como uma ponte intermediária (por exemplo, correlacionar $event.target.hostname com $datatable.hostname e $asset.graph.entity.asset.hostname).

Restrições do painel

Tipo de mesclagem Número máximo de tabelas de eventos (UDM ou tabela de dados) Número máximo de tabelas de entidades
Vários eventos (UDM para UDM) 2 N/A
UDM para entidade 2 1
UDM para tabela de dados 2 N/A
Consultas de várias etapas 2 1

Performance e proteções

O sistema monitora consultas de junção complexas para consumo excessivo de recursos. Para proteger o desempenho geral do ambiente, o sistema pode pausar ou isolar automaticamente consultas que excedam os limites de segurança de recursos.

Se uma consulta falhar ou retornar erros indicando que excedeu os limites de recursos, tente as seguintes otimizações:

  • Diminua a janela de tempo da consulta.
  • Adicione filtros mais específicos para reduzir o tamanho do conjunto de dados antes da junção.
  • Simplifique suas agregações.

Restrições de tipo de consulta e API

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