¿Conoces a DORA? Reglamento de Resiliencia Operativa Digital.

Consulta las opiniones de los expertos sobre el Reglamento de Resiliencia Operacional Digital.

El pasado jueves 20 de mayo, organizado por ISACA Madrid Chapter y con la colaboración de EY (partner Gold), tuvo lugar el interesantísimo webinar “Explorando el Reglamento de Resiliencia Operativa Digital (DORA)” que contó con más de 260 asistentes (evento exclusivo para socios de ISACA Madrid, Barcelona y Valencia) y una excelente valoración de un ¡9 sobre 10!

La bienvenida y presentación del evento corrió a cargo de Ricardo Barrasa (Immediate Past President de ISACA Madrid, Content Author), quien comenzó agradeciendo su asistencia a todos los asociados.

Además, anunció las fechas del nuevo gran evento de ISACA Madrid, que tendrá lugar durante los días 3, 10 y 17 de Junio.

Ricardo hizo una breve introducción de DORA como impulsor del modelo de madurez de la resiliencia cibernética, operacional y tecnológica. Relacionado con ello y como referencia de personaje resiliente, Ricardo trajo a colación la frase “No me juzgues por mis éxitos, júzgame por la cantidad de veces que me caí y volví a levantarme” de Nelson Mandela. “De eso va la resiliencia“, concluyó Ricardo.

Tras una breve encuesta sobre los perfiles de los asistentes y el grado de conocimiento sobre DORA, Ricardo dio paso a la primera ponencia “Digital Operational Resilience Act (D.O.R.A.)” a cargo de Julio San José (Spain FSO Cybersecurity Leader de EY).

Julio, comenzó a gradeciendo la invitación y, en relación a uno de los titulares con los que se presentó el webinar, “Explorando DORA” (por aquello del juego de palabras con la serie infantil de dibujos animados, “Dora la Exploradora“), comentó que quizá sería más apropiado decir “DORA la Integradora“.

En primer lugar Julio nos hizo una introducción sobre lo que es DORA, indicando que se trata de un reglamento (en estado de borrador), un marco de resiliencia digital, resultado del trabajo realizado por la Unión Europea, que además pretende lograr una “alineamiento normativo“, aglutinando diferentes normas y regulaciones (como EBA, EIOPA, PSD2, Solvencia, etc.).

El objetivo principal de DORA es la racionalización y la mejora de las normas existentes así como la estandarización del modelo de notificación de incidentes, aunque quizá hubiese sido conveniente que se integrase mejor con algunos de los modelos ya existentes al respecto, comentaba Julio.

En cuanto a quiénes se ven afectados por DORA, además de las entidades financieras, ésta amplía enormemente el alcance de quien debe estar regulado… entidades financieras reguladas que también incluye a los intermediarios de seguros, entidades de dinero electrónico, proveedores de servicios ITC, proveedores de cloud, de servicios digitales, auditores legales, sociedades de gestión, agencias de calificación… y un largo etcétera…

Respecto a su alcance, o el modo en el que DORA impacta en las instituciones, enumeró los siguientes aspectos:

• La gestión del riesgo TIC.
• Los incidentes y las notificaciones de incidentes relacionados con las TIC.
• Las pruebas de resiliencia operativa digital.
• Los riesgos de terceros en las TIC.
• El intercambio de información entre entidades financieras.

El nivel de evaluación e impacto de DORA dependerá mucho del nivel de madurez y, aunque a priori, parece no incorporar nada nuevo sí trae consigo integridad, uniformidad, criterios… “lo que, si no está ya hecho, debería estar hecho“, comentaba Julio.

Respecto a la gestión de riesgos TIC, el objetivo y las obligaciones que DORA impone respecto a la implementación y el mantenimiento de marcos de gestión de riesgos, es que éstos sean serios, firmes, apoyados por la alta dirección, que sean revisables, basado en estándares internacionales, que se enfrenten a auditorías periódicas, y con reevaluaciones continuas (especialmente tras cada cambio).

Julio también hizo hincapié en la relevancia que DORA asigna, de forma especial, al Comité de Dirección, además de a otros roles, detallando que exige (aunque no expresamente -apuntó Julio-) la existencia de un responsable de riesgos TIC (“CISO o figura equivalente“).

El core y principal objetivo de DORA es la correcta gestión de todos los riesgos TIC, propios y de terceros. En cuanto a los riesgos de terceros y lo que esto supone para la gestión de contratos y proveedores, el reglamento pide expresamente:

• Un conveniente análisis previo de proveedores.
• El mantenimiento de registros contractuales.
• Que los proveedores cumplan con las normativas.
• Aplicar el principio de proporcionalidad.
• La revisión periódica de riesgos por externalizaciones.
• Y, que las entidades financieras, también tomen cartas en el asunto revisando periódicamente el riesgo de terceros.
• Por supuesto, con la debida revisión por parte de la autoridad competente.

Julio continuaba explicando que DORA entra muy en detalle en la gestión de riesgos de terceros, especialmente de proveedores TIC (bajo un marco se supervisión de la Unión Europea), a quienes incluso cataloga de un modo concreto en:

• Terceros proveedores de servicios TIC.
• Terceros proveedores de servicios TIC, críticos.

En el segundo caso, en el de los proveedores de servicios TIC críticos, para poder determinar quiénes deberían ser considerados como tales, DORA, establece los siguientes criterios de valoración que nos indicaba Julio:

• Número de entidades afectadas (impacto de un fallo operativo a gran escala).
• La importancia sistémica de la entidad que forme parte de él (en el caso de entidades financieras, no solo las que sean sistémicas para Europa, sino también a nivel global).
• Criticidad de las funciones y los procesos soportados por los servicios TIC.
• El grado de capacidad de sustitución (existen servicios de los que no hay sustituto posible).
• El número de estados miembros.
• El número de estados miembros donde opera el usuario de esos servicios TIC.

Julio continuaba su ponencia exponiendo lo que plantea y exige DORA en lo referente a la resiliencia operacional digital. En este sentido, lo primero que DORA solicita es que se realicen pruebas de resiliencia operativa, para que la capacidad de recuperación de las entidades financieras esté asegurada y las debilidades o deficiencias subsanadas a tiempo.

“En lo que a las pruebas exigidas se refiere, es la primera vez que vemos que se indica, expresa y claramente, en qué deben consistir los programas de pruebas a realizar (Artículo 22), basados en el principio de proporcionalidad (según el cual el programa de pruebas varía y se adapta en función del tamaño y perfil de riesgo de la empresa)“, decía Julio.

Entrando más en detalle respecto a las pruebas avanzadas de resiliencia operativa digital, DORA llega hasta a definir aspectos como los siguientes:

• Qué entidades deben hacerlas, algo que será definido por las autoridades competentes en base a varios criterios como su nivel de riesgo y madurez, entre otros.
• Sobre qué elementos se deben realizar las pruebas (funciones esenciales).
• Con qué frecuencia se deben realizar (3 años).
• Cómo deben ser las pruebas (metodología, pruebas de penetración, frameworks, etc., independientes de los estados miembros).
• Realizarlas también sobre elementos de terceros.
• Quién debe realizar dichas pruebas (entidades externas).
• Y que, del resultado positivo de todas ellas, se expida el correspondiente certificado por parte de la autoridad competente.

Como Julio ya anunciaba al principio de su exposición, DORA incluye la obligatoriedad de la notificación de incidentes. En este sentido, se intenta unificar y obtener información de primera mano de los incidentes que están ocurriendo para que las vulnerabilidades que los estén ocasionando puedan estar identificadas y recogidas a través de la ESA y así poder informar a los bancos centrales.

Las novedades que DORA introduce respecto a la gestión de incidentes, son las siguientes:

• Análisis de la causa del incidente, con su correspondiente presentación de informes al respecto; tanto iniciales, intermedios, como finales.
• Las entidades afectadas o impactadas por DORA deberán presentar dichas notificaciones o informes de incidentes en un centro unificado.
• Dependiendo del sector, se establecen unas determinadas plantillas normalizadas de notificación y comunicación de incidentes.

En este punto de su exposición, Julio hacía una llamada a quien correspondiese, mediante una solicitud o petición de revisión.

“Lo ideal, en lo que a la eficiencia de costes, de personas y de incidentes se refiere, sería que tuviésemos un entorno armónico de reporting, de manera que DORA permitiera reutilizar los espacios y los sistemas creados en las organizaciones afectadas para poder reaprovechar, en la medida de lo posible, lo que ya está escrito, descrito y realizado“, decía Julio.

En la situación actual de borrador de DORA, el intercambio de información entre las diferentes organizaciones, infraestructuras y sectores afectados, es una solicitud de carácter voluntario cuyo objetivo es mejorar la resiliencia operativa, evitando la propagación de ciberamenazas y fortaleciendo la capacidad defensiva.

“Y DORA para cuándo…“. ¿Cuál es el timmig para que DORA pase de su actual estado de borrador a ser una realidad y, sobre todo, cuándo se prevé que deban estar definidas y aplicadas todas sus normas?, se preguntaba Julio.

Las estimaciones, y solo eso, estimaciones, lo que se espera…  son las siguientes, se respondía Julio a sí mismo:

• Junio 2021: primera votación.
• Mayo 2022: versión aprobada y publicada oficialmente.
• Mayo-Junio 2022 (20 días tras su publicación): Entrada en vigor, pues al ser un reglamento, no es necesario esperar a ningún tipo de trasposición.
• Julio-Agosto 2022 (2 meses tras su publicación): Norma técnica para las pruebas de penetración, ya en vigor.
• Mayo 2023 (1 año tras su publicación): Aplicación total de DORA (salvo los Artículos 23 y 24, que se aplicarán 3 años después).
• Mayo 2025 (3 años tras su publicación): Aplicación de los Artículos 23 y 24, así como de la norma técnica de centralización de la información de incidentes, con la correspondiente construcción de los RTSs (“los cuales, con total seguridad, darán mucho que hablar, apuntaba“, Julio).
• Mayo 2027 (5 años tras su publicación): Revisión de criterios de designación de proveedores TIC.

Antes de postular una serie de conclusiones finales, Julio mencionaba que, desde su punto de vista y opinión personal propia y no la de EY -aclaraba-, que “el caballo de batalla de DORA va a estar en la gestión de riesgos TIC de terceros, cuando éstos sean proveedores críticos, puesto que (casi) todos son transnacionales y (casi) ninguno de ellos es europeo. DORA viene a tratar de garantizar que estos proveedores (vitales para los sistemas financieros europeos) sean objeto de un seguimiento adecuado desde Europa y que puedan ser supervisados como cualquier otra entidad europea y elemento externo que opere en Europa.“

