Gobernanza de la fatiga de MFA y los ataques de bombardeo de notificaciones push

La notificación push de las 2:13 a. m. que se convirtió en una cuestión para el Consejo de Administración

A las 2:13 a. m., una administradora sénior de finanzas recibe una notificación móvil: «¿Aprobar inicio de sesión?». Está medio dormida, asume que se trata del vencimiento de una sesión en una plataforma financiera en la nube y pulsa aprobar.

A las 2:19 a. m., el atacante ya está dentro del proveedor de identidad. A las 2:31 a. m., intenta acceder a una exportación de nóminas, a una consola en la nube con privilegios y a un buzón compartido utilizado para pagos a proveedores. A las 3:05 a. m., el SOC observa solicitudes de MFA repetidas, una ubicación geográfica inusual, una aprobación correcta y una nueva sesión desde un dispositivo no gestionado.

La conversación de la mañana resulta familiar:

• «Pero teníamos MFA».
• «¿Por qué lo aprobó la usuaria?»
• «¿Registramos los detalles del desafío de MFA?»
• «¿Es esto una brecha de datos personales?»
• «¿Tenemos obligaciones de notificación en 24 o 72 horas?»
• «¿Nuestro auditor de ISO 27001:2022 lo tratará como un fallo de control?»
• «¿Afecta esto a NIS2, DORA, el RGPD de la UE, los contratos con clientes o el ciberseguro?»

Esta es la brecha de gobernanza que subyace a la fatiga de MFA y al bombardeo de notificaciones push. Los atacantes no están rompiendo la criptografía. Están agotando la capacidad humana de decisión, explotando un diseño de autenticación débil y buscando excepciones no supervisadas. El fallo de control rara vez es «MFA no habilitada». Normalmente es una cadena de aseguramiento de identidad débil, diseño arriesgado de aprobación push, ausencia de coincidencia numérica, reglas poco claras para el acceso privilegiado, registro insuficiente de eventos de autenticación, triaje deficiente de alertas, usuarios sin formación suficiente y ausencia de evidencias documentadas de que la organización revisó y corrigió la debilidad.

Para los CISO, responsables de cumplimiento, auditores y responsables de negocio, la fatiga de MFA debe tratarse como un problema de evidencias del SGSI, no solo como una configuración del proveedor de identidad. La respuesta combina el tratamiento de riesgos de ISO 27001:2022, los controles de ISO/IEC 27002:2022, las obligaciones de la política, la concienciación de usuarios, la respuesta a incidentes, la gobernanza de proveedores y las correspondencias entre marcos para NIS2, DORA, el RGPD de la UE, NIST CSF 2.0 y COBIT 2019.

La fatiga de MFA es un fallo de aseguramiento, no un problema del usuario

La fatiga de MFA, también denominada bombardeo de notificaciones push o bombardeo de solicitudes, se produce cuando un atacante con una contraseña válida activa repetidamente solicitudes de aprobación de MFA hasta que el usuario acepta una. En ocasiones, el atacante añade ingeniería social, como una llamada falsa de mesa de ayuda, un mensaje que afirma «estamos probando tu cuenta» o una petición para aprobar un inicio de sesión con el fin de detener las notificaciones.

El riesgo operativo es que las organizaciones suelen tratar todas las formas de MFA como equivalentes. No lo son.

Una notificación push simple de «aprobar o denegar» es más débil que la coincidencia numérica, las llaves de seguridad FIDO2 resistentes al phishing, la autenticación basada en certificados o el acceso condicional que bloquea viajes imposibles y dispositivos no gestionados. La MFA también falla cuando las excepciones de elusión no están documentadas, las cuentas de servicio son interactivas, los protocolos heredados siguen habilitados o el acceso de alto riesgo no exige autenticación más robusta.

En el Zenith Blueprint: An Auditor’s 30-Step Roadmap, Clarysec sitúa la autenticación segura en la fase Controles en acción, paso 19: Controles tecnológicos I. La orientación es directa:

La autenticación es la primera y más crítica línea de defensa entre un actor de amenaza y sus sistemas, datos y servicios. Si la autenticación es débil, todo lo demás —cifrado, supervisión, segmentación— puede eludirse.

