Microsoft Sentinel y KQL: SIEM en la nube y analytics rules

Cuando una organización migra su infraestructura a la nube, la superficie de ataque cambia por completo. Ya no basta con un SIEM tradicional que recoja logs de firewalls y servidores locales: los eventos ahora vienen de Azure Active Directory (Entra ID), Microsoft 365, suscripciones de Azure, máquinas virtuales, contenedores y decenas de servicios SaaS. Microsoft Sentinel nació para cubrir esa necesidad: es un SIEM (Security Information and Event Management) y SOAR (Security Orchestration, Automation and Response) cloud-native que corre sobre Azure y que permite ingestar, correlacionar, detectar y responder a amenazas a escala de nube sin gestionar infraestructura propia.

Esta lección explica cómo funciona Sentinel de extremo a extremo: desde la ingesta de datos con conectores, pasando por el lenguaje de consulta KQL (Kusto Query Language) que es el corazón de toda detección, hasta la creación de analytics rules, la gestión de incidentes y la automatización de respuestas con playbooks. Es la cuarta lección de la Tanda 9, dedicada a seguridad en entornos cloud-native e infraestructura como código.

Trabaja solo en entornos de laboratorio o suscripciones Azure de prueba. Acceder a logs de un tenant corporativo sin autorización es una violación de la política de seguridad y puede tener consecuencias legales.

Qué es Microsoft Sentinel#

Microsoft Sentinel (antes Azure Sentinel) es una solución SIEM+SOAR que Microsoft lanzó en 2019 como servicio gestionado dentro de Azure. A diferencia de un SIEM tradicional como Splunk o QRadar, donde tienes que dimensionar hardware, gestionar licencias por EPS (eventos por segundo) y mantener la infraestructura, Sentinel escala automáticamente y cobra por volumen de datos ingestados (GB/día).

La arquitectura tiene cinco capas principales:

• Data connectors: conectores predefinidos y personalizados que traen logs al workspace.
• Log Analytics workspace: el almacén central donde se guardan todos los eventos en tablas estructuradas.
• Analytics rules: reglas que ejecutan queries KQL periódicamente y generan alertas cuando se cumple una condición.
• Incidents: agrupan alertas correlacionadas, asignan severidad y permiten investigación.
• Playbooks: flujos de automatización basados en Azure Logic Apps que ejecutan acciones de respuesta.

Sentinel no es solo un visor de logs: integra threat intelligence, mapeo MITRE ATT&CK, hunting proactivo y machine learning (Fusion) para correlación avanzada.

Por qué ocurre: la causa raíz#

Los ataques en entornos cloud pasan desapercibidos cuando no hay un SIEM configurado correctamente. Las causas raíz más frecuentes de fallos en la detección son:

• Conectores sin habilitar: Sentinel no ve lo que no recibe. Si nadie habilitó el conector de Azure AD Sign-in Logs, los brute force pasan invisibles.
• Queries genéricas o inexistentes: reglas de detección demasiado amplias generan fatiga de alertas; demasiado estrechas dejan huecos.
• Falta de correlación: un login fallido aislado no dice nada; 500 login fallidos desde la misma IP seguidos de un login exitoso sí.
• Sin automatización: si cada alerta requiere intervención manual, el SOC se satura y las alertas críticas se pierden entre las informativas.

Un ejemplo concreto: una organización con Azure AD Premium P2 tiene todos los sign-in logs disponibles, pero si nadie creó una analytics rule que detecte un patrón de impossible travel (login desde Madrid y cinco minutos después desde Tokio), el ataque pasa desapercibido aunque los datos estén ahí.

// Ejemplo: detectar impossible travel (simplificado)
SigninLogs
| where ResultType == 0
| summarize Locations = make_set(Location), Count = count() by UserPrincipalName, bin(TimeGenerated, 10m)
| where array_length(Locations) > 1

Tipos de analytics rules#

Sentinel ofrece cuatro tipos de reglas de detección:

Las reglas Scheduled son las que más escribirás como analista: defines una query KQL, un intervalo de ejecución (por ejemplo cada 5 minutos), un período de lookback (por ejemplo las últimas 6 horas de datos), un umbral de resultados y el mapeo de entidades (IP, cuenta, host) que Sentinel usará para agrupar alertas en incidentes.

