Entender as repetições de regras e o MTTD

Compatível com:

Este documento explica como os replays de regras (também chamados de execuções de limpeza ou execuções de ajuste) processam dados e atualizações de contexto que chegam atrasados e como esses replays afetam as métricas de tempo médio para detecção (MTTD, na sigla em inglês).

Gravações de regras

O Google Security Operations processa grandes volumes de dados de segurança. Para garantir detecções precisas de regras que dependem de dados contextuais ou correlacionados, o mecanismo de regras executa automaticamente um processo de repetição de regras.

O processo de repetição de regras processa estas categorias:

  • Regras de evento único:essas regras são repetidas quando o processo de enriquecimento do UDM atualiza um evento avaliado anteriormente. Para exceções relacionadas a regras com tabelas de dados, consulte Cenários de dados que chegam tarde mais adiante neste documento.

  • Regras de evento único com janela (WSE) e regras de evento único com tabelas de dados:essas regras têm um mecanismo de programação distinto para processar dados que chegam com atraso, diferente das regras padrão de evento único e de eventos múltiplos.

  • Regras de vários eventos:essas regras são executadas em uma programação, processando blocos de tempo de evento. Eles reavaliam repetidamente o mesmo período em intervalos diferentes para capturar atualizações de enriquecimento tardias, como dados de contexto de usuário ou de recurso correspondentes ou um indicador de comprometimento (IOC, na sigla em inglês). Os horários exatos dependem da configuração da programação.

Acionadores de repetição de regras

O sistema reavalia (executa novamente) as regras para garantir que ele detecte tudo, mesmo que os dados cheguem ou sejam atualizados após a execução inicial da regra. Esses dados que chegam tarde incluem as seguintes categorias:

  • Eventos de origem que chegam atrasados:o registro bruto ou o próprio evento UDM chega ao Google SecOps muito depois do carimbo de data/hora real do evento.
  • Dados de enriquecimento que chegam tarde:os dados contextuais (por exemplo, usuário, ativo, inteligência contra ameaças) relacionados a um evento ficam disponíveis ou são atualizados pelo sistema depois que ele processa o evento pela primeira vez. Isso geralmente acontece porque os pipelines de enriquecimento, como o gráfico de contexto de entidade (ECG), processam dados em lotes ou dependem de fontes de dados externas.
  • Atualizações retroativas de enriquecimento da UDM:dados de origem que chegam tarde (como registros DHCP que atualizam nomes de host) acionam mudanças nos campos de eventos da UDM. As regras que usam campos com alias (campos enriquecidos) na lógica de detecção, como $udm.event.principal.hostname, podem acionar repetições quando os dados de origem estão atrasados. Essa chegada tardia atualiza retroativamente os valores desses campos.

O sistema aciona as repetições de regras de maneira diferente, dependendo do tipo de regra e da natureza dos dados atrasados. O objetivo é equilibrar a pontualidade da detecção com a integridade dos dados.

Como o sistema processa dados atrasados por tipo de regra

