De guardián a vigilante: cómo unir la seguridad previa y posterior a la autenticación

By Mirko Peters · 2026-08-11

¡Bienvenido de nuevo al podcast y a nuestro análisis técnico en profundidad que lo acompaña! Si alguna vez has sentido que tu estrategia de seguridad de identidades tiene un punto ciego justo después de que un usuario…

Automatically translated with AI from the original post. Read the English original

¡Bienvenido de nuevo al podcast y a nuestro análisis técnico que lo acompaña! Si alguna vez has sentido que tu estrategia de seguridad de identidades tiene un punto ciego justo después de que un usuario inicia sesión correctamente, no eres el único. Durante años, las organizaciones han confiado en gran medida en los controles previos a la autenticación para mantener alejados a los atacantes, tratando la puerta principal como la última frontera de la seguridad. Pero ¿qué ocurre cuando un adversario atraviesa esa puerta con un token válido o con un conjunto de credenciales robadas? Ese dilema exacto fue el eje de nuestro episodio reciente, Conditional Access with Defender for Identity Signals. En esta entrada vamos a ampliar esos conceptos y a explicar cómo puedes combinar tu guardián previo a la autenticación con tu vigilante posterior a la autenticación para construir una arquitectura de identidad realmente resiliente.

La idea central (TL;DR)

Para entender de verdad la protección moderna de identidades, debes ver tus herramientas como roles especializados que trabajan juntos en tiempo real:

• Conditional Access (CA) es tu portero. Es excepcionalmente bueno tomando decisiones previas a la autenticación basadas en quién intenta entrar, desde dónde se conecta y el estado de su dispositivo.
• Defender for Identity (DfI) es tu sistema de videovigilancia combinado con la seguridad de tus instalaciones. Destaca en la supervisión del comportamiento posterior a la autenticación, el movimiento lateral y las anomalías internas.
• La resiliencia real solo se produce cuando el riesgo posterior a la autenticación eleva la fricción previa a la autenticación de forma automática y dinámica, justo ahí, durante la sesión.

Modelo mental

Afinemos el modelo mental de cómo interactúan estos componentes dentro de tu ecosistema:

• Guardián (CA): evalúa quién inicia sesión, desde dónde, el estado del dispositivo y el riesgo en el inicio de sesión, y aplica controles de sesión inmediatos.
• Vigilante (DfI + M365 Defender): busca movimiento lateral, patrones anómalos de acceso a recursos, Kerberoasting, abuso de NTLM y escaladas de privilegios inesperadas.
• Bucle de retroalimentación: el vigilante marca el comportamiento sospechoso, lo que a su vez eleva la puntuación de riesgo del usuario o de la sesión. Esto obliga al guardián a endurecer de inmediato los controles, exigiendo MFA adicional, bloqueando el acceso por completo o restringiendo la sesión activa.

Plan de integración (qué habilitar y en qué orden)

Para que estos sistemas se comuniquen entre sí se necesita un despliegue estructurado. Este es el plan que debes seguir:

1. CA consciente del riesgo (base)
   • Entra ID Protection: activa la evaluación de Riesgo del usuario y Riesgo de inicio de sesión.
   • Crea directivas de CA:
     • Bloquear cuando el riesgo del usuario = Alto (o exigir un cambio de contraseña si tus flujos de trabajo de soporte técnico lo permiten).
     • Exigir MFA cuando el riesgo de inicio de sesión ≥ Medio.
     • Exigir dispositivo conforme para aplicaciones de sensibilidad media a alta; usa filtros de dispositivos para los puntos de conexión no administrados y dirigirlos directamente a controles de sesión restringidos.
2. Deja que el vigilante hable con el guardián
   • Asegúrate de que DfI envía alertas activamente a Microsoft 365 Defender y a Sentinel (si lo usas como SIEM/SOAR).
   • Automatiza las acciones de "Confirmar comprometido" sobre los usuarios ante alertas de alta gravedad de DfI. Esto establece el Riesgo del usuario = Alto en Entra ID Protection, lo que hace que tus directivas de CA reaccionen al instante.
   • Ruta de automatización: Incidente de M365 Defender → Logic App o Power Automate → API de Graph Security/Identity Protection (/riskDetections, /riskyUsers:confirmCompromised) → opcional: Forzar cierre de sesión.
   • Activa la Evaluación continua de acceso (CAE) en todas las aplicaciones compatibles (Exchange, SharePoint, Graph) para que los cambios de directiva finalicen realmente los tokens activos.
3. Control de sesión para la contención
   • Para sesiones no administradas o de riesgo, despliega Defender for Cloud Apps (proxy de sesión) directamente desde CA:
     • CA → Usar Conditional Access App Control (primero supervisa y, después, bloquea la exfiltración de datos como descargas, copiar y pegar, impresión y sincronización).
   • Combínalo con riesgo de dispositivo en MDE → cumplimiento en Intune → CA "Require compliant device" para todas las aplicaciones sensibles.
