Entender as repetições de regras e o MTTD

Compatível com:

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

Repetiçõ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 de regras:

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

  • Regras de evento único com janela (WSE, na sigla em inglês) e regras de evento único com tabelas de dados:essas regras têm um mecanismo de programação distinto para processar dados que chegam atrasados, diferente das regras padrão de evento único e de vários eventos.

  • Regras de vários eventos: essas regras são executadas em uma programação, processando blocos de tempo de eventos. Elas reavaliam repetidamente o mesmo bloco de tempo em intervalos diferentes para capturar atualizações de enriquecimento atrasadas, 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, mesmo que os dados cheguem ou sejam atualizados após a execução inicial da regra. Esses dados que chegam atrasados incluem as seguintes categorias:

  • Eventos de origem que chegam atrasados:o registro bruto ou o evento de UDM chega ao Google SecOps significativamente mais tarde do que o carimbo de data/hora real do evento.
  • Dados de enriquecimento que chegam atrasados:os dados contextuais (por exemplo, usuário, recurso, inteligência contra ameaças) relacionados a um evento ficam disponíveis ou o sistema os atualiza depois que o evento é processado pela primeira vez. Isso geralmente ocorre 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 de UDM:dados de origem que chegam atrasados (como registros de DHCP que atualizam nomes de host) acionam mudanças nos campos de eventos de 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 atrasada atualiza retroativamente esses valores de campo.

O sistema aciona 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 que chegam atrasados por tipo de regra

O tipo de regra e a configuração dela determinam o período em que os dados que chegam atrasados podem acionar uma reavaliação da regra.

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

    • Eventos de origem atrasados:geralmente, essas regras processam um evento, independentemente da 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 atrasado:se os dados de enriquecimento de um evento avaliado anteriormente chegarem ou ocorrer uma atualização, o sistema reavaliará essas regras de evento único em relação ao evento com o novo contexto. Isso pode acontecer horas ou até dias após o 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 ajuste de regras de vários eventos.
    • Elas têm o seguinte comportamento:
      • Corte:essas regras não processam eventos ingeridos 7 dias ou mais após o carimbo de data/hora do evento.
      • Dados que chegam atrasados (<7 dias): 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 de 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 reavaliará automaticamente as regras em relação ao evento enriquecido. Essa repetição de regras pode acionar novas detecções, mesmo que a avaliação inicial não tenha resultado em uma detecção.
      • Enriquecimento atrasado: se um evento de UDM for atualizado devido ao enriquecimento (que pode ocorrer até 7 dias após a ingestão), o sistema reavaliará essas regras em relação ao 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 anteriores 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 dessa janela de 7 dias, a regra será reavaliada.

  • Regras de vários eventos :

    • As regras de vários eventos são executadas em uma programação e reavaliam blocos de tempo para considerar dados atrasados. A programação da regra determina a janela de corte efetiva:
      • Execução principal:o sistema executa a primeira avaliação no horário do evento, além de qualquer atraso de liquidação configurado (por exemplo, T + 1 hora).
      • Execução de ajuste 1:o sistema executa a primeira execução de 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 executará uma execução de ajuste final aproximadamente 30 horas após a execução principal. Isso estende a janela para que o sistema processe dados que chegam atrasados e enriquecimentos de contexto em até aproximadamente 30 horas.
      • Implicações de corte:a execução de ajuste final determina o corte efetivo para incluir dados atrasados. Isso normalmente ocorre 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 execução de ajuste final para um determinado período não serão processados por essa regra para essa janela.

Exemplos de cenários de dados que chegam atrasados

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

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

  • Cenário 2: enriquecimento atrasado – 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 (por exemplo, uma mudança de departamento). O sistema reavalia a regra de evento único em relação ao evento de login com o contexto do usuário atualizado.

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

    • Um evento chega 3 horas após o carimbo de data/hora para uma regra de vários eventos programada com as configurações padrão. O evento perdeu a execução principal 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 de enriquecimento)

    • Você configura uma regra de vários eventos com um deslocamento de execução principal de 1 hora sem ativar a opção Garantir a integridade do enriquecimento. Um evento chega 6 horas após o 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 processará esse evento para esse período porque ele chegou após a execução de ajuste final.

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

    • Uma regra de vários eventos tem um deslocamento 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 atrasado durante a segunda execução de ajuste em aproximadamente 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 de 48 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 após o carimbo de data/hora. Esse evento não será processado porque chegou após a 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 8 dias atrás chegar atrasado, ele poderá ficar fora da janela de lookback de sete dias para regras de WSE e não ser processado.

Impacto nas métricas de tempo

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

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

Delta da 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 do pipeline / programação Tempo de avaliação Impacto na medição do MTTD
Regra de evento único (streaming) Contínuo (<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 de 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 atrasados faz com que esse tempo 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 eficaz 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 Consultas de amostra do YARA-L 2.0 para a página "Painéis".

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

Priorizar sistemas de detecção em tempo real

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

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

As regras de vários eventos incorrem inerentemente em maior latência 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 atrasado, o que aumenta a latência informada para essas detecções.

  • Para alertas críticos e urgentes: use regras de evento único ou regras de vários eventos com as frequências de execução práticas mais curtas. A redução da janela de correspondência não afeta diretamente a latência, mas pode aumentar a eficiência definindo 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 extensas ou listas de referência, que podem ser atualizadas de forma assíncrona. Elas podem apresentar 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 de enriquecimento atrasado

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

A seguir

Para conferir 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.