El ransomware entra por la puerta del usuario: el 80% de los ataques en España arranca con identidades comprometidas

El atacante ya no fuerza la puerta: entra con tu llave

Durante años, buena parte del discurso de ciberseguridad en banca y seguros giró alrededor del malware, del ransomware o del gran exploit del mes. Era cómodo. Permitía imaginar al atacante como alguien que irrumpe desde fuera, hace ruido y deja huella. El problema es que una porción creciente de incidentes serios no se parece a esa caricatura. Se parece más a un acceso aparentemente legítimo, con credenciales válidas, privilegios mal gobernados y una cadena de confianza que nadie revisó a tiempo.

Eso no convierte al phishing en una reliquia ni al malware en un problema menor. Lo que sí cambia el foco operativo es otra cosa: muchas intrusiones relevantes no necesitan “romper” nada si pueden aprovechar una identidad ya comprometida o una cuenta con más permisos de los que debería tener. El matiz importa, porque desplaza la conversación desde la prevención genérica hacia controles concretos sobre autenticación, privilegios, monitorización de sesiones y respuesta temprana.

Aquí está el quid: una organización puede cumplir su checklist de seguridad y, aun así, dejar abierta la vía que más daño hace cuando falla. Porque no basta con tener MFA “implantado”, ni con revisar accesos una vez al año, ni con decir que el directorio está “bastante limpio”. Si un proveedor externo mantiene acceso persistente, si una cuenta de servicio no rota secretos, o si un administrador conserva privilegios permanentes que nadie justifica, el castillo sigue teniendo foso, sí, pero el puente levadizo está bajado.

La lección incómoda: identidad y privilegios ya no son un subtema de IAM

El artículo 21 de NIS2 obliga a las entidades esenciales e importantes a aplicar medidas técnicas, operativas y organizativas adecuadas y proporcionadas para gestionar riesgos, incluyendo políticas de análisis de riesgos, gestión de incidentes, continuidad, seguridad de la cadena de suministro y uso de autenticación multifactor o autenticación continua, cuando proceda. No es un apéndice decorativo. Es una pista bastante clara de por dónde creen los legisladores que se rompe hoy la seguridad operativa.

DORA va por la misma vía, aunque con gramática financiera y dientes supervisores propios. El artículo 9 exige marcos sólidos de gestión del riesgo ICT. El artículo 10 entra en la protección y prevención, con medidas para minimizar el impacto de los riesgos ICT, detectar actividades anómalas y evitar accesos no autorizados. Y el artículo 28 coloca el riesgo de terceros proveedores TIC en el centro de la mesa, justo donde más duele cuando una cuenta de un proveedor, integrador o soporte técnico se convierte en atajo hacia sistemas críticos.

Si uno cruza esas exigencias con la realidad operativa, aparece una conclusión menos glamourosa que un debate sobre inteligencia artificial pero bastante más urgente: identidad, acceso y privilegios han dejado de ser una función administrativa del área de IAM. Ahora son control prudencial, ciberresiliencia y, en entidades reguladas, un asunto de consejo de administración aunque el consejo preferiría hablar de otra cosa.

La ironía es conocida por cualquier CISO con algo de cicatrices. Los comités aprueban inversiones millonarias en detección avanzada, threat intelligence y herramientas de respuesta orquestada, pero todavía toleran cuentas huérfanas, privilegios heredados, federaciones con terceros sin revisión periódica y excepciones eternas a MFA “porque rompería el proceso”. Luego llega el incidente y todos descubren que el problema no era la falta de sofisticación tecnológica, sino un acceso demasiado confiable durante demasiado tiempo.

No basta con decir “tenemos MFA”

La autenticación multifactor sigue siendo una de las medidas más eficaces para reducir accesos no autorizados. Eso es cierto. También es insuficiente como mensaje de control. La pregunta útil no es si tu organización tiene MFA, sino dónde lo tiene, para qué casos, con qué resistencias al phishing, con qué exclusiones y con qué capacidad de detectar abuso de sesión tras una autenticación legítima.

Porque no todo MFA vale lo mismo. Un esquema basado en notificaciones push mal gobernadas, sin controles frente a fatiga de autenticación, deja una superficie de abuso conocida. Un segundo factor aplicado a usuarios internos pero no a accesos privilegiados de terceros deja exactamente la puerta que no debías dejar abierta. Y un despliegue formalmente completo que permite bypass por cuentas legacy, service accounts o accesos de emergencia permanentes es, en la práctica, una excepción convertida en arquitectura.

