Panorama#

El capítulo anterior terminó con una advertencia: ejecutar un plan de emulación y observar qué pasa es solo la mitad del trabajo. La otra mitad —convertir la observación en una mejora— es el objeto de este capítulo, y es también el corazón operativo de la Parte 6. El ejercicio purple (purple team) es la forma de validación en la que la ofensiva y la defensa trabajan juntas, en la misma sala y sobre el mismo plan, con un objetivo declarado que no es ganar sino cerrar el lazo dentro del propio ejercicio.

La tesis del capítulo conviene enunciarla de entrada porque corrige un malentendido extendido. Lo valioso del purple no es descubrir que algo no se detecta: eso lo hace también un red team, y a menudo mejor, porque opera sin avisar y encuentra el camino que nadie anticipó. Lo que el purple aporta y el red team no es que la corrección y la re-ejecución ocurren en la misma sesión. Se ejecuta una técnica, se observa que no dispara nada, se escribe la regla que falta, y se vuelve a ejecutar la técnica para confirmar que ahora sí dispara —todo antes de que el equipo se levante de la mesa—. Esa re-ejecución es el paso que casi ningún programa da, y es exactamente el que separa un hallazgo de una mejora. Un informe que dice «no detectamos la técnica X» es un pendiente; una regla que se escribió, se probó y se confirmó disparando es una capacidad nueva.

Qué distingue al purple de las demás formas de probar#

La taxonomía de ejercicios de 6.1 ya ubicó al purple entre las cinco formas de validar; aquí interesa el mecanismo por el cual produce su retorno particular. Un red team entrega, al final, un diagnóstico: esta es la cadena que recorrimos, esto se detectó, esto no. El diagnóstico es honesto y valioso, pero es una foto, y la corrección queda como trabajo posterior que compite con todo lo demás en la cola del equipo de detección —y que, con frecuencia previsible, no se hace—.

El purple invierte ese orden. La ejecución se anuncia, se instrumenta y se detiene después de cada técnica para mirar juntos qué produjo. Cuando una técnica no genera la señal esperada, el equipo de detección no toma nota para después: ajusta la regla o pide la telemetría en ese momento, y la ofensiva repite la técnica para verificar el arreglo. La colaboración no es un detalle de estilo —es la condición de que el lazo se cierre—, porque quien ejecuta la técnica sabe exactamente qué hizo y quien construye la detección puede preguntárselo en lugar de inferirlo de una telemetría incompleta. El purple no es un examen sorpresa: es una sesión de calibración conjunta.

Esto define también su límite, ya adelantado en 6.1 y que conviene no olvidar: el purple valida en profundidad lo que alguien pensó en probar. No descubre la técnica que a nadie se le ocurrió incluir en el plan. Por eso es complementario del red team, no un sustituto: el red team aporta la sorpresa, el purple aporta la cobertura y la corrección.

Los cuatro resultados de cada prueba#

Cada técnica ejecutada cae en uno de cuatro resultados, y clasificarla bien es lo que convierte el ejercicio en algo accionable. La clasificación es la misma que ordenó el lazo en 6.1; lo que aquí se agrega es qué corrección corresponde a cada caso y cuánto cuesta.

Prevenida. El control bloqueó la técnica antes de que se completara. Es el mejor resultado desde la seguridad, pero no cierra el trabajo: hay que registrar que se previno y volver a probarlo periódicamente, porque un bloqueo que hoy funciona es exactamente el tipo de cosa que el drift desactiva sin avisar.

Alertada. La técnica se ejecutó, la telemetría llegó, la regla disparó y la alerta fue visible para un humano en el turno correcto. La cadena de siete eslabones de 6.1 funcionó completa. Se registra y se sigue.

Registrada pero no alertada. Este es el resultado más valioso del ejercicio, y la razón es económica. La telemetría del comportamiento ya está —el evento se generó, llegó al SIEM, quedó almacenado— pero no existe la regla que lo convierta en alerta. La corrección es barata: no hay que desplegar sensores nuevos ni cambiar la ingesta, solo escribir una regla sobre datos que ya se tienen. Un ejercicio purple bien hecho produce, sobre todo, este tipo de hallazgo, y cada uno es una alerta nueva a costo casi nulo.

Invisible. La técnica no dejó ningún rastro utilizable: la telemetría necesaria no se está recolectando. La corrección es cara porque hay que actuar sobre la capa de datos —habilitar una auditoría, desplegar un sensor, configurar un reenvío— y solo entonces se puede pensar en la regla. Es el mismo orden de prioridades que 5.2 estableció: no se detecta lo que no se registra, y registrar es el prerrequisito, no el detalle.

Por qué el registrado-no-alertado importa más que el invisible. La intuición sugiere que lo invisible es lo más urgente —es donde la ceguera es total—, y a veces lo es. Pero el registrado-no-alertado es donde el ejercicio compra más detección por unidad de esfuerzo: la inversión cara (recolectar la telemetría) ya está hecha y desperdiciada por falta de una regla barata. Un programa que solo persigue lo invisible gasta en sensores nuevos mientras deja sin explotar la telemetría que ya paga. La secuencia sensata es primero cosechar las reglas que faltan sobre datos existentes, después decidir qué telemetría nueva justifica su costo.

