Criar consultas de vários estágios

Compatível com:

Este documento descreve como as consultas de vários estágios em YARA-L permitem inserir a saída de uma etapa de consulta diretamente na entrada de uma etapa subsequente. Esse processo oferece mais controle sobre a transformação de dados do que uma única consulta monolítica.

Integrar consultas de vários estágios com recursos atuais

As consultas de vários estágios funcionam em conjunto com os seguintes recursos do Google Security Operations:

  • Regras de detecção compostas: consultas de várias etapas complementam as regras de detecção compostas ao preencher a lacuna entre a detecção automatizada e a investigação ativa. Embora as regras compostas sejam excelentes para identificar correlações complexas de vários eventos em janelas de tempo estendidas, as consultas de vários estágios permitem que os analistas façam a transição dessas detecções para pesquisas iterativas em tempo real, validando e definindo instantaneamente o escopo de uma ameaça em desenvolvimento.

  • Períodos e regras de vários eventos:é possível usar consultas de vários estágios para detectar anomalias comparando diferentes períodos nos seus dados. Por exemplo, é possível usar as consultas iniciais para estabelecer um valor de referência em um período estendido e, em seguida, usar consultas posteriores para avaliar a atividade recente em relação a esse valor. Você também pode usar regras de vários eventos para criar um tipo de comparação semelhante.

As consultas de vários estágios em YARA-L são compatíveis com Painéis e Pesquisa.

As junções ajudam a correlacionar dados de várias fontes para fornecer mais contexto a uma investigação. Ao vincular eventos, entidades e outros dados relacionados, é possível investigar cenários de ataque complexos. Para mais informações, consulte Usar mesclagens na pesquisa.

Principais considerações

Ao configurar uma consulta de vários estágios, observe o seguinte:

  • Etapa de limite: as consultas de vários estágios precisam conter entre uma e quatro etapas nomeadas, além da etapa raiz.
  • Sintaxe de ordem: sempre defina a sintaxe de estágio nomeado antes da sintaxe de estágio raiz.

Recomendamos que você analise os problemas conhecidos e as soluções alternativas recomendadas ao implementar consultas de várias etapas:

  • Todas as consultas de várias etapas se comportam como consultas de pesquisa de estatísticas. A saída consiste em estatísticas agregadas, e não em eventos não agregados ou linhas da tabela de dados.

  • A performance das junções com eventos de UDM e de entidade de um lado pode ser baixa devido ao tamanho desse conjunto de dados. Recomendamos filtrar o lado dos eventos de UDM e entidade da junção o máximo possível (por exemplo, filtrar por tipo de evento).

Para orientações gerais sobre práticas recomendadas, consulte Práticas recomendadas do YARA-L 2.0. Para informações específicas sobre junções, consulte Práticas recomendadas.

Terminologia importante

No contexto de junções, um estágio com janela se refere a um estágio com uma seção match que contém uma janela. Por outro lado, um estágio de tabela não gera janelas.

Criar uma consulta YARA-L de vários estágios

Para criar uma consulta YARA-L de várias etapas, siga estas etapas.

Estrutura e sintaxe de estágio

Acesse Investigação > Pesquisar. Siga esta estrutura ao definir os estágios da consulta:

Sintaxe: use a seguinte sintaxe para nomear cada etapa e separá-la das outras:

stage <stage name> { }

  • Chaves: coloque toda a sintaxe de estágio dentro de chaves {}.

  • Ordem: defina a sintaxe para todas as etapas nomeadas antes de definir a etapa raiz.

  • Referência: cada etapa pode referenciar etapas definidas anteriormente na consulta.

  • Etapa raiz: uma consulta precisa ter uma etapa raiz, que é processada depois de todas as etapas nomeadas.

O exemplo de etapa a seguir, daily_stats, coleta estatísticas diárias da rede:

stage daily_stats {
  metadata.event_type = "NETWORK_CONNECTION"
  $source = principal.hostname
  $target = target.ip
  $source != ""
  $target != ""
  match:
    $source, $target by day
  outcome:
    $exchanged_bytes = sum(network.sent_bytes + network.received_bytes)
}

