Instalación y configuración de Azure Sentinel

Introducción a Microsoft Sentinel

Microsoft Sentinel (anteriormente Azure Sentinel) es la solución SIEM y SOAR nativa en la nube de Microsoft. Combina análisis de seguridad inteligente, detección de amenazas, caza proactiva (hunting) y respuesta automatizada en una única plataforma escalable.

A diferencia de los SIEM tradicionales on-premise, Sentinel elimina la complejidad de gestionar infraestructura propia: no hay servidores que aprovisionar ni almacenamiento que dimensionar. Se paga por el volumen de datos ingestados en el workspace de Log Analytics, lo que permite escalar de forma elástica según las necesidades de la organización.

Las capacidades principales de Sentinel incluyen:

• Recopilación de datos a escala cloud: conectores nativos para servicios Microsoft (Azure AD, Microsoft 365, Defender) y de terceros (Fortinet, Palo Alto, AWS, GCP).
• Detección de amenazas: reglas analíticas basadas en KQL (Kusto Query Language), machine learning y fusión de alertas.
• Investigación de incidentes: grafos de investigación, timelines y correlación automática de entidades.
• Automatización (SOAR): playbooks basados en Logic Apps para respuesta automática ante incidentes.
• Threat hunting: consultas proactivas con Jupyter Notebooks y KQL.

En esta guía cubriremos desde la creación del workspace hasta la configuración de conectores, reglas analíticas y automatización.

Requisitos previos

Antes de desplegar Sentinel necesitamos:

• Una suscripción de Azure activa.
• Permisos de Owner o Contributor en el grupo de recursos donde se creará el workspace.
• Rol Microsoft Sentinel Contributor para gestionar Sentinel.
• Rol Security Administrator o Global Administrator en Azure AD para conectar fuentes de identidad.

En cuanto a costes, Sentinel tiene dos modelos de precio:

• Pago por uso (Pay-As-You-Go): se factura por GB ingestado al día.
• Reserva de capacidad (Commitment Tier): descuentos significativos al comprometer un volumen diario mínimo (100 GB/día en adelante).

Los primeros 31 días de Sentinel son gratuitos sobre un workspace nuevo de Log Analytics, lo que permite evaluar la plataforma sin coste adicional.

Crear el workspace de Log Analytics

Sentinel funciona sobre un workspace de Log Analytics, que es el repositorio donde se almacenan todos los logs y eventos. El workspace define la región, la retención de datos y los permisos de acceso.

Podemos crearlo desde el portal de Azure o mediante la CLI:

# Crear el grupo de recursos
az group create \
  --name rg-sentinel-prod \
  --location westeurope

# Crear el workspace de Log Analytics
az monitor log-analytics workspace create \
  --resource-group rg-sentinel-prod \
  --workspace-name law-sentinel-prod \
  --location westeurope \
  --retention-time 90 \
  --sku PerGB2018

Parámetros importantes:

• --location: elige la región más cercana a tu infraestructura para minimizar la latencia de ingestión.
• --retention-time: retención en días (por defecto 30, máximo 730). Los primeros 90 días son gratuitos en Sentinel.
• --sku PerGB2018: el SKU estándar para pay-as-you-go.

Habilitar Microsoft Sentinel en el workspace

Una vez creado el workspace, habilitamos Sentinel sobre él:

# Instalar la extensión de Sentinel para Azure CLI
az extension add --name sentinel

# Habilitar Sentinel en el workspace
az sentinel onboarding-state create \
  --resource-group rg-sentinel-prod \
  --workspace-name law-sentinel-prod \
  --name default

Desde el portal de Azure, el proceso es: buscar Microsoft Sentinel en la barra de búsqueda, pulsar Create, seleccionar el workspace y confirmar.

Configurar permisos y roles

Para un despliegue seguro en producción, es fundamental configurar los permisos siguiendo el principio de mínimo privilegio. Sentinel define varios roles específicos:

• Microsoft Sentinel Reader: puede ver datos, incidentes, workbooks y otros recursos de Sentinel.
• Microsoft Sentinel Responder: además de lo anterior, puede gestionar incidentes (asignar, cerrar, cambiar severidad).
• Microsoft Sentinel Contributor: acceso completo para crear y editar reglas analíticas, workbooks, playbooks y conectores.
• Microsoft Sentinel Automation Contributor: permite a Sentinel ejecutar playbooks de Logic Apps.

# Obtener el ID del workspace
WORKSPACE_ID=$(az monitor log-analytics workspace show \
  --resource-group rg-sentinel-prod \
  --workspace-name law-sentinel-prod \
  --query id -o tsv)

# Asignar rol de Sentinel Contributor a un usuario
az role assignment create \
  --assignee usuario-soc@empresa.com \
  --role "Microsoft Sentinel Contributor" \
  --scope "$WORKSPACE_ID"

# Asignar rol de Sentinel Responder al equipo de analistas
az role assignment create \
  --assignee grupo-analistas@empresa.com \
  --role "Microsoft Sentinel Responder" \
  --scope "$WORKSPACE_ID"

Conectores de datos (Data Connectors)

Los conectores de datos son el corazón de Sentinel: permiten ingestar logs y eventos desde múltiples fuentes. Sentinel ofrece más de 100 conectores nativos organizados por categorías.

Conectores recomendados para un despliegue inicial

Para una infraestructura típica con entorno Microsoft, los conectores esenciales son:

• Azure Active Directory: sign-in logs, audit logs, provisioning logs.
• Azure Activity: logs de operaciones sobre recursos de Azure (quién creó, modificó o eliminó qué).
• Microsoft 365: logs de Exchange, SharePoint y Teams.
• Microsoft Defender for Endpoint: alertas y eventos de seguridad de endpoints.
• Security Events via AMA: eventos de seguridad de Windows (reemplaza al agente MMA legacy).
• Syslog via AMA: logs de sistemas Linux y dispositivos de red.

Conectar Security Events con Azure Monitor Agent (AMA)

El conector de Security Events permite recopilar eventos de seguridad de Windows. Microsoft recomienda utilizar el nuevo Azure Monitor Agent (AMA) en lugar del agente legacy (MMA/OMS).

# Crear una Data Collection Rule (DCR) para Security Events
az monitor data-collection rule create \
  --resource-group rg-sentinel-prod \
  --name dcr-security-events \
  --location westeurope \
  --data-flows '[{
    "streams": ["Microsoft-SecurityEvent"],
    "destinations": ["law-sentinel-prod"]
  }]' \
  --destinations '{
    "logAnalytics": [{
      "workspaceResourceId": "'$WORKSPACE_ID'",
      "name": "law-sentinel-prod"
    }]
  }'

Para los niveles de recopilación de eventos de seguridad de Windows, Sentinel ofrece cuatro opciones:

• All Events: todos los eventos de seguridad de Windows. Genera mayor volumen pero proporciona visibilidad completa.
• Common: un conjunto equilibrado de eventos para auditoría. Recomendado para la mayoría de organizaciones.
• Minimal: solo eventos críticos de seguridad. Menor volumen pero puede perder contexto en investigaciones.
• None: desactiva la recopilación.

Para entornos de producción donde la visibilidad es prioritaria, recomendamos All Events o al menos Common.

Conectar fuentes Syslog (Linux y dispositivos de red)

Para recopilar logs de servidores Linux, firewalls y otros dispositivos que envían Syslog, configuramos un reenviador (forwarder):

# En el servidor Linux que actuará como forwarder,
# configurar rsyslog para reenviar a Log Analytics

# /etc/rsyslog.d/50-sentinel.conf
# Reenviar auth y authpriv al workspace
auth.*    @127.0.0.1:25226
authpriv.*    @127.0.0.1:25226

# Reiniciar rsyslog
sudo systemctl restart rsyslog

El Azure Monitor Agent escucha en el puerto 25226 local y reenvía los logs al workspace de Log Analytics.