NIS2, en su artículo 21, no habla por casualidad de autenticación multifactor o continua. DORA, en su artículo 10, tampoco se limita a pedir “seguridad” en abstracto. Lo que están empujando es un modelo donde la autenticación es solo la primera capa, no la última. La siguiente capa es el gobierno del privilegio. La siguiente, la segmentación. Después, la capacidad de detectar comportamientos anómalos aunque la credencial sea válida. Si te quedas en el titular de “tenemos MFA”, te has quedado en la diapositiva, no en el control.

Y conviene decirlo sin rodeos: la mayoría de los fallos graves en este terreno no nacen de una incapacidad técnica. Nacen de una mezcla muy humana de comodidad operativa, deuda histórica y miedo a molestar al negocio. Nadie quiere ser la persona que corta el acceso remoto del proveedor que mantiene un sistema crítico. Nadie quiere retirar privilegios a un equipo que lleva años trabajando “así”. Hasta que ese “así” aparece en la cronología forense.

El privilegio es el verdadero multiplicador del daño

Una credencial comprometida no vale lo mismo si abre un buzón de correo que si abre la consola de administración, el bastión de acceso remoto o una herramienta de gestión de identidades. El privilegio convierte un incidente manejable en una crisis regulatoria. Por eso el debate serio no es solo sobre robo de credenciales, sino sobre qué puede hacerse con ellas una vez dentro.

El principio de mínimo privilegio no tiene nada de nuevo. Lo nuevo —o, mejor dicho, lo urgente— es aplicarlo de verdad en entornos complejos, híbridos y con capas de proveedores. Eso exige recertificaciones periódicas, privilegio just-in-time cuando sea viable, cuentas separadas para administración, restricciones por contexto, revisión de accesos de terceros y eliminación sistemática de privilegios permanentes que sobreviven por pura inercia.

DORA ayuda a aterrizar esta exigencia. El artículo 6 hace responsable al órgano de dirección de definir, aprobar, supervisar y responder por la implementación del marco de gestión del riesgo ICT. Si el privilegio excesivo está normalizado en una entidad financiera, no estamos ante un mero fallo técnico: estamos ante un fallo de gobernanza. Y cuando ese privilegio se extiende a terceros TIC, el artículo 28 deja poco margen para el autoengaño. La entidad financiera debe gestionar el riesgo derivado de esos terceros, no delegarlo emocionalmente en el contrato.

Hay una escena que se repite demasiado: la organización asegura que el acceso de proveedores está controlado porque existe un proceso de alta y baja. Luego rascas un poco y descubres cuentas compartidas, VPN sin segmentación, sesiones sin grabación, credenciales no rotadas tras cambios de personal del proveedor y privilegios administrativos que nadie revalida desde hace meses o años. El proceso existe. El control, bastante menos.

Cuando el tercero entra por soporte, el riesgo entra por la cadena de suministro

La conversación sobre terceros suele quedarse atrapada en la due diligence precontractual. Cuestionario, scoring, cláusulas, semáforo y a otra cosa. El problema es que el riesgo real no termina cuando se firma el contrato; empieza cuando el tercero obtiene acceso operativo. Y ahí el control de identidad deja de ser un asunto interno para convertirse en ciberseguridad de cadena de suministro.

DORA es explícito. El artículo 28 exige una gestión sólida del riesgo de terceros proveedores de servicios TIC como parte integrante del marco de gestión del riesgo ICT. Los artículos 30 y siguientes desarrollan requisitos contractuales, estrategia sobre dependencia de terceros, registros de información y vigilancia de concentraciones de riesgo. Si un proveedor tiene acceso remoto a sistemas críticos, esa relación ya no puede tratarse como una simple externalización IT gestionada con cortesía y un PDF anual.

NIS2 también aprieta por el mismo flanco. El artículo 21 incluye la seguridad de la cadena de suministro y la relación entre cada entidad y sus proveedores o prestadores de servicios directos. Dicho de forma menos diplomática: si el atacante aprovecha una cuenta válida de un tercero, al regulador le importará poco que la cuenta no fuera “tuya” en sentido emocional. El impacto sí será tuyo. La obligación de gestión del riesgo también.

Esto tiene consecuencias muy concretas. Si el soporte de un tercero puede conectarse a producción, deberías poder responder con precisión a preguntas básicas: quién accede, cómo accede, con qué segundo factor, durante cuánto tiempo, con qué privilegios, con qué trazabilidad y bajo qué aprobación previa. Si alguna de esas respuestas es ambigua, no tienes un acceso controlado; tienes una confianza heredada.

