RED TEAM

Un pentesting encuentra los agujeros. Un red team descubre si alguien está mirando.

Un pentesting te lista las vulnerabilidades. Un red team responde a la pregunta difícil: si mañana un atacante real y decidido fuera a por ti, ¿se darían cuenta tus personas, tus procesos y tu tecnología, y podríais pararlo antes de que llegara a lo que importa?

Emulamos a un adversario de verdad contra un objetivo real, en silencio y de punta a punta, y te enseñamos exactamente hasta dónde llega y quién lo ve.

PRIMERA REUNIÓN

Cuéntanos tu ejercicio de red team

Un especialista senior te responde en un día laborable.

Protegido por reCAPTCHA. Se aplican la Política de Privacidad y las Condiciones del Servicio de Google.

Ya confían en nosotros
RED TEAM FRENTE A PENTESTING

Red team o pentesting,cuál necesitas.

Un pentesting pregunta qué es explotable aquí. Un red team pregunta si detectaríamos y pararíamos a un atacante real que va a por algo concreto.

ESTÁS AQUÍ

Red team

Pentesting

Pregunta que responde
¿Detectaríamos y pararíamos a un atacante real?
¿Qué es explotable en este alcance?
Objetivo
Alcanzar un objetivo definido (datos, dominio, fondos).
Encontrar y validar tantas vulnerabilidades como sea posible.
Visibilidad
Encubierto. Tu blue team no lo sabe.
Anunciado y colaborativo.
Qué pone a prueba
Personas, procesos, tecnología, detección y respuesta.
Las vulnerabilidades técnicas del objetivo.
Métricas clave
MTTD, MTTC, objetivos alcanzados, cobertura de ATT&CK.
Número y criticidad de los hallazgos.
Encaja cuando
Ya tienes un equipo de seguridad y quieres ponerlo a prueba. DORA / TIBER-EU.
Quieres encontrar y corregir vulnerabilidades, o cumplir una línea base normativa.

¿Detectaríamos y pararíamos a un atacante real?

Dos formas de hacerlo, y por qué un equipo contrata una.

Los adversarios reales no siempre empiezan desde cero. El modelo más barato y más útil suele ser el que arranca con el atacante ya dentro, porque responde a la pregunta que de verdad tiene tu equipo de respuesta a incidentes.

MODELO A

Initial Access (acceso inicial)

Empezamos desde fuera sin más que información pública, exactamente como lo haría un atacante real. La mayor parte del calendario se va en reconocimiento, que es lo que hace que este sea el ejercicio más largo, y después en el único intento que tiene que funcionar. Phishing o ingeniería social solo si encaja en tu modelo de amenaza y lo apruebas.

Reconocimiento
INICIO
Entrada
Punto de apoyo
Movimiento
Objetivo
  • Primero reconocimiento y después un intento: phishing, servicio expuesto o una credencial válida
  • Pone a prueba el perímetro, la concienciación y la detección en la entrada
  • Mejor cuando el modelo de amenaza es un atacante externo y oportunista
  • Ejercicio más largo, porque las semanas se van en el reconocimiento
MODELO B

Assumed Breach (brecha asumida)

Empezamos donde empieza de verdad una intrusión: un beacon corriendo en la máquina de un empleado en activo, sin privilegios. Ni un portátil de repuesto ni una imagen recién hecha, porque un operador vive de la información que deja el uso diario, y a ser posible que no sea una máquina de TI. Desde ahí medimos cuánto tardas en detectar el movimiento, hasta dónde llega y hasta qué punto funciona la contención. Si el Initial Access entra en el alcance pero no se consigue en la ventana acordada, pasamos al punto de apoyo para que la medición se haga igual. Bajo TIBER-EU y el RTS de TLPT de DORA eso es un leg-up, y CBEST lo llama de-chaining: se planifica de antemano, lo concede el Control Team y queda registrado en el informe.

Punto de apoyo
INICIO
Descubrimiento
Movimiento
Objetivo
  • Arranca en el punto de apoyo: el reloj corre desde el primer día
  • Pone a prueba el descubrimiento, los privilegios, el movimiento lateral, la nube y la detección
  • Mejor cuando el modelo de amenaza es «algún phishing acabará colando»
  • Ejercicio más ajustado, con más señal por día

Un red team casi nunca es rutina. Lo desencadena una pregunta del consejo sobre la preparación frente al ransomware, una obligación de DORA o de TIBER-EU, un SOC nuevo que quieres demostrar, un incidente en tu sector o un hito de madurez. Elige el que hoy sea verdad en tu caso.

Mira exactamente cómo se desarrollaría un ataque real.

Un ejercicio ilustrativo, hito a hito: lo que hizo el equipo rojo en cada paso, la técnica de ATT&CK que hay detrás de cada movimiento, y lo que el equipo defensor vio y lo que no vio. La empresa, las cuentas y las máquinas son inventadas. Lo que se repite de un ejercicio a otro es la secuencia, no los nombres. Los hitos marcan el orden del relato, no lo que dura tu ejercicio: eso sale del alcance.

Ejercicio de Red Team · Asperis Security
El primer movimiento no toca tu red.

Antes de que te llegue un solo paquete, el operador ya sabe quién firma tus facturas, quién atiende tu soporte y qué productos de seguridad nombran tus ofertas de empleo. Después monta la infraestructura y espera a un día en el que un correo así no llame la atención.

