Visão geral das detecções compostas

Compatível com:

Este documento apresenta as detecções compostas e como elas podem melhorar os fluxos de trabalho de detecção de ameaças correlacionando as 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 sinais de risco de entidade. Essas regras são combinadas com eventos, métricas ou sinais de risco de entidade para detectar ameaças complexas e de vários estágios que as regras individuais podem não identificar.

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 ao correlacionar dados de diferentes fontes e estágios de ataque.

Os conceitos a seguir definem os elementos básicos das 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. Se quiser, enriqueça-os 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 precisam sempre ter uma seção de correspondência e podem referenciar campos de metadados, variáveis match e variáveis outcome de 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 resultados de duas ou mais regras (por exemplo, vincular uma detecção de download de malware a um alerta de beaconing C2 subsequente do mesmo host).

  • Enriqueça os alertas com dados de eventos relacionados.

  • Reduza a fadiga de alertas acionando um alerta final apenas quando uma detecção ruidosa e de baixa confiança ocorrer várias vezes ou em combinação com outras atividades suspeitas.

  • Crie 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 geralmente são multifacetados e interconectados. A detecção composta revela a narrativa mais ampla do ataque ao vincular 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 por 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), detecções de regras, contexto de entidade, descobertas de análise de comportamento de usuários e entidades (UEBA) 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.

  • Uso em painéis: integre as detecções compostas como fontes de dados para os painéis do Google SecOps. Você pode usá-los para criar visualizações que resumem padrões de ataque em vários estágios, facilitando a compreensão de riscos complexos.

Casos de uso comuns

Nesta seção, listamos alguns casos de uso comuns para detecções compostas.

Enriquecer as detecções com o contexto de eventos brutos

Esse caso de uso envolve vincular um alerta de alto nível de um sistema com logs de eventos de outro sistema.

  • Objetivo: identificar a ação local específica que causou um alerta de alto nível.

  • Exemplo:

    1. Um alerta é acionado no Google Cloud Event Threat Detection porque uma carga de trabalho fez uma chamada DNS para um domínio mal-intencionado. Essa é a detecção.

    2. Uma regra composta é acionada por essa detecção.

    3. Em seguida, a regra pesquisa os 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 contêm o mesmo domínio malicioso.

    O alerta final fornece um contexto avançado: ele mostra que um domínio malicioso foi contatado e o comando ssh específico usado. Essas informações tornam o resultado muito mais útil do que a detecção original.

Rastrear a atividade do usuário após o login

Um caso de uso principal focado em vincular o evento de login de um usuário a atividades suspeitas subsequentes. Enquanto uma regra padrão de vários eventos pode 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 gama de atividades subsequentes de "sinal fraco" em um período mais longo, como um dia inteiro.

  • Exemplo: criar várias regras que produzem detecções de nível mais baixo. 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 upload de dados grande 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 para encontrar comportamentos mais complexos e de longo prazo.

  • Meta: correlacionar um pico em uma métrica de UEBA com outra atividade anômala.

  • Exemplo:

    1. Uma regra de UEBA detecta um número excessivo de falhas de login de um usuário.

    2. Outra regra de UEBA detecta um grande número de bytes de saída do mesmo usuário.

    3. Uma detecção composta vincula essas duas descobertas separadas de UEBA ao longo de 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 correlacionar 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 de risco por um único usuário em vários dispositivos e ações.

  • Ações correlacionadas:

    • Fazer login em vários dispositivos (por exemplo, no computador de casa e do trabalho).

    • Acessar mais fontes de dados do que o normal.

    • Baixar, imprimir e enviar dados por e-mail ao mesmo tempo.

    • Contar quantos documentos classificados um usuário está acessando em um período.

    • Depois de apresentar 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 por 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 às ações maliciosas subsequentes, mesmo que elas ocorram com horas ou dias de diferença.

  • Exemplo:

    1. Um usuário acessa um site malicioso (evento de rede inicial).

    2. Um "arquivo dropper" é baixado e executado (primeiro evento de processo).

    3. Muito mais tarde, o arquivo dropper baixa e executa outro executável (segundo evento de processo).

    Isso requer uma janela match longa para conectar os processos pai e filho, o 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:

    1. Defina uma detecção especializada ruidosa como "somente detecção" para que ela não gere mais alertas.

    2. Crie uma detecção composta que use a saída dessa regra selecionada como a primeira condição.

    3. Adicione uma segunda condição para fornecer uma qualificação adicional, como "alertar somente se essa detecção acontecer 5 vezes para o mesmo usuário em uma hora" ou se ela for combinada com uma detecção de uma regra diferente.