Instrumentar antes de ejecutar#

Un ejercicio purple mide con precisión solo si la instrumentación se prepara antes de la primera técnica, y esto es más que encender el SIEM. Instrumentar significa tres cosas.

Primero, asegurar la visibilidad de ambos lados: quien defiende tiene que poder ver la telemetría en tiempo real durante la ejecución, no reconstruirla después, porque el valor del formato colaborativo está en discutir cada resultado en el momento. Segundo, marcar la actividad del ejercicio —el aviso de 6.2 sobre no contaminar la telemetría de producción se cumple aquí—: cada acción de la ofensiva queda etiquetada como propia, para que no envenene líneas base ni deje falsos positivos que sobrevivan a la sesión, y para poder distinguir, si aparece, la actividad de un adversario real de la del ejercicio. Tercero, fijar de antemano el criterio de éxito de cada técnica: qué se espera que ocurra —prevención, alerta, con qué latencia— para que la clasificación en los cuatro resultados no se improvise ni se negocie sobre la marcha. Es la expectativa escrita que 6.1 exigió, ahora por técnica.

flowchart LR
  PREP["INSTRUMENTAR\nvisibilidad 2 lados ·\nmarcar actividad ·\ncriterio de éxito"] --> EXE["EJECUTAR\nla técnica del plan\n(6.2), anunciada"]
  EXE --> CLA{"clasificar\nresultado"}
  CLA -->|"prevenida / alertada"| REG["registrar\n+ re-probar\nperiódicamente"]
  CLA -->|"registrada\nNO alertada"| RULE["escribir la REGLA\n(datos ya existen:\ncorrección barata)"]
  CLA -->|"invisible"| TELE["habilitar TELEMETRÍA\n(corrección cara)\n→ luego la regla"]
  RULE --> REEX["RE-EJECUTAR\nla misma técnica"]
  TELE --> REEX
  REEX -->|"ahora dispara"| CONF["confirmado:\ncapacidad nueva"]
  REEX -.->|"sigue sin verse\ny no se puede automatizar"| HUNT["hipótesis de\ncacería (5.1)"]
  CONF --> EXE

La detección como código: el arreglo se prueba como se prueba el software#

El paso de corrección del ejercicio produce reglas de detección, y la disciplina que las sostiene en el tiempo es tratarlas como código —detection-as-code—. Una regla escrita durante un purple y confirmada disparando es correcta hoy; lo que garantiza que siga siéndolo es guardarla en control de versiones, someterla a revisión, y validarla automáticamente en un flujo de integración continua que ejecute la técnica correspondiente y verifique que la regla dispara con cada cambio. Es la generalización del hallazgo de 5.8: la regla no está terminada cuando se escribe, sino cuando se verificó que dispara —y, si esa verificación es manual y se hace una sola vez, vuelve a caducar con el primer cambio de entorno—.

Aquí es donde el purple y la simulación automatizada de 6.2 se encuentran: la prueba atómica que en un purple se ejecutó a mano para escribir la regla se incorpora al catálogo automatizado, que la repite con cadencia y avisa cuando deja de disparar. El purple descubre y corrige; la automatización vigila que la corrección no se degrade. Uno resuelve el hallazgo, el otro combate el drift.

El entregable de una regla, además, tiene un formato que la hace portable entre organizaciones y herramientas. 1.4 presentó Sigma como el estándar abierto para expresar lógica de detección con independencia del SIEM; una regla nacida en un ejercicio purple se escribe una vez en Sigma y se traduce al lenguaje de consulta de cada plataforma:

title: Ejecución de tarea programada con carga codificada (T1053.005)
status: experimental
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4698          # se creó una tarea programada
  encoded:
    CommandLine|contains:   # el disparador ejecuta PowerShell codificado
      - '-enc'
      - '-EncodedCommand'
  condition: selection and encoded
level: high

Lo que esa regla materializa no es una idea abstracta: es el resultado concreto de haber ejecutado la técnica T1053.005 en el ejercicio, haber visto que el evento 4698 se registraba pero no alertaba, y haber escrito la condición que faltaba —el caso «registrado pero no alertado» convertido en detección—.

La matriz de cobertura y su trampa#

Es tentador cerrar un programa de purple con un mapa de ATT&CK pintado: las técnicas probadas en verde, las pendientes en rojo, un porcentaje de cobertura que sube ejercicio a ejercicio. El mapa es útil como inventario de qué se probó y qué falta, pero como métrica de seguridad reproduce exactamente el heat map engañoso que 1.3 desarmó: una técnica marcada como «cubierta» puede tener una detección frágil, atada a una firma que el adversario cambia sin esfuerzo, o disparar solo para la variante concreta que se probó. La cobertura de una técnica no es binaria, y contar casillas verdes mide la extensión del trabajo, no su profundidad. El mapa sirve para planificar el próximo ejercicio; no sirve para afirmar que se está cubierto. Esa afirmación solo la sostiene la re-ejecución, no el color de una celda.