OSINT · transparencia de certificados Dominio parecido · evilginx
ENTREGA DEL PHISHINGCONSENTIMIENTO OAUTH
AsuntoAcción requerida · Verifica tu acceso antes de fin de día
«Tu sesión de SSO ha caducado. Vuelve a autorizarla en un clic…»
[ Autorizar ]
Autorizar Helpdesk Login
  • Leer tu buzón
  • Leer tus contactos
  • Iniciar sesión sin conexión
Permitir ✓
token=eyJ0eXAiOi… ✓ aceptado
Ejercicio de Red Team · Asperis Security
Ninguna contraseña robada. Ninguna alarma que dar.

Lo que se autoriza no es un inicio de sesión, es una aplicación. Desde ese momento el operador lee ese buzón con un consentimiento que le dieron, y el siguiente correo que recibe la empresa viene de dentro, de una dirección en la que todo el mundo confía.

Mythic / Sliver Cargador firmado · carga reflexiva
BALIZA C2 · MYTHIC● EN VIVO
10:26:29[+] task: whoami /priv · queued
10:26:29[~] 612ms · TGT cached · S-1-5-21-… (svc_deploy)
10:26:29[+] beacon 4f2a checking in · sleep 60s · jitter 30%
10:26:29[!] T1134.004 parent spoof · no alert raised
10:26:29[+] task: nltest /domain_trusts · queued
10:26:29[~] 188ms · 6 KB · 200 OK
$
$
Ejercicio de Red Team · Asperis Security
El camino ya está puesto. Solo hay que leerlo.

Escalar privilegios en un dominio maduro casi nunca es un exploit. Es un permiso que se concedió hace años por un motivo que entonces tenía sentido, y una plantilla de certificados que se fía de quien pregunta. Todos los entornos tienen al menos uno.

BloodHound / SharpHound Certify / Rubeus
CAMINO DE ATAQUE · BLOODHOUNDESC1 · 4 saltos
GenericWriteAddKeyCredentialLinkEnroll-On-Behalf-OfUSRm.ortegaGRPIT-HelpdeskCMPWS-014.corpCRTUser-AuthDCDOMAIN ADMIN
Ejercicio de Red Team · Asperis Security
Por todo el parque, usando tus propias puertas.

A partir de aquí nada parece un ataque. El operador se autentica como se autentican tus administradores, se conecta como se conectan tus administradores y cruza a la nube por una identidad en la que confían a la vez el entorno local y el tenant.

Rubeus · PKINIT Graph · registros de aplicación
LATERAL · WMI · RDP · NUBE4 saltos · 11 min
WS-014localFS-CORP-01servidor de ficherosJUMP-DC-02tier-1azure.signinnubeWMIPSExecabuso de STS
Ejercicio de Red Team · Asperis Security
Lo demostramos, no nos lo llevamos.

El objetivo se acuerda contigo antes del día uno, y es lo que de verdad haría daño si llegara otro primero. Llegamos, demostramos que hemos llegado, y el resto del ejercicio lo dedicamos a devolverle la ruta entera a tu equipo.

Canario con hash Sesión de repetición
CANARIO · PRUEBA DE SOLO LECTURASHA-256 · firmado
objetivodb-prod-01:/var/lib/postgresql/customers
acciónsolo lectura · 1 fila · muestra con hash
escribiendo el canario
prueba capturada · canary_72f4.pdf · 0.4 KB
DLPsin alerta del DLP · la política debía haber saltado

Nos eligen los equipos de seguridad.

Con nombre, cargo y empresa.

Desde Etnia valoramos muy positivamente la colaboración con Asperis Security. Su profesionalidad, cercanía, rapidez de respuesta y capacidad para adaptarse a nuestras necesidades han sido clave en cada proyecto. La calidad del servicio y el acompañamiento continuo nos aportan siempre mucha tranquilidad. Sin duda, es un placer contar con ellos como partners tecnológicos.
Sergi Leno, Responsable de Sistemas
ETNIA Barcelona
En NPAW hemos colaborado con Asperis en distintas iniciativas relacionadas con la seguridad y la experiencia ha sido muy positiva. Valoramos especialmente su capacidad para adaptarse a nuestras necesidades y el nivel de profundidad con el que abordan cada proyecto. Los resultados son claros, estructurados y útiles para la toma de decisiones y la mejora continua en seguridad. Nos gusta trabajar con Asperis por el criterio y el valor que aportan en cada colaboración. Su trabajo nos ha ayudado a reforzar nuestro nivel de seguridad.
Sergi Laencina Verdaguer, CISO
NPAW
ASPERIS nos ha acompañado en la definición e implantación de nuestro roadmap de ciberseguridad en Microsoft 365 con un enfoque estructurado y alineado a negocio. Gracias a su asesoramiento, dimos el paso estratégico de completar nuestro ecosistema Microsoft y reforzarlo con CrowdStrike para la protección avanzada de dispositivos móviles, elevando de forma significativa nuestro nivel de seguridad.
Jordi Bondia, Director de TI
SALVI
Con Asperis no contratas un servicio, contratas un compañero. No buscan facturar un proyecto, buscan establecer una relación de confianza preocupándose por los puntos clave que afectan a la seguridad de tu organización. Profesionalidad, saber hacer y diligencia.
Juan Valer Tecedor, Ingeniero de Software
GNOSS
CUANDO TÚ QUIERAS

¿Quieres saber qué hacen de verdad tus defensas?

Treinta minutos con el especialista que dirigiría tu ejercicio, para acordar el objetivo y el modelo.