Las reglas NRT tienen una restricción importante: no soportan joins ni operadores que requieran lookback amplio, porque deben ejecutarse en menos de un minuto.

Fundamentos de KQL#

KQL (Kusto Query Language) es el lenguaje de consulta de Azure Data Explorer, Log Analytics y Sentinel. Si vienes de SQL, la lógica es similar pero la sintaxis es diferente: KQL usa pipes (|) para encadenar operadores, como Bash.

Los operadores esenciales:

// where: filtrar filas
SecurityEvent
| where EventID == 4625
| where TimeGenerated > ago(1h)

// project: seleccionar columnas
SigninLogs
| project TimeGenerated, UserPrincipalName, IPAddress, ResultType

// summarize: agregar datos
SecurityEvent
| where EventID == 4625
| summarize FailedLogins = count() by TargetAccount, IpAddress
| where FailedLogins > 20

// extend: crear columnas calculadas
SigninLogs
| extend City = tostring(LocationDetails.city)

// join: cruzar tablas
let failed = SecurityEvent | where EventID == 4625 | summarize FailCount = count() by TargetAccount;
let success = SecurityEvent | where EventID == 4624 | summarize SuccessCount = count() by TargetAccount;
failed | join kind=inner success on TargetAccount
| where FailCount > 10

// render: visualizar resultados
SecurityEvent
| where EventID == 4625
| summarize count() by bin(TimeGenerated, 1h)
| render timechart

Cada tabla en Log Analytics corresponde a un tipo de datos: SigninLogs para logins de Azure AD, SecurityEvent para eventos Windows, Syslog para Linux/dispositivos, AzureActivity para operaciones en suscripciones Azure, CommonSecurityLog para CEF (Common Event Format).

Dónde aparece Sentinel#

Sentinel se usa en cualquier organización que tenga presencia en Azure o Microsoft 365:

• SOC corporativos: monitorización centralizada de identidades, endpoints, email y cloud.
• MSSPs (Managed Security Service Providers): gestionan múltiples tenants de clientes desde un Sentinel multi-workspace.
• Compliance: retención de logs para auditorías (GDPR, PCI-DSS, SOC 2).
• Hunting teams: analistas que buscan proactivamente indicadores de compromiso con queries KQL.
• Respuesta a incidentes: reconstrucción de timelines de ataque cruzando datos de múltiples fuentes.

En la práctica, cualquier organización con más de 50 usuarios en Microsoft 365 debería plantearse Sentinel como SIEM principal, porque los conectores nativos de Microsoft eliminan la complejidad de integración que existe con SIEMs third-party.

Cómo se detecta un ataque con Sentinel#

La detección sigue un flujo: datos ingestados, query KQL que filtra el patrón sospechoso, evaluación de umbral, generación de alerta, agrupación en incidente.

Escenarios comunes de detección:

Ejemplo completo: brute force seguido de login exitoso#

let threshold = 20;
let timeframe = 1h;
let failed = SigninLogs
| where TimeGenerated > ago(timeframe)
| where ResultType != 0
| summarize FailCount = count(), FirstFail = min(TimeGenerated), LastFail = max(TimeGenerated)
    by IPAddress, UserPrincipalName;
let success = SigninLogs
| where TimeGenerated > ago(timeframe)
| where ResultType == 0
| project SuccessTime = TimeGenerated, IPAddress, UserPrincipalName;
failed
| where FailCount > threshold
| join kind=inner success on IPAddress, UserPrincipalName
| where SuccessTime > LastFail
| project UserPrincipalName, IPAddress, FailCount, FirstFail, LastFail, SuccessTime

Esta query detecta cuentas que recibieron mas de 20 intentos fallidos seguidos de un login exitoso desde la misma IP. Es uno de los patrones mas frecuentes en SOCs reales.

Automatización con playbooks#

Los playbooks de Sentinel son flujos de Azure Logic Apps que se disparan cuando se crea un incidente o una alerta. Permiten automatizar acciones repetitivas:

