Ciberseguridad y seguridad de la información

Elastic Security: Creación de Reglas de Detección y Guía de Investigación

6 min de lecturaPublicado: 5 de agosto de 2026

Ilustración visual profesional sobre la Regla de Detección en Elastic Security en el campo de SIEM y detección

Respuesta rápida

Una buena Regla de Detección en Elastic Security comienza con el comportamiento a identificar y los datos disponibles, no con la elección de un lenguaje aleatorio. Se selecciona el tipo de regla adecuado, se validan ECS y los campos, se escribe la Query, se definen Schedule y Lookback, Risk y Severity, Suppression y Exceptions, y se adjunta una Guía de Investigación que guía al analista a través del Triage, Análisis y Respuesta.

Elastic Security incluye un motor de detección que ejecuta reglas sobre los datos de Elasticsearch y genera alertas cuando se cumplen las condiciones. Admite varios tipos de reglas, incluyendo Custom query, correlación de eventos mediante EQL, Threshold, Indicator match, New terms, ES|QL y Machine learning. Cada tipo resuelve una pregunta diferente.

Una regla que devuelve resultados no es necesariamente una detección útil. Para convertir una Query en un producto operativo, se necesita un Data contract, Schedule, Triage context, Risk, Exceptions, Owner, un proceso de prueba y una Guía de Investigación. El analista que recibe una Alerta debe entender en minutos qué se detectó, qué campos son importantes, qué es un falso positivo probable y qué buscar a continuación.

Paso 1: Defina el Caso de Uso y elija el Tipo de Regla

Comience con una frase de comportamiento: “Identificar un Proceso de cierto tipo que se ejecuta en un contexto inesperado en estaciones de usuario”. Luego, defina qué se considera una coincidencia, qué Contexto se necesita y cuál es una explicación legítima. Solo entonces elija el tipo de regla.

Pregunta	Tipo de regla adecuado	Ejemplo
Coincidencia con valores o condición booleana	Custom query	process.name y command_line
Secuencia de eventos por tiempo y entidad	EQL	Inicio de proceso seguido de conexión de red
Número de eventos supera un umbral	Threshold	Muchos fallos por user o source.ip
Agregación, cálculo o campos derivados	ES\|QL	STATS por host y luego WHERE en count
IOC contra evento	Indicator match	destination.ip contra índice de amenaza
Valor que aparece por primera vez	New terms	Proceso raro en un Host
Desviación de comportamiento sin patrón rígido	Machine learning	Anomalía por encima del Threshold

Una elección incorrecta crea una Query complicada o alertas inestables. Si el orden de los eventos es esencial, EQL es más natural que ES|QL. Si se requiere Agregación, ES|QL o Threshold son más apropiados. Custom query es buena para la coincidencia directa con campos.

Paso 2: Verifique ECS y Preparación de Datos

Elastic Common Schema — ECS — define nombres y estructuras comunes, como event.category, event.type, host.name, user.name, process.name, process.command_line y process.parent.name. Una regla que depende de campos que no están mapeados consistentemente funcionará con una Integration y fallará con otra.

Abra Sample events y compruebe: ¿event.category es process? ¿event.type incluye start? ¿process.command_line se recopila o se oculta? ¿Existe process.entity_id? ¿@timestamp es la hora del evento o la hora de ingesta? Documente los Index patterns, Integrations, Version y Required fields. La lista de Required fields en la interfaz es información para el usuario y no corrige el mapeo real.

Paso 3: Escriba una Query Enfocada

En un ejemplo de laboratorio, queremos identificar la creación de un proceso llamado lab-admin-tool.exe cuando el Padre no es el software de administración esperado. El nombre es ficticio. En Custom query se puede escribir un KQL simple:

event.category:process and event.type:start and process.name:"lab-admin-tool.exe" and not process.parent.name:"approved-manager.exe"

KQL para la detección de procesos

La Query indica una anomalía, pero no prueba la malicia. Se deben verificar Signer, Hash, Path, User, Host, Parent command line y frecuencia. Antes de crear la Regla, ejecútela en Discover o Timeline en diferentes rangos. Verifique si existen campos Null, Variantes en el nombre o Sources que no sean confiables.

Si el comportamiento requiere una secuencia —por ejemplo, un proceso seguido de una conexión de red del mismo process.entity_id—, pase a EQL. Si se desea resumir cuántos Hosts ejecutaron la herramienta o calcular Count por Parent, ES|QL puede ser apropiado.

Paso 4: Schedule y Lookback

Una regla incluye Query, Schedule y Actions. Interval determina cuántas veces se ejecuta. Lookback amplía la ventana de búsqueda para cubrir eventos que llegan tarde. Las ventanas superpuestas pueden crear Alertas duplicadas si no hay Deduplication o Suppression adecuada. Una ventana demasiado corta omite datos tardíos.

Verifique el Ingestion delay por origen. Los eventos de Endpoint pueden llegar casi en tiempo real, mientras que un origen Cloud o Batch puede retrasarse. Defina Run every y Additional look-back basándose en la medición. Después de cambiar el Pipeline o la Integration, vuelva a medir.

Paso 5: Severity, Risk y MITRE

Severity describe la gravedad de la coincidencia según el Caso de Uso; Risk score permite una calificación numérica. No use High para cada regla. Un proceso anómalo en un host de laboratorio es diferente al mismo proceso en un controlador de dominio. Se puede usar Risk score override cuando un campo confiable proporciona Contexto, pero se deben verificar Missing values y Range.

