El Banco de España aprueba la guía de implementación de TIBER-ES basada en TIBER-EU

El pasado 27 de diciembre de 2021, el Banco de España aprobó la «Guía de Implementación TIBER-ES – Threat Intelligence Based Ethical Red-Teaming – España», publicada este mes de enero de 2022.

En respuesta al incremento de ataques cibernéticos a nivel mundial en los últimos años, cada vez son más las entidades que optan por someter sus infraestructuras a pruebas como auditorías web y ejercicios de pentesting. En base a esto, las instituciones gubernamentales han ido optando, poco a poco, por desarrollar marcos de trabajo a los que, tanto la parte contratante como quien realiza el servicio, puedan acogerse y definir al máximo posible el alcance de las pruebas a realizar.

Siguiendo esta línea, el Banco Central Europeo (ECB, por sus siglas en inglés) publicó en mayo de 2018 el documento «TIBER-EU Framework – How to implement the European framework for Threat Intelligence-based Ethical Red Teaming» y, posteriormente, en agosto de ese mismo año, una guía para los proveedores de servicio llamada «TIBER-EU Framework – Services Procurement Guidelines«. En el caso del primer documento, el ECB lo define como un marco de trabajo común que «proporciona una serie de pruebas controladas, personalizadas y guiadas por un marco de inteligencia contra sistemas críticos en producción de las entidades», tratándose de una serie de pautas aplicables a un contexto jurisdiccional variado. En cuanto a la guía para proveedores de servicios, ésta pretende servir de apoyo a las entidades del sector financiero (entre otros) para proporcionar servicios de inteligencia de amenazas y ejercicios de Red Team.

En las siguientes secciones del artículo, explicaremos quiénes participan en un ejercicio basado en TIBER-ES y cuáles son sus roles, así como las distintas fases y tareas en las que se dividen las pruebas.

¿Quiénes son los participantes y cuáles son sus funciones?

1. TIBER Cyber Team (TCT).

• Revisar periódicamente el marco TIBER-ES y aplicar las medidas de implementación y test realizados, además de proponer actualizaciones.
• Participar en el TIBER Knowledge Centre (TKC) del ECB y proponer actualizaciones del marco TIBER-ES. En este foro común colaboran todas las jurisdicciones que han adoptado TIBER.
• Invalidar las pruebas si no se realizan de acuerdo a TIBER-ES y TIBER-EU.

El TCT no desempeña un papel supervisor, no es responsable de las acciones de la entidad que se somete al test ni de sus proveedores, ni tampoco de los riesgos de las pruebas. Por cada test, el TCT nombrará un Team Test Manager (TTM), quien debe:

• Realizar un seguimiento de la prueba.
• Representar al TCT y coordinar sus acciones de apoyo a las pruebas, actuando como punto de contacto.

2. Entidad que se somete al test.

• White Team: para cada test, la entidad que se somete a él ha de establecer un White Team (WT), que será el responsable último de la definición del alcance y de la ejecución efectiva del test. Asimismo, si existen razones que lo justifiquen, el WT podrá poner fin a las pruebas. El número de miembros será reducido y no deberán informar al resto de áreas de la empresa sobre los ejercicios a realizar. Se nombrará un White Team Lead (WTL), y los requisitos sobre su composición, actividades y responsabilidades son recogidos en la guía TIBER-EU White Team Guidance del ECB.

• Blue Team: el Blue Team (BT) estará formado por todos los demás miembros de la entidad objeto de la prueba y no deberá ser informado sobre la misma hasta la fase de cierre.

• Proveedores: la entidad y los proveedores que participan deben acordar, antes del ejercicio, aspectos como las condiciones económicas y el alcance de las pruebas, entre otros puntos. Los proveedores deben ser independientes respecto de la entidad sometida al test para garantizar la objetividad de los resultados. Por último, un mismo proveedor podrá prestar simultáneamente las funciones de TI y de Red Team (RT). Los requisitos se encuentran establecidos en la guía TIBER-EU Services Procurement Guidelines del ECB.

• Threat Intelligence: el proveedor de Threat Intelligence (TI) recopilará información, replicando la investigación que realizaría un ciberatacante y proporcionará a la entidad que se someterá al test un informe sobre las amenazas específicas.

• Red Team: su objetivo será comprometer las capacidades de seguridad de la entidad haciendo uso de técnicas, tácticas y procedimientos (TTP) y métodos de hacking ético. Sus ataques se basarán en la información del proveedor de TI y en los escenarios diseñados. Al igual que en el caso anterior, al finalizar las pruebas se realizará un informe sobre la ejecución de los escenarios y las debilidades detectadas.

¿En qué consiste un proceso de test bajo el esquema TIBER-ES?

Podemos distinguir tres fases:

1. Fase de preparación: se establecen los equipos responsables de la gestión integral del test y su alcance (focalizado en las funciones críticas de negocio), y se seleccionan los proveedores de TI y de RT que lo llevarán a cabo. Esta fase dará comienzo tras el acuerdo entre la entidad que se somete al test y el TCT. Tiene una duración de entre cuatro y seis semanas sin incluir el tiempo necesario para contratar a los proveedores.

• Prelanzamiento: la entidad designará a un WTL y establecerá la composición del WT, que el TTM deberá validar, utilizando la guía TIBER-EU White Team Guidance. Tendrá lugar una reunión de prelanzamiento y se tratarán los requisitos respecto a las partes involucradas y sus responsabilidades, protocolos de seguridad y confidencialidad. El WT adoptará las medidas necesarias para la gestión de los riesgos derivados del test.

• Contratación de proveedores: el TCT solo validará la prueba bajo el esquema TIBER-ES si esta se lleva a cabo por proveedores externos que cuenten con una adecuada independencia respecto a la entidad, debiendo acreditar los proveedores su experiencia en ese campo. La selección se basará en la guía TIBER-EU Services Procurement Guidelines. Durante la formalización de los contratos se incluirán, entre otros, aspectos como las condiciones económicas y el alcance de las pruebas.

• Lanzamiento: una vez seleccionados los proveedores de TI y de RT, el WT completará la planificación de las pruebas y la agenda de reuniones con los participantes. Se celebrará una reunión en la que se detallará el proceso del test, las expectativas de la entidad, la planificación y un cronograma con las reuniones y puntos de control básico.

• Definición del alcance: el WT definirá el alcance preliminar de la prueba, que deberá incluir funciones críticas de la entidad y los sistemas y servicios que soportan dichas funciones. Si las funciones críticas están total o parcialmente externalizadas, la entidad valorará la posibilidad de incluir a un representante del proveedor como miembro del WT, para desarrollar la prueba de la misma manera que si no existiera dicha externalización. El WT establecerá los objetivos que deberá lograr el RT durante la prueba, los cuales podrán ir actualizándose durante las pruebas. Aunque la prueba deba ser realizada en un entorno de producción, los objetivos específicos podrán realizarse sobre entornos de producción, por ejemplo. El WT compartirá con el TCT y con los proveedores de TI y de RT el documento de alcance preliminar (TIBER-EU Scope Specification Template), con el fin de incorporar sus aportaciones. El documento del alcance deberá ser validado por el TCT, los proveedores de TI y de RT, y deberá ser firmado por el consejo de administración de la entidad.

2. Fase de testing: en base a un informe proporcionado por el proveedor de TI sobre la entidad objetivo del ejercicio, el equipo de RT usará los escenarios planteados para el ataque para intentar comprometer los sistemas informáticos en producción, así como los procesos y personas que forman parte del alcance de la prueba. La consecución del objetivo se demostrará logrando, a su vez, superar una serie de pruebas. En el caso de TIBER-ES, estas pruebas se definen como «captura de banderas», un concepto conocido al menos por aquellos que participan comúnmente en competiciones CTF (Capture the Flag). Tiene una duración aproximada de entre dieciséis y dieciocho semanas.

• Recopilación de información y ciberinteligencia: se pretende emular la tarea de recopilación de información previa a un ataque, que un ciberatacante real desarrollaría como fase de reconocimiento. En este primer paso de ciberinteligencia es importante reflejar las amenazas más importantes a las que se enfrenta, así como conseguir una visión lo más detallada posible de los mecanismos de defensa y de la superficie de exposición de la entidad. Este paso suele durar unas cinco semanas. En base a esta fase se desarrollarán los escenarios de ataque. Este informe será realizado por el proveedor de TI y será facilitado al WT, RT y TCT, quienes lo revisarán y validarán.

• Plan de test del Red Team: suele durar unas dos semanas. El plan de la prueba se realizará en base al informe mencionado en el punto anterior. La entidad podrá proveer al Red Team de información relevante para simular mejor las condiciones de un ataque real. El plan de test del RT estará formado por una serie de escenarios que representarán objetivos concretos a lograr. Tras esto se llevará a cabo una reunión entre el WT y los proveedores de TI y Red Team y TCT para discutir los detalles operacionales.

• Ejecución del test: suele durar entre diez y doce semanas. El RT deberá desarrollar técnicas alternativas de ataque en caso de encontrar obstáculos para lograr los objetivos o capturar las banderas asignadas. En ocasiones, el RT puede requerir al WT asistencia para deshabilitar barreras internas y/o controles de seguridad de la entidad, con el fin de facilitar el progreso del test; esta petición deberá quedar reflejada en los informes. El RT mantendrá continuamente informado al WT de los progresos, y deberá informar al menos semanalmente al TCT del avance de la ejecución del test. En caso de reuniones, el Blue Team (BT) no debe estar al tanto.

