Ciberseguridad y seguridad de la información

Purple Team: Cómo conectar PT para mejorar las capacidades del SOC

6 min de lecturaPublicado: 5 de agosto de 2026

Ilustración visual profesional sobre Purple Team en Threat Hunting y detección

Respuesta rápida

Purple Team comienza con una pregunta o comportamiento que se desea identificar, continúa con la definición de Telemetry y lógica, y termina con pruebas, ajuste, documentación y despliegue controlado. La calidad se mide por la cobertura y la capacidad de investigación.

Threat Hunting y Detection Engineering transforman el conocimiento del comportamiento del adversario en preguntas medibles, fuentes de datos y reglas de detección. El objetivo no es generar más alertas, sino mejorar la cobertura y la calidad de la decisión. Este artículo se centra en Purple Team y está dirigido a profesionales de SOC, PT y gerentes. El objetivo es proporcionar una metodología de trabajo que se pueda aplicar en la práctica, en entrevistas profesionales y en el entorno laboral, sin limitarse a una definición de diccionario.

El desafío principal es que los datos son casi siempre parciales. emulation objective, telemetry validation, detection gap pueden indicar una dirección, pero su significado depende del tiempo, el activo, el usuario y la actividad esperada. Por lo tanto, construiremos la prueba en torno a una pregunta de investigación, la evidencia requerida y un criterio claro para su finalización.

El escenario práctico en el artículo es: Tabletop para un ejercicio de una técnica. Todos los ejemplos son datos de laboratorio o descripciones de procesos. Cuando se trata de Penetration Testing, Web o Cloud, se debe trabajar solo con autorización explícita, un alcance definido y la capacidad de detener la prueba.

¿Qué es Purple Team?

El tema '¿Qué es Purple Team?' es una parte central del trabajo en Purple Team. Se recomienda dividirlo en tres preguntas: ¿Cuál es la entrada?, ¿Qué decisión se quiere tomar?, y ¿Qué evidencia es suficiente para justificarla? Estas preguntas evitan el uso automático de una herramienta sin comprender el objetivo.

En la práctica, registre emulation objective, telemetry validation, detection gap, tuning, retest, compare con el comportamiento esperado y defina al menos un Pivot. El resultado debe ser verificable por otro analista, incluyendo limitaciones y pasos a seguir.

Selección de Técnica y Scope

El proceso de Purple Team se construye en etapas con puntos de parada. Se definen el objetivo, el alcance, las fuentes, las acciones permitidas, la evidencia requerida, los roles y el criterio de finalización. En entornos ofensivos se añaden Stop conditions y un canal de emergencia.

En cada etapa debe haber un Output claro: un mapa de activos, una línea de tiempo, un hallazgo, una regla, un Playbook o un informe. El paso a la siguiente etapa se realiza solo cuando el Output es suficiente y fiable; así se evita el trabajo aleatorio o la ampliación del Scope sin autorización.

Planificación de Telemetry y Criterios de éxito

Ejecución controlada y Gap analysis

El tema 'Ejecución controlada y Gap analysis' es una parte central del trabajo en Purple Team. Se recomienda dividirlo en tres preguntas: ¿Cuál es la entrada?, ¿Qué decisión se quiere tomar?, y ¿Qué evidencia es suficiente para justificarla? Estas preguntas evitan el uso automático de una herramienta sin comprender el objetivo.

Detection improvement y Retest

Una prueba profesional para Purple Team comienza con condiciones de éxito y de fracaso. Se definen un caso positivo, un caso negativo, un caso límite y una actividad legítima similar. Así se pueden identificar tanto Falsos Negativos como Falsos Positivos.

En un entorno autorizado, se utiliza una acción mínima que demuestre la afirmación sin causar daño. Se guardan la entrada, la salida, el tiempo y la versión, y después de la corrección se realiza un Retest en el mismo escenario y se comprueba también la regresión en funciones adyacentes.

Puntos de prueba únicos

En este tema se recomienda construir previamente un mapa de evidencia enfocado. Los puntos de prueba centrales son: emulation objective, telemetry validation, detection gap, tuning, retest, evidence. La lista no es una Checklist automática; cada elemento se elige porque puede vincular una entidad, una acción y un tiempo o explicar un comportamiento legítimo.

emulation objective: Defina cuál es el valor esperado, qué se considerará anómalo y qué otra fuente verificará el hallazgo.
telemetry validation: Defina cuál es el valor esperado, qué se considerará anómalo y qué otra fuente verificará el hallazgo.
detection gap: Defina cuál es el valor esperado, qué se considerará anómalo y qué otra fuente verificará el hallazgo.
tuning: Defina cuál es el valor esperado, qué se considerará anómalo y qué otra fuente verificará el hallazgo.
retest: Defina cuál es el valor esperado, qué se considerará anómalo y qué otra fuente verificará el hallazgo.
evidence: Defina cuál es el valor esperado, qué se considerará anómalo y qué otra fuente verificará el hallazgo.