Cada movimiento, cada evidencia: en una sola capa operativa.

El proyecto entero vive aquí, junto al calendario, las métricas, las evidencias y el especialista que lo ejecutó.

  • Relato en vivo de cada acción del operador
  • Mapeo a MITRE ATT&CK de cada movimiento
  • MTTD y MTTC por técnica, calculados automáticamente
  • Paquete completo de evidencias: PCAP, IOC, registros y capturas

Qué te llevas de verdad, y por qué es distinto.

La mayoría de los red teams te devuelven el relato de cómo ganaron. Aquí es donde vamos más allá.

Guiado por amenazas, no genérico

Emulamos al adversario que de verdad va a por tu sector, construido a partir de inteligencia real y no de un manual único para todos. El ejercicio refleja quién vendría a por ti de verdad.

Ponemos a prueba a los defensores, no solo a las puertas

La detección y la respuesta se miden, no se suponen. Te llevas el MTTD y el MTTC, los objetivos alcanzados y tu cobertura frente a MITRE ATT&CK: números sobre los que pueden actuar tanto un consejo como un SOC.

Seguro por diseño

Un Control Team, unas Rules of Engagement claras, un punto de control Pre-Out antes de tocar ninguna joya de la corona y un debrief Hot-Wash en las 24 a 48 horas siguientes a una detección clave. Un ejercicio encubierto que no se convierte nunca en un incidente real.

Detecciones que te quedas

Un Attack Replay lleva a tus defensores por todo lo que hicimos, con los artefactos y los indicadores para construir detecciones que duren. El ejercicio deja a tu blue team permanentemente mejor, y un retest gratuito confirma que las correcciones aguantaron.

Test de aplicabilidad

¿Te aplica el TLPT de DORA?

Cuatro preguntas, y se resuelve entero en esta página.

No se envía nada. Las respuestas no salen de tu navegador y no te pedimos el correo.

¿Qué tipo de entidad sois?

La lista es la del artículo 2, apartado 1, de DORA. Si no encuentras tu categoría, lo más probable es que el reglamento no te aplique.

Banca y pagos

Mercados e inversión

Seguros y pensiones

Otros

¿Dónde está autorizada o registrada la entidad?
¿Qué tamaño tiene la entidad?

DORA define microempresa en su artículo 3, punto 60. Literal: «una entidad financiera distinta de un centro de negociación, una entidad de contrapartida central, un registro de operaciones o un depositario central de valores, que emplea a menos de diez personas y cuyo volumen de negocios anual o balance anual total es igual o inferior a 2 millones EUR».

¿Os ha notificado ya vuestra autoridad competente que debéis realizar un TLPT?

La notificación es lo que abre la fase de preparación. El artículo 9, apartado 1, del RTS de TLPT dice que la entidad financiera determinada con arreglo al artículo 26, apartado 8, párrafo tercero, de DORA «iniciará una prueba de penetración basada en amenazas tras la notificación de la autoridad competente en la materia sobre la conveniencia de llevar a cabo ese tipo de prueba».

Tu resultado

Estás en el grupo del que se designa. Hoy no tienes obligación de TLPT.

Por tipo de entidad, por dónde estás autorizada y por tamaño, encajas en el conjunto del que las autoridades competentes eligen qué entidades tienen que realizar un TLPT. Que encajes no significa que te toque.

Quién tiene que hacerlo lo determina la autoridad competente, entidad por entidad. El artículo 26, apartado 8, párrafo tercero, de DORA lo dice así: «Las autoridades competentes determinarán qué entidades financieras deberán realizar pruebas de penetración basadas en amenazas». El artículo 2 del RTS de TLPT desarrolla con qué criterios: impacto, carácter sistémico y perfil de riesgo relacionado con las TIC. No hay un umbral que cruces solo ni una lista pública en la que te apuntes.

La notificación llega por escrito de tu autoridad competente y se dirige a la entidad, no a una persona. Si nadie de la entidad la ha recibido, no estáis determinados. Y desde que llega se nota: el artículo 9, apartado 2, del RTS os da tres meses para presentar la carta del proyecto, los datos del responsable del equipo de control, los canales de comunicación y el nombre clave de la prueba. Si hubiese llegado, en la casa se sabría.

No te hemos preguntado por el tamaño porque en tu caso no cambia nada. El artículo 3, punto 60, de DORA deja fuera de la definición de microempresa a los centros de negociación, las entidades de contrapartida central, los registros de operaciones y los depositarios centrales de valores. Esa salida no existe para ti.

Lo que puedes hacer hoy, y no depende de nadie más:

  • Contrastar el umbral de arriba con tus propias cifras. Es el primer criterio que tu autoridad mira.
  • Revisar los requisitos contractuales con tus proveedores TIC, que es la parte de DORA que ya te aplica hoy.
  • Si lo que quieres saber es cuánto tardaría tu equipo en detectar a alguien dentro, eso se mide con un red team, con reglamento o sin él.

Tu resultado

Os han notificado. A partir de ahí el calendario lo marca el reglamento.

