Ciberseguridad y seguridad de la información

¿Cómo se escribe una regla de análisis en Microsoft Sentinel?

7 min de lecturaPublicado: 5 de agosto de 2026

Ilustración visual profesional sobre la regla de análisis en Microsoft Sentinel en el ámbito de SIEM y detección

Respuesta rápida

Una buena regla de análisis en Microsoft Sentinel comienza con el comportamiento que se desea detectar y las fuentes que pueden probarlo. Luego se escribe KQL que devuelve una unidad de investigación clara, se define la frecuencia y el período de búsqueda, se mapean las entidades, se determina la severidad y MITRE, se elige el agrupamiento y se realizan pruebas y ajustes. El objetivo de la regla no es generar muchas alertas, sino crear incidentes que puedan entenderse, verificarse y sobre los que se pueda actuar.

Es fácil escribir una consulta que devuelva filas. Es más difícil convertirla en una detección estable. Una regla de análisis se ejecuta durante un tiempo en datos cambiantes, genera alertas, afecta la carga de trabajo de los analistas y, a veces, activa la automatización. Un error en la definición de la ventana de tiempo, la entidad o el umbral puede crear duplicidades, omisiones o una respuesta incorrecta.

Microsoft Sentinel admite varios tipos de reglas de análisis. Las reglas programadas son las más comunes y se basan en KQL que se ejecuta en intervalos y examina un período de búsqueda. También existen las NRT (Near Real-Time) y plantillas o detecciones incorporadas según la plataforma. La guía se centra en las reglas de consulta programadas, ya que permite comprender todos los componentes de la planificación.

El ejemplo es un Password Spray en un entorno de laboratorio. No está diseñado para monitorear personas sin autorización, y los umbrales no son una recomendación universal. Deben calibrarse contra la línea base, la arquitectura de identidad y el VPN/Proxy de la organización.

Paso 1: Escriba la especificación de detección antes de KQL

Un caso de uso debe responder preguntas claras: ¿Qué comportamiento detectaremos? ¿Por qué es peligroso? ¿Qué fuentes de datos son necesarias? ¿Cuál es la actividad benigna esperada? ¿Quién es el propietario? ¿Qué hará el analista cuando se active la regla? ¿A qué técnica MITRE está relacionada?

Componente	Ejemplo de Password Spray
Hipótesis	Una dirección de origen intenta fallar contra muchos usuarios para encontrar una contraseña válida
Fuente	Registros de inicio de sesión con hora, usuario, IP y resultado
Unidad de resultado	IP y ventana de tiempo con número de intentos y usuarios
Excepciones esperadas	VPN, pruebas de Red Team, servicio antiguo o proveedor de identidad
Acción del analista	Verificar usuarios, éxitos, MFA, reputación y actividad de seguimiento
Propietario y revisión	Ingeniero de detección; revisión mensual o después de un cambio de fuente

Defina también los límites. La regla no prueba una vulneración de cuenta. Identifica un patrón que requiere investigación. Si hay un éxito, puede elevar la prioridad, pero aún es necesario verificar la secuencia y el contexto.

Paso 2: Asegure la preparación de los datos

Abra la tabla y examine los eventos de muestra. ¿ResultType es un número o una cadena? ¿IPAddress está vacío en algunos eventos? ¿Los Service principals aparecen junto a los usuarios? ¿Cuál es el retraso de ingesta? ¿Existen Tenant o Application que requieran exclusión?

Una regla que se basa en un campo inestable se romperá. Documente el esquema, el conector, la normalización y la consulta de estado de los datos. Si la fuente deja de enviar, un panel debe alertar; “No hay alertas” no es necesariamente una situación segura.

Paso 3: Escriba una consulta que devuelva evidencia útil

Una consulta básica para Password Spray en un laboratorio puede agrupar fallos por IP y ventana de tiempo y requerir un número de usuarios únicos:

let Lookback = 15m;
let MinimumAttempts = 20;
let MinimumUsers = 5;
SigninLogs
| where TimeGenerated > ago(Lookback)
| where tostring(ResultType) != "0"
| summarize Attempts=count(),
            Users=dcount(UserPrincipalName),
            UserList=make_set(UserPrincipalName, 20),
            FirstSeen=min(TimeGenerated),
            LastSeen=max(TimeGenerated)
  by IPAddress, bin(TimeGenerated, 5m)
