Purple Team en la Practica: Construyendo Ciclo de Feedback Red vs Blue

Purple Team no es un taller trimestral con pizza y diapositivas bonitas, es un ritmo de ingenieria donde cada TTP ejecutado por el Red se convierte en hipotesis de deteccion para el Blue en menos de 72 horas. En Basilisk OffSec corremos sprints de dos semanas: 10 tecnicas seleccionadas del ATT&CK, ejecucion controlada en laboratorio corporativo y cierre con regla Sigma en produccion. El KPI no es cuantos shells consiguio el Red, sino cuantas tecnicas pasaron de 'no detectado' a 'alertado con bajo falso positivo'. Quien no mide ese delta esta haciendo teatro de seguridad caro. Esta guia descompone el ciclo en pasos reproducibles, herramientas concretas y metricas que sobreviven a una revision de directorio.

Que significa Purple Team de verdad#

Correr Red y Blue por separado produce dos verdades: atacantes que escriben informes que nadie convierte en deteccion, y defensores que construyen reglas que ningun adversario real dispara. Purple Team borra la frontera atando ambos lados a la misma linea de tiempo y al mismo artefacto. Es una funcion, no una plantilla permanente: las mismas personas rotan de rol en cada ejercicio. El objetivo operativo es colapsar el ciclo de feedback de meses a dias. Un ciclo maduro produce al menos una deteccion versionada por sprint, un playbook de respuesta enlazado y una caida medida del tiempo medio de deteccion para la tecnica practicada. Todo lo demas es preparacion.

Priorizar tecnicas por threat intel real#

El punto de partida es un catalogo de tecnicas priorizado por threat intel real, no por moda de conferencia. Tomamos informes recientes (Mandiant M-Trends, CrowdStrike OverWatch, CCN-CERT) y los cruzamos con la matriz ATT&CK Enterprise v15. Para una operacion financiera, por ejemplo, T1078.004 (cloud accounts), T1558.003 (Kerberoasting) y T1059.001 (PowerShell) quedan arriba. La priorizacion sigue tres ejes: probabilidad contra nuestro perfil sectorial, radio de impacto en caso de exito, y brecha de deteccion actual segun el ATT&CK Navigator. Las tecnicas que ya detectamos con fiabilidad bajan en la lista; las celdas oscuras del heatmap definen el sprint. Asi el ejercicio queda anclado a riesgo medible en lugar de curiosidad personal.

El contrato escrito entre Red y Blue#

Antes de ejecutar, el Red documenta el procedimiento exacto y el Blue dibuja que telemetria deberia capturar cada paso. Este contrato escrito evita el clasico 'no lo vimos porque Splunk no estaba ingestando ese indice'. El contrato nombra, por tecnica: fuente de datos esperada (Sysmon Event ID 1, 4688, 4104, un log de Zeek), campo esperado y ruido de base. Si la fuente de datos falta, eso ya es un hallazgo antes del primer payload. Este ensayo en seco revela con frecuencia un sensor desplegado pero no recolectado, o el PowerShell Script Block Logging apagado. Esos puntos ciegos exactos son los que salvan un incidente real mas adelante.

Ejecucion controlada dentro de la ventana#

La ejecucion ocurre en ventana acordada, con flag de ejercicio en los logs y canal Slack #purple-live abierto. Cada accion del Red recibe timestamp UTC, hostname objetivo y hash del binario usado. Cuando corremos Kerberoasting via Rubeus, el operador anota el ticket exacto extraido y la cuenta de servicio objetivo. En paralelo, el analista del SOC intenta detectar en tiempo real sin saber que paso viene, simulando el escenario real. Si detecto en cuatro minutos, marcamos verde. Si paso desapercibido, se abre ticket en Jira con prioridad definida por la criticidad del activo tocado. Corremos deliberadamente con OPSEC desactivado (flags ruidosos, named pipes por defecto) para que el Blue pueda ver los artefactos.

Del hallazgo a la regla duradera#

Post-ejecucion, el trabajo duro comienza: convertir un hallazgo en regla duradera. Convertimos hipotesis primero en Sigma como fuente de verdad neutral, luego en EQL en Elastic y KQL en Sentinel. Una regla solo se mergea en main si cumple tres criterios: cubre la tecnica del ejercicio, genera menos de 5 falsos positivos por semana en homologacion, y tiene playbook de respuesta enlazado. Las tecnicas de evasion obligan al equipo a salir de firma e ir hacia deteccion comportamental, mirando llamadas a NtAllocateVirtualMemory, patrones parent-child anomalos y acceso a handles de LSASS. Una regla sin caso de prueba que la dispare de forma demostrable se considera inconclusa.

Infraestructura de ejercicio auditable#

La infra del ejercicio debe ser auditable. El C2 corre en VLAN aislada con captura PCAP completa, y el trafico se replica al SIEM de homologacion via port mirror. El movimiento lateral sigue un playbook fijo con Impacket y Evil-WinRM, siempre con flags ruidosos para que el Blue vea los artefactos. El pivoting interno usa Chisel o Ligolo-ng sobre tuneles bien documentados. Todo registrado en un repo Git privado: cada commit del Red es referenciado por el PR de regla del Blue, creando trazabilidad que auditoria adora y el gerente ama mostrar al board. Los snapshots de las VMs antes y despues del ejercicio permiten repeticion limpia cuando una regla necesita ajuste.