El mapeo de MITRE ATT&CK debe coincidir con el comportamiento que la Regla identifica, no con el escenario de ataque completo que usted imagina. Una Regla que detecta la ejecución de un proceso no prueba necesariamente Persistence o Exfiltration.

Paso 6: Suppression y Exceptions

Alert suppression agrupa las coincidencias recurrentes por campos para reducir el volumen. No es un sustituto de una Query correcta. La Suppression por host.name puede ocultar el desarrollo si el mismo Host produce varios Comportamientos diferentes. Elija campos que representen la unidad de investigación, por ejemplo, host.id y process.hash, y defina Window a partir de la Línea Base.

Exceptions excluyen coincidencias conocidas. Cree una Exception limitada: Hash firmado, Path, Parent específico y Grupo de Host definido, en lugar de una exclusión de process.name en toda la organización. Agregue Comment, Owner y fecha de Review. Cuando sea posible, prefiera una lista de Exception administrada en lugar de una Query con docenas de cláusulas NOT.

Paso 7: Escriba una Guía de Investigación

Una Guía de Investigación es un documento Markdown que se adjunta a la Regla y aparece junto a la Alerta. Según Elastic, una buena guía se estructura en torno a Triage, Analysis y Response, comienza con el contexto y no con una lista de comandos, y se refiere a los campos de Alerta, Timeline queries y Osquery cuando es apropiado.

Parte	Qué incluir	Ejemplo
Context	Qué detecta la regla y por qué es importante	Proceso inesperado fuera de la herramienta de gestión
Triage	Verificaciones rápidas y Falsos Positivos	Signer, Path, Parent, Host group
Analysis	Timeline y búsquedas complementarias	Network, User logons, file creation
Response	Pasos si se confirma	Escalada, aislamiento según autorización, recolección
Closure	Condiciones de Disposición	Approved software, test, compromise

Se puede hacer referencia a campos dinámicos como host.name o user.name y agregar botones de Timeline cuando la versión y la licencia lo admiten. Mantenga la guía corta y fácil de escanear. El analista trabaja bajo presión; los párrafos largos sin orden se quedarán sin leer.

Paso 8: Validación y Ajuste

Ejecute una Preview o Query histórica y marque ejemplos True, False y Benign Positive.
Pruebe la Regla en una muestra Positiva simulada y en una muestra Negativa. Asegúrese de que falla cuando falta un campo y no crea una coincidencia incorrecta.
Active primero sin una respuesta peligrosa. Mida el volumen de Alertas, los tiempos de investigación y la calidad del Contexto.
Verifique el estado de ejecución de la Regla, los gaps, los permisos y la API key. Las Reglas se ejecutan con los permisos del último usuario que las editó.
Ajuste Query, Schedule, Suppression y Exceptions por separado para saber qué solucionó el problema.
Realice una prueba de Regresión después de actualizar la Integration, el mapeo de ECS o la versión de Elastic.

Lista de Verificación

El tipo de regla es adecuado para la pregunta.
Indices, Data view, ECS y Required fields han sido verificados.
La Query devuelve una unidad de investigación clara.
Schedule y Lookback cubren el Delay sin duplicidades excesivas.
Severity, Risk y MITRE son coherentes con el comportamiento.
Suppression y Exceptions están limitadas y documentadas.
La Guía de Investigación incluye Triage, Analysis y Response.
Existen Owner, Review date, Metrics y Regression test.

Errores comunes

Elegir EQL, KQL o ES|QL por preferencia y no por la pregunta.
Copiar una Regla Prebuilt sin verificar los Data requirements.
Asumir que ECS está mapeado porque el campo aparece en algunos eventos.
Aumentar el Lookback sin entender las duplicidades.
Crear una Exception amplia en el nombre del Proceso.
Activar una Respuesta automática antes de la Validación.
Escribir una Guía de Investigación que solo contenga “Verificar si es malicioso”.

Resumen y CTA

Elija un Proceso ficticio en el laboratorio y construya una Regla completa: Data contract, Query, Schedule, Risk, una Exception, Guía de Investigación y Casos de prueba. Luego, pida a otro analista que investigue la Alerta sin una explicación verbal. Si la guía y los campos no son suficientes, mejore la Regla antes de agregar más lógica.

Preguntas frecuentes

¿Qué tipo de regla es adecuado para un solo Proceso?

Generalmente, Custom query es suficiente si se trata de una condición de campo. Si se necesita una secuencia temporal, EQL es más apropiada; si se requiere agregación, considere ES|QL o Threshold.

¿Los Required fields garantizan que los campos existen?

No. La lista es documentación para el usuario. Se debe verificar el Mapping y los Sample events reales.

¿Cuál es la diferencia entre Suppression y Exception?

Suppression agrupa las Alertas recurrentes; Exception previene la creación de una Alerta cuando se cumplen ciertas condiciones.

¿Es posible editar la Guía de Investigación de una Regla Prebuilt?

La capacidad depende de la licencia y la versión. A veces es necesario duplicar la Regla y luego editar la copia.

¿Por qué una Regla dejó de funcionar después de editarla?

Las Reglas utilizan los permisos y la API key creados para el último usuario que las editó. Un cambio realizado por un usuario sin permisos de lectura puede afectar la ejecución.