En relación a esto, “¿qué va a ocurrir cuando un proveedor crítico no sea/esté en la Unión Europea?“, planteaba Julio. A lo que se respondía que esto podría llegar incluso a generar algún posible gran problema político. 

Con todo ello, y en resumen, Julio concluía con las siguientes consideraciones, aunque apuntaba que “cuanto más leo DORA, menos conclusiones puedo trasladar, porque tengo más preguntas (aunque sean retóricas)“:

• ¿Cómo se deberá transponer DORA? En este caso, DORA no requiere de trasposición puesto que se trata de un reglamento.
• ¿Qué velocidad lleva su desarrollo parlamentario?
• ¿Cómo va a afectar DORA a las personas, procesos y protocolos?
• ¿Cómo afectará a terceros IT, tanto dentro como fuera del sistema financiero?
• ¿Cuál será el papel y la responsabilidad del Consejo de Administración frente a DORA?

Éstas son preguntas que Julio aprovechaba para trasladar a la posterior mesa de debate del webinar, concluyendo que, mientras tanto, mientras todo el mecanismo de DORA se va poniendo en marcha, debemos irnos preparando ya para ello… “tempus fugit“.

Tras su exposición, Julio respondía a alguna de las preguntas que los asistentes hacían por el chat del evento:

• ¿Cómo les afecta DORA a las empresas de Criptoactivos / Criptomonedas? Julio respondía diciendo que las consideraba parte de los activos digitales y que, por tanto, les debería afectar DORA y estar bajo su paraguas, aunque apuntaba que probablemente aún no esté muy claro, al menos cuáles deben de ser.

• ¿En qué fecha estimada entra en vigor? En este caso, Julio proponía a Silvia Senabre (Experta en Tecnologías de la Información de la Dirección General de Supervisión del Banco de España) que ella respondiese esta pregunta, por contar con mayor conocimiento al respecto.

Silvia respondía que no tenía la bola de cristal, pero que sí podía aportar información sobre dónde, en qué punto del desarrollo de DORA, se encuentran en este momento.

“Estamos yendo bastante rápido. Actualmente nos encontramos en la fase de negociación técnica, que esperamos finalizar a finales de mayo o en la primera quincena de junio, durante la presidencia portuguesa de la UE. A partir de ahí, comenzará la negociación parlamentaria y los trílogos. Por lo tanto, si todo va bien y las cosas no se tuercen en la fase política, podría ser que a finales de año, de 2021, tuviésemos ya el texto definitivo. Después, los plazos que indicaba Julio, con la posibilidad de tener ya un texto definitivamente cerrado en un plazo de dos años”, finalizaba respondiendo Silvia.

• ¿Se van a aplicar los requisitos de DORA a otros sectores? La opinión personal de Julio al respecto es que sí, y que la Unión Europea lo hará especialmente con los sectores críticos.

• ¿Cuáles son las medidas sancionadoras? Las sanciones son elevadas, respondía Julio. El método a aplicar en este sentido será el mismo que se ha aplicado en el caso del RGPD / GDPR, en términos de aplicar un porcentaje sobre la facturación en concepto de multa.

• ¿Qué diferencia hay entre DORA y el Reglamento NIS? Julio redirigía la pregunta a Vicente Moret Millás (Letrado de las Cortes Generales (Congreso de los Diputados) y Of Counsel de Andersen).

Vicente respondía indicando que, aunque no lo pareciese, se trataba de una pregunta compleja. En cualquier caso, la diferencia esencial, desde el punto de vista estrictamente legal es el vehículo que se ha elegido para la aprobación.

“Mientras que en NIS hablábamos de una directiva (con una aplicación bastante regular, por cierto, matizaba Vicente, por la que en NIS2 se busca unificación), en el caso de DORA hablamos de un reglamento, en términos de mecanismo legal. Esto, que puede parecer un detalle mínimo, significa que DORA tendrá una entrada en vigor en el mismo momento de su publicación (a los 20 días), con una aplicación inmediata y directa y que, además, deberá hacerse en toda la Unión Europea.“

“Sin embargo, existen determinadas relaciones entre NIS y DORA, aunque DORA va más allá que NIS pues establece unos estándares más altos.“

“En definitiva, NIS y DORA serán pilares paralelos, pero uno de ellos (DORA) va a ser un pilar específico para entidades financieras. Un detalle muy importante a tener en cuenta es el ámbito de aplicación. Para DORA, cualquier persona jurídica que menaje dinero en la UE y que no sea micro-empresa, está dentro del ámbito de aplicación”, concluía respondiendo Vicente.

• ¿Cómo afectará DORA a los proveedores de comunicaciones? A esta respuesta Julio respondía diciendo que “son un prestador de soluciones TIC, por lo que, si son declarados críticos, les afecta totalmente“

• ¿Se superpone DORA con otras regulaciones como NIS, DCP, etc.? Del mismo modo, Julio contestaba que “DORA es una normativa europea y que no estábamos hablando de una regulación estadounidense. En el terreno de regulaciones europeas, DORA es DORA la integradora, porque aúna bajo su paraguas, por lo que no se superponen, sino que coinciden“.

