Pruebas de DORA y observación de la exposición externa

Cuando el responsable de TI trae el informe de una prueba periódica de resiliencia, por lo general confirma una sola cosa: el sistema soportó las cargas y los escenarios de fallo previstos en un momento concreto. Entre dos pruebas de ese tipo pasa el tiempo. En ese intervalo un desarrollador abre un puerto nuevo para una integración, un proveedor de nube cambia un ajuste de seguridad por defecto y un contratista conecta su propio servicio a la API externa de la empresa. Si esos cambios permanecen invisibles hasta la siguiente prueba programada, la resiliencia que se dio por aprobada describe una configuración que ya no existe.

El Reglamento (UE) 2022/2554 (DORA) establece requisitos obligatorios para la gestión del riesgo de TIC. Uno de sus artículos clave exige a las entidades financieras probar con regularidad su resiliencia operativa digital. El propio reglamento no impone un método único ni una frecuencia única para esas pruebas: fija el objetivo, que es comprobar que la infraestructura digital puede seguir funcionando bajo tensiones y perturbaciones significativas. De ahí surge una pregunta que conviene plantear. ¿Basta con una instantánea periódica del sistema para cumplir el requisito, o hay puntos ciegos que ese enfoque no puede ver por su propia naturaleza?

Qué comprueban las pruebas de DORA

El artículo 26 del Reglamento (UE) 2022/2554 exige que las entidades financieras realicen pruebas periódicas de su resiliencia operativa digital (DORA, artículo 26). El objetivo de esas pruebas es evaluar la capacidad de la organización para seguir funcionando ante amenazas extremas pero verosímiles. No se trata de comprobar que los servidores están encendidos. Se trata de modelar escenarios como ciberataques a gran escala, fallos en proveedores críticos, pérdida de datos o caídas de componentes enteros de la infraestructura.

Conviene entender la naturaleza de este control: es un procedimiento de diagnóstico con un horizonte fijo. Se toma la configuración actual del sistema, se le aplica un conjunto de factores de estrés y se analiza el resultado. Ese enfoque resuelve una tarea importante: revela los puntos débiles de la arquitectura y de los procesos de recuperación. Una prueba puede mostrar que, si falla el canal de comunicación principal, el canal de respaldo se activa demasiado despacio e incumple los niveles de servicio acordados (SLA). O que las copias de seguridad no pueden restaurarse en un tiempo aceptable. Estos hallazgos tienen peso porque afectan a la resiliencia fundamental del negocio, no solo al detalle técnico.

Sin embargo, el enfoque tiene un límite estructural firme: trabaja con lo que existe en el momento en que arranca la prueba. La configuración del sistema se considera invariable durante el procedimiento. Si la configuración cambia entre pruebas —y en cualquier entorno de TI vivo cambia constantemente—, los resultados de la prueba anterior quedan en parte desactualizados.

Imagine un chequeo médico que pasó hace un mes. Los resultados fueron buenos. Si desde entonces sus hábitos han cambiado, su estado de salud real ya difiere de lo que dice la ficha. Con las pruebas de DORA ocurre algo parecido: dan una imagen precisa a la fecha en que se ejecutaron, pero no siguen lo que cambia después de esa fecha.

El punto ciego: el perímetro externo cambia

Para una organización financiera, el área de riesgo más sensible suele estar en la frontera con el mundo exterior: sitios web públicos, pasarelas de API, servidores de correo, accesos para socios externos. Ahí es donde se forma la superficie de ataque, es decir, el conjunto de todos los puntos por los que un intruso puede intentar entrar en el sistema.

La dificultad está en que el perímetro externo es la parte más dinámica de la infraestructura. Cada día se publican nuevos microservicios en internet. Proyectos antiguos quedan olvidados y dejan puertos abiertos. Los recursos de nube se crean y se eliminan de forma automática. Todos esos cambios influyen en el riesgo y ninguno de ellos se refleja en los resultados de la última prueba programada de DORA.

Si nos apoyamos solo en las pruebas periódicas, en la práctica decidimos el nivel de protección a partir de datos que han envejecido. Entre una prueba y otra puede ocurrir cualquiera de estas cosas:

Los desarrolladores abren un nuevo punto final de API para una integración con un socio.
La plataforma de nube actualiza la configuración del cortafuegos de red y abre por accidente el acceso a un servicio interno.
Un contratista crea un entorno temporal que sigue siendo accesible desde internet después de terminar el trabajo.

Ninguno de esos eventos se detectará hasta que llegue la fecha de la siguiente prueba periódica. En ese intervalo la organización opera con un nivel de riesgo más alto y sin documentar. Para el regulador significa que la resiliencia que se declara no está respaldada por datos actuales. Para el negocio significa una exposición que nadie ha evaluado.

Conviene dejar clara una cosa: esto no es un defecto del proceso de pruebas. Se deriva de la naturaleza de un mecanismo de control discreto. Las comprobaciones periódicas nunca podrán cerrar el intervalo de tiempo entre los momentos en que se ejecutan. Dan un punto, no una línea.