Detección: el punto ciego de las sesiones legítimas

Muchas capacidades de detección están diseñadas para identificar lo anómalo en términos clásicos: malware, beaconing, exfiltración, ejecución sospechosa, movimientos laterales. Todo eso sigue siendo esencial. Lo incómodo es que una sesión iniciada con credenciales válidas puede atravesar bastantes controles antes de levantar una alerta seria, sobre todo si el usuario o proveedor ya forma parte del “ruido normal” del entorno.

Por eso la defensa basada en identidad no se agota en autenticación y privilegios. Necesita telemetría sobre el comportamiento de la sesión: geografía imposible, horarios anómalos, salto brusco de privilegios, acceso a activos no habituales, patrones de administración atípicos, uso simultáneo desde contextos incompatibles o desviaciones respecto a la línea base del rol. No es magia. Es ingeniería de señales aplicada a una verdad incómoda: el acceso legítimo puede ser el mejor disfraz del acceso malicioso.

DORA, de nuevo, no va desencaminado. El artículo 10 pide mecanismos para detectar actividades anómalas, incluidos problemas de rendimiento de red y incidentes relacionados con las TIC, y para identificar posibles puntos únicos de fallo. Esa obligación encaja directamente con el reto de visibilidad sobre sesiones válidas. Si la entidad solo ve malware y no ve abuso de identidad, su capacidad de detección está incompleta en el punto exacto donde hoy puede sufrir más.

Hay además una implicación probatoria que muchas organizaciones subestiman. Cuando llega el incidente, no basta con saber que “la cuenta se usó”. Hay que reconstruir qué hizo, con qué permisos, sobre qué sistemas y durante cuánto tiempo. Sin trazabilidad suficiente, la respuesta técnica se ralentiza y la evaluación jurídica también. Y en entornos regulados, esa lentitud se traduce en más exposición supervisora, más incertidumbre sobre impacto y peores decisiones en las primeras horas.

GDPR no desaparece porque el incidente parezca “solo” de ciberseguridad

Un acceso indebido basado en credenciales válidas puede derivar en una violación de seguridad de datos personales aunque no haya ransomware, aunque no haya cifrado visible y aunque el incidente parezca inicialmente limitado a un entorno técnico. El artículo 4.12 del GDPR define la violación de seguridad de los datos personales como una violación de la seguridad que ocasione la destrucción, pérdida o alteración accidental o ilícita de datos personales transmitidos, conservados o tratados de otra forma, o la comunicación o acceso no autorizados a dichos datos.

Si hay datos personales afectados, el artículo 33 obliga a notificar a la autoridad de control sin dilación indebida y, de ser posible, a más tardar 72 horas después de haber tenido constancia de ella, salvo que sea improbable que la violación constituya un riesgo para los derechos y libertades de las personas físicas. El artículo 34 añade la comunicación a los interesados cuando sea probable que entrañe un alto riesgo.

Esto importa porque algunas organizaciones siguen gestionando los incidentes de identidad como si fueran exclusivamente un problema de acceso corporativo. Error. Si una cuenta comprometida permitió consultar expedientes de clientes, descargar datos de empleados o entrar en sistemas con información personal, la dimensión de privacidad aparece de inmediato. No después. De inmediato. Y si el registro de auditoría es pobre, determinar el alcance real de esa exposición será más lento justo cuando el reloj de las 72 horas ya está corriendo.

La tensión entre ciberseguridad y privacidad aquí no es teórica. El equipo técnico quiere contener. El jurídico quiere entender impacto y base factual. El negocio quiere saber si hay interrupción operativa. El regulador quiere coherencia entre relato, cronología y evidencias. Si la organización no ha preparado ese cruce antes del incidente, improvisará. Y la improvisación, en este tipo de crisis, suele dejar rastros bastante más duraderos que el propio acceso inicial.

La gobernanza que falla no suele fallar por ausencia de política, sino por exceso de tolerancia

Casi todas las entidades medianas y grandes tienen políticas de acceso, de contraseñas, de privilegios y de gestión de terceros. El problema rara vez es documental. El problema es la distancia entre la política y la excepción real. Excepción para cuentas legacy. Excepción para un proveedor estratégico. Excepción para un administrador “de confianza”. Excepción porque el sistema no soporta MFA moderno. Excepción porque el proyecto de PAM se quedó a medias. Excepción porque nadie quiere revisar una integración antigua que todavía funciona.