• ¿Todas las funciones de revisión deben caer bajo la figura y responsabilidad del CISO o CSO? La respuesta de Julio era que sí y que además debe caer sobre quienes lleven la responsabilidad de las labores de auditoría como tercera línea de defensa.

• ¿Hay algún modelo disponible de DORA? “No existe un modelo para realizar los análisis bajo esta regulación“, contestaba Julio.

• ¿Estarían sujetas a DORA las casas de cambio de moneda y de transferencia? al tratarse de microempresas, sí deberían estar afectadas por DORA, indicaba Julio.

• ¿Afectará DORA a las Administraciones Públicas? En este caso, Julio proponía que Silvia respondiese a la pregunta.

Ella contestó que quien dijo que “En principio no debido a que el objetivo es cubrir entidades financieras (aunque incluso las auditoras están afectadas) pero, en cualquier caso, muy previsiblemente, las AAPP no estarán afectadas en el texto final ya que hay bastante acuerdo al respecto en el Consejo“.

A esto, Julián Inza, uno de los panelistas de la posterior mesa redonda (Experto independiente de la Comisión Europea en blockchain, auditoría, PDS2, EIDAS, MICA, DORA y el EU Digital Financial Package), añadía los siguiente:

“Las National Competence Auhtority, en cierto modo, son también Administraciones Públicas, con sus nuevos roles, por lo que los supervisores de seguros, los supervisores bancarios, los supervisores de ese ámbito, tienen que ser capaces de aplicar el régimen sancionador“.

Silvia respondía a la puntualización de Julián, indicando que se debía hacer cumplir la regulación, vigilando y supervisando a las entidades del ámbito de competencia para garantizar que cumplen con la norma.

Por tanto, concluía Silvia, “en ese sentido sí nos afecta, aunque no estemos sujetos a la norma, puesto que no somos sujetos pasivos, sino más bien vigilantes de su aplicación“.

Tras la ronda de preguntas, Ricardo, dio paso a Vicente Moret Millás (Letrado de las Cortes Generales (Congreso de los Diputados) y Of Counsel de Andersen), como moderador de la mesa redonda.

Vicente arrancó el debate directamente, lanzando la primera pregunta a los panelistas.

¿Cuál creéis que va a ser el impacto de DORA? Todos tenemos en mente la otra gran norma que ha impactado en la Unión Europea, el Reglamento General de Protección de Datos (RGPD / GDPR). ¿Pensáis que el impacto de DORA puede ser igual, menor, o simplemente diferente?

Comenzó respondiendo Silvia. “Sin lugar a dudas, tendrá un importante impacto en el sector financiero, pero incluso irá más allá, pues la gran novedad disruptiva de DORA es que establece un nuevo régimen de proveedores críticos que ahora no existe, con su correspondiente modelo sancionador. Habrá un antes y un después“.

En opinión de Carmen Moreno (Cybersecurity, IT RISK & BCP de Banca March), “DORA no viene a inventar la rueda, sino más bien a ayudarnos a los responsables de seguridad y de riesgos tecnológicos“.

“Muchas de las cosas que DORA propone ya las estábamos haciendo pero nos dará ventajas como que ya quede reglado que el Consejo de Administración tiene responsabilidad directa y lo que determina respecto al intercambio de información“.

“DORA nos dará trabajo, pero viene a ayudarnos“, finalizaba respondiendo Carmen.

El siguiente en responder, fue Pablo Montoliu (Chief Information & Innovation Officer de Aon), aludiendo a lo proclive que suele ser en sus intervenciones hacia lo “políticamente incorrecto” y la generación de debate.

En ese sentido, Pablo decía que “aún siendo habitualmente reacio a la normativa, y aun no gustándome los arquetipos como el de que Estados Unidos inventa, China copia y Europa regula… en este caso parece una realidad… pues lo vimos con el GDPR y ahora lo volvemos a ver con DORA“.

En cualquier caso le daba la bienvenida y su correspondiente reconocimiento, especialmente por la necesidad que entendía tiene en el caso de organizaciones internacionales para aspectos de “armonización y homologación de aspectos como en testing e incident response, el reporting, etc., que, hasta ahora, cada uno era de su padre y de su madre“.

“Sin duda, DORA aporta muchas ventajas para las organizaciones transnacionales“, concluía Pablo.

Para finalizar con la primera ronda de respuestas, Julián Inza (Experto independiente de la Comisión Europea en blockchain, auditoría, PDS2, EIDAS, MICA, DORA y el EU Digital Financial Package) afirmaba que “este reglamento (que forma parte del Digital Financial Package), acompaña a otro llamado “Markets in Cryto-Asset (MiCA), lo que permite definir diferentes modalidades de criptoactivos, y lo hace muy interesante pues significa que la Unión Europea quiere ponerse por delante en un contexto regulatorio frente a una enorme cantidad de normas que añaden multitud de requisitos“.

Añadido a esto, continuaba diciendo Julián, “esto se ha producido al mismo tiempo que se han preparado los reglamentos de los mercados digitales, los cuales contaban con un enorme desequilibrio entre los grandes proveedores y, finalmente, tenemos un marco regulatorio.“

“Tenemos tantas fuentes de requisitos que una enorme labor sería hacer una gran checklist que contemple a todos, dado que muchas entidades, además de ser financieras, pueden estar consideradas como operadores críticos nacionales. En este sentido, deberíamos considerar que los reglamentos ya están vigentes para ir trabajando en lo que sea necesario, pues no será un ejercicio inmediato“, concluía Julián.