3. Fase de cierre: el proveedor de RT elaborará un informe de las actividades realizadas (proceso, recomendaciones y observaciones), que será analizado por el equipo de seguridad defensiva de la entidad. Se elaborará, a su vez, un informe-resumen de la prueba y se desarrollará un plan de acción para implementar las recomendaciones.

• Elaboración del informe del RT y del BT: el primero enviará al WT y al TCT su borrador del informe del test en un plazo máximo de dos semanas después de finalizarlo. El WT informará sobre el test realizado a los miembros clave del BT, quienes usarán el informe del RT para elaborar su propio informe.

• Recreación del test, lecciones aprendidas y plan de acción: el test será recreado por el RT y el BT y ambas partes revisarán los pasos dados, aunque no será estrictamente necesaria la recreación completa ni en entornos de producción; el fin es el aprendizaje. El RT deberá dar su opinión sobre lo que un atacante real con más tiempo podría haber logrado. Opcionalmente, se puede crear un Purple Team (PT), compuesto por miembros del RT y del BT, con el objetivo de trabajar conjuntamente en analizar qué opciones podría haber tomado el RT en el test y cómo podría haber respondido el BT ante ellos. Posteriormente, el WT llevará a cabo una reunión de evaluación entre todas las partes que intervienen en el test. La entidad deberá elaborar un plan de acción (acordado entre los proveedores de TI y RT) para la implementación de las recomendaciones de mejora acordadas, el cual se enviará a la autoridad supervisora de la entidad, ya sea nacional o supranacional.

• Informe-resumen del test: la entidad elaborará un informe-resumen del test basándose en documentos como los informes anteriormente realizados. No se incluirá información técnica detallada sobre las debilidades y vulnerabilidades encontradas debido a su confidencialidad. Este informe será compartido con el TCT y será enviado a la autoridad supervisora de la entidad, ya sea de ámbito nacional o supranacional.

• Validación del test: una vez acordado el plan de acción para implementar las recomendaciones, los proveedores de TI, Red Team y el TCT deberán validar que el test se ha hecho de acuerdo a los requisitos del marco TIBER-ES.

Cómo proceder con la gestión de riesgos durante las pruebas.

En primer lugar, resulta esencial llevar a cabo una identificación y un análisis detallado de los riesgos que podrían materializarse al ejecutar el test, y tomar acciones apropiadas para mitigarlos antes, durante y después de éste, lo que se traduce en un plan de contingencias, siendo esto responsabilidad del WT.

Los contratos con los proveedores deberán incluir cláusulas de confidencialidad y cubrir aspectos como los requisitos de seguridad, las responsabilidades, las indemnizaciones, los límites en la ejecución y las actividades que no están permitidas durante la realización del test.

Respecto a la confidencialidad en la realización de las pruebas, se debe asegurar que nadie en la entidad, salvo el WT, esté al tanto del test, y para ello podrán firmarse acuerdos de confidencialidad (non-disclosure agreements) con los proveedores.

El WT deberá gestionar el escalado de los ciberincidentes relacionados con el test para que no se ejecuten acciones que se llevarían a cabo de manera obligatoria en caso de ocurrir un ciberincidente real, como comunicarse con terceros, entre ellos las Fuerzas y Cuerpos de Seguridad del Estado. Si el se sospecha que el BT está al tanto del test y de que trata de manipular sus resultados, la prueba podría quedar invalidada.

Resultados y su uso en los procesos de supervisión.

Los detalles del resultado de un test realizado bajo el esquema TIBER-ES son única y exclusivamente propiedad de la entidad que se somete a él, debido a su carácter altamente confidencial. La excepción se presenta en el caso del plan de acción para la implementación de las recomendaciones de mejora y del informe-resumen del test, dado que en ellos no se incluirán los detalles técnicos.

No obstante, el TCT puede compartir con el TKC información relativa a las vulnerabilidades encontradas o lecciones aprendidas, en cuyo caso dicha información se anonimizará y se intercambiará usando siempre canales seguros, esto con el objetivo de prmitir al TKC conformar una imagen del estado de la ciberresiliencia del sector financiero europeo.

El equipo encargado de la supervisión estará involucrado tan solo en las fases de preparación y cierre del proceso. Durante la fase de preparación se le comunicará, a título informativo, el comienzo de las pruebas y se le podrá consultar sobre si el alcance definido cubre las funciones críticas de la entidad, y, durante la fase de cierre, se le enviará el informe-resumen y el plan de acción para implementar las recomendaciones de mejora.

Más información

GUÍA DE IMPLEMENTACIÓN TIBER-ES Threat Intelligence Based Ethical Red-Teaming – España

El Banco de España aprueba la guía de implementación de TIBER-ES

TIBER-EU Services Procurement Guidelines

TIBER-EU FRAMEWORK

La entrada El Banco de España aprueba la guía de implementación de TIBER-ES basada en TIBER-EU se publicó primero en Una al Día.