El mismo Zenith Blueprint también aborda el control 5.17 de ISO/IEC 27002:2022 en el paso 22:

Si la identidad es la pregunta «¿quién eres?», la autenticación es la prueba. El control 5.17 es donde la teoría se convierte en confianza. Exige que la información de autenticación se gestione de forma segura durante todo su ciclo de vida, garantizando que los métodos y credenciales utilizados para verificar la identidad no se conviertan en el eslabón más débil.

Estas dos afirmaciones explican por qué el bombardeo de notificaciones push debe figurar en el Registro de Riesgos. El cifrado no ayuda si el atacante se convierte en un usuario aprobado. La segmentación de red ayuda menos si el acceso privilegiado a la nube se aprueba mediante una solicitud aceptada por fatiga. La supervisión solo funciona si los eventos de autenticación se registran con suficiente detalle y se revisan con rapidez.

Una declaración de riesgo madura debe ser explícita:

Aquí es donde ISO 27001:2022 resulta relevante. La norma exige contexto, partes interesadas, liderazgo, evaluación de riesgos, planificación del tratamiento, control operacional, supervisión, auditoría interna, revisión por la dirección y mejora continua. La fatiga de MFA afecta a todos estos elementos.

El conjunto de controles de ISO 27001:2022 que probarán los auditores

ISO 27001:2022 proporciona la estructura del sistema de gestión. ISO/IEC 27002:2022 proporciona orientación de implantación para los controles. Para la fatiga de MFA y el bombardeo de notificaciones push, los auditores normalmente se centrarán en un conjunto de controles, no en un único control.

Zenith Controls: The Cross-Compliance Guide de Clarysec establece la correspondencia del control 8.5 Autenticación segura de ISO/IEC 27002:2022 con controles de apoyo como 5.17 Información de autenticación, 8.2 Derechos de acceso privilegiado, 8.16 Actividades de supervisión, 5.24 Planificación y preparación de la gestión de incidentes de seguridad de la información y 5.34 Privacidad y protección de la información de identificación personal (PII). Esta relación cruzada es importante porque una captura de pantalla que muestre «MFA habilitada» no basta. Los auditores quieren pruebas de que la autenticación se diseña, supervisa, revisa y mejora en función del riesgo.

Un paquete de evidencias defendible debe incluir:

1. Evaluación de riesgos que identifique el bombardeo de notificaciones push y la ingeniería social sobre solicitudes de MFA.
2. Estándar de autenticación que defina los métodos de MFA aceptables según la criticidad del sistema.
3. Política de acceso privilegiado que exija autenticación reforzada para acceso administrativo y remoto.
4. Exportación de configuración del proveedor de identidad que muestre coincidencia numérica, límites de solicitudes, acceso condicional y autenticación heredada bloqueada.
5. Registros que muestren eventos de MFA correctos y fallidos, solicitudes denegadas, viajes imposibles y contexto del dispositivo.
6. Reglas de alerta para solicitudes repetidas de MFA, fallos repetidos y aprobaciones correctas inusuales.
7. Registros de respuesta a incidentes para alertas relacionadas con autenticación.
8. Contenido de formación y concienciación que indique a los usuarios que no aprueben solicitudes inesperadas.
9. Registros de revisión de accesos para sistemas privilegiados y de alto impacto.
10. Registro de Excepciones con fechas de caducidad, aprobaciones del Propietario del Riesgo y controles compensatorios.

La política convierte «no aprobar solicitudes inesperadas» en evidencias

Muchas organizaciones indican a los usuarios que no aprueben solicitudes sospechosas. Ese consejo es útil, pero no basta para la certificación ISO 27001:2022, la supervisión NIS2, la resiliencia DORA, la responsabilidad proactiva del RGPD de la UE, la diligencia debida de clientes o el ciberseguro.

El primer anclaje de política es P38 Secure Communications and Multi-Factor Authentication (MFA) Policy. Aborda directamente el factor humano:

Concienciación de usuarios: los usuarios deberán recibir formación para distinguir los canales de comunicación seguros de los inseguros. La formación deberá cubrir el uso adecuado de la autenticación multifactor (MFA) (por ejemplo, no aprobar solicitudes inesperadas de inicio de sesión) y las prácticas de comunicación segura (por ejemplo, verificar enlaces de videoconferencia y no tratar asuntos confidenciales por canales no seguros).

Esto convierte la fatiga de MFA en una obligación de formación, no en un ejercicio de atribución de culpa. Permite al CISO demostrar que el bombardeo de solicitudes está cubierto en la incorporación, la formación de reciclaje, la formación basada en roles y las sesiones informativas para usuarios privilegiados.

La misma P38 Secure Communications and Multi-Factor Authentication (MFA) Policy también crea una obligación de supervisión:

Seguridad de la Información deberá supervisar de forma continua los registros de autenticación para detectar cualquier intento de inicio de sesión con un único factor o fallos anómalos de autenticación multifactor (MFA). Los registros de los sistemas de comunicaciones seguras, cuando proceda, deberán supervisarse para detectar intentos de acceso no autorizado o cambios de configuración.

Para las pymes, P11S User Account and Privilege Management Policy - SME establece una base práctica:

La autenticación multifactor (MFA) debe estar habilitada, cuando sea técnicamente viable, para cuentas de administrador o sistemas sensibles.

La frase «cuando sea técnicamente viable» nunca debe convertirse en una laguna. Si un sistema no admite MFA robusta, la excepción debe registrarse con un propietario, fecha de caducidad, controles compensatorios, supervisión y un plan de migración. Las organizaciones de mayor tamaño pueden alinear la misma expectativa con P11 User Account and Privilege Management Policy y, después, comprobar si la política y la realidad operativa coinciden.

Las evidencias de detección proceden de P22S Logging and Monitoring Policy - SME, que exige el registro de eventos de autenticación:

Registros de autenticación: intentos de inicio de sesión correctos y fallidos, duración de sesión, uso de MFA

También exige la revisión urgente de señales de autenticación de alto riesgo:

Revisión inmediata tras la detección de alertas de alta severidad (por ejemplo, malware, fallos de autenticación multifactor (MFA), fallos repetidos de inicio de sesión)

La concienciación debe evolucionar a medida que evolucionan las amenazas. Information Security Awareness and Training Policy - SME apoya ese ciclo:

Los temas deben incluir amenazas emergentes (por ejemplo, phishing), cambios relevantes en las políticas y tendencias de incidentes internos.

Cuando el SOC detecte intentos de fatiga de MFA, esa inteligencia debe incorporarse a alertas para usuarios, guiones de mesa de ayuda, ejercicios de simulación y actualizaciones de formación.

Un paquete de controles gobernado para la fatiga de MFA

Suponga que su organización utiliza un proveedor de identidad en la nube, un CRM SaaS, una plataforma financiera, una VPN y un proveedor de servicios de seguridad gestionados. El objetivo es gobernar la fatiga de MFA utilizando el Zenith Blueprint de Clarysec, la biblioteca de políticas y la guía de correspondencia de cumplimiento Zenith Controls.

Empiece por el paso 19 del Zenith Blueprint, que indica a los equipos que definan requisitos de autenticación por sistema y advierte que debe evitarse la autenticación solo con contraseña para cuentas administrativas, consolas en la nube, herramientas de acceso remoto y sistemas expuestos a internet. A continuación, aplique la actividad práctica de revisión:

Revise su despliegue de MFA: identifique cualquier brecha y planifique su cierre. Valide que las cuentas de servicio sean no interactivas cuando sea posible, tengan credenciales robustas y estén documentadas. Confirme que no quedan credenciales por defecto en ningún sistema o aplicación.

Convierta esa orientación en un paquete operativo de controles.

Paso 1: clasificar los sistemas según el riesgo de autenticación

Paso 2: eliminar el comportamiento push de alto riesgo