Observación continua: cubrir el intervalo de tiempo

Aquí entra en juego un segundo tipo de control: la observación continua de la superficie de ataque externa (External Attack Surface Management, EASM). A diferencia de las pruebas de DORA, que reaccionan a los cambios después de que ocurran, el EASM es proactivo. Escanea y monitoriza de forma continua los activos de la organización accesibles públicamente: dominios, direcciones IP, certificados, puertos abiertos, registros DNS.

¿Qué aporta en concreto esa observación en el contexto de los requisitos de DORA?

Detecta los nuevos servicios públicos en cuanto aparecen

Si un desarrollador abre una API nueva, el sistema de monitorización registra el hecho casi de inmediato. Eso permite al equipo de seguridad incorporar el nuevo activo a la lista de objetos que hay que proteger y —esto es lo importante— al plan de las pruebas siguientes. Así, la próxima prueba de DORA ya trabaja con la composición actual de la superficie externa.

Descubre la deriva de configuración

La deriva es la situación en la que el estado real de un sistema difiere del estado de referencia aprobado por la política de seguridad. Un administrador puede haber abierto un puerto de forma temporal para un diagnóstico y haberlo dejado abierto. Los sistemas EASM comparan el estado actual con una línea base y señalan las desviaciones.

Aporta datos para evaluar el riesgo entre pruebas

Si la monitorización muestra un aumento brusco del número de puertos abiertos, eso es una señal para una evaluación de riesgos no programada. No sustituye a una prueba completa de DORA, pero permite tomar una decisión informada: si hay que romper el calendario previsto o se puede esperar a la siguiente iteración.

Por qué se complementan y no se sustituyen

A veces aparece la tentación de elegir uno de los dos enfoques en lugar del otro: suponer que, si hay monitorización continua, las pruebas profundas sobran, o al revés, que las pruebas de penetración periódicas hacen redundante la monitorización. Ambas visiones son erróneas, porque los dos instrumentos responden a preguntas distintas.

Sus características se comparan así.

Pruebas de DORA

Pregunta: ¿puede el sistema seguir funcionando ante cargas y fallos extremos?
Método: modelado activo de escenarios, pruebas de estrés, ingeniería del caos.
Frecuencia: periódica, conforme a la política interna.
Límite: trabaja con una instantánea de la configuración en el momento de la prueba. No ve los cambios entre pruebas.
Coste: alto. Exige recursos de especialistas, tiempo de parada o aislamiento del entorno y una preparación compleja de los escenarios.

Observación continua (EASM)

Pregunta: ¿qué activos son accesibles desde internet ahora mismo y ha cambiado su configuración?
Método: escaneo externo, recopilación de metadatos, monitorización de cambios.
Frecuencia: continua, 24/7.
Límite: no evalúa la resiliencia interna. No comprueba vulnerabilidades lógicas en el código ni en los procesos de negocio. Solo ve la superficie.
Coste: moderado. Ejecución automatizada, pocas exigencias sobre los recursos propios de la empresa.

De esta comparación se sigue una conclusión sencilla: ninguno de los dos métodos cubre todo el espectro de riesgos que aborda DORA. Las pruebas sin monitorización son ciegas a los cambios del perímetro. La monitorización sin pruebas es ciega a la profundidad de las consecuencias de esos cambios.

El EASM puede descubrir que un nuevo servidor web es accesible desde internet. Es un hecho importante. Pero el hecho de que sea accesible, por sí solo, no dice hasta qué punto ese servidor es crítico para las operaciones ni cuánto tiempo llevaría restaurarlo tras un compromiso. Esa información solo la dan las pruebas de DORA, que modelan un escenario de compromiso de ese activo concreto y evalúan el efecto sobre los procesos de negocio.

El caso inverso: una prueba de DORA puede mostrar que el sistema de copias de seguridad funciona correctamente. Pero si el EASM muestra que el servidor donde se guardan esas copias se ha vuelto accesible de forma inesperada desde la red externa, el contexto de riesgo cambia. La copia de seguridad ya no está protegida en la medida que se suponía en el momento de la prueba.

Dónde no ayuda la herramienta: una mirada honesta

Sería incorrecto afirmar que el escaneo y la monitorización automatizados resuelven todas las cuestiones de cumplimiento de DORA. Hay ámbitos que dependen exclusivamente del proceso humano y de las decisiones de gestión.

La interpretación de los resultados

Una herramienta puede decir: “el puerto 8080 está abierto”. Decidir si eso es un incumplimiento de la política o una excepción admisible corresponde a una persona. La automatización no conoce el contexto de negocio. No sabe que ese puerto hace falta para una integración concreta con un banco socio y que cerrarlo paralizaría las operaciones. Por eso cada hallazgo del EASM debe pasar por una evaluación de riesgos hecha por personas.

La gestión de terceros

