Na Elastic, operamos um conjunto amplo e diversificado de regras de detecção de comportamento em vários conjuntos de dados, ambientes e níveis de gravidade. A maioria dessas regras são atômicas, cada uma projetada para detectar um comportamento, sinal ou padrão de ataque específico. Além disso, incorporamos e promovemos alertas externos provenientes de integrações de segurança, como firewalls, EDR, WAF e outros controles de segurança.
O resultado é uma visibilidade poderosa, mas também um volume significativo de alertas. De acordo com nossos dados de telemetria, mesmo considerando apenas as regras que não são blocos de construção, 65 regras de detecção exclusivas geram quase 8.000 alertas por dia por cluster de produção. Analisar cada alerta isoladamente não é escalável nem economicamente viável.
É aqui que entram em jogo as regras de ordem superior .
Regras de ordem superior não detectam um único comportamento. Em vez disso, eles correlacionam alertas relacionados ao longo do tempo, em diferentes fontes de dados ou dentro de um contexto compartilhado (como host, usuário, IP ou processo). Ao agrupar sinais em padrões significativos, podemos priorizar o que realmente importa e reduzir a necessidade de análises profundas e dispendiosas para cada alerta individual, seja realizada manualmente, de forma automatizada ou com o auxílio de IA.
Neste blog, vamos apresentar nossa abordagem para criar regras de ordem superior no Elasticsearch, compartilhar exemplos práticos e destacar as principais lições aprendidas ao longo do processo.
O que são regras de ordem superior?
Regras de Ordem Superior (HOR, na sigla em inglês) são detecções que usam alertas como entrada, correlacionando alertas com outros alertas (alerta sobre alerta) ou combinando alertas com dados adicionais, como eventos brutos, métricas ou telemetria contextual.
Ao contrário das regras atômicas, que detectam um único comportamento, as regras de ordem superior identificam padrões em diversos sinais. Seu objetivo não é substituir as detecções básicas, mas sim destacar combinações de resultados que têm maior probabilidade de representar uma atividade de ataque real. Na prática, elas revelam resultados com maior confiabilidade e melhoram a priorização da triagem. As regras de ordem superior são projetadas para funcionar em conjunto com as regras básicas. As regras de blocos de construção geram alertas que não aparecem na visualização de alertas padrão, reduzindo o ruído e, ao mesmo tempo, fornecendo detecções correlacionadas. Muitas das regras básicas mencionadas neste artigo também podem ser configuradas como regras de construção, de modo que apenas as correlações de ordem superior sejam exibidas para análise do analista.
A ideia central é que detecções independentes convergindo para a mesma entidade aumentam a confiança, onde cada sinal adicional multiplica a probabilidade de a atividade ser real e não benigna. Esses três princípios de design operacionalizam essa ideia:
1. Correlação Baseada em Entidades
As regras correlacionam a atividade por entidades compartilhadas, como host, usuário, IP de origem, IP de destino ou processo, permitindo que os analistas vejam rapidamente quando várias descobertas convergem para o mesmo ativo ou identidade.
2. Visibilidade entre fontes de dados
Algumas regras operam dentro de uma única integração (por exemplo, detecções exclusivas de endpoints do Elastic Defend ou de um EDR de terceiros). Outros combinam intencionalmente sinais entre domínios, como endpoint com rede (PANW, FortiGate, Suricata), endpoint com e-mail ou endpoint com métricas do sistema, para capturar atividades em vários estágios ou em diferentes superfícies.
3. Conscientização sobre o tempo e a prevalência
A lógica temporal desempenha um papel fundamental.
As novas regras observadas destacam a primeira ocorrência de um determinado alerta dentro de um período de análise definido (por exemplo, cinco dias), garantindo que até mesmo um único alerta raro seja identificado para revisão.
A lógica baseada na prevalência (como o uso de INLINE STATS) filtra alertas que ocorrem em apenas um pequeno número de hosts globalmente, ajudando a reduzir o ruído e enfatizar comportamentos anômalos.
O conjunto completo de Regras de Ordem Superior abrange correlações apenas de endpoints, detecções entre domínios (endpoint + rede, endpoint + e-mail), padrões de movimento lateral (por exemplo, alert_1 host.ip = alert_2 source.ip), agrupamentos alinhados ao ATT&CK (atividade de tática única ou múltipla), alertas recém-observados e correlação de alerta com evento (como alertas combinados com métricas anormais de CPU). As seções a seguir apresentam exemplos representativos dessas categorias.
Correlação e regras de ordem superior recentemente observadas
Na prática, atividades de alto risco nem sempre se apresentam da mesma forma.
Às vezes, o compromisso se revela através de múltiplos sinais convergentes. Outras vezes, aparece como um único alerta nunca antes visto.
Para lidar com ambas as realidades, organizamos nossas Regras de Ordem Superior em três padrões complementares:
- As regras de correlação vinculam vários alertas ou eventos a uma entidade compartilhada (host, usuário, IP ou processo).
- Regras recém-observadas: um alerta único que é raro ou visto pela primeira vez dentro de um período de tempo definido.
- Padrões híbridos que combinam correlação com lógica de primeira observação, o que pode aumentar ainda mais a suspeita e revelar atividades particularmente interessantes.
As regras de correlação aumentam a confiança por meio da densidade e diversidade do sinal: quando várias detecções independentes apontam para a mesma entidade, a probabilidade de atividade maliciosa real aumenta.
As regras recentemente observadas abordam o caso oposto: baixo volume, mas alta novidade. Eles priorizam os alertas com base na raridade ao longo do tempo, garantindo que detecções inéditas ou altamente incomuns não sejam ignoradas simplesmente por ocorrerem apenas uma vez.
Em conjunto, essas abordagens formam a base de uma estratégia de triagem eficiente e escalável.
Vamos analisar exemplos e explorar as diferenças, vantagens e desvantagens de cada padrão.
Correlação de alertas de endpoint
Uma parcela significativa da descoberta de ataques no mundo real provém da telemetria de endpoints. Ela fornece um contexto rico sobre a atividade do processo, linhas de comando, comportamento de arquivos e ações do usuário, tornando-se uma das fontes de detecção mais poderosas.
Ao mesmo tempo, os ambientes de endpoint são dinâmicos. Softwares legítimos, ferramentas administrativas e aplicativos de terceiros (e, mais recentemente, os utilitários de endpoint da GenAI 🥲) podem gerar um alto volume de alertas e falsos positivos, exigindo ajustes contínuos.
A correlação de ordem superior ajuda a resolver isso, mudando o foco de alertas individuais para múltiplos sinais distintos no mesmo host ou processo, aumentando a confiança e reduzindo o esforço desnecessário de investigação.
A seguinte consulta ES|QL é acionada quando existem 3 regras de comportamento exclusivas do Elastic Defend OU alertas de diferentes recursos (por exemplo, um shellcode_thread com comportamento, um arquivo malicioso com comportamento) OU mais de 2 alertas de malware em uma janela de 24 horas do mesmo host:
from logs-endpoint.alerts-* metadata _id
| eval day = DATE_TRUNC(24 hours, @timestamp)
| where event.code in ("malicious_file", "memory_signature", "shellcode_thread", "behavior") and
agent.id is not null and not rule.name in ("Multi.EICAR.Not-a-virus")
| stats Esql.alerts_count = COUNT(*),
Esql.event_code_distinct_count = count_distinct(event.code),
Esql.rule_name_distinct_count = COUNT_DISTINCT(rule.name),
Esql.file_hash_distinct_count = COUNT_DISTINCT(file.hash.sha256),
Esql.process_entity_id_distinct_count = COUNT_DISTINCT(process.entity_id) by host.id, day
| where (Esql.event_code_distinct_count >= 2 or Esql.rule_name_distinct_count >= 3 or Esql.file_hash_distinct_count >= 2)Para aumentar ainda mais as suspeitas, também podemos correlacionar alertas do Elastic Defend que pertencem à mesma árvore de processos:
from logs-endpoint.alerts-*
| where event.code in ("malicious_file", "memory_signature", "shellcode_thread", "behavior") and
agent.id is not null and not rule.name in ("Multi.EICAR.Not-a-virus") and process.Ext.ancestry is not null
// aggregate alerts by process.Ext.ancestry and agent.id
| stats Esql.alerts_count = COUNT(*),
Esql.rule_name_distinct_count = COUNT_DISTINCT(rule.name),
Esql.event_code_distinct_count = COUNT_DISTINCT(event.code),
Esql.process_id_distinct_count = COUNT_DISTINCT(process.entity_id),
Esql.message_values = VALUES(message),
... by process.Ext.ancestry, agent.id
// filter for at least 3 unique process IDs and 2 or more alert types or rule names.
| where Esql.process_id_distinct_count >= 3 and (Esql.rule_name_distinct_count >= 2 or Esql.event_code_distinct_count >= 2)
// keep unique values
| stats Esql.alert_names = values(Esql.message_values),
Esql.alerts_process_cmdline_values = VALUES(Esql.process_command_line_values),
... by agent.id
| keep Esql.*, agent.idExemplo de correspondências:
Para complementar nossa cobertura, também precisaremos procurar por átomos raros. O seguinte ES|QL foi projetado para ser executado em um intervalo de 10 minutos com uma janela de observação de 5 ou 7 dias. O recurso de análise retrospectiva agrega todos os alertas por nome de regra ao longo de todo o período analisado para calcular o horário da primeira visualização. O filtro final (Esql.recent <= 10) garante que apenas as regras cujo primeiro horário de visualização esteja dentro da janela de execução atual de 10 minutos sejam exibidas, detectando efetivamente o momento em que uma regra é acionada pela primeira vez no período de observação. Isso revela tanto falsos positivos raros quanto comportamentos furtivos que poderiam passar despercebidos em meio ao grande volume de casos:
from logs-endpoint.alerts-*
| WHERE event.code == "behavior" and rule.name is not null
| STATS Esql.alerts_count = count(*),
Esql.first_time_seen = MIN(@timestamp),
Esql.last_time_seen = MAX(@timestamp),
Esql.agents_distinct_count = COUNT_DISTINCT(agent.id),
Esql.process_executable = VALUES(process.executable),
Esql.process_parent_executable = VALUES(process.parent.executable),
Esql.process_command_line = VALUES(process.command_line),
Esql.process_hash_sha256 = VALUES(process.hash.sha256),
Esql.host_id_values = VALUES(host.id),
Esql.user_name = VALUES(user.name) by rule.name
// first time seen in the last 5 days - defined in the rule schedule Additional look-back time
| eval Esql.recent = DATE_DIFF("minute", Esql.first_time_seen, now())
// first time seen is within 10m of the rule execution time
| where Esql.recent <= 10 and Esql.agents_distinct_count == 1 and Esql.alerts_count <= 10 and (Esql.last_time_seen == Esql.first_time_seen)
// Move single values to their corresponding ECS fields for alerts exclusion
| eval host.id = mv_min(Esql.host_id_values)
| keep host.id, rule.name, Esql.*A mesma lógica pode ser aplicada a um alerta externo proveniente de outros sistemas EDR de terceiros:
Correlação de alertas de rede com endpoints
Uma abordagem de detecção eficaz consiste em correlacionar alertas de endpoints com alertas de rede. Isso ajuda a responder à pergunta principal:
Qual processo desencadeou esse alerta de rede?
Os alertas de rede, por si só, muitas vezes carecem de contexto do processo, como qual usuário ou executável iniciou a atividade. Ao combinar alertas de rede com telemetria de endpoints (dados EDR), você pode enriquecer os alertas com:
- Nome e hash do processo
- Linha de comando e processo pai
- Informações do usuário e do dispositivo
A consulta a seguir correlaciona qualquer alerta do Elastic Defend com eventos suspeitos de dispositivos de segurança de rede, como Palo Alto Networks (PANW) e Fortinet FortiGate. A chave de junção é o endereço IP: para alertas de rede, é source.ip, para alertas de endpoint, é host.ip. A consulta normaliza estes em um único campo usando COALESCE, permitindo a correlação entre fontes de dados que usam nomes de campo diferentes para a mesma entidade. Isso pode indicar que este host está comprometido e acionando alertas de múltiplas fontes de dados.
FROM logs-* metadata _id
| WHERE
(event.module == "endpoint" and event.dataset == "endpoint.alerts") or
(event.dataset == "panw.panos" and event.action in ("virus_detected", "wildfire_virus_detected", "c2_communication", ...)) or
(event.dataset == "fortinet_fortigate.log" and (...)) or
(event.dataset == "suricata.eve" and message in ("Command and Control Traffic", "Potentially Bad Traffic", ...))
| eval
fw_alert_source_ip = CASE(event.dataset in ("panw.panos", "fortinet_fortigate.log"), source.ip, null),
elastic_defend_alert_host_ip = CASE(event.module == "endpoint" and event.dataset == "endpoint.alerts", host.ip, null)
| eval Esql.source_ip = COALESCE(fw_alert_source_ip, elastic_defend_alert_host_ip)
| where Esql.source_ip is not null
| stats Esql.alerts_count = COUNT(*),
Esql.event_module_distinct_count = COUNT_DISTINCT(event.module),
Esql.message_values_distinct_count = COUNT_DISTINCT(message),
... by Esql.source_ip
| where Esql.event_module_distinct_count >= 2 AND Esql.message_values_distinct_count >= 2
| eval concat_module_values = MV_CONCAT(Esql.event_module_values, ",")
| where concat_module_values like "*endpoint*"Exemplo de correspondências correlacionando alertas do Elastic Defend e do FortiGate onde o source.ip do alerta do FortiGate é igual ao host.ip do alerta do endpoint do Elastic Defend:
A seguinte consulta EQL correlaciona alertas do Suricata com eventos de rede do Elastic Defend para fornecer contexto sobre o processo e o host de origem:
sequence by source.port, source.ip, destination.ip with maxspan=5s
// Suricata severithy 3 corresponds to information alerts, which are excluded to reduce noise
[network where event.dataset == "suricata.eve" and event.kind == "alert" and event.severity != 3 and source.ip != null and destination.ip != null]
[network where event.module == "endpoint" and event.action in ("disconnect_received", "connection_attempted")]Exemplo de correspondências que confirmam o alerta do Suricata e o vinculam ao processo do servidor web alvo nginx a partir de eventos do Elastic Defend que confirmam a tentativa de exploração web:
Segurança de endpoints com observabilidade
A correlação entre telemetria de observabilidade e alertas de segurança é uma estratégia de detecção poderosa.
O incidente do backdoor XZ Utils demonstrou que anomalias relevantes para a segurança podem surgir inicialmente como regressões de desempenho, em vez de alertas de segurança tradicionais. Nesse caso, o comportamento incomum do daemon SSH levou a uma investigação mais aprofundada e à eventual descoberta de código malicioso.
Isso destaca um princípio importante: anomalias operacionais podem ser indicadores precoces de comprometimento.
Com o Elastic Agent, métricas do sistema, como utilização de CPU e memória, podem ser coletadas juntamente com telemetria de segurança. Ao correlacionar picos anormais de recursos com alertas do SIEM, seja por processo ou por host, podemos aumentar a confiança na detecção e identificar atividades de alto risco mais cedo.
Por exemplo, uma regra de correlação ES|QL pode identificar um processo que apresenta utilização sustentada de 70% da CPU e que também é a origem de um alerta de assinatura de memória para um minerador de criptomoedas do Elastic Defend. Individualmente, cada sinal pode ser de intensidade leve ou média. Quando correlacionadas, representam atividades maliciosas de alta probabilidade.
Desenvolvemos mais de 30 detecções de ordem superior que abrangem vários tipos de relacionamentos. Embora não possamos abordar todos os pontos aqui, os links abaixo fornecem contexto suficiente para adaptar essas regras ao seu ambiente:
Alertas de endpoint:
Vários alertas do Elastic Defend por agente
Vários alertas do Elastic Defend de uma única árvore de processos
Várias regras de comportamento raras do Elastic Defend por host
Alerta de comportamento do Elastic Defend recém-observado
Vários alertas de EDR externo por host
Endpoint e Rede:
Alerta de Rede Palo Alto recém-observado
Alerta de Alta Severidade Suricata recém-observado
Tráfego SOCKS do FortiGate proveniente de um processo incomum
Correlação entre PANW e Elastic Defend - Comando e Controle
Correlação entre Alertas de Segurança de Rede e Elastic Defend
Correlação entre Suricata e Elastic Defend Network
Genérico por MITRE ATT&CK:
Alertas em diferentes táticas do ATT&CK por host
Vários alertas na mesma tática do ATT&CK por host
Correlação genérica de múltiplas integrações:
Alertas de múltiplas integrações por endereço de origem
Alertas de múltiplas integrações por endereço de destino
Alertas de múltiplas integrações por nome de usuário
Alerta de detecção de alta severidade recém-observado
Correlação de movimento lateral:
Movimento lateral suspeito de um host comprometido
Alertas de movimento lateral de um endereço de origem recém-observado
Alertas de movimento lateral de um usuário recém-observado
Correlação entre observabilidade e segurança:
Alerta de detecção em um processo que apresenta pico de uso da CPU
Vários alertas em um host que apresenta pico de uso da CPU
Processo recém-observado apresentando alto uso da CPU
Correlação de Aprendizado de Máquina:
Vários Alertas de Aprendizado de Máquina por Campo de Influência
Outras ideias de correlação:
Múltiplas vulnerabilidades por ativo via Wiz
Correlação entre Elastic Defend e alertas por e-mail
Solicitação suspeita de ticket de autenticação Kerberos
Múltiplos segredos na nuvem acessados pelo endereço de origem
Esses exemplos ilustram como a correlação de alertas entre endpoints, rede e observabilidade pode enriquecer o contexto, acelerar as investigações e melhorar a confiança na detecção. Estamos expandindo ativamente a cobertura nessa área para dar suporte a cenários de correlação adicionais.
Você pode habilitá-las filtrando pelo valor da tag Tipo de Regra: Regra de Ordem Superior na página de gerenciamento de regras:
Ao longo de um período de 15 dias, o número de alertas manteve-se dentro de um volume aceitável (cerca de 30 alertas por dia). Espera-se que o ajuste direcionado dos valores discrepantes iniciais os reduza para cerca de 20 alertas por dia e melhore significativamente a qualidade geral do sinal.
Considerações e concessões
Regras de ordem superior introduzem uma potencial latência de agendamento. Como consultam índices de alertas, existe um atraso inerente entre o momento em que os alertas básicos são acionados e o momento em que as correlações surgem. Os intervalos de agendamento de regras e as janelas de loopback devem ser ajustados para equilibrar a pontualidade com o custo de desempenho. Além disso, a qualidade do HOR depende diretamente da qualidade das detecções de base. Uma regra atômica ruidosa irá gerar falsos positivos em cascata em todas as correlações que a referenciam. Recomendamos ajustar as regras básicas de forma agressiva antes de ativar as regras de ordem superior dependentes. Finalmente, consultas ESQL sobre padrões de índice amplos (por exemplo, logs-*) podem ser caros em grande escala. Em ambientes de alto volume, restringir os padrões de indexação a conjuntos de dados específicos ou usar visualizações de dados pode reduzir significativamente o custo das consultas.
Conclusão
Regras de ordem superior são essenciais para priorizar a triagem de alertas e gerenciar volumes de alertas para automação e análise orientada por IA. Quando combinadas com a Pontuação de Risco de Entidade, as Regras de Ordem Superior podem alimentar diretamente os perfis de risco de hosts e usuários, criando uma camada de priorização quantitativa que reduz ainda mais a carga de triagem manual. Em nossos testes de produção, a maioria dessas detecções gerou um volume de alertas de médio a baixo, tornando-as práticas para uso no mundo real. Embora inicialmente possa surgir um pequeno número de regras ruidosas ou falsos positivos, excluí-los no nível das regras atômicas resulta rapidamente em um conjunto robusto de correlações de alto valor.
Para maximizar sua eficácia, duas práticas operacionais são essenciais. Primeiramente, assegure-se de que os alertas de entrada utilizem níveis de severidade que reflitam com precisão tanto o ruído quanto o impacto no mundo real; a limpeza e a normalização da severidade são fundamentais para uma correlação significativa. Em segundo lugar, comece pequeno e expanda de forma gradual: evite tentar correlacionar todos os sinais de alerta possíveis. Exclua táticas inerentemente ruidosas (como a descoberta), despriorize sinais de baixa gravidade e descontinue regras que influenciam desproporcionalmente os resultados de correlação.
Aplicadas corretamente, as regras de alta ordem agilizam as investigações, melhoram a precisão da detecção e aumentam significativamente a eficiência e a confiabilidade das operações de segurança modernas.