Threat-led penetration testing (TLPT)

La denominación oficial en español de threat-led penetration testing es «pruebas de penetración basadas en amenazas», y quien lo define no es el mercado sino una norma. El artículo 3, punto 17, del Reglamento (UE) 2022/2554, DORA, lo describe como un marco que reproduce las tácticas, técnicas y procedimientos de agentes de amenazas reales percibidos como una ciberamenaza auténtica y que ofrece una prueba controlada, adaptada y basada en inteligencia (red team) de los sistemas de producción activos críticos de la entidad financiera. Los tres rasgos que lo separan de cualquier otra prueba están en esa sola frase: inteligencia sobre amenazas reales, red team y producción activa.

El ejercicio reparte papeles. Un proveedor de inteligencia de amenazas, externo a la entidad, construye el perfil de quién atacaría y de qué forma. Un red team, interno o externo, ejecuta los escenarios. Un grupo reducido de la entidad, el control team, dirige la prueba y es la única parte que sabe que ocurre, mientras el blue team, que defiende los sistemas, no tiene conocimiento del TLPT. Esa asimetría está en las definiciones del artículo 1 del Reglamento Delegado (UE) 2025/1190, las normas técnicas que desarrollan el TLPT, adoptadas el 13 de febrero de 2025, publicadas el 18 de junio y en vigor desde el 8 de julio de 2025, redactadas, dice su considerando 1, de acuerdo con el marco TIBER-EU, cuya metodología, proceso y estructura reflejan.

El calendario es lo que más se subestima. Desde la notificación de la autoridad TLPT, la entidad tiene tres meses para presentar la información de inicio y seis para el documento de especificación de alcance, que aprueba su órgano de dirección. El responsable del control team elige al menos tres escenarios de ataque, y como máximo uno puede no estar basado en amenazas reales. La fase de red team activo dura en todo caso al menos doce semanas.

El fallo que destapa un TLPT casi nunca es una vulnerabilidad suelta. Es la distancia entre lo que una entidad cree que es su respuesta y lo que pasa cuando no se ha avisado a nadie: la vía de escalado se atasca, el analista de guardia trata una alerta auténtica como ruido, o la contención depende de alguien que está de vacaciones. El valor para un atacante está en las horas que van de la primera acción detectable a la respuesta coordinada, y ejecutar el ejercicio sin avisar a los defensores es la única forma de medirlas.

El segundo problema aparece en la compra. El artículo 27.1 de DORA exige testers de la mayor idoneidad y reputación, con experiencia específica en inteligencia de amenazas, pruebas de penetración y red team, certificados por un organismo de acreditación de un Estado miembro o adheridos a códigos de conducta o marcos éticos formales, con aseguramiento independiente sobre su gestión del riesgo del TLPT y con seguro de responsabilidad civil profesional que cubra mala conducta y negligencia. Las normas técnicas añaden años de experiencia por perfil y referencias de encargos previos, y exigen que dentro de un mismo proveedor la inteligencia y el red team estén separados.

El tercero es leer el informe de validación como un traslado de responsabilidad. Al terminar, la entidad entrega a la autoridad el resumen de conclusiones, los planes de corrección y la documentación, y la autoridad emite un informe de validación (attestation, en la versión inglesa) que habilita el reconocimiento mutuo de la prueba entre autoridades competentes. Acredita cómo se hizo la prueba: la entidad sigue siendo plenamente responsable de su impacto.

Las tres se parecen desde fuera y responden a preguntas distintas: lo que cambia es quién fija el alcance, contra qué se ejecuta y quién lee el resultado.

Ninguno absorbe al otro: el artículo 24.6 exige pruebas anuales sobre los sistemas y aplicaciones que sustentan funciones esenciales o importantes, y ese es el ciclo del pentesting; el del TLPT es trienal y vive aparte. A un red team privado, parecido en la ejecución, le faltan los tres elementos que lo hacen contar ante un supervisor: inteligencia externa, alcance validado por la autoridad e informe de validación final. De ahí el orden que funciona: pentesting acotado, ingeniería de detección, purple team para comprobar que las detecciones disparan, y solo entonces el ejercicio dirigido por amenazas, que solo vale si hay una defensa que merezca la pena medir.

Dar por buena la prueba anual como cumplimiento del artículo 26. Las pruebas de penetración están en la lista del programa general del artículo 25.1; el TLPT es otra obligación, con otro ciclo.

Encargar la inteligencia y la ejecución al mismo equipo. El proveedor de inteligencia tiene que ser externo a la entidad, y dentro de un mismo proveedor la inteligencia y el red team deben estar separados.