4. Salvaguardas de identidades privilegiadas
   • PIM debe aplicar acceso Just-in-Time; exige MFA + dispositivo conforme + ningún estado de usuario de riesgo antes de permitir la elevación.
   • Implementa una directiva de CA para bloquear roles privilegiados si el riesgo del usuario es ≥ Bajo (sí, incluso con riesgo Bajo) para forzar una evaluación inmediata antes de que se pueda asumir un rol administrativo.

"Si esto, entonces aquello": asignar señales de DfI a acciones de CA

Asignar señales de detección concretas de Defender for Identity a acciones automatizadas de Acceso Condicional y de respuesta cierra la brecha entre la observación pasiva y la defensa activa:

Empieza ejecutando estas reglas en modo auditoría/supervisión durante 1 a 2 semanas y, a medida que ganes confianza, cambia las respuestas a modo aplicar por clase de alerta.

Directivas de ejemplo (prácticas y mínimas)

Para llevar estas estrategias a producción, estas son cuatro directivas fundamentales que deberías configurar:

1. Bloquear cuando el riesgo de usuario = Alto
   • Asignar: Todos los usuarios (excluir cuentas de acceso de emergencia), Todas las aplicaciones en la nube
   • Condiciones: Riesgo de usuario = Alto
   • Concesión: Bloquear acceso
2. Verificación adicional por riesgo de inicio de sesión
   • Asignar: Todos los usuarios, aplicaciones de alto valor (portales de administración, Exchange, SharePoint, Centro de administración de Entra)
   • Condiciones: Riesgo de inicio de sesión ≥ Medio
   • Concesión: Requerir MFA + Requerir dispositivo conforme (o dispositivo administrado)
3. Contener sesión no administrada
   • Asignar: Todos los usuarios, SharePoint/OneDrive/Teams
   • Estado del dispositivo: Híbrido/Conforme = excluir; No administrado = aplicar
   • Sesión: Usar Conditional Access App Control (bloquear descargas)
4. Protección de elevación privilegiada
   • Asignar: Roles de directorio = Roles administrativos privilegiados
   • Condiciones: Riesgo de usuario ≥ Bajo O riesgo de inicio de sesión ≥ Medio
   • Concesión: Requerir MFA + Requerir dispositivo conforme; Bloquear si el riesgo es ≥ Alto

Playbooks de automatización (listos para conectar)

La automatización es el ingrediente clave que reduce tu tiempo medio de contención (MTTC). Estos son dos playbooks que puedes crear hoy mismo:

Playbook A: Alerta de DfI de alta gravedad → Contener la identidad

• Desencadenador: incidente de M365 Defender etiquetado con IdentityThreatHigh
• Acciones:
  1. API de Graph – confirmar usuario comprometido (establece el riesgo de usuario en Alto)
  2. Entra ID – revocar tokens de actualización inmediatamente
  3. Intune/MDE – aislar dispositivo (si hay un único dispositivo principal asociado)
  4. ServiceNow/JSM – crear un ticket de incidente con la cronología y los artefactos recopilados
  5. Notificar al SOC y al responsable del usuario mediante una tarjeta adaptativa de Teams con un botón de reversión de un solo clic en caso de falsos positivos

Playbook B: Ráfaga anómala de acceso a SharePoint

• Desencadenador: alerta de Defender "Descarga de archivo inusual"
• Acciones:
  1. Etiquetar al usuario con UnderInvestigation mediante atributos de extensión de AAD
  2. Trasladar al usuario a una directiva de CA que lo redirija a App Control (bloqueando descargas e impresión)
  3. Iniciar una retención de eDiscovery en los sitios de SharePoint afectados (opcional, según las necesidades de cumplimiento)
  4. Expirar automáticamente la contención a las 72 horas, salvo que el SOC la prorrogue manualmente

Búsqueda proactiva y consultas útiles

La búsqueda proactiva te ayuda a detectar huecos antes de que los atacantes los exploten. Usa estas consultas en la búsqueda avanzada de M365 Defender:

Aumento de accesos a sitios de SharePoint por parte de un usuario frente a su línea base de 30 días:

let lookback=30d;
let recent=1h;
let baseline = CloudAppEvents
    | where Timestamp between (ago(lookback) .. ago(recent))
    | where Application == "SharePoint" and ActionType == "FileAccessed"
    | summarize uniqSites=dcount(SiteUrl) by AccountUpn;
CloudAppEvents
| where Timestamp >= ago(recent)
| where Application == "SharePoint" and ActionType in ("FileDownloaded","FileAccessed")
| summarize curSites=dcount(SiteUrl), dls=sumif(1, ActionType=="FileDownloaded") by AccountUpn
| join kind=leftouter baseline on AccountUpn
| where curSites > 3 * coalesce(uniqSites,1) or dls > 500

Picos de riesgo de inicio de sesión estrechamente relacionados con alertas posteriores de DfI:

let riskySignIns = IdentityLogonEvents
| where RiskLevelDuringSignIn in ("medium","high")
| project AccountUpn, Timestamp, RiskLevelDuringSignIn;
let dfiAlerts = IdentityDirectoryEvents
| where EventType startswith "DefenderForIdentity"
| project AccountUpn, DfiTime=Timestamp, AlertType=EventType;
riskySignIns
| join kind=inner dfiAlerts on AccountUpn
| where DfiTime between (Timestamp .. Timestamp + 4h)

