Red Team, Blue Team, Purple Team y White Team aparecen en propuestas comerciales, ofertas de empleo e informes de auditoría, y no siempre con el mismo significado. Entender qué hace cada uno, dónde se cruzan y en qué momento tiene sentido cada uno ayuda a invertir el presupuesto de seguridad en la prueba adecuada, y no en la más vistosa.
Qué hace cada equipo
Los colores provienen de ejercicios militares y fueron adoptados por la seguridad de la información. El glosario del NIST, que reproduce definiciones del CNSSI 4009, ayuda a precisar los roles:
- Red Team. Grupo autorizado a emular las capacidades de ataque de un adversario real contra la organización. El objetivo no es "ganar", sino demostrar el impacto de un ataque exitoso y mostrar qué funciona, y qué no, para quienes defienden.
- Blue Team. Quienes defienden el entorno en el día a día: monitorean, detectan, investigan y responden. En la práctica, es el SOC, el equipo de respuesta a incidentes y quienes administran los controles de seguridad.
- Purple Team. No es necesariamente un tercer equipo, sino una forma de trabajar: ataque y defensa lado a lado, técnica por técnica, para que cada hallazgo ofensivo se convierta en una mejora de detección o de respuesta.
- White Team. En el glosario del NIST, es el grupo neutral que define las reglas de enfrentamiento y las métricas, arbitra el ejercicio y garantiza que no perjudique la operación. En Network Secure, este rol de gobernanza se extiende al cumplimiento: políticas, métricas y evidencias para la dirección, los auditores y los reguladores.
Red Team no es lo mismo que pentest
Ambos usan técnicas ofensivas, y por eso suelen confundirse. La diferencia está en la pregunta que responde cada uno.
El pentest pregunta: ¿qué fallas explotables existen en este alcance? Tiene un objetivo definido (una aplicación, una red, un entorno en la nube), un plazo corto y busca cobertura: encontrar la mayor cantidad posible de vulnerabilidades relevantes y comprobar que pueden explotarse. El equipo de defensa normalmente sabe que la prueba está en curso. El NIST SP 800-115, guía técnica para pruebas y evaluaciones de seguridad, describe la prueba de intrusión como una de estas técnicas de evaluación.
El Red Team pregunta: ¿un adversario con este perfil podría alcanzar este objetivo sin ser detectado y contenido? El alcance es toda la organización (personas, procesos y tecnología), el objetivo es de negocio (por ejemplo, llegar al sistema de pagos o a una base de datos sensible), la duración es mayor y la operación es encubierta. Pocas personas conocen el ejercicio, precisamente para poner a prueba la reacción real del Blue Team.
Una buena forma de definir ese objetivo es usar los tres pilares de la seguridad de la información: confidencialidad, integridad y disponibilidad. "Exfiltrar la base de clientes" pone a prueba la confidencialidad; "alterar registros financieros sin ser detectado" pone a prueba la integridad; "paralizar la operación, como haría un ransomware" pone a prueba la disponibilidad. Vincular el ejercicio a uno de estos impactos ayuda a la dirección a entender qué se está midiendo.
Regla práctica. Si todavía no sabe qué fallas graves tiene, empiece por el pentest. Si ya corrige las fallas con regularidad y quiere saber si la defensa percibe y reacciona ante un ataque real, el siguiente paso es un ejercicio de Red Team o de Purple Team.
Cómo funciona un ejercicio de Purple Team
En un ejercicio tradicional de Red Team, el informe llega semanas después y la defensa descubre lo que dejó pasar solo al final. El Purple Team acorta ese ciclo: el equipo ofensivo ejecuta una técnica, el defensivo verifica en el momento qué vio, y ambos ajustan antes de continuar. El vocabulario común es MITRE ATT&CK, base pública de tácticas y técnicas observadas en ataques reales.
- Elegir la amenaza. Con base en inteligencia de amenazas, se define qué grupos o tipos de ataque son relevantes para el sector y el entorno, por ejemplo ransomware o fraude financiero.
- Armar el plan de emulación. Las técnicas de ese adversario se mapean en ATT&CK y se organizan en una secuencia realista. La Adversary Emulation Library, del Center for Threat-Informed Defense de MITRE, publica planes abiertos que sirven como punto de partida.
- Ejecutar y observar. Cada técnica se ejecuta de forma controlada, con el Blue Team siguiendo en tiempo real.
- Clasificar el resultado. Para cada técnica: ¿fue bloqueada, generó una alerta, quedó solo registrada en un log sin alerta o no dejó rastro? Esta clasificación muestra dónde falta telemetría y dónde faltan reglas de detección.
- Ajustar la defensa. Crear o refinar reglas en el SIEM y el EDR, activar una fuente de logs que faltaba, revisar un playbook de respuesta.
- Volver a probar. La misma técnica se ejecuta de nuevo para confirmar que el ajuste funciona. Sin esta nueva prueba, no hay forma de afirmar que la brecha se cerró.
- Registrar la evolución. El resultado se convierte en un mapa de cobertura sobre ATT&CK y una lista de pendientes priorizada, que puede compararse en el ejercicio siguiente.
La principal ganancia es que el conocimiento queda en casa: el analista del SOC ve el ataque ocurrir, entiende el rastro que deja y participa en la regla que lo detectará la próxima vez.
Cuándo está madura la empresa para cada uno
No existe un orden obligatorio, pero hay una secuencia que suele evitar desperdicio:
- Base: gobernanza e higiene. Inventario de activos, gestión de vulnerabilidades y políticas mínimas. Aquí empieza el rol del White Team: definir qué hay que proteger y cómo se medirá la evolución.
- Pentest periódico. Tiene sentido desde temprano y siempre que haya un lanzamiento de aplicación o un cambio relevante de infraestructura.
- Blue Team en operación. Monitoreo continuo y capacidad de respuesta, propios o a través de un SOC/MDR. Si nadie mira las alertas, no hay defensa que probar.
- Purple Team. Cuando ya existe un SOC con telemetría razonable y la pregunta pasa a ser "¿qué estamos dejando de ver?". Es el ejercicio con mejor relación entre esfuerzo y aprendizaje para equipos de defensa en evolución.
- Red Team completo. Cuando los controles básicos están estables, la detección ya fue calibrada y la organización quiere validar la respuesta de punta a punta, sin aviso. Hacer Red Team antes de eso suele producir un informe previsible: "entramos con facilidad".
Un ciclo, no cuatro equipos aislados
Los equipos rinden más cuando funcionan como un ciclo continuo. El Red Team encuentra la brecha; el Purple Team convierte el hallazgo en una regla de detección, un ajuste o un entrenamiento; el Blue Team pasa a detectar y contener ese tipo de ataque; y el White Team comprueba la evolución con políticas, métricas y evidencias. Así organiza Network Secure sus equipos: cada ronda deja la defensa un poco mejor y más fácil de demostrar.
No es necesario contratar todo a la vez. Cada equipo atiende una necesidad y puede activarse a través del servicio correspondiente: Pentest, SOC/MDR, Respuesta a Incidentes o GRC. Trabajan juntos cuando el proyecto lo requiere.
Preguntas frecuentes
¿Cuál es la diferencia entre Red Team y Blue Team?
El Red Team emula a un atacante para mostrar dónde falla la defensa. El Blue Team defiende el entorno: monitorea, detecta y responde a incidentes. Uno revela las brechas; el otro las cierra.
¿El Purple Team es un equipo separado?
No siempre. En la mayoría de las organizaciones, Purple Team es un formato de ejercicio en el que Red y Blue Team trabajan juntos, técnica por técnica, con ajustes y nuevas pruebas a continuación.
¿El Red Team reemplaza al pentest?
No. El pentest busca la mayor cantidad de fallas explotables en un alcance definido; el Red Team prueba si la organización detecta y contiene a un adversario que persigue un objetivo específico. Ambos son complementarios.
¿Con qué frecuencia hacer ejercicios de Purple Team?
Depende del ritmo de cambio del entorno y de las amenazas. Una referencia común es repetirlos siempre que haya un cambio relevante en las herramientas de defensa o surja una amenaza nueva y pertinente para el sector, volviendo a probar las brechas que quedaron abiertas.
Fuentes consultadas: glosario del NIST CSRC, entradas Red Team, Blue Team y White Team (definiciones del CNSSI 4009-2022); NIST SP 800-115, Technical Guide to Information Security Testing and Assessment; MITRE ATT&CK; Adversary Emulation Library, del Center for Threat-Informed Defense de MITRE. Este artículo es educativo y no describe la metodología de un proveedor específico.