Cuando uno de los puntos no está disponible, se debe documentar la brecha y elegir una alternativa. Por ejemplo, si el Process identifier no es estable, se puede utilizar el tiempo, el Host, el User y el Parent; si el Payload está cifrado, se utilizan los Metadata, el volumen, la frecuencia y el contexto TLS/DNS.

Proceso de trabajo recomendado

Defina un Scope y una pregunta de trabajo sobre Purple Team.
Registre las fuentes de datos y la evidencia necesaria: emulation objective, telemetry validation, detection gap, tuning.
Cree una línea base breve de comportamiento normal o resultado esperado.
Realice la prueba mínima en un entorno de laboratorio y guarde el tiempo, la entrada y la salida.
Construya una línea de tiempo o una tabla comparativa y separe los hechos de la interpretación.
Realice un Pivot a una fuente adicional para verificar o refutar la explicación inicial.
Resuma la decisión, las limitaciones, la acción recomendada y el criterio de Retest.

Escenario práctico

El escenario elegido es un Tabletop para un ejercicio de una Técnica. El propósito del ejercicio no es demostrar la capacidad de ataque, sino practicar la recopilación, comparación y documentación de forma segura. Antes de comenzar el trabajo, se definen datos simulados, un plazo de tiempo y un resultado esperado.

Al finalizar el ejercicio, se debe presentar un producto que otro analista o probador pueda revisar: una captura de pantalla o una exportación de la evidencia, una línea de tiempo breve, una suposición inicial, una evidencia verificadora, una limitación y una recomendación. Cuando no hay evidencia suficiente, la conclusión correcta es que el escenario no ha sido probado.

Etapa	Qué se ejecuta	Producto
Preparación	Defina el Scope, el tiempo y el objetivo. Registre qué campos o evidencias de emulation objective, telemetry validation, detection gap se espera que aparezcan.	Plan de prueba breve
Creación de datos	Realice una acción segura y simulada relacionada con Purple Team, sin información real o impacto en el sistema de producción.	Evento/Solicitud/Flujo controlado
Recopilación	Recopile la evidencia bruta y el contexto de una fuente adicional. Verifique la zona horaria, los identificadores y la integridad.	Dos evidencias vinculadas
Análisis	Escriba qué demuestra cada evidencia, qué no demuestra y cuál es la posible explicación legítima.	Conclusión intermedia
Finalización	Elija un cierre, una escalada, un Finding o un Tuning; añada una recomendación y un Retest.	Producto documentado

Checklist práctico

Verifique y documente: Hypothesis.
Verifique y documente: técnica ATT&CK.
Verifique y documente: Data sources.
Verifique y documente: Detection logic.
Verifique y documente: Expected benign behavior.
Verifique y documente: Test cases y coverage.
Indique la zona horaria, la versión de la herramienta y la hora de recopilación.
Guarde los datos brutos antes de filtrar o modificar.
Escriba qué demuestra el hallazgo y qué aún se desconoce.
Defina el propietario y la acción de seguimiento con fecha límite.

Errores comunes

Comenzar con un IOC aleatorio sin Hypothesis.
Mapear ATT&CK solo por nombre.
Escribir reglas sin Test cases.
Ignorar el comportamiento legítimo.
Medir reglas en lugar de Coverage.
No gestionar versiones.

Resumen y CTA

Purple Team: Cómo conectar PT para mejorar las capacidades del SOC es un tema que conecta el conocimiento técnico con la disciplina de trabajo. Comience con una pregunta, recopile solo la evidencia relevante, mantenga el contexto y el tiempo, y elija una acción que se pueda justificar y volver a probar.

En la ruta de Cybersecurity & AI de HPI, estos principios se practican utilizando sistemas, registros y laboratorios. Una continuación natural es pasar a los artículos vinculados, realizar el ejercicio de laboratorio y guardar el producto como parte de un portafolio profesional.

Preguntas frecuentes

¿Purple Team por sí solo demuestra un ataque o una debilidad?

No. Proporciona una señal o un hallazgo que necesita contexto, validación y una fuente adicional. Una conclusión profesional se basa en una secuencia de evidencias y en la conformidad con el comportamiento esperado.

¿Qué se hace cuando faltan algunos datos?

Se documenta lo que falta, se verifica una fuente alternativa y se reduce el nivel de confianza. No se deben completar campos con suposiciones ni presentar Unknown como válido.

¿Cuánto tiempo se debe conservar la evidencia?

El tiempo depende de la política, la regulación, el costo y el tipo de incidente. Es importante definir de antemano el Retention, Legal hold y la capacidad de exportar la evidencia en un formato verificable.

¿Cómo se practica sin poner en riesgo un sistema real?

Se utilizan máquinas virtuales, datos simulados, CTF o un laboratorio dedicado. En pruebas autorizadas, se definen el Scope, las Stop conditions y la copia de seguridad antes de comenzar el trabajo.