Instalar y configurar Sysmon

Sysmon (System Monitor) es una herramienta de Sysinternals que registra actividad detallada del sistema en los Event Logs de Windows: creación de procesos, conexiones de red, modificación de ficheros, carga de DLLs y mucho más. Es una fuente de telemetría esencial para cualquier SIEM.

Instalación de Sysmon en Windows

# Descargar Sysmon desde Sysinternals
Invoke-WebRequest -Uri "https://download.sysinternals.com/files/Sysmon.zip" `
  -OutFile "$env:TEMP\Sysmon.zip"
Expand-Archive "$env:TEMP\Sysmon.zip" -DestinationPath "C:\Tools\Sysmon"

# Descargar la configuración de SwiftOnSecurity (referencia de la comunidad)
Invoke-WebRequest -Uri "https://raw.githubusercontent.com/SwiftOnSecurity/sysmon-config/master/sysmonconfig-export.xml" `
  -OutFile "C:\Tools\Sysmon\sysmonconfig.xml"

# Instalar Sysmon con la configuración
C:\Tools\Sysmon\Sysmon64.exe -accepteula -i C:\Tools\Sysmon\sysmonconfig.xml

Configurar la recopilación de eventos Sysmon en Log Analytics

Para que los eventos de Sysmon lleguen a Sentinel, debemos configurar la recopilación de los logs del canal Microsoft-Windows-Sysmon/Operational en el workspace de Log Analytics.

Los canales de eventos de Windows recomendados para una buena visibilidad de seguridad:

Microsoft-Windows-Sysmon/Operational
Microsoft-Windows-Windows Defender/Operational
Microsoft-Windows-TerminalServices-LocalSessionManager/Operational
Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational
Microsoft-Windows-SMBServer/Operational
Microsoft-Windows-TaskScheduler/Operational
Microsoft-Windows-PowerShell/Operational
Microsoft-Windows-WMI-Activity/Operational

Estos canales cubren los vectores de ataque más comunes: ejecución de procesos, movimiento lateral por RDP y SMB, persistencia por tareas programadas y WMI, y ejecución de scripts PowerShell.

Introducción a KQL (Kusto Query Language)

KQL es el lenguaje de consultas que utiliza Log Analytics y Sentinel para buscar, filtrar y correlacionar datos. Dominar KQL es fundamental para crear reglas analíticas efectivas y realizar threat hunting.

Consultas básicas

// Eventos de login fallido en las últimas 24 horas
SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 4625
| summarize FailedAttempts = count() by TargetAccount, IpAddress
| where FailedAttempts > 10
| sort by FailedAttempts desc

// Procesos sospechosos creados por Sysmon (Event ID 1)
Event
| where Source == "Microsoft-Windows-Sysmon"
| where EventID == 1
| parse EventData with * '<Data Name="Image">' ProcessPath '</Data>' *
| parse EventData with * '<Data Name="ParentImage">' ParentProcess '</Data>' *
| where ProcessPath has_any ("powershell", "cmd", "wscript", "cscript", "mshta")
| where ParentProcess has_any ("winword", "excel", "outlook")
| project TimeGenerated, Computer, ProcessPath, ParentProcess

// Sign-ins desde ubicaciones inusuales en Azure AD
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == 0  // Login exitoso
| summarize Locations = make_set(LocationDetails.city),
            LoginCount = count()
            by UserPrincipalName
| where array_length(Locations) > 3
| sort by LoginCount desc

Reglas analíticas (Analytics Rules)

Las reglas analíticas son la pieza central de la detección en Sentinel. Ejecutan consultas KQL de forma periódica y generan alertas cuando se cumplen las condiciones definidas.

Tipos de reglas

• Scheduled: consultas KQL que se ejecutan a intervalos regulares (cada 5 minutos, cada hora, etc.). Son las más flexibles y personalizables.
• Microsoft Security: crean automáticamente incidentes a partir de alertas de productos Microsoft (Defender, Azure AD Identity Protection).
• Fusion: utiliza machine learning para correlacionar alertas de baja fidelidad en incidentes de alta fidelidad. Detecta ataques multietapa automáticamente.
• NRT (Near Real-Time): reglas que se ejecutan con un retraso mínimo (cada minuto), ideales para detecciones críticas.