Enlazando con este primer debate, Vicente afirmaba que “DORA nos aporta un valor que no teníamos pues por fin existe una guía clara sobre lo que debería ser un mapa completo de un modelo de resiliencia (aspectos de gobernanza, comunicación, suministradores, etc.) que NIS no dejaba tan claro“.

En este escenario, la pregunta que subyace es si “¿DORA va a (o debería) replicarse a otros sectores?” puesto que incluso entidades no afectadas se plantean aplicar los estándares de DORA de forma voluntaria, porque esto afecta a la gobernanza interna de la ciberseguridad.

Siendo así, y teniendo en cuenta uno de los cambios principales de DORA (que también aparece en NIS2) en cuanto a poner en el centro de la responsabilidad al Consejo de Administración, que uno de sus miembros será el responsable directo, y que el resto deben recibir la formación adecuada, Vicente preguntaba a los ponentes sobre sus opiniones al respecto y si esto no supondrá una gran inversión.

Carmen comenzaba respondiendo que, tras darle vueltas a esta situación en la que se escalan las responsabilidades, una de las conclusiones era la necesidad de realizar acciones de concienciación al Consejo de Administración, lo que, efectivamente, supondrá grandes inversiones.

Vicente preguntaba directamente a Silvia su opinión sobre si el regulador adoptará alguna medida adicional y cómo veía la gobernanza interna a partir de DORA en las entidades bancarias.

Silvia respondía que “entre los reguladores y supervisores preocupa mucho que la Alta Dirección en las entidades financieras no esté dando demasiada importancia a los riesgos tecnológicos y que quizá no los entiendan bien, o lo bien que necesitarían o deberían“.

“El Banco Central Europeo ha detectado que las entidades que cuentan con personas con conocimientos y entendimiento de la tecnología en el Consejo de Administración gestionan mejor los riesgos“, decía Silvia.

Por tanto, existe una correlación clara que confirma que es bueno que el Consejo de Administración se implique en estas cuestiones.

“Uno de los beneficios esenciales de DORA es que eleva los temas de seguridad, ciberseguridad y resiliencia, desde las capas más técnicas o de gestión técnica, hasta la alta dirección, pasando a ser algo de importancia y de primer término, haciendo que el Consejo de Administración se implique y pasando a un modelo Top-Down“, aseguraba Silvia.

Continuando con los aspectos de gobernanza, Vicente decía que DORA adopta lo que la OTAN ya decía hace tiempo respecto al modelo de Defensa en Profundidad (las tres capas de tecnología, personas y procesos).

En este sentido, “¿Creéis que ya ha llegado el momento de las personas en las organizaciones?“

Pablo opinaba que eso ya llegó hace tiempo pero que aún hay mucha gente que no se ha dado cuenta… “esto no va de tecnología, va de personas… y de procesos“.

La situación real es la siguiente, aseguraba Pablo.

“Cuando hay que tratar un tema de refinanciación, el Consejo de Administración y/o en el Comité Ejecutivo se invita al CFO y se establece un diálogo. Si el tema a tratar es un ERE, se invita al responsable de RRHH e igualmente se establece un diálogo… Pero, si el asunto a tratar es sobre tecnología en general y, específicamente, sobre todo de ciberseguridad, se invita al friki que expone pero que nadie entiende y por tanto no se establece un diálogo sino una comunicación unidireccional“.

“Hace años, cuando el presidente de la CMV (Comisión del Mercado de Valores) planteó que en el Consejo debería haber especialistas en riesgos, en retribuciones, en la actividad core de la organización… también se planteó que hubiese un especialista en ciberseguridad, pero… lo que esto pone de relieve es que este paso, que quizá se debería haber dado ya, ahora ya es ineludible“, respondía Julián.

DORA cuenta una parte muy importante en cuanto a la gestión de riesgos de terceros como suministradores/proveedores y entra muy en detalle, indicando hasta el contenido de las cláusulas a manejar en estos contratos.

Mucha gente puede entender esto como una acción de “soberanía digital” para controlar a los grandes suministradores de servicios TIC no europeos.

“¿Creéis que el empoderamiento de DORA respecto a los que compran servicios de terceros reequilibrará la situación?“, preguntaba Vicente a los contertulios.

“DORA copia las guías de la Entidad Bancaria Europea sobre outsorcing, por lo que ya se establecían esos requerimientos en cuanto a los contratos, pero lo eleva a la categoría de reglamento“, comenzaba respondiendo Silvia.

Por lo tanto, según la opinión de Silvia, esto efectivamente equilibrará la balanza y dará muchas más armas a las entidades financieras para empoderarles y negociar con sus proveedores (Google, Amazon, Microsoft, IBM, etc.) de otro modo.

“La diferencia es que ahora, con DORA, los proveedores no van a poder tener clientes ni hacer negocios en el sector financiero europeo si no cumplen con lo que DORA determina al respecto de estos contratos“, finalizaba diciendo Silvia.

Carmen estaba 100% de acuerdo con la respuesta de Silvia y argumentaba además que, “de no haber sido por la ayuda y la presión del Banco de España, no hubiéramos sido capaces de cambiar el contrato con Microsoft y esto fue una punta de lanza“.