Acessar a saída da etapa

A saída de uma etapa nomeada fica acessível às etapas subsequentes usando campos de etapa. Os campos de etapa correspondem às variáveis match e outcome da etapa e podem ser usados de maneira semelhante aos campos do modelo de dados unificado (UDM).

Use a seguinte sintaxe para acessar um campo de etapa:

$<stage name>.<variable name>

Opcional: acessar carimbos de data/hora da janela

Se um estágio nomeado usar uma janela de salto, deslizante ou rotativa, acesse o início e o fim da janela para cada linha de saída usando estes campos reservados:

  • $<stage name>.window_start

  • $<stage name>.window_end

Os campos window_start e window_end são números inteiros expressos em segundos desde a era Unix. As janelas em diferentes estágios podem variar de tamanho.

Exemplos de consultas de vários estágios

Os exemplos nesta seção ajudam a ilustrar como criar uma consulta YARA-L completa de vários estágios.

Exemplo: pesquisar conexões de rede com atividade incomum (horas)

Este exemplo de várias etapas do YARA-L identifica pares de endereços IP com atividade de rede maior que o normal, segmentando pares que mantêm alta atividade por mais de três horas. A consulta inclui dois componentes obrigatórios: o estágio nomeado, hourly_stats, e o estágio root.

A etapa hourly_stats procura pares principal.ip e target.ip com altos níveis de atividade de rede.

Essa etapa retorna um único valor por hora para os seguintes campos:

  • Estatísticas do IP de origem (string): $hourly_stats.src_ip

  • Estatísticas do IP de destino (string): $hourly_stats.dst_ip

  • Estatísticas para a contagem de eventos (número inteiro): $hourly_stats.count

  • Desvio padrão de bytes recebidos (ponto flutuante): $hourly_stats.std_recd_bytes

  • Média de bytes recebidos (ponto flutuante): $hourly_stats.avg_recd_bytes

  • Horário de início do agrupamento por hora em segundos desde a época do Unix (número inteiro): $hourly_stats.window_start

  • Horário de término do agrupamento por hora em segundos desde a época do Unix (inteiro): $hourly_stats.window_end

A etapa raiz processa a saída da etapa hourly_stats. Ele calcula estatísticas para pares principal.ip e target.ip com atividade acima do limite especificado por $hourly_stats. Em seguida, ele filtra os pares com mais de três horas de alta atividade.


stage hourly_stats {
  metadata.event_type = "NETWORK_CONNECTION"
  $src_ip = principal.ip
  $dst_ip = target.ip
  $src_ip != ""
  $dst_ip != ""

  match:
    $src_ip, $dst_ip by hour

  outcome:
    $count = count(metadata.id)
    $avg_recd_bytes = avg(network.received_bytes)
    $std_recd_bytes = stddev(network.received_bytes)

  condition:
    $avg_recd_bytes > 100 and $std_recd_bytes > 50
}

$src_ip = $hourly_stats.src_ip
$dst_ip = $hourly_stats.dst_ip
$time_bucket_count = strings.concat(timestamp.get_timestamp($hourly_stats.window_start), "|", $hourly_stats.count)

match:
 $src_ip, $dst_ip

outcome:
 $list = array_distinct($time_bucket_count)
 $count = count_distinct($hourly_stats.window_start)

condition:
 $count > 3

Se você alterar a condição de correspondência na etapa raiz da seguinte maneira, poderá introduzir uma agregação em janela por dia para a consulta de vários estágios.

match:
 $src_ip, $dst_ip by day

Exemplo: pesquisar conexões de rede com atividade incomum (usando a pontuação Z)

Essa consulta de várias etapas compara a atividade média diária da rede com a atividade de hoje usando um cálculo de pontuação Z, que mede o número de desvios padrão da média. Essa consulta pesquisa atividades de rede incomumente altas entre recursos internos e sistemas externos.

Pré-requisito: o período da consulta precisa ser maior ou igual a dois dias e incluir o dia atual para que o escore Z calculado seja eficaz.

