DORA

DORA se aplica a las entidades financieras de todo el sector: entidades de crédito, entidades de pago y de dinero electrónico, empresas de servicios de inversión, aseguradoras e intermediarios, centros de negociación, proveedores de servicios de criptoactivos, gestoras de fondos y otras, más los proveedores terceros de TIC que les dan servicio. Los proveedores terceros de TIC críticos se supervisan directamente a nivel europeo, lo cual es poco habitual y es una de las características con más consecuencias del reglamento.

Se levanta sobre cinco pilares. La gestión del riesgo de TIC, con un deber de gobernanza explícito sobre el órgano de administración. La gestión de incidentes relacionados con las TIC, incluida la clasificación y la notificación de los incidentes graves a la autoridad competente. Las pruebas de resiliencia operativa digital. La gestión del riesgo de terceros de TIC, incluidos un registro contractual y requisitos sobre lo que deben contener los acuerdos. Y los acuerdos de intercambio de información entre entidades.

El pilar de las pruebas es el que afecta directamente a una práctica de seguridad ofensiva, y tiene dos niveles. Todas las entidades dentro del ámbito deben ejecutar un programa de pruebas proporcionado a su riesgo, que cubra el abanico habitual desde el análisis de vulnerabilidades hasta las pruebas basadas en escenarios. Encima de eso, las entidades significativas identificadas por sus autoridades competentes deben realizar pruebas avanzadas basadas en pruebas de intrusión dirigidas por amenazas al menos cada tres años, sobre sistemas de producción en vivo y cubriendo funciones críticas.

Ese último requisito es lo que distingue a DORA de cualquier otro marco europeo. No pregunta si pruebas. Nombra el método, fija el ciclo, exige que sea contra producción e impone requisitos sobre quién puede ejecutarlo.

El fallo más común es tratarlo como un proyecto documental de cumplimiento cuyo dueño es riesgo, con el área de tecnología aportando evidencias. El reglamento va de resiliencia operativa, y las preguntas que hace son operativas: si esta función crítica puede continuar, con qué rapidez se detecta y se clasifica un incidente, qué pasa cuando falla un proveedor. Eso se responde con ejercicios y con mediciones, no con un registro de políticas.

El segundo es el registro de terceros. Las entidades descubren, casi siempre tarde, que no pueden producir un inventario completo de los acuerdos de TIC con el detalle exigido, porque los contratos están repartidos entre unidades de negocio y algunos servicios se contrataron con una tarjeta. Montarlo es un proyecto de verdad y se subestima de forma sistemática.

El tercero es el riesgo de concentración, que preocupa expresamente al reglamento y que la mayoría de las entidades no ha medido. Varias funciones críticas dependiendo del mismo proveedor, o de la misma región del mismo proveedor, es justo el patrón al que apuntan los requisitos de resiliencia.

El cuarto son las propias pruebas. Una prueba dirigida por amenazas sobre producción, contra funciones críticas, con un grupo de control que lo sabe y un equipo defensivo que no, es una empresa seria. A las entidades que solo han comprado pruebas de intrusión acotadas les sorprende con frecuencia la gobernanza que lleva alrededor: la fase de inteligencia de amenazas, la participación de la autoridad, los requisitos sobre quienes prueban y el hecho de que se ejecute contra sistemas en vivo. Empezar esa conversación seis semanas antes de la fecha límite no funciona.

Las entidades preguntan a menudo si las pruebas que ya hacen satisfacen el requisito avanzado. Normalmente no, y los motivos son estructurales y no de calidad.

La consecuencia práctica es de orden. Una entidad que vaya a ser identificada para las pruebas avanzadas no debería hacer de ese ejercicio su primera experiencia con pruebas adversarias. El orden que funciona es trabajo de pentesting acotado para arreglar lo evidente, después ingeniería de detección, después ejercicios de purple team para verificar las detecciones, y solo entonces un ejercicio dirigido por amenazas, cuyo valor depende por completo de que haya una defensa que merezca la pena medir.

Dar por hecho que es solo para bancos grandes. El ámbito cubre entidades de pago, aseguradoras, intermediarios, gestoras de fondos, proveedores de servicios de criptoactivos y más, y llega por contrato a sus proveedores de TIC.