Desde la notificación, la prueba tiene que cumplir el artículo 26 de DORA y el Reglamento Delegado (UE) 2025/1190, que son las normas técnicas de TLPT. Los plazos que ya corren, con el artículo de cada uno para que no tengáis que fiaros de nuestra palabra:

  • Tres meses desde la notificación para presentar la carta del proyecto, los datos del responsable del equipo de control, la información sobre si vais con probadores internos o externos, los canales de comunicación y el nombre clave de la prueba (artículo 9, apartado 2, del RTS).
  • Un equipo de control formado por personal vuestro, con su responsable, que se constituye después de que la autoridad valide esa información de puesta en marcha (artículo 9, apartado 4).
  • Un gestor de pruebas y al menos un sustituto, que designa la autoridad. No lo pone la entidad ni el proveedor (artículo 3, apartado 2).
  • Una fase activa de pruebas de equipo rojo de 12 semanas como mínimo (artículo 11, apartado 5).
  • Replay y trabajo en equipo morado dentro de las diez semanas siguientes al fin de la fase activa (artículo 12, apartado 5).
  • El informe de validación lo emite la autoridad, no el proveedor, y no os traslada la responsabilidad sobre las repercusiones de la prueba (artículo 26, apartado 7, de DORA).
  • Y la prueba se repite al menos cada tres años (artículo 26, apartado 1, de DORA).

Sobre a quién podéis contratar.

El artículo 27, apartado 1, de DORA no dice quién se somete a la prueba: fija el listón que deben cumplir los probadores. Pide idoneidad y prestigio del más alto grado; capacidades técnicas y organizativas con conocimientos especializados demostrados en inteligencia sobre amenazas, pruebas de penetración y pruebas de equipo rojo; acreditación por un órgano de certificación de un Estado miembro o adhesión a códigos de conducta o marcos éticos oficiales; una garantía independiente o informe de auditoría; y seguro de responsabilidad civil profesional que cubra también los riesgos de falta intencionada y negligencia. El artículo 7 del RTS añade la documentación concreta que vuestro equipo de control tendrá que archivar de cada proveedor, incluidos currículos, certificaciones y referencias de encargos anteriores. Pedídselo por escrito a quien se presente. A nosotros los primeros.

Dónde estamos nosotros.

De ese listón, hoy os podemos acreditar dos: la garantía independiente o informe de auditoría de la letra d), y el seguro de responsabilidad civil profesional con cobertura de falta intencionada y negligencia de la letra e). Las demás no os las podemos dar por buenas hoy. Así que no os vamos a decir que os podemos ejecutar el TLPT regulado ni que cumplimos el listón del artículo 27.

Lo que sí hacemos es red team no regulado: medir cuánto tarda vuestro equipo en detectar y contener a alguien que ya está dentro. Es otro producto y se compra por otro motivo. Si es lo que buscáis, escribidnos a [email protected].

Tu resultado

Un ejercicio TIBER puede ser justo la vía por la que se ejecuta vuestro TLPT. Quien lo determina es vuestra autoridad competente.

TIBER-EU y el TLPT de DORA no son dos mundos separados. El artículo 26, apartado 11, de DORA encarga a las Autoridades Europeas de Supervisión desarrollar las normas técnicas de TLPT «de conformidad con el marco TIBER-EU». Y el marco TIBER-EU actualizado en febrero de 2025 lo dice desde el otro lado: los requisitos de TLPT de DORA están incorporados a su proceso de prueba, de forma que una entidad que complete una prueba bajo una implantación nacional o europea de TIBER-EU cumplirá el TLPT de DORA, siempre que satisfaga los requisitos formales que fije la autoridad competente. Ese mismo marco añade que, cuando se usa para las obligaciones de TLPT de DORA, las autoridades de TLPT se consideran autoridades TIBER para esa prueba.

O sea: el mismo ejercicio puede ser voluntario o puede ser vuestro TLPT regulado. Lo que cambia no es el método, es el título bajo el que se ejecuta, y eso lo determina la autoridad, no el proveedor y no vosotros.

La pregunta útil es esta, y os toca hacerla a vosotros:

Preguntad a vuestro gestor de pruebas, o al equipo de la autoridad que lleva el ejercicio, si vuestra prueba se está ejecutando como el TLPT de DORA o al margen de él. De la respuesta dependen los plazos del reglamento, quién firma el informe de validación y si la prueba cuenta para el ciclo de al menos tres años del artículo 26, apartado 1.

Sobre TIBER-ES en concreto.

Su autoridad propietaria es el Banco de España, con la participación de la CNMV y de la DGSFP cuando las entidades que vayan a someterse a las pruebas pertenezcan a sus respectivos ámbitos de competencia. La guía de implementación publicada es de enero de 2022 y describe la participación como voluntaria, pero es anterior a DORA, a las normas técnicas de TLPT y a la actualización de TIBER-EU de febrero de 2025. No deduzcas de esa guía que tu ejercicio queda fuera de DORA.

Dónde estamos nosotros.

De los requisitos que el artículo 27, apartado 1, de DORA impone a los probadores, hoy os podemos acreditar dos: la garantía independiente o informe de auditoría de la letra d), y el seguro de responsabilidad civil profesional con cobertura de falta intencionada y negligencia de la letra e). Por eso no os vamos a decir que os podemos ejecutar un TLPT regulado. Red team no regulado sí hacemos, y es otro producto.

Tu resultado

DORA te aplica. El TLPT, no.

El artículo 26, apartado 1, de DORA deja fuera de la obligación de TLPT a las microempresas, junto con las entidades del artículo 16, apartado 1, párrafo primero. DORA define microempresa en su artículo 3, punto 60: «una entidad financiera distinta de un centro de negociación, una entidad de contrapartida central, un registro de operaciones o un depositario central de valores, que emplea a menos de diez personas y cuyo volumen de negocios anual o balance anual total es igual o inferior a 2 millones EUR». Con lo que has respondido, ahí estás. No formas parte del grupo del que se designa.