| where Attempts >= MinimumAttempts and Users >= MinimumUsers
| project TimeGenerated, IPAddress, Attempts, Users, UserList, FirstSeen, LastSeen

El resultado debe contener los campos que el analista necesita y los campos que se mapearán a las entidades. En este caso, IPAddress es una entidad central, y UserList es el contexto. Una lista dinámica de usuarios no es necesariamente adecuada para mapear una única cuenta, por lo que se puede crear una alerta por IP y agregar detalles personalizados, o cambiar la estructura del resultado según el flujo de trabajo.

Pruebe la consulta en varios rangos: una hora, un día y una semana. Etiquete manualmente Positivos Verdaderos, Falsos y Benignos. Vea si detecta actividad de VPN o comprobaciones de salud. No ajuste el umbral solo para llegar a cero alertas.

Paso 4: Frecuencia y período de búsqueda

La frecuencia de la consulta determina con qué frecuencia se ejecuta la regla. El período de consulta o Lookback determina cuánto tiempo hacia atrás se examina. Si una regla se ejecuta cada cinco minutos y examina 15 minutos, el mismo patrón puede aparecer en varias ejecuciones. Los mecanismos de agrupación de eventos, agrupación de alertas o supresión pueden reducir las duplicidades, pero es necesario comprender el impacto.

El Lookback debe ser lo suficientemente largo como para cubrir el retraso de la ingesta y detectar el comportamiento, pero no demasiado amplio. Un Password Spray lento puede requerir una ventana más grande o una línea base diferente. Una regla demasiado rápida puede generar ruido; una regla demasiado lenta aumenta el tiempo de detección.

Configuración	Pregunta profesional
Ejecutar cada	¿Qué tan rápido se necesita detectar y cuánto cuesta ejecutar?
Buscar datos de los últimos	¿Cuál es la duración del comportamiento y el retraso de los datos?
Umbral	¿Cuántos resultados constituyen una alerta?
Comenzar a ejecutar	¿Se requiere tiempo para los primeros datos?
Supresión	¿La supresión temporal ocultará un cambio real?

Paso 5: Gravedad, MITRE y detalles de la alerta

La gravedad debe reflejar el riesgo cuando se cumple la condición, no el resultado final de la investigación. Un Password Spray sin éxito puede ser Medio, pero un intento contra cuentas privilegiadas o un éxito después de los fallos puede justificar una clasificación diferente. Se puede usar la anulación de detalles de alerta para mostrar IP, usuario o conteo en el título dinámicamente, manteniendo un título legible.

El mapeo de MITRE ATT&CK ayuda a explicar el comportamiento del atacante y a construir un mapa de cobertura. Elija las tácticas y técnicas que se ajusten a la lógica real. No mapee una lista larga solo para parecer exhaustivo.

Los detalles personalizados deben mostrar un contexto que acorte el triaje: Intentos, Usuarios, Primera vista, Última vista, Aplicación o Tenant. Evite transferir información sensible que no sea necesaria.

Paso 6: Mapeo de entidades

El mapeo de entidades permite a Sentinel identificar IP, cuenta, host, URL y más. Una entidad de calidad permite la investigación, el enriquecimiento, UEBA y el enlace a otros incidentes. Asegúrese de que el campo en la salida sea escalar y en el formato apropiado.

En el ejemplo, se mapea IP.Address a IPAddress. Si la regla devuelve un único UserPrincipalName por fila, se puede mapear Account.FullName o AadUserId según el esquema. Cuando una consulta resume muchos usuarios en una lista, no fuerce un mapeo que no represente una única entidad.

Paso 7: Agrupación de eventos y agrupación de alertas

La agrupación de eventos determina si cada fila de la consulta se convierte en una alerta separada o si todos los resultados se agrupan. Si cada IP es un caso separado, una fila por cada IP y una alerta por cada resultado pueden tener sentido. Si todo se agrupa en una sola alerta, un analista puede recibir un incidente enorme con IPs no relacionadas.

