Compreenda as repetições de regras e o MTTD
Este documento explica como as repetições de regras (também denominadas execuções de limpeza) gerem os dados recebidos tardiamente e as atualizações de contexto, e como isto afeta as métricas de tempo médio de deteção (MTTD).
Repetições de regras
O Google SecOps processa grandes volumes de dados de segurança. Para garantir deteções precisas para regras que dependem de dados contextuais ou correlacionados, o motor de regras executa automaticamente um processo de repetição de regras. Este processo avalia o mesmo bloco de dados de eventos várias vezes em intervalos diferentes para processar dados recebidos tardiamente ou regras que precisam de contexto atualizado, como a correspondência de um indicador de comprometimento (IOC).
Acionadores de repetição de regras
As regras são reavaliadas (executadas novamente) quando os dados de contexto relevantes chegam ou são processados mais tarde do que os dados de eventos iniciais.
Os acionadores de repetição de regras comuns incluem:
Dados de enriquecimento recebidos tardiamente
Os pipelines de enriquecimento de dados, como o gráfico de contexto de entidades (ECG), podem processar dados em lotes. Se um evento da UDM chegar antes dos respetivos dados contextuais relacionados (como informações de recursos ou contexto do utilizador), pode perder-se uma deteção durante a execução inicial da regra.
Atualizações retroativas do enriquecimento de dados do utilizador
Se a sua regra usar campos com alias (campos enriquecidos) na lógica de deteção, como
$udm.event.principal.hostname, e os dados de origem (por exemplo, registos DHCP) chegarem mais de uma hora depois, esses valores de campo são atualizados retroativamente para essa hora específica do evento. As execuções de regras subsequentes ("execuções de limpeza") usam estes valores recém-enriquecidos, o que pode acionar uma deteção que foi anteriormente ignorada.Regras de vários eventos agendadas
As regras de vários eventos (ME) são executadas de acordo com um horário (por exemplo, 10 minutos, de hora a hora ou diariamente) para avaliar blocos de tempo de eventos. Para captar atualizações de enriquecimento tardias aos dados do histórico, estas regras reavaliam o mesmo bloco de tempo mais tarde, sendo executadas, muitas vezes, pelo menos duas ou três vezes (por exemplo, com verificações 5 a 8 horas e novamente 24 a 48 horas mais tarde).
Impacto nas métricas de tempo
Quando uma deteção resulta de uma repetição de regras, a Janela de deteção ou a Data/hora do evento do alerta refere-se à hora da atividade maliciosa original. A Hora de criação é a hora em que a deteção é criada, o que pode acontecer muito mais tarde, por vezes, horas ou dias depois.
A latência de deteção elevada (uma grande diferença de tempo entre o evento e a deteção) é normalmente causada pelo re-enriquecimento de dados que chegam tarde ou pela latência no pipeline do gráfico de contexto da entidade (ECG).
Esta diferença de tempo pode fazer com que uma deteção apareça "tarde" ou "com atraso", o que pode confundir os analistas e distorcer as métricas de desempenho, como o MTTD.
| Componente de métrica | Origem da hora | Como as repetições afetam o MTTD |
|---|---|---|
| Período de deteção/data/hora do evento | Hora em que ocorreu o evento de segurança original. | Isto permanece preciso em relação à hora do evento. |
| Hora da deteção / Hora de criação | Hora em que a deteção foi realmente emitida pelo motor. | Esta hora aparece "atrasada" ou "com atraso" relativamente à data/hora do evento porque depende de uma execução secundária (repetição) que incorpora dados de enriquecimento tardios. Esta diferença afeta negativamente o cálculo do MTTD. |
Práticas recomendadas para medir o MTTD
O MTTD quantifica o tempo desde a comprometimento inicial até à deteção eficaz da ameaça. Quando analisar deteções acionadas por repetições de regras, aplique as seguintes práticas recomendadas para manter métricas de MTTD precisas.
Dê prioridade a sistemas de deteção em tempo real
Para as deteções mais rápidas, use Regras de evento único. Estas regras são executadas em tempo quase real, normalmente com um atraso inferior a 5 minutos.
Isto também suporta uma utilização mais abrangente das deteções compostas.
Tenha em conta a repetição de regras em regras com vários eventos
As regras com vários eventos incorrem inerentemente numa latência mais elevada devido à frequência de execução agendada. Ao medir o MTTD para deteções geradas por regras de vários eventos, é fundamental reconhecer que as deteções resultantes de repetições de regras automatizadas servem para aumentar a cobertura e a precisão. Embora estas repetições detetem frequentemente ameaças que requerem contexto tardio, aumentam necessariamente a latência comunicada para essa deteção específica.
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 (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 fases): espere uma latência mais elevada (até 48 horas ou mais) se as regras dependerem de junções contextuais extensivas ou listas de referência que podem ser atualizadas de forma assíncrona. A vantagem aqui é uma deteção de maior fidelidade em vez de velocidade absoluta.
Otimize as regras para reduzir a dependência do enriquecimento tardio
Para otimizar a velocidade de deteção e minimizar o impacto das execuções de enriquecimento retroativas, considere usar campos não associados (campos que não estão sujeitos a pipelines de enriquecimento a jusante) na lógica da regra, sempre que possível.
Precisa de mais ajuda? Receba respostas de membros da comunidade e profissionais da Google SecOps.