Essa consulta de vários estágios inclui as etapas daily_stats e root, que trabalham juntas para calcular o escore Z da atividade de rede:

  • A etapa daily_stats realiza a agregação diária inicial. Ele calcula o total de bytes trocados a cada dia para cada par de IP (source e target) e retorna os seguintes campos de estágio (correspondentes às colunas nas linhas de saída):

    • $daily_stats.source: singular, string
    • $daily_stats.target: singular, string
    • $daily_stats.exchanged_bytes: singular, número inteiro
    • $daily_stats.window_start: singular, número inteiro
    • $daily_stats.window_end: singular, número inteiro

  • A etapa raiz agrega a saída da etapa daily_stats para cada par de IP. Ele calcula a média e o desvio padrão dos bytes diários trocados em todo o intervalo de pesquisa, além dos bytes trocados hoje. Ele usa esses três valores calculados para determinar a pontuação Z.

  • A saída lista os escores Z de todos os pares de IP de hoje, classificados em ordem decrescente.

// Calculate the total bytes exchanged per day by source and target

stage daily_stats {
  metadata.event_type = "NETWORK_CONNECTION"
  $source = principal.hostname
  $target = target.ip
  $source != ""
  $target != ""

  match:
    $source, $target by day

  outcome:
    $exchanged_bytes = sum(network.sent_bytes + network.received_bytes)
}

// Calculate the average per day over the time window and compare with the bytes exchanged today

$source = $daily_stats.source
$target = $daily_stats.target
$date = timestamp.get_date($daily_stats.window_start)

match:
  $source, $target

outcome:
  $today_bytes = sum(if($date = timestamp.get_date(timestamp.current_seconds()), cast.as_int($daily_stats.exchanged_bytes), 0))
  $average_bytes = window.avg($daily_stats.exchanged_bytes)
  $stddev_bytes = window.stddev($daily_stats.exchanged_bytes)
  $zscore = ($today_bytes - $average_bytes) / $stddev_bytes

order:
  $zscore desc

Exportar variáveis não agregadas de estágios

Em uma consulta típica de vários estágios, os dados geralmente são transmitidos entre os estágios por um processo de agregação, que pode "reunir" vários eventos em um único resumo. No entanto, há cenários em que é necessário preservar os detalhes específicos de cada evento, como um ID de processo exclusivo ou uma linha de comando específica, sem perder essa granularidade. Para isso, exporte variáveis diretamente sem uma função de agrupamento.

As etapas nomeadas podem incluir uma seção outcome não agregada. Isso significa que as variáveis definidas nessa seção outcome são geradas diretamente da etapa, permitindo que as etapas subsequentes acessem essas variáveis como campos de etapa sem exigir uma agregação agrupada.

Esse detalhe é útil porque:

  • Preserva a fidelidade dos dados: é possível transmitir os atributos exatos de um evento (por exemplo, um caminho de arquivo específico) para a próxima etapa sem precisar usar uma agregação artificial de "substituição", como max() ou array_distinct().
  • Reduz a complexidade da consulta: simplifica a lógica da YARA-L ao remover a necessidade de uma seção match ou de agrupar instruções apenas para transportar um valor do estágio 1 para o estágio 2.
  • Otimiza a performance: ao ignorar o mecanismo de agregação, o sistema pode transmitir dados entre as etapas com mais eficiência, o que resulta em tempos de execução mais rápidos para pesquisas complexas e de alto volume.

Exemplo: exportar variável não agregada

Este exemplo demonstra como exportar variáveis não agregadas. Observe a seguinte lógica:

  • A etapa top_5_bytes_sent pesquisa os cinco eventos com a maior atividade de rede.

  • A etapa top_5_bytes_sent gera os seguintes campos de etapa correspondentes às colunas nas linhas de saída:

    • $top_5_bytes_sent.bytes_sent: singular, número inteiro
    • $top_5_bytes_sent.timestamp_seconds: singular, número inteiro

  • A etapa root calcula os carimbos de data/hora mais recentes e mais antigos dos cinco eventos com maior atividade de rede.

