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) 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 SecOps 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: quando o processo de enriquecimento de UDM atualiza um evento avaliado anteriormente, o sistema repete as regras de evento único. Consulte as exceções para regras com tabelas de dados abaixo.

  • 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 de evento único e de vários eventos.

  • Regras de vários eventos: Regras de vários eventos são executadas em uma programação, processando blocos de tempo de eventos. Essas regras 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 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 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 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 atrasados (como registros 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 atrasados por tipo de regra

O tipo de regra e a configuração dela determinam o período em que os dados 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 um período de corte estrito 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 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 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 maneira como você configura a programação da regra determina o período de corte efetivo:
      • Programação padrão:o sistema geralmente executa execuções de ajuste automáticas aproximadamente 5 horas e 24 horas após o horário do evento. Se os dados chegarem após a conclusão da execução de 24 horas, eles não serão avaliados por essa regra para esse período.
      • Programações personalizáveis ativadas:esse recurso oferece mais controle sobre os horários de execução nas configurações de "Frequência de execução". Consulte Configurar programações personalizadas para regras. Os principais horários são:
        • Primeira execução:o sistema executa a primeira execução no horário do evento mais o deslocamento 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 primeira execução. Isso significa que o sistema pode incluir eventos que chegam até aproximadamente T + 4 a 5 horas.
        • 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 primeira execução. Isso estende o período para o sistema processar dados atrasados para cerca de T + 30 a 31 horas.
      • Implicações de corte:com programações personalizáveis, a última execução de ajuste determina o corte efetivo para incluir dados atrasados. Isso geralmente ocorre cerca de 4 horas após a primeira execução ou cerca de 30 horas após a primeira execução 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 esse período.

Exemplos de cenários de dados 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 de evento único padrão 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 (programação padrão)

    • Se um evento chegar 10 horas após o carimbo de data/hora, o sistema vai perdê-lo durante a execução de ajuste de 5 horas, mas o processará durante a execução de ajuste de 24 horas. Um evento que chegar 25 horas atrasado não será processado.

  • Cenário 4: evento de origem atrasado – regra de vários eventos (programação personalizável)

    • Você configura uma regra de vários eventos com um deslocamento de primeira execução de 1 hora. Um evento chega 6 horas após o carimbo de data/hora.
    • Esse evento perde a primeira execução (T + 1h) e a primeira execução de ajuste (T + 4h). O sistema NÃO processará esse evento com essa regra, a menos que você ative a opção Garantir a integridade do enriquecimento.

  • Cenário 5: enriquecimento atrasado – regra de vários eventos (personalizável 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.
    • Alguns desses dados de enriquecimento atrasados podem estar disponíveis para a segunda "execução de ajuste", que ocorre por volta de T + 30h (porque você ativou a opção Garantir a integridade do enriquecimento). Se os dados de enriquecimento estiverem disponíveis, o sistema reavaliará a regra usando esse enriquecimento atrasado.

  • 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 personalizada 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 horário 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.

O re-enriquecimento devido a dados atrasados ou a latência com uma atualização de origem de contexto como o gráfico de contexto de entidade (ECG) geralmente causa alta latência de detecção.

Essa diferença de tempo pode fazer com que uma detecção pareça "atrasada", o que pode confundir os analistas e distorcer métricas de performance, como o MTTD.

Componente da métrica Fonte de tempo Como as repetições afetam o MTTD
Janela de detecção / Carimbo de data/hora do evento Horário em que o ocorrência de segurança original ocorreu. As repetições mantêm a precisão do horário do evento.
Horário de detecção / Horário de criação Horário em que o mecanismo realmente emitiu a detecção. Uma execução secundária (repetição) que incorpora dados de enriquecimento atrasados faz com que esse horário pareç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 detalhes 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 que o sistema gera a partir de dados de eventos que chegam com mais de 30 minutos de atraso, execuções de reprocessamento de regras ou retrocaças. Esse ícone também aparece na página Alertas no Google SecOps.

Priorizar 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 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 atrasados, mas oferecem o benefício de 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.

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