El SOC legacy: síntoma de un problema más antiguo
Cuando llegamos al proyecto, el equipo del SOC llevaba cuatro años en modo supervivencia. SIEM on-premise con más de ocho años de antigüedad. Reglas de detección escritas a mano en 2019 y nunca revisadas sistemáticamente. EDR de tercera generación que generaba alertas pero que no tenía integración nativa con el SIEM. El resultado era predecible: el 70% del tiempo del equipo analista se iba en gestionar falsos positivos. El MTTD real (no el que figuraba en los informes) era de 72 horas. La cobertura de MITRE ATT&CK no llegaba al 35%.
Lo más revelador no fue el dato técnico. Fue la conversación con el analista senior del turno de noche: "llevamos años sabiendo que hay tráfico sospechoso en algunos segmentos de red, pero cuando lo escalas se pierde en la cola de tickets y nunca se investiga". Un SOC en el que las anomalías conocidas no se investigan no es un SOC. Es un generador de informes de cumplimiento.
El problema no era la falta de talento. Era la arquitectura: un sistema diseñado para generar volumen de alertas, no para producir decisiones de seguridad.
Decisión 1: el tier model de ingesta de Sentinel
El error más caro en un proyecto de Sentinel es ingestar todo desde el día 1. Sentinel cobra por gigabyte ingestado. Una organización mediana con 40 fuentes de datos heterogéneas puede fácilmente llegar a 50-80 GB/día. A precios de producción, eso es 18.000-28.000€ mensuales solo en ingesta, sin contar el workspace de Log Analytics.
El tier model que aplicamos divide las fuentes de datos en tres categorías:
Tier 1 — Ingesta directa a Sentinel (crítico): Entra ID (sign-ins, audit logs, risky users), Defender for Endpoint (alertas y eventos de alta severidad), Defender for Identity (detecciones laterales y Kerberoasting), firewall perimetral (deny logs con destinos externos), y Azure Activity Logs de subscripciones productivas. Esto cubre el 85% de los vectores de ataque relevantes para el sector asegurador a un volumen de ingesta razonable.
Tier 2 — Ingesta al workspace de Log Analytics con query a demanda: logs de aplicaciones de negocio, eventos de Windows (solo nivel Warning y Error, no Information), logs de servidores Linux (autenticación y sudo únicamente). Se pueden consultar desde Sentinel mediante queries a demanda y se incluyen en el scope de reglas de detección específicas, pero no se indizan de forma permanente en el workspace primario.
Tier 3 — Retención en almacenamiento frío: logs de acceso web de nivel informativo, NetFlow completo, logs de aplicaciones no críticas. Accesibles para investigaciones forenses mediante Azure Data Explorer, pero fuera del ciclo de detección en tiempo real.
Con este modelo, el coste de ingesta se redujo un 62% respecto a la propuesta inicial de "ingestar todo", manteniendo una cobertura de detección superior. El ahorro se reinvirtió en licencias de Defender XDR que aportaban más valor de detección que el volumen bruto de logs.
Decisión 2: las reglas de detección por táctica MITRE ATT&CK
Sentinel incluye más de 300 reglas de detección out-of-the-box. El error más común es activarlas todas desde el primer día. El resultado son miles de alertas diarias, el 90% de ellas falsos positivos en entornos que no han sido tuneadas para el contexto específico de la organización.
El enfoque correcto es priorizar por táctica MITRE ATT&CK en función del perfil de amenaza real del sector. Para una aseguradora española en 2026, las tácticas de mayor riesgo son:
Initial Access (TA0001): phishing, spearphishing y explotación de aplicaciones expuestas. Reglas prioritarias: detección de sign-ins desde ubicaciones imposibles (Entra ID), MFA fatigue attacks (más de 5 notificaciones MFA en 10 minutos por usuario), y nuevas aplicaciones OAuth con permisos de acceso a buzones.
Credential Access (TA0006): el vector más activo en el sector financiero-asegurador. Password spray detection (Entra ID Smart Lockout + Sentinel), Kerberoasting (Defender for Identity), y LSASS dumping (Defender for Endpoint).
Lateral Movement (TA0008): Pass-the-Hash, Pass-the-Ticket, y uso de PsExec/WMI para movimiento lateral. Las reglas de correlación entre Defender for Identity y Defender for Endpoint son el activo diferencial de Defender XDR frente a soluciones SIEM de terceros.
Exfiltration (TA0010): volúmenes anómalos de descarga desde SharePoint, emails con adjuntos grandes hacia dominios externos no corporativos (Purview DLP + Sentinel), y transferencias a dispositivos de almacenamiento extraíble.
Activamos inicialmente 47 reglas cubriendo estas cuatro tácticas, ajustadas al contexto de la organización durante las primeras cuatro semanas. Al final del trimestre teníamos 112 reglas activas con una tasa de falsos positivos del 8%, frente al 70% del SIEM anterior.
Decisión 3: SOAR sin perder el juicio humano
SOAR (Security Orchestration, Automation and Response) es la palanca que libera al equipo analista para el trabajo de alto valor. Pero implementado mal, crea un problema diferente: acciones automáticas que deshabilitan cuentas o aíslan endpoints de usuarios legítimos que estaban trabajando correctamente.
El principio que aplicamos: automatización de contención, no de remediación definitiva. Los playbooks de Logic Apps que desplegamos operan en tres niveles:
Nivel 1 — Acción automática inmediata (sin aprobación humana): aislamiento de red de un endpoint con alerta de severidad alta de Defender for Endpoint + confirmación de segunda señal independiente (Entra ID risky sign-in o Defender for Identity alerta crítica). El endpoint queda aislado de la red corporativa pero con conectividad a los endpoints de Microsoft para que el analista pueda seguir investigando remotamente. Ticket creado automáticamente en ServiceNow con toda la evidencia disponible.
Nivel 2 — Acción con aprobación acelerada (Teams adaptive card al analista de guardia): deshabilitación de cuenta de usuario por riesgo Entra ID "High" sostenido más de 30 minutos. El analista recibe una card en Teams con los detalles del usuario, la señal de riesgo y dos botones: "Deshabilitar cuenta" / "Falso positivo". Si no hay respuesta en 15 minutos, se escala al responsable de turno.
Nivel 3 — Notificación enriquecida sin acción automática: anomalías de comportamiento UEBA, accesos a recursos sensibles fuera de horario habitual, y patrones que requieren contexto de negocio para interpretar correctamente. El analista decide con toda la información disponible.
Al final de los primeros seis meses, el 60% de los incidentes de baja y media severidad se cerraban sin intervención humana directa. El equipo analista dedicaba el 80% de su tiempo a investigación proactiva y cazas de amenazas (threat hunting), frente al 30% anterior.
Decisión 4: UEBA como detector de amenazas internas
Las amenazas internas y las cuentas comprometidas con comportamiento "lento" —que evitan los umbrales de las reglas estáticas— son el punto ciego de los SIEM de primera generación. UEBA (User and Entity Behavior Analytics) crea una línea de base de comportamiento para cada usuario y entidad de la red, y alerta cuando hay desviaciones estadísticamente significativas.
En los primeros 90 días de UEBA activo identificamos tres casos que las reglas estáticas no habrían detectado: un empleado que descargaba volúmenes progresivamente crecientes de documentación de siniestros (patrón de exfiltración gradual por debajo del umbral de DLP), una cuenta de servicio que empezó a autenticarse contra controladores de dominio fuera de su scope operativo habitual, y un proveedor externo con acceso VPN que realizaba consultas a bases de datos en horario nocturno desde una IP diferente a la habitual.
Ninguno de los tres resultó ser un incidente de seguridad confirmado. Pero los tres se investigaron, se documentaron y en el tercer caso se identificó que las credenciales del proveedor habían sido cedidas a un tercero no autorizado. Se corrigió antes de que generara un problema mayor.
Los números al cabo de seis meses
MTTD: de 72 horas a menos de 4 horas para amenazas de severidad alta. Cobertura MITRE ATT&CK: del 35% al 95%. Falsos positivos: reducción del 80%. Coste operativo del SOC: reducción del 35% gracias a la automatización (menor carga de trabajo por analista sin reducir el equipo, con redirección del tiempo liberado a actividades de mayor valor). Incidentes gestionados sin intervención humana: 60% del volumen total.
El dato que más importó al CISO no fue ninguno de los anteriores. Fue que en la primera auditoría NIS2 posterior al despliegue, el equipo pudo demostrar con logs, evidencias y trazabilidad completa que cada alerta de severidad alta había sido investigada y documentada. Sin excepciones. Eso es lo que diferencia un SOC que funciona de un SOC que parece que funciona.
Las tres preguntas que siempre hacen los CISOs antes de arrancar
"¿Cuánto tarda en estar operativo?" — Con el tier model de ingesta y las reglas de detección prioritarias activadas, un Sentinel mínimamente viable para el perfil de amenaza del sector financiero-asegurador se puede tener operativo en 8-12 semanas. Operativo no significa tuneado. El tuning continuo de reglas y UEBA requiere entre 3 y 6 meses de operación en el entorno de producción real.
"¿Necesito migrar el SIEM legacy de golpe?" — No. La migración en paralelo es la mejor práctica: Sentinel recibe las fuentes de datos críticas mientras el SIEM legacy sigue operativo. Las alertas se contrastan entre los dos sistemas durante un período de overlap. Esto permite validar que Sentinel detecta lo que detectaba el legacy antes de apagarlo, y revela casos en los que el legacy no detectaba nada aunque debería haberlo hecho. En este proyecto el período de overlap fue de ocho semanas.
"¿Cuántos analistas necesito?" — Para una entidad mediana con 500-2.000 endpoints y el modelo de SOAR descrito, un equipo de 3-4 analistas con disponibilidad 8x5 más cobertura externa (MSSP o servicio de guardia externo) para el horario nocturno y festivos es suficiente. El error habitual es diseñar el equipo antes que la arquitectura de automatización. La arquitectura correcta determina el número de analistas necesario, no al revés.