stage top_5_bytes_sent {
  metadata.event_type = "NETWORK_CONNECTION"
  network.sent_bytes > 0

  outcome:
    $bytes_sent = network.sent_bytes
    $timestamp_seconds = metadata.event_timestamp.seconds

  order:
    $bytes_sent desc

  limit:
    5
}

outcome:
  $latest_timestamp = timestamp.get_timestamp(max($top_5_bytes_sent.timestamp_seconds))
  $earliest_timestamp = timestamp.get_timestamp(min($top_5_bytes_sent.timestamp_seconds))

Implementar o janelamento em consultas de vários estágios

Nas detecções de vários estágios, o janelamento permite definir limites de tempo específicos para a correlação de eventos em um estágio. Ao particionar dados em intervalos temporais discretos, como uma janela deslizante de 5 minutos ou uma janela contínua de 1 hora, é possível identificar padrões como ataques de força bruta ou comportamento de beaconing que só ficam visíveis quando analisados como uma sequência limitada por tempo.

As consultas de vários estágios oferecem suporte a todos os tipos de janelas (hop, deslizante e rotativa) em estágios nomeados. Isso ajuda você a transmitir dados contextualizados por tempo entre as etapas, como usar a etapa 1 para identificar uma janela de eventos de alta frequência e a etapa 2 para correlacionar essa janela específica com ações administrativas subsequentes.

Se um estágio nomeado incluir uma janela, o início e o fim dela para cada linha de saída poderão ser acessados usando os seguintes campos reservados:

  • $stage_window_start: o carimbo de data/hora Unix que marca o início da janela.
  • $stage_window_end: o carimbo de data/hora Unix que marca o fim da janela.

Para mais detalhes sobre janelamento, consulte Lógica de janelamento do YARA-L 2.0.

Casos de uso comuns

  • Detecção sequencial: passar o período específico de um pico detectado de logins com falha para uma segunda etapa que procura um login bem-sucedido logo em seguida.
  • Análise de duração: cálculo do "tempo até o comprometimento" comparando o $stage_window_start de um estágio inicial de exploração com os carimbos de data/hora de eventos em um estágio posterior.
  • Criação de linha de base histórica: usa janelas para comparar as contagens de eventos atuais com as variáveis de saída de uma janela anterior.

Exemplo: janela de salto

O exemplo a seguir ilustra como usar janelas de salto em uma consulta de vários estágios:

  • A etapa hourly_stats procura pares de IP com alta atividade de rede na mesma hora.

  • hourly_stats gera os seguintes campos de etapa correspondentes às colunas nas linhas de saída:

    • $hourly_stats.src_ip: singular, string
    • $hourly_stats.dst_ip: singular, string
    • $hourly_stats.count: singular, número inteiro
    • $hourly_stats.std_recd_bytes: singular, ponto flutuante
    • $hourly_stats.avg_recd_bytes: singular, ponto flutuante
    • $hourly_stats.window_start: singular, número inteiro
    • $hourly_stats.window_end: singular, número inteiro

  • A etapa raiz filtra pares de IP com mais de três horas de alta atividade. As horas podem se sobrepor devido ao uso de uma janela de salto na etapa hourly_stats.

stage hourly_stats {
  metadata.event_type = "NETWORK_CONNECTION"
  $src_ip = principal.ip
  $dst_ip = target.ip
  $src_ip != ""
  $dst_ip != ""

  match:
    $src_ip, $dst_ip over 1h

  outcome:
    $count = count(metadata.id)
    $avg_recd_bytes = avg(network.received_bytes)
    $std_recd_bytes = stddev(network.received_bytes)

  condition:
    $avg_recd_bytes > 100 and $std_recd_bytes > 50
}

$src_ip = $hourly_stats.src_ip
$dst_ip = $hourly_stats.dst_ip
$time_bucket_count = strings.concat(timestamp.get_timestamp($hourly_stats.window_start), "|", $hourly_stats.count)

match:
 $src_ip, $dst_ip

outcome:
 $list = array_distinct($time_bucket_count)
 $count = count_distinct($hourly_stats.window_start)

condition:
 $count > 3

