Microsoft Sentinel: conectores, una regla en KQL y un incidente de principio a fin

Qué vas a conseguir

Un Sentinel que recibe los registros que importan, genera incidentes que alguien atiende y no se come el presupuesto. Una regla de análisis escrita por ti, una automatización que la asigna y avisa al canal del equipo, y la rutina para investigar y cerrar un incidente con una clasificación que sirva para mejorar las reglas.

Antes de empezar

• Un área de trabajo de Log Analytics en la región que corresponda a tus datos, y el rol Microsoft Sentinel Contributor sobre ella (y Log Analytics Contributor para los conectores).
• Sentinel se usa desde el portal de Microsoft Defender (operaciones de seguridad unificadas), junto con los incidentes de Defender XDR. Las rutas de esta guía son las de ese portal.
• Una idea del presupuesto: se paga por GB ingerido. Hay orígenes gratuitos (actividad de Azure, auditoría de Office 365, alertas de Defender) y otros que no lo son (inicios de sesión de Entra ID, eventos de seguridad de Windows).
• La guía de Azure Monitor y Log Analytics explica el área de trabajo por dentro; aquí basta con saber escribir una consulta KQL sencilla.

1. Los conectores que importan

• Empieza por identidad (Entra ID) y correo y documentos (Microsoft 365): es por donde entra la mayoría de los ataques en un tenant de oficina.
• Los eventos de Windows se recogen con el agente de Azure Monitor y una regla de recopilación de datos. El conjunto Común basta para empezar; Todos los eventos multiplica el coste sin multiplicar las detecciones.
• Comprueba que llegan datos antes de escribir ninguna regla:

›SigninLogs›| where TimeGenerated > ago(1h)›| summarize Inicios = count() by ResultTypeResultType   Inicios0            1 28450126        3750074        1253003        4

ResultType 0 es un inicio correcto; el resto son códigos de error de Entra ID (50126: credenciales incorrectas; 50074: falta completar MFA; 53003: bloqueado por Conditional Access).

2. La primera regla: entra una cuenta de emergencia

Las cuentas de emergencia no se usan nunca (guía de Global Admin y PIM). Si alguien entra con una, tiene que saberse en minutos. Primero, una watchlist con sus nombres para no escribirlos dentro de la regla:

›let breakglass = _GetWatchlist("breakglass") | project UserPrincipalName;›SigninLogs›| where UserPrincipalName in~ (breakglass)›| project TimeGenerated, UserPrincipalName, IPAddress, Location, AppDisplayName, ResultType, UserAgent

• Una regla NRT se ejecuta cada minuto. Para la mayoría de reglas basta una programada cada 5 o 15 minutos; las NRT se reservan para lo que no puede esperar.
• La asignación de entidades es lo que permite después ver la cuenta y la IP como objetos en la investigación, y que Sentinel relacione este incidente con otros de la misma IP.

3. La automatización: asignar y avisar

El playbook es una aplicación lógica de Azure: recibe el incidente y publica en Teams con el enlace. Las reglas de automatización ordenan el trabajo; los playbooks hacen cosas fuera de Sentinel (avisar, deshabilitar una cuenta, abrir un ticket en Jira Service Management).

4. Un incidente de principio a fin

Lunes, 07:12. El canal de seguridad recibe: Cuenta de emergencia brk-admin-02 desde 198.51.100.23.

1. Abrir el incidente (Investigación y respuesta › Incidentes y alertas › Incidentes): ver la alerta, las entidades (cuenta e IP) y la línea temporal.
2. ¿Fue un cambio planificado? El registro de cambios dice que no hay prueba de las cuentas de emergencia programada esta semana.
3. ¿Qué hizo esa IP?

›SigninLogs›| where TimeGenerated > ago(24h) and IPAddress == "198.51.100.23"›| summarize Usuarios = dcount(UserPrincipalName), Fallos = countif(ResultType != "0"), Correctos = countif(ResultType == "0") by bin(TimeGenerated, 1h)TimeGenerated         Usuarios   Fallos   Correctos27/10/2026 05:00      143        141      027/10/2026 06:00      211        208      127/10/2026 07:00      1          0        1

Muchos usuarios distintos, casi todo fallos y un acierto: un ataque de difusión de contraseñas (password spray) que acertó con la contraseña de una cuenta de emergencia.

1. Contener: deshabilitar la cuenta, revocar sus sesiones (Revoke-MgUserSignInSession), cambiar la contraseña, bloquear la IP en una ubicación con nombre de Conditional Access y revisar en AuditLogs qué hizo la cuenta en esos minutos.
2. Clasificar y cerrar: Verdadero positivo — actividad sospechosa, con un comentario de lo que se hizo y las acciones pendientes (por qué la cuenta de emergencia podía entrar solo con contraseña).

La clasificación no es burocracia: los incidentes cerrados como Falso positivo te dicen qué reglas hay que afinar, y los Benignos (actividad sospechosa pero esperada, como una prueba planificada) qué excepciones faltan.

5. El coste

›Usage›| where TimeGenerated > ago(30d) and IsBillable == true›| summarize GB = round(sum(Quantity) / 1000, 1) by DataType›| sort by GB descDataType                          GBSecurityEvent                     412.6AADNonInteractiveUserSignInLogs   188.3SigninLogs                        41.2Syslog                            19.8

• SecurityEvent arriba del todo suele ser un conjunto de eventos demasiado amplio o un servidor ruidoso: se ajusta la regla de recopilación.
• Las tablas que solo se consultan en una investigación pueden ir al plan Basic o Auxiliary, mucho más barato, a cambio de consultas más limitadas.
• Con un volumen estable, un nivel de compromiso diario abarata el GB.

6. Lo que revisas cada mes

• Reglas que no han generado ningún incidente en 90 días (¿siguen llegando los datos que miran?) y reglas que generan tantos que nadie los lee.
• El estado de los conectores y de las reglas: la tabla SentinelHealth y la página de cada conector dicen cuándo dejaron de llegar datos.
• Tiempo medio hasta asignar y hasta cerrar los incidentes de gravedad alta.
• La factura de ingesta frente al mes anterior, por tabla.

Siguientes pasos

• Las plantillas de reglas de cada solución del Centro de contenido: se activan, se prueban y se afinan en lugar de escribirlas desde cero.
• UEBA (análisis de comportamiento de usuarios y entidades): detecta lo raro para cada usuario, no lo raro en general.
• Inteligencia de amenazas: indicadores de IP y dominios cruzados con tus registros.
• La alerta de copias borradas o inmutabilidad cambiada de la guía de DR/BCP, como segunda regla propia.

¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.