El resto de DORA sí te aplica: gestión del riesgo relacionado con las TIC, notificación de incidentes graves, pruebas de resiliencia operativa digital y los requisitos contractuales con tus proveedores TIC.

Y la pregunta de fondo no depende de DORA.

Los motivos por los que se contrata un red team sin reglamento de por medio suelen ser estos cuatro:

  • Una pregunta del consejo sobre la preparación frente al ransomware.
  • Un SOC nuevo, propio o subcontratado, que quieres comprobar que funciona.
  • Un cliente grande que lo pide en su diligencia de proveedor.
  • Un incidente en tu sector que ha cambiado la conversación en casa.

Si lo que quieres es medir detección y respuesta, eso lo hace un red team. Si lo que necesitas es cobertura sobre una superficie concreta, la respuesta es un pentesting. Te decimos cuál te conviene en [email protected].

Tu resultado

Estás en el marco simplificado. El TLPT no va contigo.

El artículo 26, apartado 1, de DORA excluye de la obligación de TLPT a las entidades contempladas en el artículo 16, apartado 1, párrafo primero. Ese párrafo nombra a las empresas de servicios de inversión pequeñas y no interconectadas, las entidades de pago exentas en virtud de la Directiva (UE) 2015/2366, las entidades exentas en virtud de la Directiva 2013/36/UE respecto de las cuales el Estado miembro haya decidido no aplicar la opción del artículo 2, apartado 4, las entidades de dinero electrónico exentas en virtud de la Directiva 2009/110/CE y los fondos de pensiones de empleo pequeños. Con lo que has respondido, estás en ese grupo.

Lo que sí te aplica es el marco simplificado de gestión del riesgo relacionado con las TIC del artículo 16 y los requisitos contractuales con tus proveedores TIC.

Y la pregunta de fondo no depende de DORA.

Los motivos por los que se contrata un red team sin reglamento de por medio suelen ser estos cuatro:

  • Una pregunta del consejo sobre la preparación frente al ransomware.
  • Un SOC nuevo, propio o subcontratado, que quieres comprobar que funciona.
  • Un cliente grande que lo pide en su diligencia de proveedor.
  • Un incidente en tu sector que ha cambiado la conversación en casa.

Si lo que quieres es medir detección y respuesta, eso lo hace un red team. Si lo que necesitas es cobertura sobre una superficie concreta, la respuesta es un pentesting. Te decimos cuál te conviene en [email protected].

Tu resultado

DORA no te aplica.

El artículo 2, apartado 3, letra e), de DORA deja fuera del reglamento a «los intermediarios de seguros, los intermediarios de reaseguros y los intermediarios de seguros complementarios que sean microempresas o pequeñas o medianas empresas». DORA define esos tres tamaños en su artículo 3, puntos 60, 63 y 64: mediana empresa es la que emplea a menos de 250 personas y cuyo volumen de negocios anual es igual o inferior a 50 millones EUR o cuyo balance anual es igual o inferior a 43 millones EUR. Con lo que has respondido estás dentro de ese grupo, así que ni el reglamento ni el TLPT te obligan.

Dos matices que conviene tener a mano:

  • Si trabajas para entidades que sí están sujetas a DORA, sus requisitos contractuales con proveedores TIC pueden llegarte por contrato aunque el reglamento no te obligue directamente.
  • Otra normativa de seguridad puede aplicarte por otra vía. Este test solo mira DORA.

Y la pregunta de fondo sigue en pie: si alguien entrase hoy en tu red, ¿cuánto tardaríais en verlo? Eso se mide igual, con reglamento o sin él. Escríbenos a [email protected].

Tu resultado

DORA no te aplica.

El artículo 2, apartado 3, letra c), de DORA deja fuera del reglamento a «los fondos de pensiones de empleo que gestionen planes de pensiones que, en conjunto, no tengan más de quince partícipes en total». Con lo que has respondido ese es tu caso, así que ni el reglamento ni el TLPT te obligan.

Dos matices que conviene tener a mano:

  • Si trabajas para entidades que sí están sujetas a DORA, sus requisitos contractuales con proveedores TIC pueden llegarte por contrato aunque el reglamento no te obligue directamente.
  • Otra normativa de seguridad puede aplicarte por otra vía. Este test solo mira DORA.

Y la pregunta de fondo sigue en pie: si alguien entrase hoy en tu red, ¿cuánto tardaríais en verlo? Eso se mide igual, con reglamento o sin él. Escríbenos a [email protected].

Tu resultado

Estás dentro de DORA, pero por el otro lado del contrato.

Los proveedores terceros de servicios de TIC son la letra u) del artículo 2, apartado 1. Y hay un detalle del texto que conviene conocer: el apartado 2 de ese mismo artículo reserva el nombre de «entidades financieras» a las letras a) a t). Vosotros no lo sois, y el TLPT es una obligación de la entidad financiera, no del proveedor. Lo que os llega es otra cosa:

  • Los requisitos contractuales que vuestros clientes financieros tienen que trasladar a los contratos que firmáis con ellos.
  • Si las Autoridades Europeas de Supervisión os designan proveedor tercero esencial de servicios de TIC, entráis en el marco de vigilancia, con un supervisor principal asignado.
  • Si un cliente vuestro es determinado para un TLPT, el alcance puede alcanzar a los servicios que le prestáis. El artículo 26, apartado 3, obliga a la entidad financiera a tomar las medidas necesarias para asegurar vuestra participación, y el apartado 4 prevé que en ciertos casos seáis vosotros quienes contratéis directamente al probador, para una prueba conjunta con varias entidades financieras. Eso se negocia y se documenta antes de empezar, no durante.

