DORA: gestión del riesgo de TIC en un perímetro externo cambiante

Un nuevo host público, un endpoint en la nube o un servicio de acceso remoto puede aparecer entre dos inventarios programados. Si la organización no detecta ese cambio, no puede identificar a tiempo al responsable del activo, evaluar el riesgo ni comprobar si la exposición del servicio estaba autorizada. El perímetro externo real se aleja entonces del registro, y la dirección y los auditores se quedan sin evidencia integral del control.

Desde el 17 de enero de 2025, las entidades financieras incluidas en el ámbito de aplicación de DORA deben identificar de forma continua las fuentes de riesgo relacionado con las TIC y mantener un marco documentado para gestionarlo. Si un activo externo forma parte de los activos de TIC de la organización o da soporte a sus funciones, debe entrar en el ciclo de identificación, evaluación y control (DORA, artículos 6 y 8).

Por qué no basta con una lista estática

DORA exige identificar los activos de información y los activos de TIC, incluidos los recursos de red y el equipamiento en emplazamientos remotos, y cartografiar los activos críticos, sus configuraciones y sus interdependencias. Los registros deben actualizarse periódicamente y ante cada cambio significativo (DORA, artículo 8(4)).

El Reglamento Delegado exige que los registros de activos de TIC incluyan, entre otros datos, el identificador, la ubicación, el responsable, las funciones de negocio a las que dan soporte, las interdependencias y la información sobre la accesibilidad desde redes externas, incluida internet (Reglamento (UE) 2024/1774, artículo 4).

Por eso, una lista de direcciones responde a una sola pregunta: qué era visible el día de la comprobación. No muestra cuándo el activo pasó a ser accesible desde fuera, si está anotado en el registro interno, qué función depende de él, quién responde del riesgo ni si el cambio siguió el procedimiento establecido.

La observación del perímetro externo puede detectar un activo nuevo o un cambio en la exposición. Solo un proceso interno permite determinar el responsable, la criticidad, la aceptabilidad del riesgo y la acción siguiente.

Paso 1. Detectar los cambios

DORA exige identificar de forma continua las fuentes de riesgo relacionado con las TIC y evaluar las ciberamenazas y las vulnerabilidades pertinentes para sus funciones y activos. También debe realizarse una evaluación de riesgos ante cada cambio significativo en la infraestructura, en los procesos o en los procedimientos que afecten a las funciones de negocio y a los activos soportados por TIC (DORA, artículos 8(2) y 8(3)).

Para el perímetro externo, esto significa comparar estados sucesivos de forma regular. El resultado verificable no es una casilla que indique que el escaneo está activado, sino un registro de qué activo y qué servicios accesibles desde fuera se encontraron, y cuándo.

Al mismo tiempo, DORA no declara significativo cualquier cambio en un host público. Los criterios de significatividad, la vía de revisión y la autoridad de quien toma la decisión los define la propia organización.

Los eventos pueden ordenarse en tres colas:

1. un activo conocido cuya accesibilidad externa ha cambiado;
2. un activo nuevo con responsable y finalidad establecidos;
3. un activo nuevo con responsable o finalidad desconocidos.

No se trata de una clasificación tomada de DORA, sino de una forma de hacer verificable el control: para cada evento quedan a la vista el momento de la detección, el resultado del cotejo con el registro y la decisión adoptada.

Paso 2. Vincular el activo con una función de negocio

Una dirección IP o un nombre de dominio no producen por sí solos una evaluación de riesgo. DORA exige clasificar las funciones de negocio soportadas por TIC, los activos de información y los activos de TIC, y documentar sus funciones y dependencias. También hay que identificar los procesos que dependen de proveedores terceros de servicios de TIC y los vínculos con los proveedores que dan soporte a funciones esenciales o importantes (DORA, artículos 8(1) y 8(5)).

Un endpoint en la nube que se detecta debe cotejarse con un responsable, un sistema y la función a la que da soporte. Sin eso no se puede determinar la urgencia de la revisión ni los requisitos aplicables de disponibilidad, integridad y confidencialidad.

Las herramientas técnicas pueden sugerir un vínculo a partir de un certificado, de registros DNS, de una cuenta en la nube o de otras señales. Confirmar el responsable y la función de negocio sigue siendo una tarea del proceso. Un indicador práctico para un responsable de TI es la proporción de activos externos detectados que tienen un responsable confirmado y un vínculo con el registro interno. DORA no fija un valor de referencia para ese indicador.

Paso 3. Incorporar el evento a la gestión de cambios