Uno de los aspectos adicionales, y de vital importancia, que introducía Julián en la conversación, es la necesidad que tienen las entidades de preparar, sí o sí, porque así lo pide DORA, el Plan de Sustitución de Proveedores Críticos.

Esto, además, conlleva hacerlo de forma conjunta con el proveedor que corresponda, aunque se trate de una situación delicada, incómoda y, en términos de viabilidad, en muchos casos, imposible o utópico.

“Algo está pasando ya, porque todos los grandes proveedores del GAFAM (Google, Amazon, Facebook, Apple, Microsoft), están abriendo CPDs en España, lo que es muy significativo, que sea en España y no en Europa, que ya tenían“, apuntaba Julián.

“Gracias a la regulación nos vamos a poder ver respaldados ante riesgos de terceros como los de los GAFAM (o cualquier otro de envergadura), porque ninguno de ellos hubiese accedido a garantizar esos requisitos si así no lo hubiese impuesto el regulador“, dijo Carmen.

La opinión de Pablo era que “la apertura de CPDs en España y en Europa por parte de los mega-proveedores ha tenido mucho que ver con el GDPR / RGPD y que las cosas seguirán de un modo similar, pues la regulación europea puede ser un influencer, pero la batalla digital de los grandes super-proveedores, Europa la perdió ya hace tiempo y no la vamos a recuperar“.

ENISA (la Agencia de Ciberseguridad Europea) está creando un esquema de certificación europeo y todos los países miembros de la Unión están tratando de que sus esquemas de certificación se trasladen o parezcan lo máximo posible a él.

En relación a ello, Vicente preguntaba lo siguiente: “¿Cómo creéis que encaja el tema de los terceros suministradores en un sistema o modelo de certificaciones que permita mitigar o eludir responsabilidades?“

Silvia, aun entendiendo lo positivo y el valor de las certificaciones, exponía su escepticismo al respecto, puesto que las revisiones de dichas certificaciones, en muchas ocasiones son superficiales y/o no se hacen con el rigor que se debería.

Vicente traía a la mesa la noticia sobre la ralentización de las empresas aseguradoras en materia de ciberriesgo relacionado con el ransomware y preguntaba a la mesa por sus opiniones al respecto.

Pablo, apoyado en un reciente estudio e informe preparado desde AON y avalado con datos reales en lugar de encuestas, sobre empresas que tienen o están pensando en contratar un seguro de ciberriesgo (ciberseguro), afirmaba que se obtuvieron las siguientes cuatro importantes conclusiones:

1. Solo el 40% de las empresas tiene estrategias de teletrabajo implantadas y, de entre las que lo tienen, solo el 17% tiene medidas de seguridad para monitorizar la seguridad del teletrabajo.
2. Respecto al riesgo de proveedores (con lo que Pablo respondía así a la pregunta de Vicente), un 21% (1 de cada 5 empresas), monitoriza el riesgo derivado de los terceros.
3. En los 2’5 últimos años, se ha incrementado un 390% la siniestralidad de las aseguradoras con respecto a incidentes de ransomware a cubrir.
4. Respecto a normativas y regulación, el cumplimiento no equivale a seguridad. Un 35% de las empresas reconoce cumplir plenamente con las normativas que les afectan.

“Las aseguradoras están perdiendo dinero con el producto de ciberseguro/ciberriesgo, especialmente en casos de ataques de ransomware, por lo que están dejando de cubrir estas situaciones en sus ciberpólizas y, probablemente, planteándose contar con una póliza independiente y específica para ransomware“.

“¿Creéis que DORA ha bajado demasiado al incluir a micro-empresas y que se esté sobre-regulando?“, preguntaba Vicente.

Julián opinaba que no y que determinadas empresas pequeñas (especialmente las de IT), que tienen talento, y que están prestando servicios a entidades financieras grandes, deben tener esos requisitos y exigencias de cumplimiento.

Silvia apuntaba que el tema de la proporcionalidad ha sido y está siendo uno de los caballos de batalla en las negociaciones de DORA. Además, explicada que en estos momentos se estaba considerando un enfoque que tiene en cuenta el tamaño de la empresa, junto con el perfil de riesgo (puesto que puede estar prestando un servicio de nicho que sea crítico para sus clientes).

Teniendo en cuenta esa postura, “debemos exigir unos mínimos si queremos tener un sistema financiero resiliente, garantizando que estén todos los que deban estar. Esto no les eximiría de tener un mínimo conjunto de controles que garanticen su resiliencia aunque, probablemente, sí de los aspectos burocráticos. Sólo así evitaremos la propagación de amenazas“, finalizaba diciendo Silvia.

DORA no entra en detalles sobre la inteligencia de amenazas especialmente relacionada con la Deep Web, pero sí en lo que al pentesting se refiere.

“¿Las empresas financieras están ya llevando a cabo actividades de pentesting que permitan determinar su nivel de resiliencia?“

Carmen comenzaba respondiendo a Vicente indicando que el objetivo principal es descubrir y eliminar las vulnerabilidades (tanto dentro como fuera) lo antes posible, por lo que se realiza todo tipo de tests de código estático y dinámico durante los desarrollos, tests de penetración, etc.

El modelo que en su caso están aplicando, continuaba diciendo Carmen, es el de contar con especialistas dentro de la casa además de proveedores de renombre que nos permitan variar el auditor periódicamente y así conseguir unas mejores garantías.

