El simulador de Microsoft 365 no es gestión de riesgo humano

El Attack Simulation Training, la herramienta de simulación de phishing incluida en Microsoft Defender para Office 365, hace bien lo que promete: envía correos de prueba realistas, mide quién hace click y asigna capacitación a quien cae. Lo que no hace es validar que el comportamiento de esa persona cambió después del fallo, y esa es justo la pregunta que un programa de gestión de riesgo humano (Human Risk Management, HRM), la disciplina que mide y reduce el riesgo que viene de las personas, existe para responder. La diferencia no es de calidad, es de alcance: una cosa es medir envíos y clicks, otra es demostrar que alguien dejó de ser vulnerable. Confundirlas deja a la organización con reportes llenos y con la pregunta importante sin responder.

Qué hace bien el Attack Simulation de Microsoft 365

Empecemos por reconocer lo que el simulador nativo resuelve, porque no es poco. El dato que justifica su existencia es de CISA, la agencia de ciberseguridad de Estados Unidos: más del 90 por ciento de los ciberataques exitosos comienzan con un correo de phishing. Probar a los empleados con correos simulados no es opcional, y para una empresa que ya vive en Microsoft 365 tener esa prueba integrada en su propia consola es una ventaja real.

El alcance documentado por Microsoft es serio. Las técnicas de ingeniería social están curadas del marco MITRE ATT&CK, el catálogo público de tácticas de atacantes, e incluyen robo de credenciales, adjunto con malware, enlace dentro de un adjunto, enlace a malware, drive-by URL y abuso del consentimiento de OAuth; el enlace puede ser una URL o un código QR. Trae un catálogo de plantillas integrado, permite crear plantillas propias y hasta capturar versiones inofensivas de correos de phishing reales detectados en el propio tenant para reutilizarlas como simulación. Las automatizaciones programan campañas con varias técnicas a la vez, y los reportes responden lo operativo: quién recibió el correo, quién hizo click, quién entregó credenciales, quién lo reportó y quién completó la capacitación asignada. Incluso estima una tasa de compromiso prevista por plantilla, calculada con datos históricos agregados de Microsoft 365.

El requisito es la licencia: viene con Microsoft Defender para Office 365 Plan 2, incluido en Microsoft 365 E5, y con E3 solo hay una versión de prueba recortada. Muchas empresas medianas de LATAM que viven en planes Business no lo tienen completo, y conviene saberlo antes de dar por hecha la herramienta. Cómo encaja la protección del empleado dentro del ecosistema de Microsoft la tratamos en nuestra pieza sobre seguridad para empleados en Microsoft 365.

Dónde se queda corto: sin retest, un solo canal, sin monitoreo de credenciales y sin selección por persona

El límite más importante es el que menos se ve en un reporte. Cuando alguien cae en una simulación, el simulador nativo le asigna capacitación y mide si la completó. Lo que la documentación de Microsoft no describe es un retest individual programado: volver a probar a esa misma persona semanas después, con otra plantilla de la misma categoría, para verificar que aprendió a reconocer el patrón y no que recordó un correo. Lo más cercano que documenta Microsoft es el grupo sugerido de reincidentes (repeat offenders, quienes cayeron en simulaciones consecutivas), que el administrador puede incluir como objetivo de una campaña nueva; sigue siendo una campaña armada a mano, no una validación automática de que cada persona aprendió la lección. Sin esa segunda prueba, la organización sabe quién cayó y quién terminó el curso, pero no sabe quién sigue siendo vulnerable, que es lo único que importa para el riesgo. Completar una capacitación y cambiar el comportamiento son dos cosas distintas, y ya explicamos cómo medir si la capacitación en seguridad funciona sin confundirlas.

El segundo límite es el canal. Toda la simulación vive en el correo: el enlace, el adjunto y hasta el código QR llegan a la bandeja de entrada. Las llamadas de voz falsas y los mensajes de texto fraudulentos, que atacan a la misma persona por canales que el correo no ve, quedan fuera del alcance de la herramienta.

El tercero es la exposición real. El simulador no monitorea si las credenciales de los empleados aparecieron en brechas de datos o en la dark web, así que sus pruebas no distinguen entre la persona cuya contraseña ya circula entre atacantes y la que no tiene exposición conocida. La simulación opera a ciegas del riesgo que ya existe.

Y el cuarto es quién elige la plantilla. En el simulador nativo, el administrador selecciona las plantillas y los grupos objetivo por campaña; la tasa de compromiso prevista ayuda a comparar plantillas, pero es una predicción agregada, no una selección por persona. La propia documentación sugiere crear simulaciones idénticas por departamento para comparar cuál es más vulnerable, es decir, la segmentación es manual. Un programa de riesgo humano invierte esa lógica: cruza el rol, el historial de fallos y la exposición de cada persona para enviarle el engaño que más probablemente la haría caer, porque ahí es donde la prueba revela algo.

Tabla: simulador nativo frente a programa de gestión de riesgo humano

La comparación por alcance queda más clara en una tabla. No son rivales: uno es una función de una suite de correo, el otro es un programa completo sobre las personas.

Qué debería exigir un CISO que ya vive en Microsoft 365

La respuesta corta: no descartar el simulador, pero no confundirlo con el programa. El marco 90-5-5 de Cisco, que estima que cerca del 90 por ciento de las brechas involucran un factor humano, pone la vara de lo que ese programa debe demostrar: si las personas son la principal superficie de riesgo, la métrica que importa es si su comportamiento mejora, no cuántos correos de prueba se enviaron.

De ahí salen las exigencias concretas. Primero, retest individual: que quien cayó sea probado de nuevo con otra plantilla de la misma categoría, porque esa es la única evidencia de cambio real. Segundo, consecuencia en el puntaje de riesgo: que un fallo pese en el indicador de esa persona hasta que demuestre resistencia sostenida, no hasta que termine un video. Tercero, conexión con la exposición real: que las credenciales filtradas de un empleado influyan en qué simulación recibe y en su prioridad de remediación. Y cuarto, reportes que hablen de comportamiento: la dirección no necesita saber cuántos clicks hubo, necesita saber si la organización resiste mejor que hace un trimestre.

Un CISO que ya paga E5 puede cubrir la línea base con lo nativo y exigir estas cuatro cosas a cualquier plataforma que evalúe encima. Uno que no tiene E5 debería evaluar directamente por estas exigencias, porque va a pagar de todos modos y le conviene pagar por el alcance completo.

Ese ciclo de exigencias (monitoreo de credenciales filtradas, simulación personalizada por persona y retest que valida el cambio) es el caso de uso donde trabaja Fensivo, como complemento del entorno de Microsoft 365 y no como reemplazo de sus controles. La plataforma vuelve a probar a quien cayó y responde la pregunta que el simulador nativo deja abierta. Puedes ver cómo lo abordamos en los casos de uso de Fensivo.

¿Qué responderías hoy si la dirección te pidiera demostrar, con datos, que la persona que cayó el mes pasado ya no caería?

Fuentes y referencias

• CISA, "4 Things You Can Do To Keep Yourself Cyber Safe". cisa.gov
• Cisco, "The 90-5-5 Concept: Your Key to Solving Human Risk in Cybersecurity", 27 de mayo de 2025. blogs.cisco.com