La agrupación de alertas puede adjuntar alertas a un incidente según entidades o detalles. Defina una ventana e identifique una conexión real. Una agrupación demasiado agresiva oculta el desarrollo y mezcla alcances; una agrupación demasiado débil crea un incidente por cada ejecución.

Paso 8: Automatización y tareas

En la primera etapa, la automatización puede asignar un propietario, agregar etiquetas, crear tareas, enriquecer IP o enviar notificaciones. Las acciones de contención automáticas requieren alta confianza, excepciones, aprobación y capacidad de reversión. Una nueva detección generalmente necesita un período de monitoreo antes de una respuesta automática significativa.

Adjunte tareas que guíen al analista: verifique éxitos desde la misma IP, verifique MFA, verifique la reputación, busque actividad de seguimiento y contacte al propietario de la cuenta. De esta manera, la regla genera un proceso y no solo una alerta.

Pruebas y ajuste

Ejecute la consulta manualmente en datos históricos y marque los resultados.
Realice pruebas unitarias con eventos simulados que representen casos positivos y negativos.
Active la regla en modo de monitoreo sin automatización peligrosa.
Mida el volumen, los positivos verdaderos/falsos/benignos, el tiempo de triaje y la calidad del contexto.
Cambie el umbral, las exclusiones o la agrupación con la documentación de la razón.
Realice una prueba de regresión después de cambiar el analizador, el conector o la consulta.
Establezca una fecha de revisión y un propietario; una regla sin mantenimiento se convierte en una deuda de detección.

Lista de verificación antes de la implementación

Caso de uso e hipótesis documentados.
Fuente de datos, esquema y retraso verificados.
La consulta devuelve una unidad de investigación clara.
Frecuencia y período de búsqueda cubren el comportamiento sin duplicidades inusuales.
Gravedad y MITRE coherentes con la lógica.
Entidades y detalles personalizados correctos.
Agrupación probada con varios resultados.
Playbook, propietario y fecha de revisión existentes.
Privacidad, costo y permisos verificados.
Rollback existente para cambios y automatización.

Errores comunes

Comenzar con una consulta encontrada en Internet sin un caso de uso local.
Mapear una entidad desde una lista o desde un campo que no es estable.
Usar un período de búsqueda superpuesto sin comprender las duplicidades.
Definir una gravedad alta para cada regla.
Excluir una IP o un usuario permanentemente sin una fecha de caducidad.
Agregar supresión que oculta la escalada de actividad.
Activar el bloqueo automático antes del período de ajuste.
No verificar el estado de los datos y los cambios de esquema.

Resumen y llamada a la acción

Elija un caso de uso en el laboratorio y escriba una especificación de detección de una página antes de KQL. Luego construya la regla, ejecútela con datos simulados y documente tres resultados: Positivo Verdadero, Falso y Benigno. La mejora más importante no es otra condición en la consulta, sino un incidente que el próximo analista pueda investigar de manera rápida y consistente.

Preguntas frecuentes

¿Cuál es la diferencia entre una regla programada y una regla NRT?

Una regla programada ejecuta KQL en intervalos y examina un período de búsqueda. NRT está diseñada para la detección casi en tiempo real con diferentes limitaciones y configuraciones. La elección depende del caso de uso y del soporte de la plataforma.

¿Cómo se elige un umbral?

Se comienza con el comportamiento y el riesgo, se examina la línea base histórica y se marcan los resultados. El umbral es un punto de partida para la calibración, no un número universal.

¿Cada fila de la consulta debe ser una alerta?

No necesariamente. La agrupación de eventos debe coincidir con la unidad de investigación. A veces, cada IP o host es una alerta separada; a veces, es apropiado agruparlos.

¿Por qué es importante el mapeo de entidades?

Las entidades permiten el contexto, la investigación, la vinculación entre alertas y el enriquecimiento. Una regla sin entidades puede ser más difícil de investigar.

¿Cuándo se activa una respuesta automática?

Cuando la confianza, el impacto y las excepciones se comprenden, existe una aprobación organizacional y un rollback, y la regla ha pasado pruebas y ajustes suficientes.