Saiba como aplicar uma regra a dados dinâmicos

Compatível com:

Quando você cria uma regra, ela não pesquisa detecções com base em eventos recebidos na sua conta do Google Security Operations em tempo real. No entanto, você pode definir a regra para pesquisar detecções em tempo real ativando a opção Regra ativa.

Quando uma regra é configurada para pesquisar detecções em tempo real, ela prioriza dados ativos para detecção imediata de ameaças.

Para ativar uma regra, siga estas etapas:

  1. Clique em Detecção > Regras e detecções.

  2. Clique na guia Painel de regras.

  3. Clique no ícone de opções more_vert Regras de uma regra e ative a Regra ativa.

    Regra ativa

    Regra ativa

  4. Selecione Ver detecções de regras para conferir as detecções de uma regra ativa.

Cota de regras de exibição

Na parte de cima à direita do painel "Regras", clique em Capacidade de regras para mostrar os limites do número de regras que podem ser ativadas como ativas.

O Google SecOps impõe os seguintes limites de regras:

  • Cota de regras de vários eventos: mostra a contagem atual de regras de vários eventos ativadas e o máximo permitido. Saiba mais sobre a diferença entre as regras de Evento único e Vários eventos.
  • Cota total de regras: mostra a contagem total atual de regras ativadas como ativas em todos os tipos de regras e o número máximo de regras que podem ser ativadas como ativas.

Execuções de regras

As execuções de regras ativas para um determinado período de evento são acionadas com frequência decrescente. Uma execução de limpeza final é realizada, e depois disso, nenhuma outra execução é iniciada.

Cada execução é feita nas versões mais recentes das listas de referência usadas nas regras e no enriquecimento de dados de eventos e entidades mais recente.

Algumas detecções podem ser geradas retrospectivamente se forem detectadas apenas por execuções posteriores. Por exemplo, a última execução pode usar a versão mais recente da lista de referência, que agora detecta mais eventos, e os dados de eventos e entidades podem ser reprocessados devido a novos enriquecimentos.

Eliminação de duplicação

O Google SecOps identifica e remove automaticamente detecções duplicadas das regras. Esse processo se aplica apenas a regras com variáveis de correspondência, já que elas dependem de janelas baseadas em tempo. As detecções com valores de variáveis de correspondência idênticos, dentro de intervalos de tempo sobrepostos, são suprimidas como duplicadas.

O Google SecOps trata cada versão de regra como uma lógica nova e distinta. Como resultado, quando uma regra é atualizada, ela pode acionar detecções repetidas com base em eventos anteriores. Essas detecções não são removidas, mesmo que pareçam duplicadas.

Latências de detecção

Vários fatores determinam quanto tempo leva para uma detecção ser gerada com base em uma regra ativa. A lista a seguir inclui os diferentes fatores que contribuem para atrasos na detecção:

Tipos de regra

  • As regras de evento único são executadas quase em tempo real em uma abordagem de streaming. Use essas regras, quando possível, para minimizar a latência.
  • As regras de vários eventos são executadas de forma programada, o que resulta em maior latência devido ao tempo entre as execuções programadas.

Frequência de execução

Para detecções mais rápidas, use uma frequência de execução menor e uma janela de correspondência menor. Usar janelas de correspondência mais curtas (menos de uma hora) permite execuções mais frequentes.

Atraso na ingestão

Verifique se os dados são enviados para as Operações de segurança do Google assim que o evento ocorre. Ao analisar uma detecção, verifique com cuidado os carimbos de data/hora de eventos e ingestão da UDM.

Junções contextuais

Regras de vários eventos que usam dados contextuais, como UEBA ou Entity Graph, podem ter atrasos maiores. Os dados contextuais precisam ser gerados primeiro pelo Google SecOps.

Dados enriquecidos do UDM

O Google SecOps enriquece eventos com dados de outros eventos. Para identificar se uma regra está avaliando um campo enriquecido, revise o Visualizador de eventos. Se a regra estiver avaliando um campo enriquecido, a detecção poderá ser adiada.

Problemas de fuso horário

As regras são executadas com mais frequência para dados em tempo real. Os dados podem chegar em tempo real, mas o Google SecOps ainda pode tratá-los como atrasados se o horário do evento estiver incorreto devido a discrepâncias de fuso horário.

O fuso horário padrão do SIEM do Google SecOps é UTC. Se os dados originais tiverem um carimbo de data/hora de evento definido para outro fuso horário além do UTC, atualize o fuso horário dos dados. Se não for possível atualizar o fuso horário na origem do registro, entre em contato com o suporte para substituir o fuso horário.

Regras de não existência

As regras que verificam a não existência (por exemplo, regras que contêm !$e ou #e=0) são executadas com um atraso mínimo de uma hora para verificar se os dados têm tempo para chegar.

Listas de referências

As execuções de regras sempre usam a versão mais atualizada de uma lista de referência. Se a lista de referência foi atualizada recentemente, uma nova detecção pode aparecer com atraso. Isso acontece porque a detecção só pode ser incluída em novos conteúdos da lista atualizada durante execuções posteriores da regra programada.

Para reduzir as latências de detecção, recomendamos fazer o seguinte:

  • Envie dados de registro para o Google SecOps assim que o evento ocorrer.
  • Revise as regras de auditoria para determinar se é necessário usar dados de não existência ou enriquecidos com contexto.
  • Configure uma frequência de execução menor.

Status da regra

As regras ativas podem ter um dos seguintes status:

  • Ativada:a regra está ativa e funcionando normalmente como uma regra ativa.

  • Desativada:a regra está desativada.

  • Limitado:as regras ativas podem ser definidas como "Limitado" quando mostram um uso de recursos muito alto. As regras limitadas são isoladas das outras regras ativas no sistema para manter a estabilidade do Google SecOps.

    Para regras ativas limitadas, nem sempre é possível executar as regras com sucesso. No entanto, se a execução da regra for bem-sucedida, as detecções serão retidas e ficarão disponíveis para revisão. As regras ativas limitadas sempre geram uma mensagem de erro, que inclui recomendações sobre como melhorar o desempenho da regra.

    Se a performance de uma regra Limitada não melhorar em três dias, o status dela será alterado para Pausada.

    Observação: se não houver mudanças recentes nessa regra, os erros podem ser intermitentes e podem ser resolvidos automaticamente.

  • Pausada:as regras ativas entram nesse status quando estão no status Limitado por três dias e não mostram nenhuma melhoria de performance. As execuções dessa regra foram pausadas, e mensagens de erro com sugestões de como melhorar a performance dela foram retornadas.

Para retornar uma regra ativa ao status Ativada, siga as práticas recomendadas da YARA-L para otimizar a performance da regra e salve as mudanças. Depois que a regra for salva, ela será redefinida para o estado Ativada e levará pelo menos uma hora para atingir o status Limitada novamente.

É possível resolver problemas de performance com uma regra configurando-a para ser executada com menos frequência. Por exemplo, é possível reconfigurar uma regra para que ela seja executada uma vez por hora ou a cada 24 horas, em vez de a cada 10 minutos. No entanto, mudar a frequência de execução de uma regra não muda o status dela de volta para Ativada. Se você fizer uma pequena modificação na regra e salvar, poderá redefinir automaticamente o status dela para Ativada.

Os status das regras são mostrados no painel de regras e também podem ser acessados pela API Detection Engine. Os erros gerados por regras no status Limitado ou Em pausa estão disponíveis usando o método da API ListErrors. O erro indica que a regra está no status Limitada ou Pausada e fornece um link para a documentação sobre como resolver o problema.

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