Metricas y lenguaje comun#

La comunicacion mata mas programas de Purple Team que la falta de herramienta. Establecemos vocabulario comun: 'detectado' significa alerta generada y triada, no solo log presente en algun indice frio. Las retros duran 60 minutos con tres diapositivas: tecnicas ejecutadas, detecciones creadas, deuda tecnica abierta. Metricas que seguimos: MTTD por categoria ATT&CK, porcentaje de cobertura de Tactics en el ambiente y numero de reglas con FP por encima del umbral. En seis meses, un cliente paso de 23% de cobertura en Credential Access a 71%, con caida de 40% en alertas ruidosas. Esos numeros son el lenguaje que libera presupuesto.

Errores comunes#

El primer error es la competencia: en cuanto el Red quiere 'ganar', deja de jugar ruidoso y el Blue no aprende nada. El segundo es la regla sin playbook que dispara a las 3 de la manana y no guia a nadie a actuar. El tercero es la regla nunca probada en homologacion que produce 200 falsos positivos por dia en produccion y queda silenciada en una semana. El cuarto es la ausencia de versionado: una deteccion que vive solo en la cabeza de un analista desaparece con el. El quinto es saltar el ensayo en seco, de modo que la telemetria faltante aparece a mitad de ejecucion y revienta el sprint.

Checklist practico#

Antes del sprint: elige cinco tecnicas relevantes para tu sector, firma contrato escrito con el SOC, verifica fuentes de datos por tecnica. Durante el sprint: ejecuta en la ventana con flag de ejercicio y logging completo, anota cada accion con timestamp y hash, marca detecciones en vivo en #purple-live. Despues del sprint: escribe la regla Sigma, traducela a EQL y KQL, pruebala en homologacion contra el umbral de FP, enlaza el playbook de respuesta, mergea a Git, mide el MTTD. Ningun sprint cuenta como hecho sin un unico artefacto versionado. Ese artefacto es exactamente lo que separa deteccion continua de entretenimiento puntual.

Roles, rotacion y psicologia#

Purple Team solo funciona cuando los roles rotan y nadie ocupa un asiento permanente de ganador. En la practica, un analista que jugo Blue durante tres sprints cambia deliberadamente al lado Red para sentir que tan fragiles son sus propias detecciones ante una variacion leve. Esta rotacion construye empatia y disuelve la mentalidad de silo donde el Red cree que los defensores son lentos y el Blue cree que los atacantes son fanfarrones. El facilitador, a menudo un detection engineer, mantiene el ejercicio honesto: sin momentos gotcha, sin payloads ocultos, sin remate en la retro. Cuando una tecnica se cuela, eso es una brecha sistemica de telemetria, no una falla personal del analista. Esta cultura exacta decide si el programa sigue vivo tras el tercer sprint o se asfixia en culpas mutuas. Un directorio financia maduracion medible, no una pelea de barro entre dos equipos. Trata la relacion como un solo equipo con dos sombreros y los numeros llegan solos.

Automatizacion con Atomic Red Team y CI#

Una vez que el ciclo manual esta solido, automatizamos la regresion. Atomic Red Team entrega tests atomicos descritos en YAML por tecnica ATT&CK que corren en un pipeline contra una VM desechable. Tras cada actualizacion de contenido del SIEM volvemos a disparar los atomics relevantes y verificamos si la regla Sigma asociada sigue disparando; si se rompe, el build falla, exactamente como un unit test. Esto previene el detection drift, donde una regla que funcionaba se silencia porque un campo fue renombrado en el esquema de logs. Los resultados quedan como reporte de cobertura en el mismo repo Git, versionados junto a las reglas. El limite importa: la automatizacion no reemplaza la hipotesis humana, solo protege lo ya logrado. Las tecnicas nuevas siguen naciendo de threat intel y emulacion manual; el CI solo garantiza que ninguna deteccion existente se degrade sin ser notada mientras el entorno sigue evolucionando debajo.

FAQ: Con que frecuencia debe correr un ciclo de Purple Team?#

Los sprints de dos semanas son el punto dulce para la mayoria de equipos: cortos para mantener el impulso, largos para endurecer de verdad una regla hasta produccion. Semanal quema al equipo y entrega detecciones a medias; mensual deja que el ciclo de feedback pierda filo. Cinco a diez tecnicas por sprint es realista cuando cada una termina en una regla versionada.

FAQ: Se necesitan herramientas caras para Purple Team?#

No. Sysmon con configuracion endurecida, el stack ELK o Wazuh, Atomic Red Team para la ejecucion y Sigma para reglas portables bastan para un ciclo completo con cero costo de licencia. El cuello de botella nunca es la herramienta, es la disciplina de cerrar el ciclo y convertir cada tecnica en un artefacto versionado.

Conclusion#

Takeaway practico: empieza pequeno y medible. Elige cinco tecnicas relevantes para tu sector, define contrato escrito con el SOC, ejecuta en ventana corta con logs completos, y no cierres el sprint sin regla Sigma versionada en Git. Purple Team que no deja artefacto versionado atras no escalo, solo entretuvo. El ciclo Red-crea-hipotesis, Blue-valida-telemetria, equipo-mergea-regla-en-produccion debe caber en dos semanas. Si tarda mas, estas gestionando proyecto, no operando deteccion continua. Repite el ciclo hasta que las celdas oscuras del heatmap ATT&CK se conviertan en cobertura medida.