• Bloquear una IP en el firewall (Azure Firewall, NSG, Palo Alto).
• Deshabilitar una cuenta comprometida en Azure AD.
• Enviar notificación a Slack, Teams o email.
• Crear ticket en ServiceNow, Jira o PagerDuty.
• Enriquecer la alerta con threat intelligence (VirusTotal, AbuseIPDB).
• Aislar un endpoint con Defender for Endpoint.

Un playbook típico de respuesta a brute force exitoso:

Trigger: Sentinel Incident Created (severity >= Medium)
  → Parse incident entities (extract Account, IP)
  → Lookup IP in VirusTotal
  → If malicious:
      → Disable user account in Azure AD
      → Block IP in NSG
      → Post message to SOC Teams channel
      → Add comment to incident
  → If benign:
      → Add comment "IP clean, manual review"

La combinación de analytics rules bien escritas con playbooks de respuesta automática es lo que convierte a Sentinel de un visor de logs pasivo en una plataforma de defensa activa.

Hunting y threat intelligence#

Además de las reglas de detección reactivas, Sentinel permite hunting proactivo: el analista escribe queries KQL exploratorias buscando indicadores de compromiso que las reglas automáticas no cubren.

Funcionalidades de hunting:

• Hunting queries: biblioteca de queries predefinidas organizadas por técnica MITRE ATT&CK, mas queries custom.
• Bookmarks: cuando encuentras algo sospechoso durante hunting, lo marcas como bookmark para investigar después o escalar a incidente.
• Livestream: ejecuta una query de hunting en tiempo real y te notifica cuando aparece un resultado.
• Notebooks (Jupyter): para investigaciones complejas que requieren Python, visualización avanzada o integración con APIs externas.

Sentinel también integra threat intelligence nativa: puedes importar feeds de IoCs (Indicators of Compromise) desde STIX/TAXII, archivos CSV o la API de Microsoft, y cruzar esos indicadores con tus logs automáticamente mediante analytics rules de tipo TI (Threat Intelligence Matching).

Qué puede lograr un atacante si el SIEM falla#

La diferencia entre un incidente contenido en minutos y uno que dura meses es, en la mayoría de los casos, un SIEM bien configurado con reglas de detección adecuadas y automatización de respuesta.

Cómo se configura correctamente#

La configuración correcta de Sentinel sigue un orden lógico:

Paso 1: crear el workspace#

Azure Portal → Microsoft Sentinel → Create
  → Seleccionar o crear Log Analytics Workspace
  → Región: la más cercana a tus datos (latencia y compliance)
  → Pricing tier: Pay-as-you-go o Commitment Tier según volumen

Paso 2: habilitar data connectors#

Conectores prioritarios para la mayoría de organizaciones:

• Azure Active Directory (Sign-in Logs, Audit Logs, Provisioning Logs)
• Microsoft 365 (Exchange, SharePoint, Teams)
• Microsoft Defender XDR (Incidents, Alerts)
• Azure Activity (operaciones en suscripciones)
• Security Events via AMA (Windows Security Events)
• Syslog via AMA (Linux, firewalls, switches)
• CEF via AMA (Palo Alto, Fortinet, Check Point)

Paso 3: crear analytics rules#

Empieza con las rule templates que Sentinel proporciona (hay mas de 300), actívalas y ajusta umbrales a tu entorno. Luego añade reglas custom para patrones específicos de tu organización.

Paso 4: configurar playbooks#

Crea Logic Apps para las respuestas mas comunes: deshabilitar usuario, bloquear IP, notificar al equipo. Asócialas a las analytics rules mediante automation rules.

Paso 5: optimizar costes#

La factura de Sentinel depende del volumen de datos ingestados. Estrategias de optimización:

• Basic Logs: tablas con datos de alto volumen y baja consulta (por ejemplo, logs de flow de red) a precio reducido, con limitaciones en queries.
• Transformation rules: filtrar o agregar datos antes de la ingesta con Data Collection Rules (DCR) para reducir volumen.
• Commitment Tiers: si ingestas mas de 100 GB/día, los tiers con compromiso ofrecen descuentos de hasta el 50 por ciento.
• Data retention: el estándar son 90 días en Log Analytics; archiva a largo plazo con archive tiers.

Errores comunes al implementar Sentinel#

