TIBER-ES: cómo prepararse para el TLPT, guía del CISO

TIBER-ES (Threat Intelligence-Based Ethical Red-teaming, España) es la implementación española del marco TIBER-EU del BCE, coordinada por el Banco de España como autoridad nacional. No es un pentest ampliado: es una simulación de ataque dirigida por inteligencia, ejecutada de forma encubierta contra sistemas de producción reales que soportan funciones críticas o importantes de la entidad, con el regulador implicado antes, durante y después.

El alcance no se autoselecciona. Las autoridades competentes designan a las entidades obligadas según impacto, carácter sistémico y perfil de riesgo TIC, con los criterios desarrollados en las normas técnicas de regulación. El Banco de España gestiona la lista por ciclo y actúa como autoridad TLPT del ejercicio. Las entidades no designadas siguen debiendo el programa base de pruebas de resiliencia del Art. 24 de DORA, y muchas ejecutan ejercicios TIBER voluntarios para anticiparse a una designación futura.

DORA, el Reglamento (UE) 2022/2554, divide las pruebas de resiliencia operativa digital en dos niveles. Todas las entidades en alcance ejecutan el programa base de los Art. 24 y 25. Un grupo más reducido debe además realizar threat-led penetration testing, TLPT, bajo el Art. 26: como mínimo una vez cada tres años, con la autoridad competente facultada para ajustar esa frecuencia según el perfil de riesgo. Probar un entorno de preproducción no cumple el artículo.

La cuestión metodológica está resuelta en la práctica: el Art. 26(11) mandó desarrollar las normas técnicas conforme a TIBER-EU. Para una entidad española, TIBER-ES es el manual operativo del TLPT de DORA.

El Art. 27 gobierna a los testers. Los externos deben acreditar la máxima idoneidad y reputación, capacidad técnica y organizativa, certificación o adhesión a códigos de conducta formales, seguro de responsabilidad profesional e independencia respecto a los defensores de la entidad. Los testers internos solo se permiten bajo condiciones adicionales, incluida la aprobación de la autoridad y el uso obligatorio de un proveedor externo de threat intelligence; las entidades de crédito significativas deben usar testers externos.

Los defensores, el SOC ante todo, se mantienen deliberadamente a ciegas. Ese es el sentido del ejercicio: mide qué detecta el SOC y cómo responde cuando nadie le avisó. Un White Team demasiado grande es el error que más ejercicios invalida: la fuga de información al Blue Team destruye la validez de la prueba.

Dónde encaja un asesor independiente. Un asesor independiente sin capacidad ofensiva, sin red team propio ni tooling de explotación, puede asumir el rol de Test Manager. Es el rol que más refuerza la independencia del ejercicio, y antes del ciclo puede aportar la línea base de madurez del SOC que decide si la entidad está lista para someterse a la prueba.

1. 1.Preparación: designación confirmada, White Team constituido, alcance acordado con la autoridad, funciones críticas o importantes mapeadas a sistemas, reglas de enfrentamiento y controles de riesgo firmados.
2. 2.Threat intelligence: el proveedor de TI produce un informe de targeting con los actores más relevantes para la entidad y escenarios realistas basados en sus TTPs conocidas.
3. 3.Ejecución del red team: típicamente en torno a doce semanas de prueba activa contra producción, persiguiendo flags acordados como el acceso a sistemas de pago o a repositorios de datos críticos.
4. 4.Cierre y purple teaming: red team y Blue Team reconstruyen juntos la cadena de ataque, paso a paso, comparando lo ejecutado con lo detectado, triado y escalado.
5. 5.Informe y remediación: hallazgos, causas raíz y plan de remediación se remiten al Banco de España, que emite la attestation confirmando que el ejercicio cumplió los requisitos.

El purple teaming es el producto. La attestation satisface al regulador. El workshop de purple teaming es donde la entidad recupera la inversión: cada paso de la kill chain que pasó sin detectarse se convierte directamente en un elemento de backlog de ingeniería de detección o de proceso de respuesta. Comprimir esta fase a una presentación de cierre desperdicia la mayor parte del presupuesto.

El hallazgo primero: un TLPT evalúa a los defensores, no al firewall. Si su SOC no detecta, tría y escala con fiabilidad, el informe del red team se lee como una larga lista de acciones no observadas. Es una forma cara de documentar ceguera. Un SOC necesita ingeniería de detección operativa, un proceso de respuesta ensayado y un uso real de threat intelligence antes de que un TIBER-ES produzca señal accionable.

El SOC-CMM da el vocabulario para verificarlo con antelación. El modelo, creado por Rob van Os en 2016 y hoy en la versión 2.4, puntúa cinco dominios y 27 aspectos en una escala continua de 0 a 5. Tres áreas mapean directamente sobre la supervivencia en un TLPT: ingeniería de detección y gestión de casos de uso (¿puede usted ver las TTPs del informe de threat intelligence?), respuesta a incidentes de seguridad (¿escalan sus analistas una intrusión real dentro de los plazos acordados?) y threat intelligence (¿convierte el informe de TI en contenido de hunting y detección?).

Los datos sectoriales de 2026 explican la urgencia. Las medias por dominio se sitúan en 2,7 en Tecnología, 2,5 en Negocio y en torno a 2,2-2,3 en Personas, Proceso y Servicios, con una cobertura de técnicas MITRE ATT&CK cercana al 60%. Y las autoevaluaciones sobreestiman la madurez en unos 0,6 puntos: la entidad que entra a un TIBER-ES fiándose de su propia puntuación está, de media, medio nivel de madurez menos preparada de lo que cree. Un assessment de madurez SOC independiente antes del ciclo corrige esa imagen y convierte el TLPT de un examen que se suspende en un ejercicio del que se aprende.

• 12 meses antes: ejecute un assessment SOC-CMM independiente centrado en los aspectos de detección, respuesta y threat intelligence; cierre las brechas que harían el ejercicio trivial para el red team.
• 9 meses antes: constituya el White Team mínimo viable y formalice reglas de confidencialidad; seleccione Test Manager y proveedores de TI y red team conforme a los requisitos del Art. 27.
• 6 meses antes: valide la cobertura ATT&CK frente a los actores que probablemente aparecerán en el informe de TI; ensaye las rutas de escalado con ejercicios de mesa.
• 3 meses antes: acuerde alcance, flags y controles de riesgo con el Banco de España; congele cambios mayores en la pila de detección que contaminarían la medición.
• Después del ejercicio: vuelque cada hallazgo del purple teaming al backlog de detección y vuelva a puntuar los aspectos afectados para evidenciar la mejora ante el consejo y la autoridad.

Si su entidad está designada, trate el ciclo trienal como un programa, no como un evento: evaluar madurez, remediar, probar, purple teaming, reevaluar. Si no lo está, ejecute el mismo bucle de forma voluntaria a menor intensidad; los criterios de designación evolucionan y las autoridades pueden ampliar la lista. En ambos casos, la mejora más barata por euro ocurre antes de contratar al red team: en el SOC, con una línea base de madurez independiente como evidencia de partida.