En Elastic, operamos un conjunto amplio y diverso de reglas de detección de comportamiento en múltiples conjuntos de datos, entornos y niveles de gravedad. La mayoría de estas reglas son atómicas, cada una diseñada para detectar un comportamiento, señal o patrón de ataque específico. Además, recibimos y promovemos alertas externas procedentes de integraciones de seguridad como firewall, EDR, WAF y otros controles de seguridad.
El resultado es una visibilidad poderosa pero también un volumen de alertas significativo. Desde nuestra telemetría, incluso considerando solo las Reglas no Bloques de Construcción, 65 reglas de detección únicas generan casi 8000 alertas al día por clúster de producción. Analizar cada alerta de forma aislada no es ni escalable ni rentable.
Aquí es donde entran en juego las Reglas de Orden Superior .
Las reglas de orden superior no detectan un solo comportamiento. En su lugar, correlacionan alertas relacionadas a lo largo del tiempo, entre fuentes de datos o dentro de un contexto compartido (como anfitrión, usuario, IP o proceso). Agrupando las señales en patrones significativos, podemos priorizar lo que realmente importa y reducir la necesidad de análisis profundos y costosos de cada alerta individual, ya sea realizada manualmente, automatizada o aumentada por IA.
En este blog, repasaremos nuestro enfoque para construir Reglas de Orden Superior en Elastic, compartiremos ejemplos prácticos y destacaremos las lecciones clave aprendidas a lo largo del camino.
¿Cuáles son las reglas de orden superior?
Las Reglas de Orden Superior (HOR) son detecciones que emplean alertas como entrada, ya sea correlacionando alertas con otras alertas (alerta en alerta) o combinando alertas con datos adicionales como eventos en bruto, métricas o telemetría contextual.
A diferencia de las reglas atómicas que detectan un solo comportamiento, las Reglas de Orden Superior identifican patrones entre señales. Su propósito no es sustituir las detecciones base, sino elevar combinaciones de hallazgos que tienen más probabilidades de representar actividad real de ataques. En la práctica, ponen a la luz hallazgos de mayor confianza y mejoran la priorización del triaje. Las reglas de orden superior están diseñadas para funcionar junto con las Reglas de Bloques de Construcción. Las reglas de bloques de construcción generan alertas que no aparecen en la vista predeterminada de alertas, reduciendo el ruido mientras alimentan las detecciones correlacionadas. Muchas de las reglas base referenciadas en este artículo también pueden configurar como reglas de bloques de construcción, de modo que solo aparezcan correlaciones de orden superior para la revisión por parte de los analistas.
La idea central es que las detecciones independientes que convergen en la misma entidad compoñen la confianza, donde cada señal adicional multiplica la probabilidad de que la actividad sea real, no benigna. Estos tres principios de diseño operacionalizan esa idea:
1. Correlación basada en entidades
Las reglas correlacionan la actividad entre entidades compartidas como anfitrión, usuario, IP de origen, IP de destino o proceso, permitiendo a los analistas ver rápidamente cuando múltiples hallazgos convergen en el mismo activo o identidad.
2. Visibilidad entre fuentes de datos
Algunas reglas funcionan dentro de una única integración (por ejemplo, detecciones solo de endpoint de Elastic Defend o EDR de terceros). Otros combinan intencionadamente señales entre dominios: endpoint con red (PANW, FortiGate, Suricata), endpoint con email o endpoint con métricas del sistema para capturar actividad multietapa o transversal.
3. Conciencia sobre el tiempo y la prevalencia
La lógica temporal juega un papel clave.
Las reglas recién observadas destacan la primera aparición de una alerta dada dentro de una ventana de revisión definida (por ejemplo, cinco días), cerciorando que incluso una única alerta rara se muestre para su revisión.
La lógica basada en prevalencias (como el uso de INLINE STATS) filtra alertas que ocurren solo en un pequeño número de hosts a nivel global, ayudando a reducir el ruido y a enfatizar comportamientos anómalos.
El conjunto completo de Reglas de Orden Superior abarca correlaciones solo de endpoint, detecciones multidominio (endpoint + red, endpoint + email), patrones de movimiento lateral (por ejemplo, alert_1 host.ip = alert_2 source.ip), agrupaciones alineadas con ATT&CK (actividad de una o múltiples tácticas), alertas recién observadas y correlación alerta-evento (como alertas combinadas con métricas anómalas de CPU). Las siguientes secciones repasan ejemplos representativos de estas categorías.
Correlación y reglas de orden superior recién observadas
En la práctica, la actividad de alto riesgo no siempre es igual.
A veces el compromiso se manifiesta a través de múltiples señales convergentes. Otras veces, aparece como una sola alerta que nunca se vio antes.
Para manejar ambas realidades, organizamos nuestras Reglas de Orden Superior en tres patrones complementarios:
- Reglas de correlación múltiples alertas o eventos vinculados a una entidad compartida (anfitrión, usuario, IP o proceso).
- Reglas de recién observadas son una única alerta que es rara o que se ve por primera vez dentro de una ventana de tiempo definida.
- Patrones híbridos que combinan correlación con lógica de primera vista, lo que puede aumentar aún más la sospecha y sacar a la luz actividades especialmente interesantes.
Las reglas de correlación aumentan la confianza mediante la densidad y diversidad de señales: cuando varias detecciones independientes apuntan a la misma entidad, aumenta la probabilidad de actividad maliciosa real.
Las reglas recién observadas abordan el caso opuesto: bajo volumen pero alta novedad. Priorizan las alertas según la rareza a lo largo del tiempo, cerciorando que las detecciones primerizas o muy inusuales no pasen por alto simplemente por ocurrir una vez.
En conjunto, estos enfoques forman la base de una estrategia de triaje eficiente y escalable.
Vamos a profundizar en ejemplos y explorar las diferencias, fortalezas y compensaciones de cada patrón.
Correlación de alertas de endpoint
Una parte significativa del descubrimiento de ataques en el mundo real proviene de la telemetría de punto final. Proporciona una actividad de procesos en contexto enriquecido, líneas de comandos, comportamiento de archivos y acciones del usuario, convirtiéndolo en una de las fuentes de detección más poderosas.
Al mismo tiempo, los entornos de endpoint son dinámicos. El software legítimo, las herramientas de administración y las aplicaciones de terceros (y recientemente las utilidades 🥲 de endpoint GenAI) pueden generar un alto volumen de alertas y falsos positivos, requiriendo un ajuste continuo.
La correlación de orden superior ayuda a abordar esto desplazando el enfoque de alertas individuales a múltiples señales distintas en el mismo anfitrión o proceso , aumentando la confianza y reduciendo el esfuerzo de investigación innecesario.
El siguiente ES|La consulta QL se activa cuando hay 3 reglas de comportamiento únicas de Elastic Defend O alertas de diferentes características (por ejemplo, un shellcode_thread con comportamiento, malicious_file con comportamiento) O más de 2 alertas de malware en una ventana de tiempo de 24 horas desde el mismo 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 aún más las sospechas, también podemos correlacionar alertas de Elastic Defend que pertenecen al mismo árbol de procesos:
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.idEjemplo de partidas:
Para complementar nuestra cobertura, también tendremos que buscar casos atómicos raros. El siguiente ES|QL está diseñado para funcionar con un horario de 10 minutos con una ventana de revisión de 5 o 7 días. La revisión agrega todas las alertas por nombre de la regla a lo largo de toda la ventana para calcular el tiempo de primera visualización. El filtro final (Esql.recent <= 10) cerciora que solo se activen reglas cuyo primer tiempo visto se encuentre dentro de la ventana actual de ejecución de 10 minutos, detectando efectivamente el momento en que una regla se activa por primera vez en el periodo de retroceso. Esto pone a la luz tanto falsos positivos raros como comportamientos sigilosos que de otro modo podrían perder en volumen:
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.*La misma lógica puede aplicar a una Alerta Externa de otros EDRs de terceros:
Correlación entre el punto final y las alertas de red
Un enfoque poderoso de detección es correlacionar las alertas de endpoint con las alertas de red. Esto ayuda a responder la pregunta clave:
¿Qué proceso activó esta alerta de red?
Las alertas de red por sí solas suelen carecer de contexto de proceso, como qué usuario o ejecutable inició la actividad. Combinando alertas de red con telemetría de endpoint (datos EDR), puedes enriquecer las alertas con:
- Nombre del proceso y hash
- Línea de comandos y proceso padre
- Información del usuario y del dispositivo
La siguiente consulta correlaciona cualquier alerta de Elastic Defend con eventos sospechosos procedentes de dispositivos de seguridad de red como Palo Alto Networks (PANW) y Fortinet FortiGate. La clave de unión es la dirección IP: para alertas de red, esto es source.ip, para alertas de endpoint, es host.ip. La consulta normaliza estos en un solo campo usando COALESCE, permitiendo correlación entre fuentes de datos que usan diferentes nombres de campo para la misma entidad. Esto puede indicar que este host está comprometido y está activando alertas multifuente de datos.
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*"Ejemplo de coincidencias que correlacionan alertas Elastic Defend y Fortigate donde el source.ip de la alerta FortiGate es igual al host.ip de la alerta endpoint de Elastic Defend:
La siguiente consulta EQL correlaciona las alertas Suricata con los eventos de red de Elastic Defend para proporcionar contexto sobre el proceso fuente y el host:
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")]Ejemplo de coincidencias que confirman la alerta Suricata y la vinculan al proceso del servidor sitio web objetivo nginx de eventos de Elastic Defend que confirman el intento de explotación sitio web:
Seguridad en endpoints con observabilidad
Correlacionar la telemetría de observabilidad con alertas de seguridad es una estrategia de detección poderosa.
El incidente de la puerta trasera de XZ Utils demostró que las anomalías relevantes para la seguridad pueden surgir primero como regresiones de rendimiento en lugar de alertas de seguridad tradicionales. En ese caso, un comportamiento inusual en el daemon SSH llevó a una investigación más profunda y al eventual descubrimiento de código malicioso.
Esto pone de relieve un principio importante: las anomalías operativas pueden ser indicadores tempranos de compromiso.
Con el Agente Elástico, métricas del sistema como la utilización de CPU y memoria pueden recopilar junto con la telemetría de seguridad. Correlacionando picos anormales de recursos con alertas SIEM, ya sea por proceso o por anfitrión, podemos aumentar la confianza en la detección y detectar actividades de alto riesgo antes.
Por ejemplo, un ES|La regla de correlación QL puede identificar un proceso que exhibe una utilización sostenida del 70% de la CPU y que también es la fuente de una alerta de firma de memoria para un criptominero de Elastic Defend. Cada señal puede ser de baja o media severidad individualmente. Correlacionados entre sí, representan actividades maliciosas de alta confianza.
Desarrollamos más de 30 detecciones de orden superior que cubren diversos tipos de relaciones. Aunque no podemos cubrirlas todas aquí, los enlaces que aparecen a continuación proporcionan suficiente contexto para adaptar estas normas a tu entorno:
Alertas de endpoint:
Múltiples alertas de Elastic Defend por Agente
Múltiples alertas de defensa elástica desde un solo árbol de procesos
Múltiples reglas raras de comportamiento de defensa elástica por anfitrión
Alerta de comportamiento de defensa elástica recién observada
Múltiples alertas externas de EDR por anfitrión
Punto final y red:
Alerta de Red de Palo Alto recientemente observada
Alerta Suricata de Alta Severidad Recientemente Observada
Tráfico de FortiGate SOCKS de un proceso inusual
PANW y Elastic Defend - Correlación de Mando y Control
Correlación con Elastic Defend y Alertas de Seguridad de Red
Correlación entre Suricata y Elastic Defend Network
Genérico por MITRE ATT&CK:
Alertas en diferentes tácticas ATT&CK por anfitrión
Múltiples alertas en la misma táctica ATT&CK por anfitrión
Correlación genérica de multiintegraciones:
Alertas de múltiples integraciones por dirección de origen
Alertas de múltiples integraciones por dirección de destino
Alertas de múltiples integraciones por nombre de usuario
Alerta de detección de alta severidad recién observada
Correlación del movimiento lateral:
Movimiento lateral sospechoso de un huésped comprometido
Alertas de movimiento lateral desde una dirección de origen recién observada
Alertas de movimiento lateral de un usuario recién observado
Correlación entre observabilidad y seguridad:
Alerta de detección en un proceso que presenta picos de CPU
Múltiples alertas en un host que muestra picos de CPU
Proceso recién observado que presenta un alto uso de CPU
Correlación con el aprendizaje automático:
Múltiples alertas de aprendizaje automático por campo de influencers
Otras ideas de correlación:
Múltiples vulnerabilidades por activo vía Wiz
Correlación con Elastic Defend y alertas por email
Solicitud sospechosa de tiquete de autenticación de Kerberos
Múltiples secretos de la nube accedidos por dirección de origen
Estos ejemplos ilustran cómo correlacionar alertas entre endpoints, red y observabilidad puede enriquecer el contexto, acelerar investigaciones y mejorar la confianza en la detección. Estamos ampliando activamente la cobertura en esta área para apoyar escenarios adicionales de correlación.
Puedes activarlas filtrando por el valor de etiqueta Tipo de Regla: Regla de orden superior en la página de gestión de reglas:
Durante un periodo de 15 días, los recuentos de alertas se mantuvieron dentro del volumen aceptable (~30 alertas/día). Se espera que la optimización dirigida de los valores atípicos iniciales los reduzca a ~20 alertas al día y mejore sustancialmente la calidad general de la señal.
Consideraciones y compensaciones
Las reglas de orden superior introducen la latencia potencial de planeación. Como consultan índices de alerta, existe un retraso inherente entre el momento en que se activan las alertas base y cuando surgen correlaciones. Los intervalos de programación de reglas y las ventanas de loopback deberían ajustar para equilibrar la puntualidad con el costo de rendimiento. Además, la calidad del HOR depende directamente de la calidad de las detecciones base. Una regla atómica ruidosa generará falsos positivos en cada correlación que la mencione. Recomendamos ajustar las reglas base de forma agresiva antes de activar las Reglas de Orden Superior dependientes. Finalmente, consultas ESQL sobre patrones de índice amplios (por ejemplo, logs-*) puede ser costoso a gran escala. En entornos de alto volumen, definir patrones de índice para conjuntos de datos específicos o emplear vistas de datos puede reducir significativamente el costo de consulta.
Conclusión
Las reglas de alto nivel son esenciales para priorizar el triaje de alertas y gestionar volúmenes de alertas para la automatización y el análisis impulsado por IA. Cuando se combinan con el Puntaje de Riesgo de Entidad, las Reglas de Orden Superior pueden alimentar directamente en los perfiles de riesgo de anfitrión y usuario, creando una capa cuantitativa de priorización que reduce aún más la carga de triaje manual. En nuestras pruebas de producción, la mayoría de estas detecciones produjeron un volumen de alerta medio a bajo, lo que las hacía prácticas para uso real. Aunque inicialmente pueden surgir un pequeño número de reglas ruidosas o falsos positivos, excluirlas a nivel de regla atómica deja rápidamente un conjunto robusto de correlaciones de alto valor.
Para maximizar su efectividad, dos prácticas operativas son fundamentales. Primero, cerciórate de que las alertas de entrada empleen niveles de gravedad que reflejen con precisión tanto el ruido como el impacto real; limpiar y normalizar la gravedad es fundamental para una correlación significativa. Segundo, empieza poco a poco y amplía deliberadamente: evita intentar correlacionar todas las posibles señales de alerta. Excluye tácticas inherentemente ruidosas (como el descubrimiento), desprioriza las señales de baja severidad y desestima las reglas que influyen desproporcionadamente en los resultados de correlación.
Si se aplican correctamente, las reglas de alto nivel agilizan las investigaciones, mejoran la precisión de la detección y aumentan significativamente la eficiencia y fiabilidad de las operaciones de seguridad modernas.