El Reglamento Delegado concreta los requisitos de gestión de la seguridad de la red y de los cambios en los sistemas de TIC: los cambios deben registrarse, evaluarse, aprobarse, implantarse y verificarse de forma controlada (Reglamento (UE) 2024/1774, artículos 12 y 16).

Por eso, cada cambio confirmado en la exposición externa debe tener asociado un registro de cambio autorizado o bien generar una tarea de análisis de la desviación.

Son posibles tres resultados:

• el cambio estaba autorizado y figura en el registro;
• el cambio estaba autorizado, pero la documentación no se ha actualizado;
• el cambio no está confirmado y requiere restringir el acceso o abrir una investigación.

Paso 4. Conservar la evidencia del control

DORA exige documentar el marco de gestión del riesgo relacionado con las TIC y revisarlo al menos una vez al año, así como tras incidentes graves relacionados con las TIC, instrucciones de supervisión o conclusiones de las pruebas y auditorías. Las entidades deben auditar internamente el marco y hacer seguimiento de la subsanación de las deficiencias detectadas (DORA, artículos 6(5)-6(8)).

Para el perímetro externo no sirve solo la lista actual, sino la cadena de registros:

detección → identificación del responsable → vínculo con el activo y la función → evaluación → decisión → cambio del control → verificación del resultado

El registro de la observación muestra qué apareció o desapareció, cuándo se advirtió y qué quedó visible después de la corrección. El registro de activos, la solicitud de cambio, la evaluación de riesgos y la aprobación del responsable acreditan la parte de proceso.

Una herramienta de observación externa no demuestra que la dirección haya aprobado el riesgo como aceptable. DORA atribuye al órgano de dirección la responsabilidad sobre los mecanismos de gestión del riesgo relacionado con las TIC, la asignación de funciones, la política de continuidad y la auditoría (DORA, artículo 5).

Dónde no ayuda la observación del perímetro externo

Las normas analizadas no exigen adquirir un producto específico para la gestión de la superficie de ataque externa. Lo que se exige es un resultado: identificación actualizada de los activos y de las fuentes de riesgo, control de los cambios, decisiones documentadas y la posibilidad de comprobar que el marco funciona.

La observación cubre la parte observable: encuentra los activos accesibles públicamente, registra los cambios y permite comprobar la exposición después de una acción. No sustituye:

• la clasificación de las funciones esenciales e importantes;
• la designación de responsables de los activos;
• los criterios de cambio significativo;
• la aceptación o el rechazo del riesgo;
• la aprobación de los cambios;
• la gestión contractual de los proveedores terceros de servicios de TIC;
• la auditoría interna y el control de las medidas correctoras.

En lugar de otra lista de dominios, un responsable de TI necesita un informe integral del periodo: qué cambios del perímetro externo se detectaron, con qué activos y funciones se cotejaron, quién tomó la decisión y con qué documento se acredita el cierre de cada desviación.

Del requisito a la evidencia verificable

Para cada requisito siguiente: la acción verificable, lo que aporta la observación por sí sola y lo que solo puede aportar el proceso.

Identificar las fuentes de riesgo de TIC

• Referencia — DORA, artículo 8(2)
• Acción verificable — comparar estados sucesivos del perímetro y registrar los cambios
• Qué aporta la observación — el activo y el momento de la detección
• Qué aporta el proceso — la cola de análisis, el responsable y la decisión sobre el riesgo

Mantener el registro de activos

• Referencia — DORA, artículo 8(4); 2024/1774, artículo 4
• Acción verificable — cotejar el activo externo con una entrada del registro
• Qué aporta la observación — señales técnicas del vínculo y de las discrepancias
• Qué aporta el proceso — la confirmación del responsable, la finalidad y la función

Evaluar los cambios significativos

• Referencia — DORA, artículo 8(3)
• Acción verificable — remitir los eventos pertinentes a la evaluación de riesgos
• Qué aporta la observación — los datos sobre la nueva exposición
• Qué aporta el proceso — los criterios de significatividad y la decisión

Controlar los cambios

• Referencia — 2024/1774, artículos 12 y 16
• Acción verificable — vincular la exposición con una solicitud de cambio o con una desviación
• Qué aporta la observación — el cotejo del estado real con el estado registrado
• Qué aporta el proceso — la evaluación, las pruebas y la aprobación

Auditar la gestión del riesgo de TIC

• Referencia — DORA, artículos 6(5)-6(8)
• Acción verificable — conservar la cadena desde la detección hasta la verificación
• Qué aporta la observación — el histórico de observaciones
• Qué aporta el proceso — las decisiones de dirección, la auditoría y el control de la subsanación