Silvia, como dijo, aprovechó a meter una cuña publicitaria institucional, indicando que “en 2018 el Banco Central Europeo publicó TIBER-EU como marco de pruebas avanzadas de ciberseguridad, que el Banco de España ya ha adoptado, por lo que se podrá convertir en autoridad ciber para ayudar al resto de entidades a realizar esas pruebas“.

Vicente recogía y trasladaba a la mesa una interesante pregunta desde el chat del seminario: “¿Los estándares DORA puede ayudar a que en la parte del software, del código fuente, se apliquen nuevas normas que mejoren o impongan obligaciones de codificación que ahora no existen?“

En el Artículo 22 se habla de Testing Tools and Systems y, dentro de él, de Source Code Review, por lo que a priori, parece que la revisión de código formará parte del alcance de DORA, comentó Pablo.

“Muchos de los desarrollos del software bancario son propios y, además, cada vez tenemos mejores herramientas que se encargan de probar la seguridad del código fuente“, dijo Julián.

¡Eso es!, “una buena calidad de código va directamente relacionada con un menor número de vulnerabilidades“, respondió Carmen.

“¿Todos estos cambios regulatorios, están produciendo los correspondientes cambios organizativos internos y de cultura en las empresas?“, seguía preguntando Vicente.

Carmen respondía de inmediato con un interesante y muy acertado lema interno: “principiantes atacan a máquinas, expertos atacan a personas… a partir de ahí, ya te puedes poner las pilas“.

Respecto a las taxonomías de ataque, dos de las que en su día más le llamaron la atención a Julián, fueron:

• La ingeniería social.
• Y, especialmente, lo que llamó “magia” (que, como citó Julian, era un término que le gustó y había leído de Marcus Ranum), entendiéndose como aquellas formas de atacar que sabemos que existen pero no sabemos cómo lo hacen.

“Nos acordamos de Santa Bárbara solo cuando truena. Desde el WannaCry, no he visto otro impulso para hacer algo al respecto“, comentó Pablo.

Por parte de Silvia, sí había observado un movimiento relacionado con la gobernanza, en términos de formación, procesos, implicación del Consejo, etc. “Muchos (la mayoría, el 90%) de los ciberataques que vemos, triunfan porque fallan los procesos y las personas, no la tecnología“.

Uno de los artículos de DORA dice que “las empresas financieras deben tener preparados planes de comunicación integral (interno y externo), en caso de que se produzca un incidente, que además deben ser probado cada cierto tiempo“.

La duda de Vicente era si “¿las entidades financieras tienen ya, y están aplicando ya, esos planes de comunicación de incidentes?“

En el caso de Carmen, nos comentaba que ya tienen varios modelos y mecanismos de comunicación interna e externa, que identifican qué comunicar y por qué tipo de canales. En el caso de la comunicación a los reguladores (si ésta fuese necesaria), estamos adheridos al procedimiento de notificación del Banco de España.

Pablo comentaba que durante mucho tiempo se han estado haciendo ciberejercicios, pero que no tenía claro hasta qué punto éstos se basaban o focalizaban en la información o notificación tanto como en la acción de contingencia.

A esa afirmación de Pablo, Carmen indicaba que, en su caso, y precisamente por eso y por no generar interferencias y dependencias entre la contención o erradicación de un ciberincidente y su comunicación, habían decidido gestionarlos como elementos totalmente separados e independientes.

En checklist del EIDAS (Reglamento Europeo de Servicios de Confianza) que tienen que superar los prestadores, está incluido el Plan de Comunicación (hacia clientes y hacia supervisores), como una actividad más a realizar, comentaba Julián,

A colación de esta conversación, Carmen sacaba un nuevo tema a debate, especialmente destinado a una respuesta por parte de Silvia como órgano supervisor, en tanto en cuanto a que existen en torno a siete trámites diferentes en caso de que ocurra un incidente… si ese incidente llegase a cumplir los valores umbrales en los siete casos… ¿se deberían realizar siete comunicaciones o bastaría con una unificada?

Silvia respondió que será una de las buenas cosas que llegue con DORA, pues tratará de unificar los incidentes bajo la NIS, bajo la Directiva de Seguridad de la Información de las Redes, bajo PSD2 y todos los incidentes sectoriales. Por lo tanto, la notificación será unificada y se deberá realizar en una sola ocasión.

Sin embargo, Silvia nos facilitaba más información sobre “el estado del arte” actual de este tema. La versión de DORA que actualmente está publicada, no cubre ese objetivo, el tratar de armonizar las diferentes notificaciones de incidentes.

La realidad es que, en estos momentos, está negociándose encima de la mesa, siendo un tema extremadamente político que aún no se sabe cómo va a quedar, pues, además, la NIS2 se está negociando en paralelo.

“La propuesta que se ha hecho desde el Consejo de Delegados es que la notificación de un incidente se haga a la autoridad nacional, para que la entidad notifique una sola vez (en nuestro caso, al Banco de España) y que esa autoridad notificada sea la encargada de notificar a su vez a las autoridades que le corresponda. Así se quita esa carga de las entidades, trasladándosela a las autoridades“, finalizaba respondiendo Silvia.