Como funcionam as detecções compostas

Quando as regras atendem a condições predefinidas, elas geram detecções. Essas detecções podem incluir variáveis de resultado, que capturam dados específicos ou estados de eventos.

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 da regra original, nas variáveis de resultado e nas variáveis de correspondência.

Com base nessa avaliação, é possível usar regras compostas para criar novas detecções que serão 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 composta e Exemplos.

Defina 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.

  1. Avalie sua estratégia de detecção atual. Revise as regras atuais para identificar aquelas que são muito ruidosas, geram um alto número de falsos positivos ou são excessivamente complexas e difíceis de gerenciar.

  2. Determine os cenários específicos em que as regras compostas podem ser úteis. Isso inclui detectar ataques de vários estágios, correlacionar vários alertas de baixa confiança em um único alerta de alta confiança ou enriquecer as detecções com contexto adicional de outras fontes de dados.

  3. Com base na sua avaliação, crie um plano de implementação. Decida quais regras ruidosas você precisa refinar, quais regras complexas você precisa simplificar e quais novas detecções de vários estágios você precisa priorizar.

Esse plano definido fornece um roteiro para criar regras compostas direcionadas e eficazes. Considere as seguintes estratégias de alto nível para aproveitar ao máximo as detecções compostas e gerenciar as restrições técnicas.

Selecione o método apropriado

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. Complicar demais uma detecção pode aumentar a sobrecarga de manutenção e consumir a cota de regras.

  • Use uma detecção composta quando: sua meta for correlacionar os resultados finais de duas ou mais regras diferentes 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 detecção de beaconing C2.

  • Use uma detecção de UEBA existente quando: você 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 só faz o download de 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 sua cota de regras.

  • As regras selecionadas não são contabilizadas na sua cota de regras personalizadas.

  • As regras compostas e as regras personalizadas de vários eventos são contabilizadas na sua cota.

É possível usar uma detecção especializada definindo-a como somente detecção. Isso permite que a regra selecionada realize a detecção ampla inicial sem produzir alertas. Em seguida, use uma regra composta para aplicar uma lógica específica a essas descobertas, agregando mais valor e gerenciando estrategicamente sua cota.

Entender a diferença entre risco e contexto

Ao projetar a lógica de detecção, diferencie as regras que avaliam o risco das 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 uma única falha de login forneça contexto, um número alto delas indica o risco de um ataque de força bruta.

Contexto se refere aos detalhes factuais de um evento. Uma regra projetada para contexto enriquece um evento com detalhes de outro. Por exemplo, enquanto uma regra pode 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 em potencial, como uma chamada de DNS para um domínio malicioso. Uma regra composta correlaciona esse alerta com os logs de eventos no Google SecOps para encontrar o processo de linha de comando específico que iniciou a chamada. Isso enriquece o alerta de risco de alto nível com um contexto crítico e acionável.

Use 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á-los inadequados para alertas urgentes. Considere usar essas janelas de longa duração para detectar atividades adversárias lentas e persistentes em 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 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 em um widget de painel, é possível acompanhar tendências, identificar outliers e ter uma visão de auditoria de alto nível da atividade sem se sobrecarregar com alertas individuais.

Exemplo: rastrear o tratamento de dados de PII

Uma regra rastreia todas as vezes que um usuário lida com dados sensíveis de PII. Em vez de alertar sempre, ele está configurado apenas para detectar. Um widget do painel mostra quais usuários estão se aproximando de um limite diário de saída (por exemplo, 10,000 bytes). Isso fornece uma visualização de auditoria rápida de comportamentos de risco sem gerar alertas constantes.