Dejar el registro de terceros para el final. Es lo que más veces retrasa un programa.

Tratar el requisito de pruebas como una línea de compras. Lleva gobernanza, inteligencia y participación de la autoridad.

Ignorar el riesgo de concentración. Varias funciones críticas sobre un solo proveedor es exactamente el escenario al que apunta el reglamento.

Llevarlo por separado del trabajo de NIS2. La sustancia de los controles se solapa mucho y la evidencia es en buena parte la misma.

Confirma la situación de la entidad y si es probable que la identifiquen para las pruebas avanzadas, porque esa sola pregunta cambia el tamaño del programa. Pregúntaselo a la autoridad competente en vez de deducirlo.

Construye el registro de terceros de TIC como es debido, con el detalle que exige el reglamento, y úsalo para medir la concentración. Ese registro es además lo que hace abordable el trabajo contractual, porque las cláusulas obligatorias hay que introducirlas en las renovaciones y antes tienes que saber qué contratos existen.

Arregla la clasificación y la notificación de incidentes contra los propios criterios del reglamento, y ensáyalo. La pregunta que importa en un ejercicio no es si se puede escribir la notificación, sino si la entidad sabe clasificar bien un incidente mientras todavía está en curso.

Construye el programa de pruebas como una escalera y no como un único evento anual, y guarda el rastro de evidencia de cada peldaño: qué se probó, qué se encontró, qué se subsanó y qué dijo el retest. Ese rastro es lo que lee un supervisor.

Y aborda la pregunta de la resiliencia de frente: para cada función crítica, cuál es la tolerancia a la interrupción, qué pasa cuando el proveedor principal no está disponible, y cuándo se ejercitó eso por última vez. Esas respuestas son la sustancia del reglamento, y están más cerca de la planificación de la respuesta a incidentes que de cualquier lista de controles.

Para el pilar de pruebas, la evidencia es el ejercicio: su alcance, la inteligencia que lo perfiló, las rules of engagement, qué se ejecutó, qué detectaron los defensores y cuándo, qué se encontró y qué cambió después. Los informes se estructuran para que el relato de detección y respuesta vaya al lado de los hallazgos, porque al reglamento le importan las dos cosas.

Somos explícitos sobre lo que damos y lo que no. Ejecutamos el ejercicio técnico y producimos la evidencia. No determinamos el ámbito regulatorio, no decidimos si una entidad está identificada para las pruebas avanzadas y no presentamos nada ante las autoridades. Cuando una entidad necesita un ejercicio dirigido por amenazas formalmente reconocido, se aplican los requisitos sobre los proveedores y sobre el proceso, y conviene confirmarlos con la autoridad competente antes de acotar nada.

La severidad en estos informes se escribe contra la función crítica afectada y no contra el activo técnico, porque esa es la unidad en la que trabajan tanto el reglamento como quien lee.

El requisito de pruebas avanzadas apunta directamente a la emulación de adversarios ejecutada contra producción y contra una defensa en vivo, que es la única forma de prueba que responde a la pregunta que hace el reglamento.

¿A quién se aplica DORA? A las entidades financieras de todo el sector, desde entidades de crédito y proveedores de pago hasta aseguradoras, empresas de servicios de inversión, gestoras de fondos y proveedores de servicios de criptoactivos, más los proveedores terceros de TIC que les dan servicio. Los proveedores críticos se supervisan directamente a nivel europeo.

¿DORA es una directiva o un reglamento? Un reglamento, así que se aplica directamente en todos los estados miembros sin transposición nacional. Esa es una diferencia importante con NIS2, donde las obligaciones te llegan a través de la ley nacional.

¿Cada cuánto hay que hacer las pruebas dirigidas por amenazas? Las entidades identificadas por sus autoridades competentes deben realizar pruebas avanzadas basadas en pruebas de intrusión dirigidas por amenazas al menos cada tres años. Las demás entidades siguen necesitando un programa de pruebas proporcionado a su perfil de riesgo.

¿Nuestro pentesting anual satisface DORA? Contribuye al programa general de pruebas. No satisface el requisito avanzado, que va dirigido por inteligencia, se ejecuta contra producción en vivo y funciones críticas, no se anuncia a los defensores y lleva requisitos sobre quién lo realiza.