Para cuentas de administrador y de alto impacto, deshabilite la aprobación push básica. Utilice autenticadores resistentes al phishing siempre que sea posible. Cuando se mantenga el uso de push, exija coincidencia numérica, contexto de aplicación, contexto geográfico, vinculación del dispositivo y límites de frecuencia de solicitudes. Bloquee la autenticación heredada y exija reautenticación para sesiones de riesgo.

Paso 3: definir reglas de alerta para la fatiga de MFA

Una regla práctica de SIEM debe activarse cuando se produzca uno o más de estos patrones en una ventana breve:

• Tres o más solicitudes push de MFA para un mismo usuario.
• Dos solicitudes denegadas seguidas de una solicitud aprobada.
• Aprobación de MFA desde una nueva ubicación geográfica o desde un dispositivo no gestionado.
• Solicitud de MFA posterior a una señal de ataque de pulverización de contraseñas o relleno de credenciales.
• Aprobación de MFA para acceso privilegiado fuera del horario laboral habitual.
• Registro de un nuevo autenticador poco después de intentos fallidos de inicio de sesión.

La alerta debe crear un ticket de incidente, notificar al SOC o al Responsable de Seguridad y exigir medidas de contención: suspender la sesión, revocar tokens de actualización, exigir restablecimiento de contraseña, verificar el dispositivo, entrevistar al usuario, revisar el acceso durante la sesión y clasificar si se produjo impacto sobre datos personales o sobre un servicio crítico.

Paso 4: vincular los registros de privacidad e incidentes

Si la cuenta puede acceder a datos personales, aplique la PII Security and Access Control Policy. Exige autenticación robusta antes del acceso a PII de alto impacto:

[Ambos] El Responsable de Seguridad de la Información DEBE exigir autenticación robusta para el acceso privilegiado, remoto, administrativo o a PII de alto impacto antes de habilitar dicho acceso y registrar el requisito en REG12.

También exige definir el alcance del registro de eventos con PII:

[Ambos] El Propietario del sistema / Propietario de la aplicación DEBE definir el alcance del registro de eventos con PII para eventos de autenticación, eventos de acceso, acciones privilegiadas, actividad de exportación de PII y cambios materiales de configuración en REG12 antes del uso en producción o de un cambio material.

Cuando la supervisión sugiera acceso no autorizado a PII, crea una obligación de registro de incidente:

[Condicional] El Coordinador de Respuesta a Incidentes DEBE abrir o vincular un registro REG10 en el plazo de un día laborable cuando la supervisión indique sospecha de acceso no autorizado a PII, sospecha de comunicación de PII, sospecha de alteración de PII o sospecha de pérdida de disponibilidad de PII.

El escalado de privacidad se completa con la PII Incident and Breach Management Policy:

[Condicional] El Responsable de Privacidad / Responsable del PIMS DEBE evaluar los criterios de activación de notificación legales, sectoriales, del sector financiero, de ciberseguridad, contractuales, de clientes y de destinatarios del servicio aplicables a cada incidente de PII de alto impacto, y registrar el resultado de aplicabilidad en REG01, REG08 y REG10.

Esto es lo que convierte una alerta de MFA en evidencias aptas para auditoría en seguridad, privacidad y cumplimiento.

NIS2, DORA y RGPD de la UE: un incidente, preguntas diferentes

La fatiga de MFA es una prueba de estrés útil de correspondencia entre marcos porque afecta a gobernanza, higiene cibernética, control de acceso, detección de incidentes, acceso de proveedores y notificación de brechas de seguridad.

NIS2: responsabilidad de la dirección e higiene cibernética

NIS2 se aplica a muchas entidades esenciales e importantes, según el sector, el tamaño y la designación por el Estado miembro. El Article 20 atribuye responsabilidad a los órganos de dirección para aprobar las medidas de gestión del riesgo de ciberseguridad, supervisar su implantación y recibir formación. El Article 21 exige medidas técnicas, operativas y organizativas adecuadas, incluidas la gestión de incidentes, la higiene cibernética, la seguridad de la cadena de suministro, el control de acceso, la gestión de activos, la formación y la autenticación multifactor o la autenticación continua cuando proceda. El Article 23 introduce obligaciones de notificación escalonada para incidentes significativos, incluida la alerta temprana en las 24 horas siguientes al momento en que se tiene conocimiento y la notificación del incidente en un plazo de 72 horas.