Exemplo: monitorar riscos específicos da DLP:

Um widget agrega as pontuações de risco de um subconjunto muito específico de regras da DLP. Isso permite que uma equipe específica (por exemplo, os administradores da 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 composta e Exemplos.

  1. Defina o cenário de ameaça: defina a ameaça específica que você quer detectar.

  2. 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.

  3. Defina as condições de mesclagem: determine as informações comuns que vinculam as detecções das regras de entrada, como rótulos de regras, variáveis ou campos de detecção.

  4. Crie a regra composta: escreva a regra que ingere as detecções das regras de entrada.

    • Defina a seção events, referenciando as regras de entrada pelo nome, ID ou um rótulo de metadados compartilhado.

    • Defina a seção match para especificar a chave de mesclagem e o período da correspondência.

    • Defina a seção condition para estabelecer a condição que precisa ser atendida para que o alerta final seja acionado.

  5. Teste e implante a cadeia de regras: recomendamos executar manualmente uma retrohunt para cada regra na sequência.

    Quando você usa o recurso Regra de teste em uma regra composta, ele é executado apenas 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 retrohunt para a sequência de regras, faça o seguinte:

    1. Inicie manualmente uma retrohunt a partir da primeira regra da sequência.

    2. Aguarde a conclusão.

    3. Continue para a próxima regra.

Exemplo: a regra a seguir fornece um modelo básico de correlação de regras:


rule Basic_Rule_Correlation_Template {
    
    meta:
    description = "Triggers when a user triggers two different rules within X days"

    events: 
    // 1. Identify the first sub-rule detection
    $d1.metadata.event_type = "DETECTION" $d1.metadata.rule_name = "INSERT_RULE_NAME_A_HERE" $user = [REDACTED_GENERIC_ID]

    // 2. Identify the second sub-rule detection
    $d2.metadata.event_type = "DETECTION"
    $d2.metadata.rule_name = "INSERT_RULE_NAME_B_HERE"
    $user = [REDACTED_GENERIC_ID]
    match: 
    // 3. Connect the rules by the same user over the specified window
    $user over 14d
    condition: 
    // 4. Fire when both conditions have occurred
    $d1 and $d2
}

Exemplo: a regra a seguir verifica detecções especializadas com uma regra de detecção de eventos e um gráfico de eventos, além de usar algumas funções avançadas do YARA-L e definições de variáveis:


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 composta

É possível ver 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 origem e a coluna Tipo de detecção exibe um rótulo 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 latência mínima em 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 mesclar detecções

Recomendamos o uso de variáveis de resultado, metarrótulos 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 metarrótulos 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, será possível ter uma regra composta que segmente qualquer detecção em que o rótulo de tática tenha o valor exfiltration.

Ao usar nocase com variáveis de mesclagem em detecções compostas, você pode 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. Aplicar nocase a atribuições de variáveis subsequentes da mesma variável de mesclagem (por exemplo, $username = $fact2...) é interpretado 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 do YARA-L em pontos estratégicos de uma regra composta para aumentar o sinal 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 dela. 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 projetar e implementar detecções compostas, considere as seguintes limitações:

  • Exclusões: não aplique uma exclusão de regra diretamente a uma regra composta. É necessário aplicar a exclusão às regras básicas que alimentam a regra composta. Isso ocorre porque as exclusões de regras são avaliadas em relação aos campos de UDM (como principal.user.userid), mas as regras compostas são acionadas com base em outras detecções, e não em campos de UDM. Se você aplicar uma exclusão de regra diretamente a uma regra composta, a exclusão não vai corresponder e o evento não será excluído.

  • Disponibilidade de dados de casos do SOAR: as detecções compostas não têm acesso a todos os dados de casos do 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 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 diário de 10.000 detecções por regra.

  • Variáveis de resultado: cada regra é limitada a no máximo 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 $e1 e 10 para $e2.

Para mais informações sobre limites de detecção, consulte Limites de detecção.

A seguir

Para saber como criar regras de detecção composta, consulte Regras de detecção composta e Exemplos.

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