Detecções compostas
Este documento apresenta as detecções compostas e como elas podem melhorar os fluxos de trabalho de detecção de ameaças correlacionando saídas de várias regras.
As detecções compostas são geradas por regras que usam detecções de outras regras como entrada, combinadas com eventos, métricas ou indicadores de risco de entidades. Essas regras são combinadas com eventos, métricas ou indicadores de risco de entidades para detectar ameaças complexas e de vários estágios que as regras individuais podem perder.
As detecções compostas ajudam a analisar eventos por meio de interações e acionadores de regras definidos. Isso melhora a precisão, reduz os falsos positivos e oferece uma visão abrangente das ameaças de segurança, correlacionando dados de diferentes fontes e estágios de ataque.
Os conceitos a seguir definem os blocos de construção de regras compostas e esclarecem como elas funcionam nos fluxos de trabalho de detecção:
Regras compostas: usam detecções ou alertas (ou ambos) como entrada. Opcionalmente, elas podem ser enriquecidas com eventos, métricas e uma ampla variedade de dados contextuais do gráfico de entidades, como dados de prevalência, inteligência contra ameaças ou uma pontuação de risco de entidade. Essas regras sempre precisam ter uma seção de correspondência e podem fazer referência a metacampos, variáveis
matche variáveisoutcomede regras de entrada.Detecção: saída gerada quando as condições de uma regra são atendidas.
Regras somente de detecção: regras compostas que usam apenas detecções ou alertas como entradas.
Quando usar detecções compostas
As detecções compostas podem ser úteis para alcançar os seguintes objetivos:
Correlacionar os resultados de duas ou mais regras (por exemplo, vincular uma detecção de malware baixado a um alerta de beaconing de C2 subsequente do mesmo host).
Enriquecer alertas com dados de eventos relacionados.
Reduzir a fadiga de alertas acionando apenas um alerta final quando uma detecção ruidosa e de baixa confiança ocorre várias vezes ou em combinação com outra atividade suspeita.
Criar um alerta para um ataque complexo de vários estágios em que cada estágio já é identificado pela própria regra.
Benefícios das detecções compostas
As detecções compostas têm os seguintes benefícios:
Desmascarar ataques de vários estágios: os ataques cibernéticos costumam ser multifacetados e interconectados. A detecção composta revela a narrativa de ataque mais ampla, vinculando ocorrências de segurança aparentemente isoladas. Por exemplo, as detecções compostas podem identificar a sequência completa de um ataque, como uma violação inicial seguida de escalonamento de privilégios e exfiltração de dados.
Reduzir a fadiga de alertas: as regras compostas consolidam e filtram alertas ruidosos, permitindo uma resposta mais focada. Essa abordagem ajuda a priorizar incidentes de alto impacto e reduzir a fadiga geral de alertas.
Melhorar a precisão da detecção: combine insights de eventos do Modelo de dados unificado (UDM, na sigla em inglês), detecções de regras, contexto de entidades, descobertas de análise de comportamento de usuários e entidades (UEBA, na sigla em inglês) e tabelas de dados para criar uma lógica de detecção mais precisa.
Simplificar a lógica complexa: divida cenários de detecção complexos em regras gerenciáveis, interconectadas e reutilizáveis para simplificar o desenvolvimento e a manutenção.
Usar em painéis: integre perfeitamente detecções compostas como fontes de dados para painéis do Google SecOps. É possível usá-las para criar visualizações que resumem padrões de ataque de vários estágios, facilitando a compreensão de riscos complexos.
Casos de uso comuns
Esta seção lista alguns casos de uso comuns para detecções compostas.
Enriquecer detecções com contexto de eventos brutos
Esse caso de uso envolve a vinculação de um alerta de alto nível de um sistema a registros de eventos de outro sistema.
Objetivo:identificar a ação local específica que causou um alerta de alto nível.
Exemplo :
Um alerta é acionado em Google Cloud Detecção de ameaças do evento porque uma carga de trabalho fez uma chamada de DNS para um domínio malicioso. Essa é a detecção.
Uma regra composta é acionada por essa detecção.
Em seguida, a regra pesquisa registros brutos de detecção e resposta de endpoints (EDR, na sigla em inglês) (os eventos) da mesma carga de trabalho em uma janela de um minuto, procurando operações de linha de comando que continham o mesmo domínio malicioso.
O alerta final fornece um contexto rico: ele mostra que um domínio malicioso foi contatado e o comando
sshespecífico usado. Essas informações tornam o resultado muito mais útil do que a detecção original.
Acompanhar a atividade do usuário após o login
Um caso de uso principal focado na vinculação do evento de login de um usuário a atividades suspeitas subsequentes. Embora uma regra padrão de vários eventos possa rastrear uma sequência curta, uma detecção composta é melhor para criar um perfil de risco abrangente de toda a sessão de um usuário.
Objetivo: correlacionar um único evento, como um login de alto risco, com uma ampla variedade de atividades de "sinal fraco" subsequentes durante um período mais longo, como um dia inteiro.
Exemplo: crie várias regras que produzam detecções de nível inferior. Em seguida, use uma regra composta com uma janela de correspondência longa (por exemplo, 24 horas) para acionar um login suspeito inicial e correlacioná-lo com qualquer uma das seguintes detecções do mesmo usuário:
Um usuário limpando o histórico da linha de comando.
A criação de uma nova conta de administrador local.
Um grande upload de dados para um site pessoal do Cloud Storage.
Combinar com métricas de UEBA
Esse caso de uso aproveita as métricas de UEBA atuais como ponto de partida para uma detecção composta, a fim de encontrar um comportamento mais complexo e de longo prazo.
Objetivo: correlacionar um pico em uma métrica de UEBA com outra atividade anômala.
Exemplo:
Uma regra de UEBA detecta um número excessivo de falhas de login para um usuário.
Outra regra de UEBA detecta um grande número de bytes de saída do mesmo usuário.
Uma detecção composta vincula essas duas descobertas separadas de UEBA durante um período de dias para identificar um possível comprometimento de conta seguido de roubo de dados.
Detectar tentativas de exfiltração de dados
Isso envolve a correlação de várias ações distintas do usuário que, quando combinadas, podem indicar uma tentativa de exfiltrar dados.
Objetivo: criar um perfil de tratamento de dados arriscado por um único usuário em vários dispositivos e ações.
Ações correlacionadas:
Fazer login em vários dispositivos (por exemplo, máquina doméstica e de trabalho).
Acessar mais fontes de dados do que o normal.
Fazer download, imprimir e enviar dados por e-mail simultaneamente.
Contar quantos documentos classificados um usuário está tocando em um período.
Ter apresentado uma carta de demissão.
Detectar malware de vários estágios
Esse caso de uso envolve a identificação de malware que opera lentamente durante um longo período, o que é difícil de detectar com regras únicas que têm janelas de correspondência curtas.
Objetivo:vincular o vetor de infecção inicial a ações maliciosas subsequentes, mesmo que estejam separadas por horas ou dias.
Exemplo :
Um usuário visita um site malicioso (evento de rede inicial).
Um "arquivo de dropper" é baixado e executado (primeiro evento de processo).
Muito mais tarde, o arquivo de dropper baixa e executa outro executável (segundo evento de processo).
Isso exige uma janela
matchlonga para conectar os processos pai e filho, que as detecções compostas podem fornecer.
Reduzir o ruído de alertas
Esse caso de uso envolve o gerenciamento de detecções que são muito "ruidosas" ou produzem muitos falsos positivos por conta própria.
Objetivo:refinar uma regra ruidosa sem desativá-la ou criar exclusões complexas.
Exemplo :
Defina uma detecção selecionada ruidosa como "detectar apenas" para que ela não gere mais alertas.
Crie uma detecção composta que use a saída dessa regra selecionada como a primeira condição.
Adicione uma segunda condição para fornecer mais qualificação, como "alertar apenas se essa detecção ocorrer cinco vezes para o mesmo usuário em uma hora" ou se ela for combinada com uma detecção de uma regra diferente.
Como as detecções compostas funcionam
Quando as regras atendem a condições predefinidas, elas geram detecções. Essas detecções podem incluir variáveis de resultado, que capturam dados ou estados de eventos específicos.
As regras compostas usam essas detecções de outras regras como parte das entradas. A avaliação pode ser baseada nas informações da seção de metadados, variáveis de resultado e variáveis de correspondência da regra original.
Com base nessa avaliação, é possível usar regras compostas para criar novas detecções a serem usadas como uma representação intermediária para investigação e alertas com uma regra subsequente. Isso ajuda a correlacionar vários fatores de diferentes detecções para identificar ameaças complexas.
Para mais informações sobre sintaxe e exemplos, consulte Regras de detecção compostas e Exemplos.
Definir sua estratégia
Antes de começar a criar regras compostas, planeje sua estratégia para garantir que as novas regras sejam eficazes, eficientes e resolvam os problemas certos.
Avalie sua estratégia de detecção atual. Analise as regras atuais para identificar aquelas que são muito ruidosas, geram um grande número de falsos positivos ou são muito complexas e difíceis de gerenciar.
Determine os cenários específicos em que as regras compostas podem agregar valor. Isso inclui a detecção de ataques de vários estágios, a correlação de vários alertas de baixa confiança em um único alerta de alta confiança ou o enriquecimento de detecções com mais contexto de outras fontes de dados.
Com base na sua avaliação, crie um plano de implementação. Decida quais regras ruidosas precisam ser refinadas, quais regras complexas precisam ser simplificadas e quais novas detecções de vários estágios precisam ser priorizadas.
Esse plano definido fornece um roteiro para a criação de regras compostas direcionadas e eficazes. Considere as seguintes estratégias de alto nível para aproveitar ao máximo as detecções compostas ao gerenciar restrições técnicas.
Selecionar o método adequado
Antes de criar uma detecção composta, verifique se é possível alcançar o resultado necessário com outras alternativas. Analise se é possível identificar um padrão complexo com uma detecção de UEBA atual. A complexidade excessiva de uma detecção pode aumentar a sobrecarga de manutenção e consumir a cota de regras.
Use uma detecção composta quando: seu objetivo for correlacionar os resultados finais de duas ou mais regras diferentes e preexistentes. Isso conecta estágios conceitualmente separados de um ataque.
Exemplo: correlacionar uma detecção de uma regra de malware baixado com uma detecção subsequente de uma regra de beaconing de C2 detectada.
Use uma detecção de UEBA atual quando: quiser descobrir quando um usuário ou dispositivo quebra o padrão normal de atividade.
Exemplo: detectar automaticamente que um usuário fez o download de 100 GB de dados hoje, quando normalmente ele só baixa 1 GB.
Gerenciar cotas de regras e pontuações de risco
Para gerenciar os recursos da sua organização, entenda como diferentes tipos de regras afetam a cota de regras.
As regras selecionadas não são contabilizadas na cota de regras personalizadas.
As regras compostas e as regras personalizadas de vários eventos são contabilizadas na cota.
É possível usar uma detecção selecionada definindo-a como somente detecção. Isso permite que a regra selecionada execute a detecção inicial ampla sem produzir alertas. Em seguida, é possível usar uma regra composta para aplicar uma lógica específica a essas descobertas, oferecendo mais valor ao gerenciar estrategicamente sua cota.
Entender a diferença entre risco e contexto
Ao criar a lógica de detecção, distinga entre regras que avaliam o risco e regras que fornecem contexto.
O risco é a avaliação de quão perigoso é um conjunto de atividades. Uma regra projetada para risco geralmente agrega vários eventos ou detecções contextuais para fazer um julgamento. Por exemplo, embora um único login com falha forneça contexto, um grande número deles indica o risco de um ataque de força bruta.
O contexto se refere aos detalhes factuais que envolvem um evento. Uma regra projetada para contexto enriquece um evento com detalhes de outro. Por exemplo, embora uma regra possa detectar um login de usuário bem-sucedido, uma regra contextual fornece o contexto crucial de que esse login veio de um país novo e incomum.
Exemplo: uma detecção inicial pode alertar sobre um risco potencial, como uma chamada de DNS para um domínio malicioso. Uma regra composta correlaciona esse alerta com registros de eventos no Google SecOps para encontrar o processo específico de linha de comando que iniciou a chamada. Isso enriquece o alerta de risco de alto nível com contexto crítico e útil.
Usar janelas de correspondência longas de forma estratégica
As regras compostas configuradas com janelas de correspondência longas (por exemplo, 14 dias) são executadas com menos frequência. A alta latência pode torná-las inadequadas para alertas sensíveis ao tempo. Considere usar essas janelas de longa duração para detectar atividades adversárias lentas e persistentes durante períodos prolongados.
Usar detecções para visualização
Uma estratégia para gerenciar regras ruidosas é transformar a saída delas em uma visualização em um painel. Essa abordagem não consome a cota de regras e pode transformar dados de alto volume e baixa fidelidade em insights valiosos.
Ao definir uma regra para detectar apenas e, em seguida, plotar as detecções dela em um widget do painel, é possível acompanhar tendências, identificar outliers e ter uma visão geral da atividade sem ser sobrecarregado por alertas individuais.
Exemplo: acompanhar o tratamento de dados PII
Uma regra acompanha cada vez que um usuário trata dados PII sensíveis.
Em vez de alertar sempre, ela é definida para detectar apenas. Um widget do painel
mostra quais usuários estão se aproximando de um limite de saída diário (por exemplo,
10,000 bytes). Isso fornece uma visão geral rápida do comportamento de risco sem gerar alertas constantes.
Exemplo: monitorar riscos específicos de DLP:
Um widget agrega as pontuações de risco de um subconjunto muito específico de regras de DLP. Isso permite que uma equipe específica (por exemplo, os administradores de prevenção contra perda de dados (DLP)) monitore apenas os riscos relevantes, filtrando o ruído de outros domínios de segurança.
Criar detecções compostas
O fluxo de trabalho a seguir descreve a jornada típica para criar uma regra composta. Para mais informações sobre sintaxe e exemplos, consulte Regras de detecção compostas e Exemplos.
Defina o cenário de ameaça: defina a ameaça específica que você quer detectar.
Crie ou identifique as regras de entrada: para cada estágio do cenário de ameaça, crie ou identifique uma regra de entrada que detecte a atividade específica.
Defina as condições de junção: determine a informação comum que vincula as detecções das regras de entrada, como rótulos de regras, variáveis ou campos de detecção.
Crie a regra composta: escreva a regra que ingere as detecções das regras de entrada.
Defina a seção
events, fazendo referência às regras de entrada pelo nome, ID ou um rótulo de metadados compartilhado.Defina a seção
matchpara especificar a chave de junção e a janela de tempo para a correspondência.Defina a seção
conditionpara definir a condição que precisa ser atendida para que o alerta final seja acionado.
Teste e implante a cadeia de regras: recomendamos executar manualmente uma retrocaça para cada regra na sequência.
Quando você usa o recurso Testar regra em uma regra composta, ele só é executado em detecções preexistentes que correspondem aos critérios de entrada da regra. Ele não executa automaticamente as regras subjacentes para gerar novas entradas para o teste, o que significa que não é possível validar uma cadeia de regras inteira em uma única ação.
Para executar uma retrocaça para a sequência de regras, faça o seguinte:
Inicie manualmente uma retrocaça da primeira regra na sequência.
Aguarde a conclusão.
Continue com a próxima regra.
Exemplo:
rule CheckCuratedDetection_with_EDR_and_EG {
meta:
author = "noone@cymbal.com"
events:
$d.detection.detection.rule_name = /SCC: Custom Modules: Configurable Bad Domain/
$d.detection.collection_elements.references.event.network.dns.questions.name = $domain
$d.detection.collection_elements.references.event.principal.asset.hostname = $hostname
$e.metadata.log_type = "LIMACHARLIE_EDR"
$e.metadata.product_event_type = "NETWORK_CONNECTIONS"
$domain = re.capture($e.principal.process.command_line, "\\s([a-zA-Z0-9.-]+\\.[a-zA-Z0-9.-]+)$")
$hostname = re.capture($e.principal.hostname, "([^.]*)")
$prevalence.graph.metadata.entity_type = "DOMAIN_NAME"
$prevalence.graph.metadata.source_type = "DERIVED_CONTEXT"
$prevalence.graph.entity.hostname = $domain
$prevalence.graph.entity.domain.prevalence.day_count = 10
$prevalence.graph.entity.domain.prevalence.rolling_max <= 5
$prevalence.graph.entity.domain.prevalence.rolling_max > 0
match:
$hostname over 1h
outcome:
$risk_score = 80
$CL_target = array($domain)
condition:
$e and $d and $prevalence
}
Ver descobertas de detecção compostas
É possível conferir os resultados da detecção composta
na página Detecções. Um alerta é uma detecção composta quando a coluna Entradas mostra Detecção como uma fonte e a coluna Tipo de detecção mostra um rótulo de Alerta com um número ao lado (por exemplo, Alert (3)).
Observação: se você tiver o SIEM e o SOAR, também poderá conferir os resultados na guia Casos.
Otimizar detecções compostas
Recomendamos as práticas a seguir para criar regras compostas.
Otimizar para latência
Para minimizar a latência nos pipelines de detecção, use regras de evento único sempre que possível, como para o acionador inicial. As regras compostas podem usar as detecções para realizar correlações mais complexas com outros eventos, entidades ou detecções, o que ajuda a reduzir a latência geral.
Usar métodos eficientes para unir detecções
Recomendamos o uso de variáveis de resultado, rótulos de metadados e variáveis de correspondência para unir detecções. Esses métodos fornecem resultados mais determinísticos e confiáveis do que o uso de amostras de eventos. Os rótulos de metadados são particularmente flexíveis porque permitem categorizar regras para que uma regra composta possa segmentar qualquer detecção com esse rótulo.
Por exemplo, se várias regras compartilharem o mesmo rótulo de metadados
tactic: exfiltration, você poderá ter uma regra composta que segmenta qualquer detecção
em que o rótulo de tática tenha o valor exfiltration.
Ao usar nocase com variáveis de junção em detecções compostas, você poderá receber o seguinte erro de análise semântica:
semantic analysis: match variable <variable_name> is not assigned to an event field.
Em detecções compostas, a primeira atribuição de variável (por exemplo, $username = $fact1...)
define as propriedades da variável, incluindo a não diferenciação de maiúsculas e minúsculas ao usar
nocase. A aplicação de nocase a atribuições de variáveis subsequentes da mesma variável de junção (por exemplo, $username = $fact2...) é interpretada pelo compilador como uma redefinição conflitante ou uma restrição redundante, resultando no erro semântico.
Melhorar as detecções com a biblioteca de funções
É possível usar a biblioteca de funções YARA-L em pontos estratégicos de uma regra composta para aumentar o indicador e adicionar uma lógica mais complexa.
Gerenciar atualizações de regras
Quando você atualiza uma regra usada em uma ou mais regras compostas, o sistema cria automaticamente uma nova versão da regra. As regras compostas usam automaticamente a nova versão. Recomendamos testar toda a sequência de regras atualizada para verificar o comportamento pretendido.
Limitações
Ao criar e implementar detecções compostas, considere as seguintes limitações:
Disponibilidade de dados de casos de SOAR: as detecções compostas não têm acesso a todos os dados de casos de SOAR. A lógica de regra que tenta filtrar ou excluir casos com base no status (por exemplo,
$edetection.feedback_summary.status != "CLOSED") não é compatível.Regras compostas: o Google SecOps oferece suporte a uma profundidade máxima de 10 para regras compostas. A profundidade é o número de regras de uma regra de base até a regra composta final.
Regras somente de detecção: têm uma janela de correspondência máxima de 14 dias e estão sujeitas a um limite de detecção diário de 10.000 detecções por regra.
Variáveis de resultado: cada regra é limitada a um máximo de 20 variáveis de resultado. Além disso, cada variável de resultado repetida é limitada a 25 valores.
Amostras de eventos: apenas 10 amostras de eventos são armazenadas por variável de evento em uma regra, como 10 para
$e1e 10 para$e2.
Para mais informações sobre limites de detecção, consulte Limites de detecção.
A seguir
Para informações sobre como criar regras de detecção compostas, consulte Regras de detecção compostas e Exemplos.
Precisa de mais ajuda? Receba respostas de membros da comunidade e profissionais do Google SecOps.