Junções internas em consultas de vários estágios

As junções internas permitem correlacionar dados em diferentes estágios ou tipos de origem, o que cria fluxos de trabalho analíticos complexos, como comparar eventos em tempo real com valores de referência estatísticos pré-calculados. Ao unir estágios, você pode enriquecer a telemetria bruta com dados com estado (como medianas ou tabelas de pesquisa) para identificar outliers ou ameaças multivetoriais que um filtro de eventos de estágio único não detectaria.

As junções internas são aceitas dentro e entre os estágios de consultas de vários estágios. A funcionalidade de junção interna é compatível com os seguintes tipos:

  • UDM e UDM: correlacionar dois conjuntos diferentes de eventos de segurança (por exemplo, combinar um evento de login com um acesso a arquivo subsequente).
  • UDM e ECG: fusão de dados de eventos com informações do Entity Context Graph para enriquecimento de identidade ou ativos.
  • UDM e tabela de dados: junção de eventos ao vivo com listas de referência estáticas ou enviadas por upload (por exemplo, uma lista de ativos de alto valor ou intervalos de IP específicos do departamento).

O exemplo a seguir mostra como configurar uma junção sem correspondência (uma junção realizada na seção outcome ou events em vez da seção match) entre eventos da UDM e um estágio de tabela calculado. Esse padrão permite realizar a detecção de anomalias estatísticas, conforme mostrado no cálculo do desvio absoluto médio (MAD, na sigla em inglês):

  • Etapa median: calcula a mediana de bytes enviados para cada par de host de origem e IP de destino.
    • $median.host: singular, string
    • $median.target: singular, string
    • $median.median: singular, ponto flutuante
  • Etapa absolute_deviations: une cada evento da UDM com a linha correspondente da etapa da mediana. Isso permite calcular o desvio absoluto dos bytes enviados para cada evento individual em relação ao grupo de empresas semelhantes.
    • $absolute_deviations.host: singular, string
    • $absolute_deviations.target: singular, string
    • $absolute_deviations.absolute_deviation: singular, ponto flutuante
  • Etapa raiz: calcula a média desses desvios absolutos em todos os eventos da UDM para estabelecer um limite de anomalia.

Exemplo: configurar uma junção sem correspondência

stage median {
  metadata.event_type = "NETWORK_CONNECTION"
  $host = principal.hostname
  $target = target.ip

  match:
    $host, $target

  outcome:
    $median = window.median(network.sent_bytes, true)
}

stage absolute_deviations {
  metadata.event_type = "NETWORK_CONNECTION"
  $join_host = principal.hostname
  $join_host = $median.host
  $join_target = target.ip[0]
  $join_target = $median.target

  outcome:
    $host = $join_host
    $target = $join_target
    $absolute_deviation = math.abs(network.sent_bytes - $median.median)
}

$host = $absolute_deviations.host
$target = $absolute_deviations.target

match:
  $host, $target

outcome:
  $mean_absolute_deviation = avg($absolute_deviations.absolute_deviation)

Exemplo: junção sem correspondência entre estágios de janela e de tabela

O exemplo a seguir ilustra como configurar uma junção sem correspondência entre um estágio de janela e um estágio de tabela em uma consulta de vários estágios.

  • A etapa hourly_stats calcula o total de bytes enviados para cada par de host de origem e destino e bucket de hora.
  • A etapa hourly_stats gera os seguintes campos de etapa correspondentes às colunas nas linhas de saída:
    • $hourly_stats.source_host: singular, string
    • $hourly_stats.dst_host: singular, string
    • $hourly_stats.total_bytes_sent: singular, ponto flutuante
    • $hourly_stats.window_start: singular, número inteiro
    • $hourly_stats.window_end: singular, número inteiro
  • A etapa agg_stats calcula a média e o desvio padrão de bytes por hora para cada par de hosts de origem e destino.

  • agg_stats gera os seguintes campos de etapa correspondentes às colunas nas linhas de saída:

    • $agg_stats.source_host: singular, string
    • $agg_stats.dst_host: singular, string
    • $agg_stats.avg_bytes_sent: singular, ponto flutuante
    • $agg_stats.stddev_bytes_sent: singular, ponto flutuante

  • A etapa raiz une cada linha de hourly_stats com a linha de agg_stats para o mesmo par de hosts de origem e destino. Para cada par de host de origem e destino, ele calcula o escore z usando o total de bytes enviados para o bucket desse par de hosts e as estatísticas agregadas.