Crear una regla analítica personalizada

Ejemplo: detectar intentos de fuerza bruta RDP seguidos de un login exitoso desde la misma IP:

// Regla: Fuerza bruta RDP con login exitoso posterior
let threshold = 20;
let timeframe = 1h;
let failed_logons = SecurityEvent
| where TimeGenerated > ago(timeframe)
| where EventID == 4625
| where LogonType == 10  // RDP
| summarize FailedCount = count() by IpAddress, TargetAccount
| where FailedCount > threshold;
SecurityEvent
| where TimeGenerated > ago(timeframe)
| where EventID == 4624
| where LogonType == 10
| join kind=inner failed_logons on IpAddress
| project TimeGenerated, Computer, TargetAccount,
          IpAddress, FailedCount

Al crear la regla en el portal, configuramos:

• Query scheduling: cada 5 minutos, buscando datos de la última hora.
• Alert threshold: generar alerta cuando el número de resultados sea mayor que 0.
• Entity mapping: mapear TargetAccount como Account, IpAddress como IP y Computer como Host.
• Incident grouping: agrupar alertas del mismo IpAddress en un único incidente durante 24 horas.

Habilitar reglas de la galería (Rule Templates)

Sentinel incluye cientos de reglas predefinidas mapeadas a MITRE ATT&CK. Para activarlas, navegamos a Analytics > Rule templates, filtramos por el conector de datos que tengamos habilitado y activamos las más relevantes.

Reglas recomendadas para un despliegue inicial:

• Brute force against Azure Portal
• Explicit MFA Deny
• Anomalous sign-in location by user account
• New executable via Office application
• Rare subscription-level operations
• Security Event log cleared

Gestión de incidentes

Cuando una regla analítica dispara, Sentinel crea un incidente que agrupa una o más alertas relacionadas. La gestión de incidentes es donde el equipo SOC realiza el triaje, investigación y resolución.

El flujo de trabajo típico de un incidente:

1. Triaje: revisar la severidad, las entidades involucradas y el contexto. Asignar al analista correspondiente.
2. Investigación: usar el grafo de investigación para visualizar relaciones entre entidades (usuarios, IPs, hosts, ficheros). Pivot sobre entidades para buscar actividad relacionada.
3. Respuesta: ejecutar acciones de contención (bloquear usuario, aislar host) manualmente o mediante playbooks automatizados.
4. Cierre: documentar la resolución, clasificar como verdadero/falso positivo y cerrar el incidente.

Sentinel permite configurar reglas de automatización para el triaje inicial: asignar automáticamente incidentes según la severidad, cambiar el estado, añadir etiquetas o ejecutar playbooks.

Automatización con playbooks (Logic Apps)

Los playbooks de Sentinel están basados en Azure Logic Apps y permiten automatizar respuestas a incidentes. Algunos casos de uso comunes:

• Enviar notificación a un canal de Teams o Slack cuando se crea un incidente de alta severidad.
• Bloquear una IP en el firewall (Azure Firewall, NSG, Fortinet) cuando se detecta un ataque de fuerza bruta.
• Deshabilitar una cuenta de Azure AD comprometida.
• Enriquecer alertas con datos de inteligencia de amenazas (VirusTotal, AbuseIPDB).
• Crear un ticket en ServiceNow o Jira automáticamente.

Ejemplo de estructura de un playbook para bloquear una IP en un NSG:

{
  "trigger": "Microsoft Sentinel incident",
  "actions": [
    {
      "step": 1,
      "action": "Get incident entities",
      "filter": "IP addresses"
    },
    {
      "step": 2,
      "action": "For each IP",
      "sub_actions": [
        "Query VirusTotal for reputation",
        "If malicious score > 5:",
        "  Add deny rule to NSG",
        "  Add comment to incident",
        "  Send Teams notification"
      ]
    }
  ]
}