DORA presta mucha atención a los riesgos vinculados a los proveedores de servicios (DORA, artículo 30). Monitorizar la superficie externa propia no da una imagen completa de los proveedores. Se puede saber qué servicios están expuestos en casa, pero no qué vulnerabilidades hay en los sistemas del proveedor de alojamiento o de nube. Hace falta un proceso aparte para recabar información de las contrapartes y evaluar su madurez en seguridad. Ningún escáner externo sustituye a las obligaciones contractuales y a las solicitudes de auditoría a los socios.

La resiliencia organizativa

Parte de los requisitos de DORA se refiere a factores humanos: formación del personal, procesos de respuesta a incidentes, comunicación con los reguladores. Una herramienta técnica no enseñará a los empleados a reconocer un correo de phishing y no se encargará de notificar a tiempo un incidente grave al BCE o al regulador nacional. Son tareas puramente de proceso.

Por eso la estrategia de cumplimiento debe ser híbrida. Los medios técnicos —pruebas más monitorización— aportan visibilidad y base probatoria. Los mecanismos de proceso —políticas, formación, relación con los proveedores— aportan gobierno y responsabilidad. No se pueden sustituir unos por otros.

Elegir el control: situación por situación

El resumen siguiente ayuda a determinar qué tipo de control hace falta según la situación. No sustituye a una planificación detallada, pero da un marco para decidir.

Hay que acreditar el cumplimiento de DORA mediante pruebas periódicas

Enfoque recomendado: pruebas periódicas de resiliencia operativa digital.
Por qué este: es un requisito directo del artículo 26 de DORA. Aporta pruebas de resiliencia frente a factores de estrés.
Límites del enfoque: caro y lento; da una instantánea que envejece rápido. No ve los cambios entre pruebas.

Hay que saber qué servicios son accesibles desde internet ahora mismo

Enfoque recomendado: observación continua (EASM).
Por qué este: da un mapa actualizado de la superficie externa casi en tiempo real.
Límites del enfoque: no evalúa la profundidad de las vulnerabilidades. No comprueba la lógica de las aplicaciones. Requiere interpretación humana.

Se ha descubierto un servicio público nuevo que no ha pasado por las pruebas

Enfoque recomendado: evaluación de riesgos urgente más incorporación del activo al alcance del EASM.
Por qué este: permite entender rápido la magnitud de la amenaza y poner el activo bajo monitorización continua.
Límites del enfoque: no sustituye a unas pruebas completas. Sin un análisis profundo, la evaluación de riesgos puede quedarse en la superficie.

Se sospecha una deriva en la configuración de los cortafuegos

Enfoque recomendado: escaneo no programado y cotejo con el estado de referencia.
Por qué este: revela rápido la discrepancia entre el estado esperado y el real.
Límites del enfoque: puede dar falsos positivos. No explica la causa del cambio: quién lo hizo y para qué.

Gestión de los riesgos de proveedores externos

Enfoque recomendado: auditoría de procesos y solicitud de documentos.
Por qué este: DORA exige control sobre la cadena de suministro. Los escáneres técnicos no penetran en los sistemas de los proveedores.
Límites del enfoque: depende de la transparencia y la cooperación de las contrapartes. Es un proceso lento.

Preparación ante un incidente

Enfoque recomendado: una combinación de datos del EASM y escenarios de las últimas pruebas.
Por qué este: el EASM muestra dónde puede caer el golpe y las pruebas muestran cómo cede el sistema. Juntos dan una imagen más completa de la preparación.
Límites del enfoque: exige integrar datos de sistemas distintos. Mantener actualizadas ambas partes cuesta esfuerzo.

Para terminar

El cumplimiento de DORA no es un ejercicio puntual, sino un ciclo continuo de gestión de riesgos. Las pruebas periódicas de resiliencia operativa digital son un elemento necesario de ese ciclo, porque comprueban la solidez fundamental del sistema. Sin embargo, trabajan en tiempo discreto y no son capaces de ver los cambios que ocurren en el intervalo entre pruebas.

La observación continua de la superficie de ataque externa cubre ese intervalo de tiempo. Mantiene un mapa actualizado de la exposición, de modo que los riesgos nuevos salen antes a la luz y los planes de pruebas pueden ajustarse. Los dos enfoques no compiten: juntos forman un circuito cerrado de retroalimentación. La monitorización alimenta las pruebas con datos actuales de configuración y los resultados de las pruebas afinan los criterios de importancia para la monitorización.

Como responsable del negocio, no hace falta que se convierta en experto en la configuración de escáneres ni en metodologías de ingeniería del caos. Su tarea es confirmar que ambos elementos están presentes en la estrategia de seguridad y que existe un proceso claro para pasar datos entre ellos. Una pregunta para su responsable de TI: “¿cómo llegan a nuestras pruebas periódicas los datos sobre los nuevos servicios externos?”. Si la respuesta no es evidente, hay una brecha en el enfoque de DORA que conviene cerrar.

Qué aporta la observación externa continua a las pruebas de DORA