Lo útil:

Si vendes al sector financiero, lo que suele desatascar una diligencia de proveedor es poder enseñar una prueba ofensiva reciente sobre el servicio que prestas, con el informe y las correcciones verificadas. Escríbenos a [email protected].

Tu resultado

DORA no va contigo.

DORA se aplica a los tipos de entidad que enumera su artículo 2, apartado 1, todos del sector financiero, más los proveedores terceros de servicios de TIC. Si no estás en esa lista, ni el reglamento ni el TLPT te obligan.

Puede llegarte igualmente por contrato: si vendes a banca, seguros o mercados, tus clientes sí están sujetos y te trasladarán requisitos de seguridad. Y otra normativa puede aplicarte por otra vía, porque este test solo mira DORA.

La pregunta de fondo aguanta sin reglamento: ¿cuánto tardaría tu equipo en detectar a alguien dentro? Eso es exactamente lo que mide un red team. Escríbenos a [email protected].

Tu resultado

Sin autorización en la UE, DORA no te obliga directamente.

DORA se dirige a las entidades autorizadas o registradas en la Unión Europea. Sin autorización ni registro en la UE, el reglamento no os obliga por sí mismo, y la determinación de TLPT del artículo 26 no os alcanza.

Dos vías por las que puede alcanzaros igualmente:

  • Por contrato, si prestáis servicios a entidades financieras de la UE o si ellas os los prestan a vosotros.
  • Por grupo, si tenéis o autorizáis una filial o una sucursal en un Estado miembro. Ahí la entidad que hay que mirar es la europea, y este test cambia de respuesta.

Y la pregunta de fondo no cambia de país: si alguien entrase hoy en vuestra red, ¿cuánto tardaríais en verlo? Escríbenos a [email protected] y lo vemos.

El umbral que tu autoridad mira primero

El artículo 2, apartado 2, del Reglamento Delegado (UE) 2025/1190 obliga a las autoridades a exigir el TLPT a las entidades de una lista tasada, salvo que su propia evaluación de impacto, estabilidad financiera y perfil de riesgo TIC diga que no está justificado. No es automático y sigue haciendo falta la notificación, pero es el criterio que se aplica antes que ninguno, y lo puedes contrastar hoy con tus cifras.

Las entidades de crédito identificadas como entidades de importancia sistémica mundial (EISM) o como otras entidades de importancia sistémica (OEIS) conforme al artículo 131 de la Directiva 2013/36/UE, y las que forman parte de una EISM o de una OEIS.

Las entidades de pago con operaciones de pago por valor total superior a 150 000 millones de euros en cada uno de los dos años naturales anteriores a la evaluación. Las entidades de dinero electrónico, con ese mismo umbral de operaciones o con dinero electrónico en circulación por importe total superior a 40 000 millones de euros. Para los proveedores de servicios de información sobre cuentas, el artículo 2, apartado 2, no fija umbral propio: se evalúan con los criterios generales del apartado 1.

Los depositarios centrales de valores y las entidades de contrapartida central están en la lista sin umbral: todos. Los centros de negociación con sistema electrónico de negociación entran si ostentan la mayor cuota de mercado nacional por volumen de negocios en alguna de las categorías de instrumentos que enumera la letra f), o más del 5 % de cuota a escala de la Unión, en cada uno de los dos años naturales anteriores. Para los registros de operaciones, el apartado 2 no fija umbral propio.

Las empresas de seguros y de reaseguros que cumplan los tres criterios de la letra g): prima bruta suscrita superior a 1 500 millones de euros, provisiones técnicas superiores a 10 000 millones, y, para las que ejerzan solo actividades de vida o de vida y no vida, activos totales que superen el 3,5 % de la suma de los activos totales de las empresas de seguros y reaseguros establecidas en el Estado miembro. Dentro de ese subconjunto, la obligación se activa si además se cumple alguno de estos tres: prima bruta suscrita superior a 3 000 millones, provisiones técnicas superiores a 30 000 millones, o activos totales por encima del 10 % de esa misma suma. La letra g) está redactada de forma densa: si tus cifras rondan esos números, léela directamente.

Para tu figura, el artículo 2, apartado 2, no fija un umbral propio. Se te evalúa con los criterios generales del apartado 1: tamaño, interconexión, carácter esencial y sustituibilidad de tus servicios, complejidad del modelo de negocio, pertenencia a un grupo sistémico, y por el lado TIC tu perfil de riesgo, tu panorama de amenazas, la dependencia de tus funciones esenciales respecto de los sistemas de TIC y la madurez de tu detección y respuesta.

Quién manda en tu caso, en España

El artículo 46 de DORA reparte la supervisión por tipo de entidad, remitiendo a la normativa sectorial de cada figura. Un matiz que conviene tener claro antes de la tabla: para el TLPT la autoridad puede no ser la misma. El artículo 1, punto 7, del RTS llama «autoridad competente en relación con las pruebas de penetración basadas en amenazas» a tres cosas posibles: la autoridad pública única que un Estado miembro designe conforme al artículo 26, apartado 9, de DORA; la autoridad en la que se deleguen tareas conforme al apartado 10; o cualquiera de las autoridades del artículo 46. Y el artículo 16, apartado 6, del RTS prevé expresamente que las dos sean distintas y tengan que compartir información.

