Entender as repetições de regras e o MTTD
Este documento explica como os replays de regras (também chamados de execuções de limpeza) gerenciam dados que chegam atrasados e atualizações de contexto, e como isso afeta as métricas de tempo médio para detecção (MTTD, na sigla em inglês).
Gravaçõ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. Esse processo avalia o mesmo bloco de dados de eventos várias vezes em intervalos diferentes para processar dados que chegam atrasados ou regras que precisam de contexto atualizado, como a correspondência de um indicador de comprometimento (IOC, na sigla em inglês).
Acionadores de repetição de regras
As regras são reavaliadas (executadas novamente) quando dados de contexto relevantes chegam ou são processados depois dos dados iniciais do evento.
Os gatilhos comuns de repetição de regras incluem:
Dados de enriquecimento que chegam atrasados
Pipelines de enriquecimento de dados, como o Entity Context Graph (ECG), podem processar dados em lotes. Se um evento da UDM chegar antes dos dados contextuais relacionados (como informações de recursos ou contexto do usuário), uma detecção poderá ser perdida durante a execução inicial da regra.
Atualizações retroativas de enriquecimento do UDM
Se a regra usar campos com alias (campos enriquecidos) na lógica de detecção, como
$udm.event.principal.hostname, e os dados de origem (por exemplo, registros DHCP) chegarem mais de uma hora depois, esses valores de campo serão atualizados retroativamente para esse horário específico do evento. As execuções de regra subsequentes ("execuções de limpeza") usam esses valores enriquecidos, o que pode acionar uma detecção que antes não foi feita.Regras de vários eventos agendadas
As regras de vários eventos (ME, na sigla em inglês) são executadas em uma programação (por exemplo, a cada 10 minutos, por hora ou diariamente) para avaliar blocos de tempo de evento. Para capturar atualizações de enriquecimento tardias nos dados históricos, essas regras reavaliam o mesmo bloco de tempo mais tarde, geralmente executando pelo menos duas ou três vezes (por exemplo, com verificações de 5 a 8 horas e novamente de 24 a 48 horas depois).
Impacto nas métricas de tempo
Quando uma detecção resulta de uma repetição de regra, 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 a detecção é criada, o que pode acontecer muito depois, às vezes horas ou dias depois.
A alta latência de detecção (uma grande diferença de tempo entre o evento e a detecção) geralmente é causada pelo reprocessamento de dados que chegam atrasados ou pela latência no pipeline do gráfico de contexto da entidade (ECG, na sigla em inglês).
Essa diferença de horário pode fazer com que uma detecção pareça "tardia" ou "atrasada", o que pode confundir os analistas e distorcer as métricas de performance, como o MTTD.
| Componente de métricas | Origem do 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. | Isso permanece preciso até o horário do evento. |
| Horário de detecção / Horário de criação | Horário em que a detecção foi emitida pelo mecanismo. | Esse horário aparece como "atrasado" em relação ao carimbo de data/hora do evento porque depende de uma execução secundária (repetição) que incorpora dados de enriquecimento atrasados. 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.
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 geradas por regras de vários eventos, é fundamental reconhecer que as detecções resultantes de repetições automáticas de regras aumentam a cobertura e a precisão. Embora essas repetições geralmente detectem ameaças que exigem contexto tardio, elas aumentam necessariamente a latência informada para essa detecção específica.
Para alertas críticos e urgentes:use regras de evento único ou de vários eventos com as frequências de execução mais curtas possíveis (por exemplo, janelas de correspondência mais curtas, com menos de uma hora).
Para correlação complexa e de longa duração (UEBA, ataques de várias etapas): espere uma latência maior (até 48 horas ou mais) se as regras dependerem de junções contextuais extensas ou listas de referência que podem ser atualizadas de forma assíncrona. O benefício aqui é uma detecção de maior fidelidade, e não uma 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 aliasados (campos que não estão sujeitos a pipelines de enriquecimento downstream) na lógica da regra sempre que possível.
Precisa de mais ajuda? Receba respostas de membros da comunidade e profissionais do Google SecOps.