Vicente retomaba el debate afirmando que el sector de los bancos está muy regulado y por lo tanto acostumbrado, pero DORA no es solo para bancos, también incluye aseguradoras, agencias de valores, criptomonedas y otras entidades que manejen dinero en Europa.

“¿Qué ocurrirá cuando DORA y toda esta regulación se aplique a empresas afectadas que no han estado reguladas (o no del todo, o de ese modo) hasta ahora y que no están tan acostumbradas a este modo de funcionar?“

La respuesta de Julián vinculaba el escenario expuesto por Vicente al reglamento Markets in Cryto-Asset (MiCA), porque las entidades que gestionen criptoactivos (dado que MiCA deja muy claras las diferentes modalidades de inversión y los criptoactivos son una de ellas) deberán ser reguladas del mismo modo.

Yendo un poco más allá, Julián extendía la pregunta de Vicente poniendo encima de la mesa la duda de lo que pasaría con Sandbox, pues tiene 18 proyectos aprobados y 9 de ellos están relacionados con blockchain.

La preocupación de Pablo, visto desde la perspectiva del sector seguros, es la aplicabilidad en entidades de tan diverso perfil de riesgo.

Silvia afirmaba que ese tipos de empresas no reguladas hasta el momento parten de una situación diferente, por lo que los que tengan un mayor nivel de madurez lo tendrán más fácil en contraposición con otros. Pero, definitivamente, en su opinión, el efecto e impacto debe alcanzar a todos aquellos que estén dentro de las TIC con relaciones con el sector financiero.

Dando respuesta a la pregunta del Sandbox que Julián puso encima de la mesa, Silvia hacía hincapié en que guarda total relación con aspectos regulatorios. Y, en este caso, lo que aplicaría hacer es chequear si la regulación existente es válida o no para determinado tipo de productos/servicios, que es precisamente lo que se va a probar en lugar de la parte técnica.

Es decir, concluía respondiendo Silvia, “Sandbox no es un espacio donde poner un proyecto que se ha estado desarrollado para probarlo en un entorno de producción, sino que su objetivo es probar si encaja o no en el marco regulatorio, averiguar si hay que tocar la regulación, detectando normas que hay que corregir o que hay que hacer“.

Vicente traía a la mesa una información proveniente del chat de asistentes, relacionada con que recientemente se ha publicado la Norma UNE 32002 sobre Arquitecturas de Confianza en el Intercambio de Inteligencia de Ciberamenazas. La pregunta era si se había planteado su implementación en el sistema financiero pero se desconocía por ser algo tan reciente.

La última pregunta en el debate fue si “DORA, tal y como salga finalmente, ¿se convertirá en el nuevo paradigma (en otro pilar básico) como el que en su momento supuso el RGPD / GDPR en relación con los datos de carácter personal y constituirse como una norma de referencia internacional fuera de la UE?“

Julián respondía afirmativamente, pues entendía que esta nueva situación supone un importante empujón para l sector financiero a nivel global, respecto a la credibilidad y a la funcionalidad del sector financiero europeo mundialmente.

Los deseos de Carmen serían esos, que DORA tuviese tanto o más impacto que el RGPD en su momento, aunque quizá pueda llegar suponer un poco más de esfuerzo porque las autoridades reguladoras para cada uno de los sectores son diferentes. En cualquier caso, el tema de las sanciones hará que “le veamos las orejas al  lobo y nos pongamos las pilas“.

Sin duda, habrá un antes y un después de DORA, respondía Silvia, pues era la pieza definitiva que necesitábamos para tener un sistema financiero moderno, del Siglo XXI, donde no hablemos solo de capital sino también de tecnología, sin la que no se podría sobrevivir.

Para finalizar con el evento, Vicente dejaba una serie de conclusiones tras el debate:

1. DORA es muy importante.
2. Debemos comenzar a hacer cosas ya para adaptarnos a DORA, independientemente de que el texto sufra cambios por el camino en su negociación.
3. Quizá la UE haya comenzado con el sector financiero porque éste se encuentre más y mejor preparado pero, probablemente, luego se continúe con la extensión a otros sectores estratégicos (energía, telecomunicaciones, salud, etc.).
4. Es una cuestión tecnológica, pero la tecnología es un componente más que debe coexistir con los procesos y con las personas.

Tras estas conclusiones, Vicente terminaba agradeciendo, felicitando y dando la enhorabuena a ISACA, a Carlos y a Joris, por ser el alma de estas iniciativas y debates tan interesantes, necesarios y productivos.

En la réplica por parte de Ricardo, agradecía la participación de los panelistas, expertos y excelentes ponentes, por sus clases magistrales; así como al resto de asistentes (más de 230).

Y, dando por concluido el evento, y dando paso a Joris con su habitual “After Work“, Ricardo dejaba encima de la mesa la siguiente reflexión o frase de resiliencia de una empresa:

“No me juzgues por mis beneficios, júzgame por la cantidad de veces que me atacaron los delincuentes y la cantidad de veces que volví a dar servicio a mis clientes“.

Así fue el webinar “Explorando el Reglamento de Resiliencia Operativa Digital (DORA)” y así se lo contamos.

Si estuviste y quieres recapitular alguno de los temas comentados, o si te lo perdiste y quieres verlo, puedes hacerlo en el canal de YouTube de ISACA Madrid Chapter (solo para asociados).

Autor: Iñigo Ladrón Morales, Asociado, y Creador de contenidos de ISACA Madrid.