Por tanto, un incidente de bombardeo de notificaciones push se convierte en una cuestión para el Consejo de Administración: ¿la MFA se diseñó de forma segura o simplemente se habilitó?

DORA: la autenticación como resiliencia operativa digital

Para las entidades financieras cubiertas, DORA es aplicable desde el 17 de enero de 2025. Exige gestión del riesgo de las TIC, detección, respuesta, recuperación, notificación de incidentes, pruebas de resiliencia operativa digital y gestión del riesgo de terceros de TIC.

El Article 9 de DORA aborda la protección y la prevención, incluidas las medidas de control de acceso y autenticación. El Article 10 aborda la detección de actividad anómala. El Article 17 exige un proceso de gestión de incidentes relacionados con las TIC. En un contexto DORA, las evidencias de fatiga de MFA deben demostrar que los activos de TIC afectados se identificaron, la supervisión detectó comportamiento anómalo, el incidente se clasificó utilizando criterios de impacto, se escaló a la Alta Dirección cuando fue necesario y las lecciones aprendidas se reintegraron en el marco de riesgo de las TIC.

RGPD de la UE: seguridad del tratamiento y responsabilidad proactiva

El Article 5(1)(f) del RGPD de la UE exige integridad y confidencialidad. El Article 5(2) exige responsabilidad proactiva. El Article 32 exige una seguridad adecuada al riesgo. El Article 4 define una brecha de datos personales como una brecha de seguridad que ocasiona la destrucción, pérdida o alteración accidental o ilícita de datos personales, o la comunicación o acceso no autorizados a dichos datos.

Si un incidente de fatiga de MFA afecta a datos personales, la pregunta sobre evidencias es sencilla: ¿puede la organización demostrar controles de autenticación, supervisión, respuesta a incidentes y evaluación de brechas de seguridad adecuados?

Correspondencia para ISO, NIST CSF 2.0, COBIT 2019 y evidencias de auditoría

NIST CSF 2.0 es útil porque traduce la gobernanza de MFA en resultados de GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND y RECOVER.

COBIT 2019 añade claridad de gobernanza. Un auditor orientado a COBIT puede revisar DSS05.04 Gestionar la identidad y el acceso lógico, DSS05 Gestionar los servicios de seguridad, APO13 Gestionar la seguridad y MEA03 Gestionar el cumplimiento de requisitos externos. El foco no es el proveedor de MFA. Es si la autenticación respalda los objetivos de negocio, si los derechos de acceso están gobernados, si la supervisión es eficaz y si la dirección recibe aseguramiento significativo.

Una correspondencia consolidada ayuda a los equipos de cumplimiento a evitar solicitudes de evidencias fragmentadas:

Qué pedirán auditores y reguladores

Un programa robusto de gestión de la fatiga de MFA debe superar varios estilos de auditoría. La guía de correspondencia de cumplimiento Zenith Controls de Clarysec muestra cómo se prueban los controles de ISO/IEC 27002:2022 en metodologías ISO, NIST, COBIT e ISACA.

Un programa débil dice: «Preguntamos al usuario y restablecimos la contraseña». Un programa gobernado produce una alerta SIEM, un ticket de incidente, un registro de revocación de sesión, evidencias de restablecimiento de contraseña, revisión del factor de MFA, análisis de registros de acceso, evaluación de PII, evaluación de criterios de activación de notificación, declaración de causa raíz, acciones correctivas y entrada para la revisión por la dirección.

Plan de acción de 30 días para la gobernanza de la fatiga de MFA

El objetivo no es la perfección en 30 días. El objetivo es visibilidad, propiedad y evidencias.

Semana 1: identificar y delimitar el alcance

• Enumerar todos los proveedores de identidad, VPN, consolas en la nube, plataformas SaaS y herramientas de acceso privilegiado.
• Identificar sistemas con datos personales, datos financieros, acceso al entorno de producción o funciones con impacto en el servicio.
• Exportar los métodos y excepciones actuales de MFA.
• Identificar cuentas externas y de proveedores.
• Añadir la fatiga de MFA y el bombardeo de notificaciones push al Registro de Riesgos.
• Asignar un Propietario del Riesgo y un propietario del tratamiento.