O tipo de regra e a configuração dela determinam a janela de tempo em que os dados atrasados podem acionar uma reavaliação.

  • Regras de evento único (sem janelas de correspondência ou tabelas de dados):

    • Eventos de origem atrasados:geralmente, essas regras processam um evento, não importa a idade do carimbo de data/hora quando ele chega ao sistema. O sistema não impõe uma janela de corte estrita para o processamento inicial de eventos de origem atrasados.
    • Enriquecimento tardio:se os dados de enriquecimento de um evento avaliado anteriormente chegarem ou ocorrer uma atualização, o sistema vai reavaliar essas regras de evento único com base no evento com o novo contexto. Isso pode acontecer horas ou até dias depois do evento inicial.

  • Regras de evento único com janela (WSE) e regras de evento único com tabelas de dados:

    • Essas regras não seguem o mesmo tratamento de dados atrasados que outras regras de evento único ou as programações de correção das regras de vários eventos.
    • Elas têm o seguinte comportamento:
      • Limite:essas regras não processam eventos ingeridos 7 dias ou mais após a marcação de tempo do evento.
      • Dados que chegam com atraso (<7d): o sistema processa eventos que chegam com menos de 7 dias de atraso, mas com latência potencialmente maior.
      • Eventos de origem que chegam atrasados: as regras do WSE não processam eventos se os dados chegarem ao Google SecOps 7 dias ou mais após o carimbo de data/hora do evento.
      • Atualizações de contexto:se o contexto de um evento chegar atrasado ou se um evento for enriquecido retroativamente, o sistema vai reavaliar automaticamente as regras em relação ao evento enriquecido. Essa repetição de regra pode acionar novas detecções, mesmo que a avaliação inicial não tenha resultado em uma detecção.
      • Enriquecimento tardio: se um evento do UDM for atualizado devido ao enriquecimento (que pode ocorrer até 7 dias após a ingestão), o sistema vai reavaliar essas regras com base no evento atualizado. No entanto, ao contrário de outros tipos de regras, as atualizações no conteúdo da tabela de dados não acionam uma reavaliação automática de eventos passados para essas regras.
      • Janela de lookback:essas regras usam uma janela de lookback de aproximadamente 7 dias para reavaliar eventos. Se os dados de enriquecimento chegarem para um evento que esteja dentro desse período de sete dias, a regra será reavaliada.

  • Regras de vários eventos:

    • As regras de vários eventos são executadas de acordo com uma programação e reavaliam os blocos de tempo para considerar dados atrasados. A programação da regra determina o período de corte efetivo:
      • Execução principal:o sistema executa a primeira avaliação no horário do evento mais o atraso de liquidação configurado (por exemplo, T + 1 hora).
      • Execução de ajuste 1:o sistema executa o primeiro ajuste aproximadamente 4 horas após a execução principal. Isso permite que o sistema inclua eventos que chegam atrasados.
      • Execução de ajuste 2 (condicional): se você ativar a opção Garantir a integridade do enriquecimento, o sistema vai executar um ajuste final aproximadamente 30 horas após a execução principal. Isso estende a janela para que o sistema processe dados e enriquecimentos de contexto que chegam com atraso por até aproximadamente 30 horas.
      • Implicações do corte:a última execução de ajuste determina o corte efetivo para incluir dados atrasados. Isso geralmente acontece cerca de 4 horas após a execução principal (ou cerca de 30 horas após a execução principal se você ativar a opção Garantir a integridade do enriquecimento). Eventos ou enriquecimentos que chegarem após a última execução de correção para um determinado período não serão processados por essa regra.

Exemplos de cenários de dados de chegada tardia

  • Cenário 1: evento de origem atrasado – regra de evento único

    • O Google SecOps ingere um evento com um carimbo de data/hora de três dias atrás. Uma regra padrão de evento único processa esse evento como novos dados.

  • Cenário 2: enriquecimento tardio – regra de evento único

    • O sistema processou um evento de login ontem. Hoje, ele ingere e enriquece novas informações para o usuário envolvido, como uma mudança de departamento. O sistema reavalia a regra de evento único em relação ao evento de login com o contexto de usuário atualizado.

  • Cenário 3: evento de origem atrasado – regra de vários eventos (ajuste padrão de quatro horas)

    • Um evento chega 3 horas depois do carimbo de data/hora dele para uma regra de vários eventos programada com as configurações padrão. O evento perdeu a execução primária inicial (T + 1h), mas o sistema o processa durante a execução de ajuste de 4 horas.

  • Cenário 4: evento de origem atrasado – regra de vários eventos (sem integridade do enriquecimento)

    • Você configura uma regra de vários eventos com um ajuste de execução principal de uma hora sem ativar a opção Garantir a integridade do enriquecimento. Um evento chega 6 horas depois do carimbo de data/hora.
    • Esse evento perde a execução principal (T + 1h) e a primeira execução de ajuste (T + 4h). O sistema não vai processar esse evento para esse período porque ele chegou depois da última execução de ajuste.

  • Cenário 5: enriquecimento tardio – regra de vários eventos (com integridade do enriquecimento)

    • Uma regra de eventos múltiplos tem um ajuste de 1 hora, e você ativa a opção Garantir a integridade do enriquecimento. Os dados de enriquecimento de um evento chegam 28 horas após o carimbo de data/hora do evento.
    • O sistema reavalia a regra usando esse enriquecimento tardio durante a segunda execução de ajuste, aproximadamente em T + 31h.

  • Cenário 6: evento de origem atrasado: regra de vários eventos com janela de correspondência

    • Uma regra de vários eventos tem uma janela de match horas e uma programação com a opção Garantir a integridade do enriquecimento ativada (ajuste final por volta de T + 30h). Um evento chega 36 horas depois do carimbo de data/hora. Esse evento não será processado porque chegou depois da última execução de ajuste final, mesmo que o horário do evento esteja dentro da janela de correspondência da regra em relação a outros eventos. O corte é baseado no horário de chegada em relação à programação de ajuste, não apenas na janela de correspondência.

  • Cenário 7: evento de origem atrasado - regra de evento único com janela

    • Se um evento de origem com um carimbo de data/hora de oito dias atrás chegar atrasado, ele poderá ficar fora do período de 7 dias das regras da WSE e não ser processado.

