Articulo 25 DORA

El programa de pruebas de resiliencia operativa digital (…) dispondrá (…) la ejecución de las pruebas adecuadas, como evaluaciones y exploraciones de vulnerabilidad, análisis del software de código abierto, evaluaciones de seguridad de la red, análisis de carencias, exámenes de la seguridad física, cuestionarios y soluciones de software de detección, revisiones del código fuente cuando sea posible, pruebas basadas en escenarios, pruebas de compatibilidad, pruebas de rendimiento, pruebas de extremo a extremo y pruebas de penetración.

La primera propuesta

Cuando en septiembre de 2020 la Comisión Europea presentó la COM(2020) 595 final, sorprendió al sector financiero por instaurar como obligación algunos de los controles más comunes en el mundo de la ciberseguridad.

Sin embargo, el problema que la Comisión buscaba solventar no era la ausencia de controles de seguridad, sino la ausencia de un modelo homogéneo para comprobar que dichos controles realmente funcionaban.

Antes de DORA, cada entidad decidía qué probar, cuándo hacerlo y con qué metodología. Algunas realizaban pruebas de penetración periódicas. Otras únicamente ejecutaban análisis automáticos de vulnerabilidades. Y muchas limitaban las pruebas a proyectos concretos o a determinadas áreas tecnológicas.

Desde el punto de vista regulatorio esto generaba tres problemas:

• ausencia de criterios homogéneos entre entidades financieras;
• dificultad para que los supervisores evaluaran el verdadero nivel de resiliencia;
• aparición de vulnerabilidades que nunca llegaban a detectarse simplemente porque nadie las buscaba.

Por ello, la Comisión Europea busca imponer un modelo común y comparable que lograse poner de relieve las vulnerabilidades ocultas que podían afectar a la capacidad de las entidades para continuar prestando un servicio financiero cuando se produce un incidente.

Quizá por ello, este artículo fue “poco discutido” regulatoriamente hablando. Y es que cuando se estudia el procedimiento legislativo de DORA no se aprecian grandes discusiones o modificaciones entorno al artículo 25.

La propuesta inicial de la Comisión Europea ya contenía prácticamente toda la arquitectura técnica que terminó aprobándose en el Reglamento definitivo. Ni el Parlamento Europeo ni el Consejo cuestionaron realmente la necesidad de incorporar análisis de vulnerabilidades, revisiones de código, pruebas de rendimiento o pruebas basadas en escenarios.

Esto resulta poco habitual. En muchas normas europeas los artículos cambian profundamente durante la negociación. En el artículo 25 ocurrió justamente lo contrario.

De hecho, lo único destacable es un pequeño cambio de alcance en una de las pruebas. En concreto, en la propuesta inicial de la Comisión, el texto terminaba haciendo referencia a las pruebas extremo a extremo “o” a las pruebas de penetración. Mientras que en el Reglamento finalmente aprobado, esa dualidad desaparece y se obliga a realizar pruebas de extremo a extremo “y” pruebas de penetración.

Claramente, se entendió que una prueba de penetración no sustituye una prueba extremo a extremo; una prueba extremo a extremo tampoco sustituye un pentest. Cada una responde a objetivos distintos y ambas deben formar parte del programa de pruebas cuando resulten aplicables según el análisis de riesgos.

El listado de pruebas

Analizando conjuntamente los considerandos, la evaluación de impacto [^2] y la evolución del procedimiento legislativo aparece una idea constante: el legislador europeo no desconfiaba únicamente de los ataques, desconfiaba de la falsa sensación de seguridad.

Durante años muchas entidades habían construido programas de seguridad centrados exclusivamente en controles preventivos, pero apenas verificaban si dichos controles funcionaban en situaciones reales. Por eso DORA convierte las pruebas en una obligación jurídica. No porque las pruebas sean un fin en sí mismas. Sino porque constituyen el mecanismo que permite descubrir aquello que las políticas, procedimientos y certificaciones nunca llegan a revelar.

En este sentido, el listado definitivo incluye controles destinados a verificar distintas dimensiones de la resiliencia:

Aquí lo importante es comprender que DORA no inventa nuevas metodologías de prueba. Muchas de ellas ya aparecían desde hacía años en documentos como: guías de la EBA sobre gestión del riesgo TIC, marcos internacionales de pruebas de penetración, recomendaciones del G7 sobre Threat-Led Penetration Testing o metodologías ampliamente utilizadas por la industria financiera.

Lo único que hace DORA es transformar esas buenas prácticas en obligaciones regulatorias. Con ello, lo que anteriormente podía considerarse una decisión técnica del CISO pasa a convertirse en una obligación supervisable, modificando completamente conversación entre áreas técnicas, Compliance, Riesgos y Auditoría.

Ahora bien, el Reglamento sólo lista qué tipos de pruebas deben contemplarse, pero deja la metodología concreta a estándares técnicos, buenas prácticas y futuras especificaciones regulatorias.

Una última reflexión

Después de revisar toda la documentación legislativa vinculada al artículo 25 DORA la conclusión es simple: DORA busca obligar a las entidades a hacer más pruebas para asegurarse que son verdaramente resilientes. Es decir, DORA no convierte las pruebas en un requisito técnico sinon en una herramienta para demostrar la resiliencia digital de sus servicios.

FAQ Art. 25 DORA

• ¿DORA obliga a realizar todas las pruebas del artículo 25 con la misma frecuencia? No. El Reglamento exige un enfoque basado en el riesgo. La selección, alcance y periodicidad deben justificarse conforme a la criticidad de los activos y al perfil de riesgo de la entidad.

• ¿Por qué aparecen pruebas que no son estrictamente de ciberseguridad? Porque DORA regula la resiliencia operativa digital, no únicamente la seguridad informática.

• ¿El artículo 25 crea metodologías nuevas? No. En gran medida incorpora como obligación jurídica prácticas que ya eran habituales en estándares y guías internacionales.