En España se gestionaron y notificaron 160 incidentes de ciberseguridad en 2024, un 97,53 % más que en 2023, según el Informe sobre la cibercriminalidad en España del Ministerio del Interior. En 2023 ya se habían gestionado 90 incidentes de alta peligrosidad o impacto. Con este contexto, un red team no debería justificarse como una auditoría técnica más, sino como una forma de comprobar si tu empresa detectaría y contendría una intrusión antes de enfrentarse a ella.
Para un CTO, la pregunta útil no es cuántas vulnerabilidades puede encontrar un proveedor. Es si el equipo defensivo ve el acceso inicial, entiende la progresión del atacante, bloquea el movimiento lateral y puede explicar a dirección qué control falló. Esa diferencia cambia cómo se compra el servicio, cómo se mide y qué inversión debe venir después.
Por qué un red team es validación operativa y no solo pentesting
Un pentest busca vulnerabilidades dentro de un alcance definido. Un red team persigue un objetivo de negocio mediante una simulación de adversario. Puede intentar acceder a un ERP, exfiltrar datos de clientes o comprometer el dominio corporativo, combinando vectores técnicos, sociales y, cuando aplica, físicos. El equipo defensivo suele desconocer el ejercicio para que la organización responda como lo haría ante una amenaza real, no como quien espera una auditoría programada.
La diferencia importa especialmente en startups y scaleups. Una empresa puede tener un informe lleno de hallazgos críticos y seguir sin saber si sus alertas llegan al SOC, si alguien valida una señal sospechosa o si el equipo puede aislar una cuenta comprometida sin detener operaciones esenciales. El trabajo de un especialista en ciberseguridad solo genera valor empresarial cuando conecta la técnica con esas decisiones operativas.
Regla para dirección: si el resultado principal del ejercicio es una lista de vulnerabilidades ordenadas por severidad, probablemente has comprado un pentest, no una validación completa de resiliencia.
El problema de medir solo lo que es fácil
Contar vulnerabilidades es sencillo. Medir si una intrusión fue detectada, cuánto tardó el equipo en contenerla y qué evidencias quedaron disponibles exige coordinar red team, SOC, infraestructura, legal y responsables de negocio. Por eso muchos ejercicios se quedan en la explotación inicial. El proveedor demuestra que puede entrar, entrega un informe técnico y la empresa vuelve a su backlog habitual.
Ese enfoque desperdicia la parte más cara del ejercicio. El red team debe producir una cadena observable: reconocimiento, acceso, escalada, movimiento, objetivo y salida. En cada fase, el SOC debería poder identificar qué telemetría existía, qué alerta se generó, quién la recibió y qué respuesta se ejecutó. Si la empresa no dispone de registros suficientes, el hallazgo no es solo una vulnerabilidad. Es un gap de visibilidad que afecta a la respuesta.
La presión española cambia la prioridad
En 2025, INCIBE gestionó 122.223 incidentes de ciberseguridad, un 26 % más que en 2024, y notificó más de 237.000 sistemas vulnerables explotables, según la publicación oficial del BOE. Estos datos no prueban que todas las empresas necesiten un red team inmediato, pero sí cambian la conversación sobre prioridades: conocer la exposición no equivale a saber contener una intrusión.
Mi recomendación es directa. Prioriza un red team frente a otra ronda de herramientas cuando ya tienes controles desplegados, pero no sabes si funcionan en una secuencia de ataque realista. Si todavía no tienes inventario fiable, gestión de identidades básica, parches razonables o logs utilizables, empieza por corregir esos fundamentos. Un red team no sustituye la higiene de seguridad. La pone a prueba.
Diferencias reales entre red team, pentest y blue team
Pentest, red team y blue team cumplen funciones distintas. Confundirlos produce propuestas mal planteadas, expectativas equivocadas y presupuestos que no responden al riesgo que la dirección quiere reducir.
Pentest
El pentest tiene un alcance normalmente limitado y una intención clara: encontrar vulnerabilidades explotables en aplicaciones, APIs, redes, configuraciones o dispositivos. El equipo conoce las reglas y suele recibir información suficiente para evaluar un activo de forma profunda. Su entregable habitual es un informe de hallazgos, evidencias, criticidad y recomendaciones.
Contrata un pentest cuando necesitas validar una aplicación antes de lanzarla, revisar una superficie concreta o confirmar la corrección de vulnerabilidades. También es la opción adecuada cuando aún no tienes una base técnica clara y necesitas construir un inventario priorizado de problemas.
Red team
El red team trabaja con una intención ofensiva y objetivos concretos. La guía TIBER-ES del Ministerio de Economía formaliza estos ejercicios como pruebas controladas de inteligencia de amenazas para evaluar la resiliencia real de una entidad frente a atacantes avanzados. El marco TIBER-EU es, según la CNMV, el primer marco común europeo para realizar pruebas de red teaming, orientadas a anticipar el impacto de un ciberataque real.
El proveedor puede encadenar ingeniería social, explotación técnica, abuso de identidades y técnicas de persistencia, siempre dentro de reglas aprobadas. El equipo defensivo no necesita conocer cada acción. El informe final debe explicar qué objetivo se alcanzó, qué ocurrió en la línea temporal y qué se detectó o pasó inadvertido.
Para una guía práctica sobre la selección del proveedor, consulta esta guía para contratar un hacker ético. La clave es verificar que ofrece simulación integral y no solo explotación de vulnerabilidades.
Blue team
El blue team defiende. Opera herramientas como SIEM, EDR y sistemas de detección, investiga alertas, coordina incidentes y endurece controles. Su éxito no se mide por “ganar” al red team, sino por mejorar la capacidad de identificar, contener y aprender de una intrusión simulada.
| Equipo o ejercicio | Pregunta que responde | Entregable principal |
|---|---|---|
| Pentest | ¿Qué vulnerabilidades tiene este alcance? | Informe técnico de hallazgos |
| Red team | ¿Puede un adversario alcanzar un objetivo de negocio sin ser detenido? | Informe de impacto y cadena de ataque |
| Blue team | ¿Detectamos y respondemos de forma eficaz? | Métricas, evidencias y mejoras defensivas |
Si el problema es una aplicación concreta, empieza por pentesting. Si necesitas validar una cadena ofensiva contra un objetivo empresarial, elige red team. Si ya sabes que tus controles fallan y necesitas corregir detecciones, involucra al blue team desde el diseño. Separar los papeles evita contratar un servicio caro para responder a una pregunta equivocada.
Cómo diseñar un ejercicio de red team con objetivos de negocio
El ejercicio debe empezar por el resultado que la empresa quiere validar, no por la herramienta que el proveedor sabe utilizar. “Atacar la infraestructura” es un alcance débil. “Acceder al ERP con una cuenta comprometida y demostrar si el SOC detecta el movimiento hacia datos sensibles” permite definir reglas, evidencias y criterios de éxito.
Empieza por el objetivo y los límites
Define uno o varios objetivos verificables. Los ejemplos más útiles son acceso al ERP, exfiltración controlada de datos de clientes o compromiso del dominio. Cada objetivo debe tener un criterio de parada. No necesitas extraer datos reales si basta con demostrar acceso a una muestra sintética o a un fichero señuelo.
Después, documenta activos incluidos, exclusiones, horarios sensibles, proveedores afectados y acciones prohibidas. Acordar las reglas de enfrentamiento protege la operación y evita que el proveedor interprete una autorización ambigua como permiso para interrumpir un servicio crítico.
Diseña una ruta de adversario
Un red team competente no dispara técnicas al azar. Construye una hipótesis de ataque con vectores técnicos y sociales, y la adapta a la arquitectura y al perfil de la empresa. La descripción profesional de un ejercicio de red team en España recoge una combinación de vectores técnicos, sociales y físicos cuando aplica, con objetivos y entregables diferenciados.
Pide al proveedor que documente las TTPs con el marco MITRE ATT&CK, conserve evidencias y registre los tiempos relevantes. El informe técnico debería incluir comandos ejecutados, pruebas de concepto, evidencias y tiempos de detección. No aceptes un documento que solo diga que “se consiguió acceso”. Necesitas saber qué permitió el acceso y qué control podría haberlo impedido.
Separa los entregables
Dirección y SOC no necesitan leer el mismo informe. El primero debe recibir una narración comprensible, el objetivo alcanzado, el impacto operativo, la línea temporal y los puntos en que la organización detectó o no detectó al atacante. El segundo necesita detalle técnico para reproducir, investigar y corregir.
La especialidad formativa de Red Team de Fundae tiene 50 horas y plantea competencias básicas de defensa ofensiva. La existencia de una formación estructurada refuerza una conclusión práctica: ejecutar técnicas no basta. El proveedor debe saber informar y transferir conocimiento al SOC.
Antes de aprobar la propuesta, exige estas respuestas:
- Objetivo: ¿Qué activo o resultado de negocio se intentará alcanzar?
- Visibilidad: ¿Qué logs, alertas y equipos defensivos participarán?
- Seguridad operacional: ¿Qué acciones están prohibidas y quién puede detener el ejercicio?
- Evidencia: ¿Cómo se probará cada paso sin exponer datos reales?
- Remediación: ¿Quién convierte cada hallazgo en una tarea priorizada y verificable?
El ejercicio termina cuando el equipo defensivo puede actuar sobre los resultados. Si el proveedor desaparece después del informe, has comprado una demostración, no una mejora operativa.