Impacto nas métricas de tempo

Quando uma detecção resulta de uma repetição de regra, o sistema usa a seguinte terminologia:

  • A janela de detecção ou o carimbo de data/hora do evento do alerta se refere ao momento da atividade maliciosa original.
  • O Horário de criação é o momento em que o sistema cria a detecção, que pode ser muito depois, às vezes horas ou dias depois.
  • A latência de detecção é a diferença entre o carimbo de data/hora do evento e o horário de criação da detecção.

Delta de linha do tempo e MTTD

O tempo decorrido entre o carimbo de data/hora do evento inicial e a criação de uma detecção afeta diretamente o cálculo do MTTD.

Estágio de pipeline / programação Tempo de avaliação Impacto na medição do MTTD
Regra de evento único (streaming) Contínuo (menos de 5 minutos após a chegada) As detecções em tempo real representam a velocidade real da plataforma com impacto mínimo no MTTD.
Regra de vários eventos (execução principal) 1 a 2 horas após a chegada (mais o atraso de liquidação configurado) Inclui a janela de buffer em lote inevitável necessária para agregar estados de correlação de vários eventos.
Regra de vários eventos (execuções de ajuste) 4 horas ou 30 horas após a execução principal Uma execução secundária (repetição) que incorpora dados de enriquecimento tardio faz com que esse horário apareça atrasado em relação ao carimbo de data/hora do evento. Esse delta afeta negativamente o cálculo do MTTD.

Práticas recomendadas para medir o MTTD

O MTTD quantifica o tempo desde o comprometimento inicial até a detecção efetiva da ameaça. Ao analisar detecções acionadas por repetições de regras, aplique as práticas recomendadas a seguir para manter métricas de MTTD precisas.

O Google SecOps oferece várias métricas que podem ser consultadas pelo usuário para medir o MTTD com precisão. Para mais informações sobre essas métricas, consulte Exemplos de consultas YARA-L 2.0 para a página "Painéis".

Um ícone na coluna Tipo de detecção identifica detecções geradas com base em dados de eventos que chegam com mais de 30 minutos de atraso, execuções de ajuste automático, pipelines de reprocessamento ou retrocaças. Esse ícone também aparece na página Alertas do Google SecOps.

Priorize sistemas de detecção em tempo real

Para detecções mais rápidas, use regras de evento único. Essas regras são executadas quase em tempo real, geralmente com um atraso de menos de cinco minutos. Isso também oferece suporte a um uso mais abrangente das detecções compostas.

Considerar a repetição de regras em regras de vários eventos

As regras de vários eventos têm uma latência maior devido à frequência de execução programada. Ao medir o MTTD para detecções de regras de vários eventos, reconheça que as repetições de regras automatizadas aumentam a cobertura e a precisão. Essas repetições geralmente detectam ameaças que exigem contexto tardio, o que aumenta a latência informada para essas detecções.

  • Para alertas críticos e urgentes:use regras de evento único ou de vários eventos com as frequências de execução práticas mais curtas. Reduzir a janela de correspondência não afeta diretamente a latência, mas pode aumentar a eficiência ao definir o atraso mínimo.

  • Para correlação complexa e de longa duração (UEBA, ataques de vários estágios): Essas regras dependem de junções contextuais ou listas de referência extensas, que podem ser atualizadas de forma assíncrona. Eles podem ter alta latência com dados contextuais ou de eventos que chegam atrasados, mas oferecem o benefício de uma detecção de maior fidelidade em vez de velocidade absoluta.

Otimizar regras para reduzir a dependência do enriquecimento tardio

Para otimizar a velocidade de detecção e minimizar o impacto das execuções de enriquecimento retroativo, use campos não aliased (campos que os pipelines de enriquecimento downstream não processam) na lógica da regra sempre que possível.

A seguir

Para conhecer conceitos de programação e fluxos de trabalho de configuração relacionados, consulte os seguintes documentos:

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