stage hourly_stats {
 $source_host = principal.hostname
 $dst_host = target.hostname
 principal.hostname != ""
 target.hostname != ""
 match:
   $source_host, $dst_host by hour
 outcome:
   $total_bytes_sent = sum(network.sent_bytes)
}

stage agg_stats {
  $source_host = $hourly_stats.source_host
  $dst_host = $hourly_stats.dst_host
  match:
    $source_host, $dst_host
  outcome:
   $avg_bytes_sent = avg($hourly_stats.total_bytes_sent)
   $stddev_bytes_sent = stddev($hourly_stats.total_bytes_sent)
}

$source_host = $agg_stats.source_host
$source_host = $hourly_stats.source_host

$dst_host = $agg_stats.dst_host
$dst_host = $hourly_stats.dst_host

outcome:
  $hour_bucket = timestamp.get_timestamp($hourly_stats.window_start)
  $z_score = ($hourly_stats.total_bytes_sent - $agg_stats.avg_bytes_sent)/$agg_stats.stddev_bytes_sent

Junções cruzadas em consultas de várias etapas

Ao usar a pesquisa ou os painéis do Google SecOps, as junções cruzadas em consultas de várias etapas permitem comparar dados de eventos UDM individuais com estatísticas agregadas calculadas em outras etapas do YARA-L.

Em YARA-L, a palavra-chave cross join funciona com um estágio que retorna apenas uma linha.

Quando uma correlação é usada entre uma etapa com um limite de 1 e outro conjunto de dados (por exemplo, eventos da UDM), a saída de linha única da etapa é anexada a cada linha do outro conjunto de dados. Isso enriquece os dados de eventos com as estatísticas gerais.

Exemplo: encontrar atividade de login incomum

O exemplo a seguir identifica os usuários que fazem login com mais frequência do que o normal. Para isso, ele compara a contagem de logins de cada usuário (usando a etapa user_login_counts) com a contagem média de logins de todos os usuários (usando a etapa total_users). Os usuários que fazem login um número incomum de vezes podem ser classificados nos resultados da pesquisa.

Em seguida, use a correlação para vincular os resultados da etapa total_users aos resultados da etapa user_login_counts.

stage user_login_counts {
    $user = principal.user.userid
    metadata.event_type = "USER_LOGIN"
    security_result.action = "ALLOW"

    match:
        $user

    outcome:
        $login_count = count(metadata.id)
}

stage total_users {
    outcome:
        $count = count($user_login_counts.user)
    limit:
        1
}

cross join $total_users, $user_login_counts

$login_count = $user_login_counts.login_count
$user = $user_login_counts.user
$tot_users = $total_users.count

// all users who logged in the same number of times are grouped together.
match:
    $login_count
outcome:
    $num_users = count($user)
    $frequency_percent = (count($user) / max($tot_users) ) * 100

Limitações

As consultas de vários estágios têm as seguintes restrições funcionais e estruturais:

Requisitos estruturais

Você precisa seguir estes requisitos estruturais ao criar consultas:

  • Etapa raiz: só é permitida uma etapa raiz por consulta.
  • Estágios nomeados: é possível usar no máximo quatro estágios nomeados.
  • Referência de etapa: uma etapa só pode referenciar etapas definidas logicamente antes dela na mesma consulta.
  • Correlações: uma correlação só pode referenciar uma etapa que retorna uma única linha. Você precisa incluir um limite (1) na etapa referenciada para atender a esse requisito. Isso é útil porque permite anexar uma única estatística global (como um máximo ou uma média) a cada linha de evento individual para comparação.
  • Junções: é permitido um máximo de quatro junções que não sejam de tabela de dados em todas as etapas.
  • Requisito de resultado: cada etapa nomeada (exceto a raiz) precisa incluir uma seção match ou outcome, em que a seção outcome não exige agregação.