Cuando acumulas suficientes excepciones, dejas de tener un modelo de control y pasas a tener un museo de renuncias operativas. Ahí es donde la gobernanza de DORA pega de lleno. El artículo 5 y el artículo 6 atribuyen al órgano de dirección responsabilidad última sobre la gestión del riesgo ICT. No pide perfección. Pide dirección, supervisión y rendición de cuentas. Si la entidad conoce las excepciones críticas y no corrige plazos, compensaciones o caducidad, el problema deja de ser solo técnico. Es una decisión de gestión del riesgo, aunque nadie la escriba así en el acta.

El consejo no necesita saber configurar un IdP ni discutir protocolos de federación. Sí necesita saber algo mucho más incómodo: qué accesos privilegiados persisten sin justificación renovada, cuántos terceros pueden entrar en sistemas sensibles, qué cobertura real tiene la autenticación robusta en esos accesos y cuánto tardaría la entidad en revocar, investigar y contener si una identidad de alto privilegio se viera comprometida. Si no recibe esa información con claridad, está gobernando a ciegas.

Qué revisar ya si no quieres descubrirlo durante el incidente

Hay organizaciones que siguen tratando identidad y privilegios como proyectos largos, casi filosóficos, siempre prometedores y siempre inacabados. Mala idea. El enfoque útil aquí es menos épico y más quirúrgico: identificar primero los accesos cuya combinación de legitimidad aparente y capacidad de daño los convierte en material de crisis.

Empieza por cuatro zonas donde el riesgo suele concentrarse:

• Accesos privilegiados permanentes a administración de sistemas, directorio, cloud, EDR, backup y herramientas de seguridad. Si una de estas cuentas cae, el atacante no solo entra: puede desactivar la linterna.
• Accesos de terceros con conectividad remota a producción, soporte de aplicaciones críticas o administración de infraestructura. DORA art. 28 convierte este punto en prioridad regulatoria, no en buena práctica opcional.
• Cuentas no humanas como service accounts, claves API, secretos embebidos y automatizaciones con permisos amplios. Son esenciales y, a menudo, tremendamente poco visibles.
• Excepciones heredadas a MFA, segmentación, recertificación o grabación de sesiones. Una excepción aislada puede ser razonable. Cincuenta excepciones heredadas son un patrón de riesgo.

Después, formula preguntas binarias. No “tenemos un proceso”, sino “podemos demostrarlo ahora”. ¿Toda cuenta privilegiada usa autenticación reforzada sin bypass conocido? ¿Los terceros entran solo bajo aprobación y por tiempo acotado? ¿Las sesiones privilegiadas dejan trazabilidad suficiente? ¿La revocación de acceso ante baja o incidente funciona de forma rápida y verificable? ¿Existen cuentas cuyo privilegio nadie ha revalidado recientemente? Si la respuesta es “depende”, ya tienes trabajo real.

El error clásico: confundir cobertura de control con efectividad de control

Una entidad puede mostrar una cobertura amplia de herramientas y seguir expuesta por diseño. Tiene MFA, sí. Tiene PAM, también. Tiene SIEM, EDR, CASB, IAM y una política de recertificación. Todo eso suena impecable en una presentación. La pregunta es otra: ¿qué porcentaje de las cuentas que de verdad podrían agravar un incidente están dentro de esos controles sin excepción material? Y, más importante todavía, ¿quién verifica que el control opera como se cree que opera?

La efectividad se rompe en detalles desagradablemente concretos: una consola cloud federada con atributos mal mapeados; un rol privilegiado que hereda permisos históricos; una cuenta de servicio cuya rotación se pospone porque nadie quiere tocar una aplicación frágil; un proveedor que mantiene acceso VPN permanente porque “si no, el soporte tarda más”. Ninguno de estos fallos invalida el programa entero. Pero cada uno puede invalidar el relato complaciente de que el acceso está bajo control.

El regulador, además, cada vez mira menos la existencia formal del control y más su funcionamiento verificable. Esa lógica está en DORA cuando exige marcos, pruebas, monitorización y gestión continua del riesgo ICT, y está en NIS2 cuando habla de medidas adecuadas y proporcionadas, no de compra de herramientas. La era del control como casilla marcada dura poco cuando el incidente revela que la casilla estaba vacía por dentro.

Pruebas, crisis y la pregunta que casi nadie ensaya de verdad

Las pruebas de resiliencia suelen centrarse en caída de sistemas, ransomware, pérdida de conectividad o indisponibilidad de proveedores. Todo correcto. Pero hay un escenario que merece más protagonismo del que suele recibir: una identidad válida con privilegios suficientes para moverse sin disparar alarmas inmediatas. No es el incidente más vistoso. Puede ser el más traicionero.

