Entender as repetições de regras e o MTTD
Este documento explica como as reexecuções de regras (também chamadas 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.
O processo de repetição de regras lida com duas categorias diferentes:
Regras de evento único:quando o processo de enriquecimento da UDM atualiza um evento avaliado anteriormente, o sistema reproduz regras de evento único.
Regras de vários eventos:regras de vários eventos são executadas em uma programação selecionada por você, processando blocos de tempo de evento. Essas regras reavaliam repetidamente o mesmo bloco de tempo em intervalos diferentes para capturar atualizações de enriquecimento tardias, como dados de contexto de usuários ou recursos correspondentes ou um indicador de comprometimento (IOC, na sigla em inglês).
Por exemplo, uma regra pode ser executada pelo menos duas ou três vezes (de 5 a 8 horas e novamente de 24 a 48 horas depois) para considerar dados de contexto e eventos que chegam atrasados.
Acionadores de repetição de regras
O sistema reavalia (executa novamente) as regras quando chegam dados de contexto relevantes ou quando esses dados são processados depois dos dados iniciais do evento.
Confira alguns motivos comuns para a reprodução:
Dados de aprimoramento que chegam atrasados:os pipelines de aprimoramento de dados, como o gráfico de contexto de entidade (ECG), geralmente processam dados em lotes. Quando um evento da UDM chega antes dos dados contextuais relacionados (como informações de recursos ou contexto do usuário), a execução inicial da regra pode não detectar algo.
Atualizações retroativas de enriquecimento do UDM: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 (por exemplo, registros DHCP) estão atrasados. Essa chegada tardia atualiza retroativamente esses valores de campo. As repetições de regras subsequentes usam esses valores recém-enriquecidos, o que pode acionar uma detecção que não foi feita antes.
Impacto nas métricas de tempo
Quando uma detecção resulta de uma repetição de regra, usamos a seguinte terminologia:
- A janela de detecção ou o carimbo de data/hora do evento do alerta se refere ao momento da atividade mal-intencionada 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 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 que chegam tarde ou a latência com uma atualização de fonte de contexto, como o gráfico de contexto de entidade (ECG), geralmente causa alta latência de detecção.
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 decorrido 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 detalhes 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 atrasados em mais de 30 minutos, execuções de reprocessamento de regras ou retrocaças. Esse ícone também aparece na página Alertas do 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 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 automáticas de regras 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 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.