Limites de janela e compatibilidade

As seguintes restrições se aplicam à forma como você usa janelas e onde executa consultas:

  • Compatibilidade com recursos: as consultas de vários estágios funcionam na Pesquisa e nos painéis, mas não são compatíveis com as regras.
  • Tipos de janela: evite misturar tipos diferentes de janela em uma única consulta.
  • Dependência de janela: um estágio que usa uma janela deslizante ou um salto não pode depender de outro estágio que também usa uma janela deslizante ou um salto.
  • Tamanho da janela de rolagem: embora as janelas de rolagem em diferentes estágios possam variar de tamanho, a diferença precisa ser menor que 720x.

Exemplo: diferença de agregação de etapa (inválida)

A configuração a seguir é inválida porque um mês tem 44.640 minutos (44.640 / 1 > 720):

Stage: monthly_stats { ... match: by month }

Raiz: match: by minute

Exemplo: diferença de agregação de estágio (válida)

Para corrigir isso, verifique se a proporção entre as etapas é menor. Por exemplo, agregue dados por hora em um relatório diário:

Stage: daily_stats { ... match: by day }

Raiz: match: by hour

Como 24 (horas em um dia) é menor que 720, o sistema pode mapear os dados de estágio para o estágio raiz de maneira eficiente.

Limitações de fase e consulta

Cada estágio individual em uma consulta de vários estágios tem restrições específicas. A maioria das limitações que se aplicam a uma consulta de estágio único também se aplicam a cada estágio individual:

  • Requisito de saída: cada etapa precisa gerar pelo menos uma variável de correspondência ou resultado (campo de etapa).

  • Período da consulta:

    • Consultas padrão: o máximo é de 30 dias.
    • Consultas de vários estágios com junções sem correspondência: o máximo é restrito a 14 dias.

  • Limites de tamanho da janela: o tamanho máximo da janela (hop, deslizante ou rotativa) depende de a consulta incluir uma junção:

    • Com junções: o tamanho máximo da janela para qualquer tipo (hop, deslizante ou rotativa) é de dois dias. Para mais detalhes, consulte Limitações de junções de pesquisa.

    • Sem junções (evento único):

    • Janelas deslizantes e de salto: o máximo é de dois dias.

    • Janelas móveis: o máximo aumenta para 30 dias.

  • Número máximo de variáveis de resultado:

    • 20 por padrão
    • 50 para clientes que ativaram o limite maior
    • Limites de matriz: é permitido um máximo de 10.000 elementos em uma variável de resultado com valor de matriz.

  • Restrições de eventos por consulta:

    • Máximo de dois eventos do UDM
    • Máximo de um evento de ECG
    • Máximo de duas tabelas de dados

Limites de serviço e desempenho

As consultas de vários estágios estão sujeitas às mesmas limitações das consultas de estatísticas:

  • Consultas de estatísticas: 120 QPH (API e UI).
  • Visualizações de pesquisa: 100 visualizações por minuto.
  • Suporte a API: o sistema do Google SecOps e a API EventService.UDMSearch são compatíveis com junções de várias etapas, mas a API SearchService.UDMSearch não é. O sistema também permite executar consultas de várias etapas sem junções.

Limitações globais e de eventos

Você precisa obedecer a estas restrições em relação a eventos e plataformas:

Número máximo de eventos

As consultas de vários estágios limitam estritamente o número de eventos que podem processar simultaneamente:

  • Eventos do UDM: é permitido um máximo de dois eventos do UDM.
  • Eventos do gráfico de contexto da entidade (ECG): é permitido no máximo um evento do ECG.

Limitações de consultas globais

Essas restrições em toda a plataforma controlam a quantidade de dados e o período que uma consulta de vários estágios retorna:

  • Período da consulta: o período máximo de uma consulta padrão é de 30 dias.
  • Conjunto total de resultados: o tamanho máximo do conjunto total de resultados é de 10.000 resultados.

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