Para crear playbooks, necesitamos el rol Logic App Contributor en el grupo de recursos y asignar el rol Microsoft Sentinel Automation Contributor a la identidad gestionada del Logic App.

Threat hunting con Sentinel

El módulo de Hunting de Sentinel permite buscar proactivamente amenazas que las reglas analíticas automáticas podrían no detectar. Proporciona consultas KQL predefinidas mapeadas a MITRE ATT&CK y la capacidad de crear consultas personalizadas.

// Hunting: Ejecución de PowerShell codificada en Base64
// MITRE ATT&CK: T1059.001 (Command and Scripting Interpreter: PowerShell)
SecurityEvent
| where TimeGenerated > ago(7d)
| where EventID == 4688
| where CommandLine has "-EncodedCommand" or
        CommandLine has "-enc " or
        CommandLine has "-e " and CommandLine has "powershell"
| project TimeGenerated, Computer, Account,
          ParentProcessName, CommandLine
| sort by TimeGenerated desc

// Hunting: Conexiones de red sospechosas (Sysmon Event ID 3)
Event
| where Source == "Microsoft-Windows-Sysmon"
| where EventID == 3
| parse EventData with * '<Data Name="Image">' Process '</Data>' *
| parse EventData with * '<Data Name="DestinationIp">' DestIP '</Data>' *
| parse EventData with * '<Data Name="DestinationPort">' DestPort '</Data>' *
| where DestPort in ("4444", "5555", "8888", "1234", "9001")
| project TimeGenerated, Computer, Process, DestIP, DestPort
| sort by TimeGenerated desc

Workbooks y dashboards

Los workbooks de Sentinel proporcionan dashboards interactivos para visualizar datos de seguridad. Sentinel incluye plantillas predefinidas que se activan automáticamente al habilitar un conector de datos.

Workbooks recomendados:

• Azure AD Sign-in Logs: análisis de patrones de autenticación, logins fallidos, ubicaciones y dispositivos.
• Microsoft Sentinel Incidents: métricas del SOC (MTTR, incidentes por severidad, tendencias).
• Security Events: vista general de eventos de seguridad de Windows.
• Insecure Protocols: identifica el uso de protocolos obsoletos (NTLMv1, SMBv1, telnet).

Para crear un workbook personalizado, navegamos a Workbooks > Add workbook y usamos el editor visual o insertamos consultas KQL directamente.

Buenas prácticas de despliegue

Para un despliegue exitoso de Sentinel en producción:

• Empieza con los conectores de mayor valor: Azure AD, Security Events y los logs de tu firewall perimetral cubren la mayoría de los casos de uso iniciales.
• Controla los costes desde el inicio: monitoriza el volumen de ingestión diario con la tabla Usage y configura alertas de presupuesto.
• Configura retención diferenciada: utiliza las tablas auxiliares (Auxiliary Logs) para datos de alto volumen y baja consulta con menor coste.
• Implementa Sysmon en todos los endpoints Windows: es la fuente de telemetría con mejor relación coste/valor para detección de amenazas.
• Habilita las reglas Fusion: detectan ataques multietapa combinando señales de baja fidelidad sin necesidad de configuración manual.
• Automatiza el triaje: configura reglas de automatización para cerrar falsos positivos conocidos y asignar incidentes automáticamente.
• Mapea a MITRE ATT&CK: utiliza la vista de cobertura MITRE de Sentinel para identificar gaps en las detecciones y priorizar nuevas reglas.
• Documenta los playbooks: cada playbook debe tener un runbook asociado que describa qué hace, cuándo se ejecuta y cómo validar que funcionó correctamente.

// Monitorizar el volumen de ingestión por tabla
Usage
| where TimeGenerated > ago(30d)
| where IsBillable == true
| summarize TotalGB = sum(Quantity) / 1024 by DataType
| sort by TotalGB desc
| take 10

:wq!