El Banco de España. Si el banco está clasificado como significativo dentro del Mecanismo Único de Supervisión, quien supervisa es el Banco Central Europeo (artículo 46, letra a).

El Banco de España (artículo 46, letra b, que remite al artículo 22 de la Directiva (UE) 2015/2366).

El Banco de España, que en España asume la supervisión de los emisores de fichas referenciadas a activos y de fichas de dinero electrónico bajo MiCA (artículo 46, letra d).

La CNMV (artículo 46, letra c).

La CNMV (artículo 46, letras i y j).

La CNMV para depositarios centrales de valores, entidades de contrapartida central y centros de negociación (artículo 46, letras e, f y g). Para los registros de operaciones, la letra h remite al artículo 22 del Reglamento (UE) n.º 648/2012, que designa autoridad nacional, y en España es la CNMV. Ten en cuenta que el registro y la supervisión ordinaria de los registros de operaciones bajo EMIR los lleva la ESMA, así que aquí puedes tener dos interlocutores.

La CNMV, autoridad competente en España para la supervisión del cumplimiento de MiCA por los proveedores de servicios de criptoactivos (artículo 46, letra d).

La CNMV (artículo 46, letra p).

Depende de cuál de las cuatro seas. Para las agencias de calificación crediticia, el artículo 46, letra n, remite al artículo 21 del Reglamento (CE) n.º 1060/2009, que es la ESMA. Para los registros de titulizaciones, la letra q remite a los artículos 10 y 14, apartado 1, del Reglamento (UE) 2017/2402, que también es la ESMA. Los administradores de índices de referencia cruciales (letra o) y los proveedores de servicios de suministro de datos (letra g) se reparten entre la ESMA y la autoridad nacional según el caso. Dinos cuál eres y lo concretamos.

La Dirección General de Seguros y Fondos de Pensiones, la DGSFP (artículo 46, letra k).

La DGSFP (artículo 46, letra l).

La DGSFP (artículo 46, letra m).

Y para TIBER-ES: la autoridad propietaria del marco es el Banco de España, con la participación de la CNMV y de la DGSFP cuando las entidades que vayan a someterse a las pruebas pertenezcan a sus respectivos ámbitos de competencia.

Tu autoridad competente es el supervisor sectorial de ese Estado miembro, no el español. El reparto español te sirve de referencia de cómo suele estructurarse: banca y pagos en el banco central, mercados e inversión en el supervisor de valores, seguros y pensiones en el supervisor de seguros.

La entidad que hay que mirar es la europea, y su autoridad competente es la del Estado miembro donde esté autorizada.

De dónde sale cada cosa: Reglamento (UE) 2022/2554 (DORA), artículos 2, 3, 16, 26, 27 y 46. Reglamento Delegado (UE) 2025/1190, las normas técnicas de regulación de TLPT, artículos 1, 2, 3, 7, 9, 11, 12 y 16. El marco TIBER-EU del Banco Central Europeo, actualizado el 11 de febrero de 2025. La guía de implementación TIBER-ES del Banco de España, de enero de 2022.

Las preguntas que salen antes de firmar.

Las preguntas que más nos hacen los responsables de seguridad antes de la primera llamada.

Un ejercicio de red team es una simulación encubierta y dirigida a un objetivo de un atacante real, ejecutada contra tu entorno en producción para poner a prueba no solo tus defensas, sino si tu equipo detecta y detiene una intrusión. En vez de listar vulnerabilidades, emula a un actor de amenaza real para alcanzar un objetivo definido, como el control del dominio o unos datos sensibles, y mide tu detección y tu respuesta por el camino. El entregable es el relato del ataque, los objetivos alcanzados, tus MTTD y MTTC, tu cobertura de MITRE ATT&CK y un plan para cerrar los huecos.

Un pentesting encuentra y valida tantas vulnerabilidades como sea posible dentro de un alcance definido, de forma anunciada y colaborativa. Un red team es encubierto y va a por un objetivo: un adversario realista, una meta, y la pregunta de si tus personas, tus procesos y tu tecnología detectan y contienen el ataque. Un pentesting responde a qué es explotable; un red team responde a si los veríamos venir y si podríamos pararlos. Se complementan, y la mayoría de las organizaciones maduras hacen los dos en ciclos distintos.

Primero un pentesting, en casi todos los casos. Un red team mide si tu equipo de seguridad y tus controles funcionan bajo un ataque realista, y eso solo tiene sentido cuando ya los tienes montados. Sin un SOC, o con las vulnerabilidades evidentes todavía abiertas, un red team se limitaría a confirmarte lo que te diría por menos dinero un test de intrusión. Te lo diremos con honestidad en la primera reunión en vez de venderte el proyecto grande.

El TLPT (Threat-Led Penetration Testing) es un red team regulado y guiado por inteligencia que se exige a determinadas entidades financieras bajo DORA y a las instituciones que participan en TIBER-EU. Combina un perfil de adversario construido a partir de inteligencia de amenazas con un red team encubierto contra tu entorno de producción, con un Control Team dentro de tu propia organización y un Test Manager designado por la autoridad TIBER. Lo necesitas cuando tu autoridad competente determina que tu organización debe realizar un TLPT conforme al artículo 26 de DORA, o cuando participas en un ejercicio TIBER-EU o TIBER-ES. La obligación empieza cuando la autoridad te lo notifica, no cuando superas un umbral de tamaño, y el artículo 27 no dice quién debe someterse a la prueba: fija el listón que deben cumplir los probadores. Construimos nuestros ejercicios de red team sobre el método TIBER-EU, y los cerramos con el ejercicio de replay, que el marco exige desde 2018, y el de purple teaming, que la actualización de 2025 convirtió de opcional en obligatorio.