El entregable no es un informe#

De aquí se sigue la diferencia más práctica entre un purple y casi cualquier otra evaluación: su producto no es un documento. Un pentest entrega un informe de hallazgos; un purple entrega capacidades: reglas de detección nuevas en control de versiones, telemetría nueva ingiriéndose, pruebas atómicas incorporadas al catálogo de regresión, y —para lo que no se pudo automatizar— hipótesis de cacería concretas.

Esa última categoría es la que conecta con el programa de detección. Cuando una técnica resulta invisible o su detección automática no es viable —demasiado ruido, demasiada latencia, un comportamiento indistinguible del legítimo salvo en contexto—, la salida correcta no es dejarla marcada en rojo en el mapa: es convertirla en una misión de cacería. El ejercicio purple produce, en ese caso, una hipótesis con la que alimentar el ciclo de hunt-to-detection de 5.1: si no se puede automatizar la detección, se busca a mano y de forma periódica, y el resultado de esa cacería vuelve, más adelante, a intentar convertirse en una regla.

La salida que el cierre del lazo tiene que rechazar. Cada técnica probada termina en una de cuatro decisiones —se previene, se detecta automáticamente, se caza periódicamente, o se acepta el riesgo con dueño, fecha y revisión—, las mismas cuatro salidas de 6.1. La que un ejercicio bien cerrado no admite es la quinta, tácita: «se aceptó el riesgo» sin dueño y sin fecha, que en la práctica significa que el hallazgo quedó anotado y nadie hará nada. Aceptar un riesgo es una decisión legítima; aceptarlo sin que nadie lo firme ni se comprometa a revisarlo es la forma en que un programa de validación produce documentación en lugar de seguridad.

Postura#

  1. Instrumentar antes de ejecutar: visibilidad en tiempo real de ambos lados, actividad del ejercicio marcada, criterio de éxito escrito por técnica.
  2. Clasificar cada resultado en los cuatro casos y priorizar la corrección del registrado-no-alertado, que es la detección más barata que existe.
  3. Cerrar el lazo en la sesión: escribir la regla o pedir la telemetría, y re-ejecutar la técnica para confirmar. Sin re-ejecución no hay mejora, solo un pendiente.
  4. Tratar la detección como código: control de versiones, revisión, validación en CI, con la prueba atómica incorporada al catálogo de regresión para que la corrección no se degrade.
  5. Usar la matriz de cobertura para planificar, no para afirmar cobertura. El verde de una celda no es una garantía; la re-ejecución sí.
  6. Entregar capacidades, no informes: reglas, telemetría, pruebas de regresión, hipótesis de cacería para lo que no se automatiza.
  7. Cerrar cada hallazgo con una de las cuatro salidas y rechazar la quinta —aceptación sin dueño ni fecha—.

Cierre#

El purple es el punto donde la validación deja de ser diagnóstico y se vuelve construcción: el ejercicio no termina con una lista de lo que falta sino con la parte de eso que ya se corrigió y se confirmó. Es, de las formas de validar, la que mejor encarna la tesis de la Parte —convertir supuestos en datos— porque no se limita a exponer el supuesto falso, lo reemplaza por una capacidad probada antes de cerrar la sesión.

Pero todo lo que este capítulo valida son controles: sensores, reglas, telemetría, la cadena técnica que convierte un comportamiento en una alerta. Queda fuera una clase de falla que ningún control detecta y que, en una crisis real, suele importar más: quién tiene autoridad para desconectar un sistema, cuándo se declara un incidente, con qué se cuenta si la infraestructura de respuesta está caída. Validar decisiones en lugar de controles es un ejercicio distinto, con otro sujeto —la organización, no el sensor—, y es el tema del capítulo 6.4.

Referencias#

  • blue-dfir/defenders-advantage/cap-07 — Validate: el modelo colaborativo del purple team, la ejecución iterativa de simulaciones para ajustar controles y calibrar alertas del SIEM en tiempo real, y el cierre del lazo con ingeniería de detección o, cuando la automatización no es viable, con una misión de cacería. (El resto del capítulo —drift, taxonomía de ejercicios, expectativas, pruebas dirigidas por inteligencia— se desarrolló en 6.1 y 6.2.)
  • La clasificación operativa de los cuatro resultados con su coste de corrección, la disciplina de instrumentación previa, la práctica de detección como código validada en integración continua, la trampa de la matriz de cobertura y el rechazo de la aceptación de riesgo sin dueño son enriquecimiento propio, apoyados en material previo del manual: la capa de datos de 5.2, la regla «no está terminada hasta que dispara» de 5.8, el hunt-to-detection de 5.1, el heat map engañoso de 1.3 y Sigma como formato de entregable de 1.4.