Semana 2: bastionar la autenticación

• Deshabilitar la autenticación heredada.
• Exigir MFA resistente al phishing para administradores cuando sea viable.
• Habilitar coincidencia numérica y contexto de aplicación para MFA push.
• Aplicar acceso condicional por ubicación, cumplimiento del dispositivo y viajes imposibles.
• Limitar las solicitudes push repetidas.
• Exigir reautenticación para acciones de alto riesgo.
• Hacer que las cuentas de servicio sean no interactivas cuando sea posible.
• Documentar excepciones con caducidad y controles compensatorios.

Semana 3: supervisar y ensayar

• Asegurarse de que los registros de autenticación capturan éxito, fallo, duración de sesión y uso de MFA.
• Crear reglas de alerta para solicitudes repetidas, solicitudes denegadas seguidas de aprobación, registro de nuevo dispositivo y ubicación inusual.
• Probar las alertas mediante una simulación controlada.
• Validar la creación y el escalado de tickets de incidente.
• Formar a los usuarios con un ejercicio breve sobre «solicitud de MFA inesperada».
• Actualizar los guiones de mesa de ayuda para prevenir ingeniería social durante restablecimientos de contraseña y nuevo registro de MFA.

Semana 4: evidencias y revisión por la dirección

• Conservar exportaciones de configuración y capturas de pantalla.
• Registrar los resultados de las revisiones de acceso.
• Vincular la finalización de formación con usuarios privilegiados.
• Revisar incidentes y cuasi incidentes.
• Actualizar la Declaración de Aplicabilidad y el plan de tratamiento.
• Presentar el riesgo residual y las métricas a la dirección.
• Programar muestreo de auditoría interna.

Haga auditable la fatiga de MFA antes de que sea notificable

La fatiga de MFA recuerda que los controles de seguridad fallan en las uniones: entre identidad y supervisión, entre política y formación, entre proveedores y acceso interno, entre respuesta a incidentes y notificación de privacidad.

Las organizaciones que la gestionan bien no se limitan a «activar MFA». Gobiernan la autenticación como un ciclo de vida, la supervisan como una señal de amenaza, forman a los usuarios como parte del control y preservan evidencias como parte del SGSI.

Clarysec integra tres activos:

• El Zenith Blueprint: An Auditor’s 30-Step Roadmap, especialmente el paso 19 para autenticación segura, el paso 22 para información de autenticación y el paso 16 para la notificación de incidentes impulsada por el personal.
• Plantillas de políticas de Clarysec, incluidas P38 Secure Communications and Multi-Factor Authentication (MFA) Policy, P22S Logging and Monitoring Policy - SME, P11S User Account and Privilege Management Policy - SME, Information Security Awareness and Training Policy - SME, PII Security and Access Control Policy y PII Incident and Breach Management Policy.
• Zenith Controls: The Cross-Compliance Guide, que establece la correspondencia de los controles 5.17, 8.5, 8.15 y 8.16 de ISO/IEC 27002:2022 con controles de apoyo, expectativas de auditoría ISO, RGPD de la UE, NIS2, DORA, NIST y COBIT.

Si es CISO, responsable de cumplimiento, auditor o responsable de negocio, ejecute una revisión de evidencias de fatiga de MFA de una semana. Reúna la configuración de MFA, los registros de autenticación, la lista de accesos privilegiados, la lista de accesos de proveedores, el procedimiento de actuación ante incidentes, el material de formación y el Registro de Excepciones. Si esos artefactos no cuentan una historia coherente, Clarysec puede ayudarle a construir el paquete de controles antes de que lo soliciten un atacante, un auditor o un regulador.

Explore el Zenith Blueprint, revise Zenith Controls o programe una llamada de descubrimiento con Clarysec para convertir la fatiga de MFA de una sorpresa para el Consejo de Administración en un programa de autenticación defendible y auditable.