• Habilitar todos los conectores sin calcular el coste: los logs de Azure AD Sign-in de un tenant grande pueden ser 50 GB/día.
• No ajustar los umbrales de las analytics rules al tamaño de tu organización: 10 logins fallidos es normal en una empresa de 10.000 usuarios, no en una de 20.
• Ignorar los falsos positivos: cada falso positivo sin resolver erosiona la confianza del SOC en las alertas.
• No mapear entidades correctamente en las analytics rules: sin entity mapping, Sentinel no puede agrupar alertas en incidentes coherentes.
• Crear playbooks sin manejo de errores: si el playbook de bloqueo falla silenciosamente, nadie se entera.
• Olvidar el RBAC: dar acceso de Sentinel Contributor a todo el equipo cuando la mayoría solo necesita Sentinel Reader o Sentinel Responder.

Preguntas frecuentes#

Sentinel vs Splunk, cual elegir#

Si tu infraestructura es mayoritariamente Azure y Microsoft 365, Sentinel tiene ventaja por la integración nativa con conectores Microsoft, Defender XDR y Azure AD. Si tu entorno es multi-cloud o on-premise, Splunk o Elastic tienen mas madurez en conectores third-party. El coste de Sentinel puede ser menor para cargas Microsoft-heavy porque muchos logs de primera parte tienen descuento o son gratuitos.

KQL es difícil de aprender#

KQL tiene una curva de aprendizaje suave si vienes de SQL. Los operadores pipe son intuitivos y la documentación de Microsoft es extensa. El recurso mas útil para empezar es la demo de Log Analytics (demo.azure.com) que tiene datos sintéticos para practicar sin coste.

Se puede usar Sentinel sin Azure#

Técnicamente Sentinel necesita un Log Analytics workspace en Azure, pero puede ingestar datos de cualquier fuente: AWS (via S3 o CloudTrail connector), GCP, on-premise, SaaS third-party. No necesitas que tu infraestructura esté en Azure para usar Sentinel como SIEM.

Qué diferencia hay entre alert y incident#

Una alert es una detección individual generada por una analytics rule. Un incident agrupa una o mas alerts que comparten entidades (misma IP, mismo usuario, mismo host). Los analistas trabajan con incidentes, no con alerts individuales, para tener contexto completo.

Fusion realmente detecta ataques avanzados#

Fusion usa ML para correlacionar alerts de bajo ruido individuales que juntas indican una kill chain. Por ejemplo: login sospechoso (baja severidad) + descarga masiva de archivos (baja severidad) + creación de regla de buzón de reenvío (baja severidad) = posible compromiso de cuenta (alta severidad). Es efectivo para ataques multi-etapa que ninguna regla individual capturaría.

Cuánto cuesta Sentinel#

El coste base es por GB ingestado: Pay-as-you-go parte de aproximadamente 4.30 USD por GB (precios 2025, región East US). Los Commitment Tiers empiezan en 100 GB/día con descuentos escalonados. Los logs de Azure Activity y Microsoft 365 Audit tienen ingesta gratuita. Los primeros 5 GB/día de Log Analytics son gratuitos por workspace. Usa la calculadora de Azure para estimar según tu volumen real.

Resumen#

• Microsoft Sentinel es un SIEM+SOAR cloud-native sobre Azure que escala automáticamente sin infraestructura propia.
• Los data connectors ingesan logs de Azure AD, Microsoft 365, Syslog, CEF y fuentes custom en un Log Analytics workspace.
• KQL es el lenguaje de consulta: encadena operadores con pipes para filtrar, agregar, cruzar y visualizar datos de seguridad.
• Las analytics rules (scheduled, NRT, Fusion) ejecutan queries periódicamente y generan alertas cuando se detecta un patrón sospechoso.
• Los playbooks automatizan la respuesta: bloquear IPs, deshabilitar cuentas, notificar al equipo, crear tickets.
• Optimiza costes con Basic Logs, transformation rules y Commitment Tiers para evitar facturas inesperadas.

Fuentes y lecturas recomendadas#

• Microsoft Sentinel documentation
• KQL quick reference
• Microsoft Sentinel GitHub repository (queries, playbooks, workbooks)
• MITRE ATT&CK framework
• Must Learn KQL (blog series by Rod Trent)
• Log Analytics demo environment