TIBER-ES es la implantación española de TIBER-EU. Su autoridad propietaria es el Banco de España, que adoptó el marco en diciembre de 2020, con la participación de la CNMV y de la DGSFP cuando la entidad que va a someterse a la prueba pertenece a su ámbito de competencia. La guía de implementación de TIBER-ES publicada es de enero de 2022, así que es anterior a DORA, a las normas técnicas de TLPT y a la actualización de TIBER-EU de febrero de 2025. Todavía usa el término White Team, que el BCE sustituyó por Control Team, y todavía describe una validación firmada por el consejo de administración de la entidad y por los proveedores. Si tu prueba va bajo DORA, la referencia es el marco vigente y las normas técnicas. Nosotros leemos los dos antes de definir el alcance, y te decimos qué texto manda en tu prueba.

Lo firma la autoridad TIBER. No lo firma el proveedor que ejecuta, ni la entidad que se somete a la prueba, y es un cambio reciente. El artículo 26.7 de DORA dice que las autoridades proporcionarán a la entidad financiera un informe de validación que confirme que la prueba se efectuó de conformidad con los requisitos, y las normas técnicas de TLPT ponen ese deber en la autoridad competente para el TLPT. El marco TIBER-EU de 2025 lo dice igual de claro: la attestation debe firmarla la autoridad TIBER, y emitirla es lo que cierra la prueba. Los textos anteriores, incluida la guía TIBER-ES de enero de 2022, todavía describen una validación firmada por el consejo de administración de la entidad y por los proveedores. Así que nosotros no validamos nuestro propio trabajo. Producimos el informe del equipo rojo y la evidencia que la autoridad examina, y DORA es explícito: el informe de validación no traslada fuera de la entidad financiera la responsabilidad sobre las repercusiones de la prueba.

No, y para eso está el diseño de seguridad del ejercicio. Cada proyecto se ejecuta con un Control Team (un grupo pequeño e informado dentro de tu organización), unas Rules of Engagement documentadas y un punto de control Pre-Out en el que paramos y confirmamos antes de tocar algo verdaderamente crítico. Nunca hacemos nada destructivo contra producción y podemos detener el ejercicio en cualquier momento. El objetivo es medir tu respuesta, no provocar el incidente.

Un red team suele durar de tres a seis semanas, porque el realismo se paga con paciencia: recogida de inteligencia, una entrada cuidada, movimiento silencioso y tiempo para que tu equipo nos detecte. Los ejercicios TLPT bajo DORA o TIBER-EU duran bastante más: solo la fase activa de red team tiene un mínimo regulatorio de 12 semanas, con las fases de inteligencia de amenazas y de cierre a cada lado. La ventana y los hitos se acuerdan en la propuesta, que entregamos en las 48 horas siguientes a la primera llamada.

El precio depende del objetivo, del modelo (Initial Access o Assumed Breach), de la duración y de si el alcance incluye parte física o de ingeniería social. Damos un precio cerrado, sin costes ocultos. Un ejercicio Assumed Breach enfocado arranca bastante por encima de un pentesting estándar por el tiempo que exige, y uno de Initial Access de alcance completo escala desde ahí. El ejercicio de replay y un retest de las correcciones van siempre incluidos.

Lo lleva de punta a punta un especialista senior, la misma persona con la que hablas en la primera llamada. Nuestro equipo cuenta con credenciales OSCP, OSCE³, OSEP, CRTO y CRTP, que son las certificaciones construidas alrededor del oficio de red team; la mayoría ha trabajado dentro de equipos de seguridad corporativos, y somos colaboradores verificados del programa de Bug Bounty de la NASA. El mismo responsable define el alcance, ejecuta, conduce el Attack Replay y hace el retest. Hablas siempre con quien está ejecutando el ejercicio.

¿Listo para poner a prueba tu resiliencia frente a un adversario real?

Empieza por una primera reunión sin compromiso. Acordamos el objetivo, el modelo y las reglas, y definimos el ejercicio de red team adecuado antes de que empiece.

Pide una propuesta de red team.
Te responde un líder de red team experimentado en un día laborable.

Protegido por reCAPTCHA. Se aplican la Política de Privacidad y las Condiciones del Servicio de Google.

O escribe directamente a [email protected]. Llega a un especialista senior.

NUESTROS CLIENTES YA LO HAN HECHO
  • Desde Etnia valoramos muy positivamente la colaboración con Asperis Security.
    Sergi Leno, Responsable de Sistemas ETNIA Barcelona
  • ASPERIS nos ha acompañado en la definición e implantación de nuestro roadmap de ciberseguridad en Microsoft 365 con un enfoque estructurado y alineado a negocio.
    Jordi Bondia, Director de TI SALVI
  • En NPAW hemos colaborado con Asperis en distintas iniciativas relacionadas con la seguridad y la experiencia ha sido muy positiva.
    Sergi Laencina Verdaguer, CISO NPAW
  • Con Asperis no contratas un servicio, contratas un compañero.
    Juan Valer Tecedor, Ingeniero de Software GNOSS