DORA, en sus artículos 24 y siguientes, exige pruebas del marco de resiliencia operativa digital proporcionadas al tamaño, perfil de riesgo y complejidad de la entidad. Eso ofrece una oportunidad excelente para dejar de ensayar solo el desastre ruidoso y empezar a ensayar el acceso creíble. ¿Qué pasa si una cuenta de administración de un tercero muestra actividad anómala fuera de patrón? ¿Quién decide revocarla? ¿Cómo se mantiene el servicio? ¿Qué logs permiten delimitar alcance? ¿Cuándo se activa la evaluación de posible brecha de datos personales bajo GDPR art. 33? ¿Quién habla con el supervisor si la afectación toca funciones críticas?

Si la organización no ha trabajado esas preguntas antes, el incidente obligará a resolverlas a la carrera. Y la carrera, en materia de identidades privilegiadas, tiene un defecto de fábrica: cada minuto de duda puede ampliar el radio del daño o destruir evidencia útil para entenderlo.

La objeción habitual: “esto ya lo sabemos”

Sí, el sector sabe desde hace tiempo que las credenciales, los permisos y los terceros son puntos de riesgo. El problema no es ignorancia conceptual. Es prioridad real. Si algo merece crítica en buena parte de los programas de cumplimiento y ciberseguridad es esta costumbre de tratar riesgos viejos como si estuvieran ya resueltos por el mero hecho de ser conocidos.

Decir que identidad es importante no cambia nada. Traducirlo a decisiones incómodas sí: retirar privilegios permanentes, imponer autenticación fuerte sin excepciones blandas en accesos críticos, rediseñar el soporte remoto de terceros, instrumentar trazabilidad de sesiones, vincular recertificación de accesos a dueños de riesgo con nombre y apellidos y elevar al consejo métricas que muestren exposición real, no solo despliegue tecnológico.

La parte menos sexy de la seguridad suele ser la más decisiva. No porque el atacante haya dejado de usar otras técnicas, sino porque una cuenta válida con privilegios excesivos le ahorra trabajo y a ti te complica la defensa, la investigación, la notificación y la explicación posterior. Todo a la vez.

Lo que deberían hacer ahora las entidades reguladas

Si tu entidad está bajo DORA, NIS2 o ambas, la agenda útil para los próximos meses no necesita más eslóganes. Necesita decisiones. Primera: inventariar accesos privilegiados y de terceros con una precisión que aguante una auditoría, no una presentación. Segunda: revisar excepciones a MFA, grabación de sesión, segmentación y recertificación, con fecha de cierre o compensación formal. Tercera: validar que las cuentas no humanas y secretos críticos están bajo gobierno real, no bajo fe heredada. Cuarta: ensayar un incidente basado en identidad válida y privilegio alto, cruzando ciberseguridad, legal, privacidad, continuidad y comunicación regulatoria.

Ese cruce es donde muchas organizaciones aún pinchan. El equipo de seguridad suele ver primero el patrón técnico. El área de privacidad entra después. Compras y gestión de proveedores aparecen cuando ya hay tensión. El consejo recibe un resumen tardío. DORA y NIS2, leídas juntas, empujan en sentido contrario: gestión integrada del riesgo, terceros dentro del perímetro y responsabilidad de dirección desde el principio, no en la autopsia.

Si quieres una regla simple, aquí va una: trata cualquier identidad con capacidad de tocar procesos críticos, datos sensibles o controles de seguridad como un activo regulatorio de alto impacto. Porque lo es. Y si no la gobiernas como tal, el incidente no te preguntará si tenías una política. Te preguntará, con bastante mala leche, si tenías control.

La conclusión menos cómoda y más útil

La industria lleva años hablando de transformación digital, cloud y automatización como si la principal pregunta fuera la velocidad. Ya no lo es. La pregunta dura es cuánta confianza operativa has acumulado sin mecanismos suficientes para verificarla, limitarla y revocarla cuando toca.

Ni DORA ni NIS2 convierten por sí solos a una entidad en resistente. Pero ambos dejan claro algo que merece ser tomado al pie de la letra: la resiliencia no se juega solo en evitar el gran ataque, sino en gobernar accesos, privilegios y dependencias antes de que una sesión aparentemente legítima se convierta en un problema de continuidad, supervisión y privacidad a la vez.

La puerta principal sigue siendo importante. Solo que ahora conviene mirar también quién tiene copia de la llave, cuánto tiempo la conserva y por qué nadie revisó antes si aún debía tenerla.