Contar el proyecto desde la primera semana de ataque. Antes hay hasta seis meses de preparación con entregables a la autoridad, y después un cierre con plazos propios.

Confundir TIBER-ES con el TLPT obligatorio. El Banco de España es la autoridad propietaria de TIBER-ES, desarrollado con la CNMV y la DGSFP, y su web presenta esas pruebas como voluntarias. La obligación nace del artículo 26 de DORA.

Suponer que el ENS pide lo mismo. El Esquema Nacional de Seguridad exige pruebas de penetración como refuerzo de la medida de vigilancia, y solo en sistemas de categoría alta; su texto no menciona el red team ni las pruebas dirigidas por inteligencia.

Averigua si la entidad entra en los criterios de identificación en vez de deducirlo. Las normas técnicas obligan a las autoridades a exigir TLPT, salvo que la evaluación cualitativa lo desaconseje, a las entidades de crédito de importancia sistémica mundial o de otro tipo, a los depositarios centrales de valores y a las entidades de contrapartida central sin umbral alguno, y a las entidades de pago que superen 150.000 millones de euros en operaciones en cada uno de los dos años naturales previos, con umbrales propios para dinero electrónico, seguros y centros de negociación.

Decide pronto si usarás testers internos, porque ese camino es más estrecho: hacen falta la aprobación de la autoridad, su verificación de que hay recursos dedicados y de que se evitan conflictos de interés, y un proveedor de inteligencia externo en todo caso. La política interna debe exigir un responsable de pruebas y al menos dos miembros más, empleados por la entidad o por un proveedor de TIC del grupo durante los doce meses previos. Aun así hay que contratar testers externos cada tres pruebas, y las entidades de crédito significativas solo pueden usar testers externos.

Mete la aprobación del alcance en el calendario de gobierno: la firma el órgano de dirección y vence a los seis meses de la notificación. Y si operas en varios Estados miembros, tu autoridad informará a las de acogida, que tienen veinte días hábiles para pedir participar como observadoras o designar un test manager.

La evidencia de un TLPT no es un informe, son varios y con fecha. Contados desde el fin de la fase activa, el informe del red team se entrega en cuatro semanas y el del blue team a más tardar en diez, plazo en el que también entran el repaso de acciones ofensivas y defensivas y el purple teaming. El resumen de conclusiones y el plan de corrección se presentan en ocho semanas desde la notificación correspondiente. Un supervisor lee ese conjunto.

Somos explícitos sobre lo que aportamos y lo que no. Ejecutamos el ejercicio técnico y producimos la evidencia: la inteligencia utilizada, los escenarios, las cronologías de detección y respuesta, los hallazgos y la severidad, escrita contra la función afectada y no contra el activo técnico. No determinamos el ámbito regulatorio ni presentamos nada ante las autoridades.

Cuando el ejercicio tiene que valer formalmente, los requisitos sobre testers y proceso se confirman con la autoridad competente antes de acotar nada, porque de eso depende el informe de validación final. El artículo 26 apunta a la emulación de adversarios ejecutada contra producción y contra una defensa en vivo, que es la forma de prueba que responde a la pregunta que hace el reglamento.

¿Cada cuánto hay que hacer un TLPT? Al menos cada tres años para las entidades financieras que identifique la autoridad competente, que puede exigir una frecuencia mayor o menor según el perfil de riesgo. Quedan fuera las microempresas y las entidades sujetas al marco simplificado de gestión del riesgo de TIC.

¿Nuestro pentesting anual cumple el artículo 26? No. Suma al programa general de pruebas, donde el artículo 24.6 ya exige pruebas anuales sobre los sistemas que sustentan funciones esenciales o importantes. El TLPT es otra obligación: dirigida por inteligencia externa, contra producción activa y con el alcance validado por la autoridad.

¿Podemos usar nuestro propio red team? Con tres condiciones acumulativas: aprobación de la autoridad competente, verificación de que hay recursos dedicados y de que se evitan conflictos de interés, y un proveedor de inteligencia externo a la entidad. Además hay que recurrir a testers externos cada tres pruebas.

¿TIBER-EU y el TLPT son lo mismo? No. TIBER-EU es el marco del BCE y los bancos centrales nacionales, publicado en mayo de 2018 y de adopción voluntaria; el TLPT del artículo 26 de DORA es obligatorio para las entidades identificadas. El marco se actualizó el 11 de febrero de 2025 para alinearse con las normas técnicas.

¿Cuánto dura un TLPT? La norma fija mínimos y plazos, no una duración total: al menos doce semanas de fase activa, hasta seis meses de preparación desde la notificación y varias semanas de cierre. La duración real depende del alcance y del calendario que se acuerde con la autoridad.