Métricas que demuestran que funciona

Al informar a la dirección, necesitas métricas que demuestren una reducción tangible del riesgo. Haz seguimiento de estos indicadores clave de rendimiento:

• Tiempo medio de contención (MTTC) para incidentes de identidad (tiempo desde la generación de la alerta hasta la aplicación de CA) ↓
• Tiempo de permanencia del atacante (tiempo desde la primera acción sospechosa hasta la remediación completa) ↓
• Sesiones de riesgo bloqueadas (eventos activados por directivas) ↑ mientras que la tasa de falsos positivos ↓
• Antigüedad de los usuarios de riesgo pendientes (casos abiertos con más de 24 horas) ↓
• Latencia de revocación de tokens (medida en segundos) ↓
• Errores de elevación privilegiada por riesgo (detectados a tiempo, antes de que se produzca un daño) ↑ y, después, estabilizándose con el tiempo
• Puntuación segura en Identidad, Dispositivos y Aplicaciones ↑ sin un aumento correspondiente de las incidencias en la mesa de ayuda

Estrategia de despliegue 30/60/90

Evita intentar cambiarlo todo de golpe. Sigue este calendario por fases:

Días 0–30 (Fundamentos)

• Habilita la configuración de riesgo de usuario e inicio de sesión de Entra y despliega las directivas base de CA en modo de auditoría; después, pasa a modo de aplicación.
• Incorpora Defender for Identity a M365 Defender; valida las alertas y las asignaciones de entidades principales.
• Activa la Evaluación continua de acceso (CAE) para las aplicaciones compatibles e integra el riesgo del dispositivo de MDE con el cumplimiento de Intune.

Días 31–60 (Retroalimentación y contención)

• Crea los playbooks A y B en Logic Apps; pruébalos exhaustivamente en un estado de simulación.
• Haz un piloto de App Control para sesiones no administradas con de 2 a 3 equipos de negocio colaborativos.
• Implementa la directiva de protección de elevación de PIM.

Días 61–90 (Aplicación y medición)

• Cambia tus playbooks automatizados al modo enforce completo para las alertas de alta confianza.
• Crea un libro de seguridad de identidades (en Sentinel o Power BI) que haga seguimiento de las métricas indicadas anteriormente.
• Realiza trimestralmente un simulacro de purple team para validar tu MTTC, la velocidad de revocación de tokens y los cambios de directivas de CA en un escenario real.

Errores comunes (y valores predeterminados más seguros)

Ten cuidado con estos errores habituales durante la implementación:

• Error común: confiar únicamente en el riesgo de inicio de sesión de CA → Solución: reacciona también ante el riesgo del usuario y las alertas de DfI posteriores a la autenticación.
• Error común: no tener CAE configurado, lo que permite que los tokens obsoletos mantengan activas las sesiones comprometidas → Solución: habilita CAE e incorpora la revocación de tokens directamente en tus playbooks automatizados.
• Error común: bloquear las descargas de archivos de forma generalizada en toda la organización, lo que provoca el rechazo de los usuarios → Solución: aplica App Control de forma selectiva, solo cuando las sesiones sean no administradas o de riesgo.
• Error común: tormentas de alertas y falsos positivos provocados por flujos de autocompromiso demasiado agresivos → Solución: condiciona tus automatizaciones a una verificación con múltiples señales (por ejemplo, alerta alta de DfI + volumen de descargas inusual + acceso fuera del horario laboral).
• Error común: cuentas de acceso de emergencia bloqueadas por error por directivas de riesgo automatizadas → Solución: excluye dos cuentas de acceso de emergencia muy supervisadas y rota sus credenciales trimestralmente.

Fragmentos listos para copiar y pegar

Para ayudarte a comunicar estos cambios en toda la organización, usa estos fragmentos ya preparados:

Resumen de una frase para directivos (CAB):

Hemos conectado correctamente el comportamiento del usuario posterior al inicio de sesión con nuestras decisiones de control de acceso. Si una cuenta empieza a comportarse de forma inusual, añadimos fricción de seguridad o bloqueamos el acceso durante la sesión. Esto reduce drásticamente el tiempo de permanencia del atacante sin ralentizar el trabajo diario normal.

Nota de cambio para administradores:

• Las nuevas directivas de acceso condicional pueden solicitar MFA reforzada o bloquear el acceso cuando se detecte un riesgo anómalo. Los tokens de autenticación activos ahora pueden revocarse durante la sesión en función de la telemetría. Las cuentas de acceso de emergencia siguen excluidas explícitamente. Revisa el libro de resiliencia de identidades para analizar el impacto.

Tarjeta de notificación de Teams para propietarios (automatizada):

• "Hemos detectado actividad inusual con archivos desde tu cuenta. Hemos aplicado protecciones temporales (como desactivar las descargas en dispositivos no administrados). Si fuiste tú, simplemente haz clic en Confirmar; si no, haz clic en Informar de inmediato."