1. Objetivos de la semana
Hasta ahora hemos construido progresivamente un sistema capaz de detectar amenazas, analizarlas mediante IA y ejecutar respuestas controladas.
Ahora introducimos una nueva dimensión: la defensa debe enfrentarse continuamente a ataques simulados.
Esto permite transformar el sistema de seguridad de un modelo reactivo en un modelo de mejora continua.
Construir un ecosistema donde un agente ofensivo pueda generar escenarios de ataque controlados y un sistema defensivo basado en IA pueda detectarlos, investigarlos, responder y medir su eficacia.
Al finalizar la semana el alumno podrá:
Crear agentes capaces de seleccionar y ejecutar escenarios de ataque dentro de un entorno controlado.
Construir agentes defensivos capaces de analizar telemetría y detectar comportamientos anómalos.
Representar ataques como secuencias de técnicas y objetivos.
Ejecutar campañas controladas y repetibles.
Calcular cobertura, tiempo de detección, tiempo de respuesta y falsos positivos.
Utilizar los resultados de los ejercicios para mejorar las defensas.
2. ¿Qué significa AI Red Team vs AI Blue Team?
En un entorno tradicional, el Red Team intenta comprometer sistemas mientras el Blue Team intenta detectarlo y responder.
Con IA podemos convertir ambos equipos en sistemas parcialmente autónomos.
La clave está en el último paso.
El resultado de un ejercicio no debe quedarse en un informe. Debe convertirse en nuevo conocimiento defensivo.
3. AI Red Team
Un Red Team tradicional necesita especialistas que planifican y ejecutan operaciones ofensivas.
Un AI Red Team puede ayudar a automatizar parte de ese trabajo.
Funciones posibles
- generar escenarios de ataque;
- seleccionar técnicas;
- analizar posibles caminos;
- priorizar objetivos;
- adaptarse a resultados;
- evaluar defensas;
- generar variantes.
El objetivo del laboratorio educativo es trabajar sobre entornos autorizados y aislados. El agente ofensivo debe estar limitado por scope, objetivos y capacidades explícitamente permitidas.
Modelo conceptual
El agente no debe tener libertad ilimitada
Debemos definir:
- targets autorizados;
- horarios;
- técnicas permitidas;
- técnicas prohibidas;
- máximo impacto;
- rate limits;
- mecanismos de parada;
- logging completo.
4. AI Blue Team
El Blue Team recibe telemetría generada por los sistemas defensivos.
Puede estar compuesto por varios agentes especializados.
Agente de detección
Identifica patrones sospechosos.
Agente de investigación
Busca contexto adicional y construye una hipótesis.
Agente de Threat Intelligence
Enriquece indicadores con información externa o interna.
Agente de respuesta
Propone acciones de contención y las somete al Policy Engine.
5. Purple Team
El Purple Team tiene una función especialmente importante: cerrar el ciclo entre ataque y defensa.
No se trata simplemente de preguntar:
Debemos preguntar:
- ¿Qué técnica utilizó?
- ¿Qué evidencia generó?
- ¿Dónde apareció esa evidencia?
- ¿Qué sensor la observó?
- ¿Qué regla la detectó?
- ¿Cuánto tardamos?
- ¿Qué acción se ejecutó?
- ¿Podríamos haberlo detectado antes?
- ¿Podemos mejorar la cobertura?
El Purple Team transforma los resultados ofensivos en mejoras defensivas.
6. Arquitectura multiagente
Una de las arquitecturas más interesantes consiste en utilizar diferentes agentes especializados.
Cada agente tiene una función específica.
Esto permite aplicar el principio de separation of concerns.
7. Attack Graph
Un ataque complejo puede representarse como un grafo.
El AI Red Team puede intentar seleccionar diferentes caminos.
El Blue Team puede analizar en qué puntos del grafo existen mecanismos de detección.
| Fase | Pregunta ofensiva | Pregunta defensiva |
|---|---|---|
| Initial Access | ¿Cómo podría obtener acceso? | ¿Tenemos controles de entrada? |
| Execution | ¿Cómo podría ejecutar código? | ¿Tenemos telemetría? |
| Persistence | ¿Cómo mantendría acceso? | ¿Detectamos cambios persistentes? |
| Discovery | ¿Qué información buscaría? | ¿Observamos reconocimiento interno? |
| Lateral Movement | ¿Cómo podría desplazarse? | ¿Detectamos comportamiento lateral? |
| Impact | ¿Qué impacto podría conseguir? | ¿Tenemos mecanismos de contención? |
8. Attack Chain basada en IA
Una campaña puede representarse como una secuencia de estados.
{
"campaign": "LAB-001",
"target": "lab-network",
"steps": [
{
"phase": "recon",
"status": "completed"
},
{
"phase": "initial_access",
"status": "completed"
},
{
"phase": "execution",
"status": "detected"
},
{
"phase": "persistence",
"status": "blocked"
}
]
}Esto permite posteriormente calcular cobertura defensiva.
9. Simulación frente a explotación real
Para construir una plataforma segura debemos diferenciar entre:
| Simulación | Explotación real |
|---|---|
| Controlada | Potencialmente destructiva |
| Entorno autorizado | Puede afectar sistemas reales |
| Reproducible | Resultado variable |
| Objetivo educativo | Objetivo operativo |
En nuestro laboratorio utilizaremos preferentemente emulación y simulación.
Por ejemplo, en lugar de ejecutar una acción destructiva podemos generar un evento equivalente:
SIMULATED_EVENT
type:
suspicious_process
host:
LAB-WS-01
technique:
execution
severity:
high
timestamp:
2026-08-29T10:15:00Z
El Blue Team debe comportarse como si el evento fuera real.
10. Detection Engineering
La existencia de un agente ofensivo permite probar continuamente nuestras detecciones.
Podemos medir:
Porcentaje de técnicas simuladas que generan detección.
Mean Time To Detect.
Mean Time To Respond.
Cantidad de detecciones incorrectas.
Calidad contextual de las detecciones.
Eficacia de las acciones defensivas.
11. Métrica fundamental: Coverage
Supongamos que el Red Team ejecuta 20 escenarios.
El Blue Team detecta correctamente 16.
coverage = detected / executed
coverage = 16 / 20
coverage = 0.80
coverage = 80%
Esto significa que tenemos una cobertura del 80%.
Pero la métrica todavía no es suficiente.
También debemos estudiar:
- qué técnicas no fueron detectadas;
- qué sensores fallaron;
- qué reglas faltan;
- qué señales existían pero no fueron correlacionadas.
12. MTTD y MTTR
Dos métricas fundamentales.
MTTD =
Time of Detection - Time of Attack
MTTR =
Time of Response - Time of Detection
Ejemplo:
Attack:
10:00:00
Detection:
10:02:30
Response:
10:04:00
MTTD = 2m 30s
MTTR = 1m 30s
El objetivo del sistema autónomo es reducir ambos valores sin incrementar de manera inaceptable los falsos positivos.
13. Feedback Loop
Este es probablemente el concepto más importante de toda la semana.
Este proceso convierte el sistema en una plataforma de continuous security validation.
14. Knowledge Base
Los resultados de las campañas deben almacenarse.
Podemos almacenar:
- ataque;
- técnica;
- evidencias;
- alertas;
- detección;
- respuesta;
- resultado;
- fallos;
- mejoras recomendadas.
Ejemplo:
{
"technique": "example-technique",
"detected": false,
"evidence_available": true,
"sensor": "endpoint",
"reason": "Detection rule not configured",
"recommendation":
"Create detection rule for observed behaviour"
}El conocimiento puede utilizarse en futuras campañas.
15. AI vs AI
A partir de este punto aparece una dinámica especialmente interesante:
Red AI
Busca nuevas rutas y escenarios.
Blue AI
Busca señales y mecanismos de detección.
Ninguno debería tener acceso ilimitado al otro.
El sistema de orquestación debe controlar:
- qué información recibe cada agente;
- qué herramientas puede utilizar;
- qué objetivos puede atacar;
- qué acciones puede ejecutar;
- qué datos puede modificar.
16. AI Red Team adaptativo
Una evolución interesante consiste en que el Red Team no ejecute siempre la misma campaña.
Puede observar el resultado:
Scenario A
↓
Detected immediately
↓
Low effectiveness
y seleccionar otro escenario.
Scenario B
↓
Not detected
↓
High effectiveness
De esta manera puede priorizar áreas donde existen debilidades.
La adaptación debe seguir estando limitada por las reglas del laboratorio. Un agente no debe poder escapar del scope porque considere que necesita hacerlo para completar el objetivo.
17. AI Blue Team adaptativo
El Blue Team también puede evolucionar.
Si detecta que una técnica no está cubierta:
Esto nos aproxima a un concepto muy poderoso: self-improving security operations.
18. Human Oversight
Aunque utilicemos agentes autónomos, el sistema debe incorporar puntos de control humanos.
Especialmente cuando:
- el scope pueda cambiar;
- una acción pueda afectar producción;
- se modifiquen políticas;
- se desplieguen nuevas detecciones;
- se concedan nuevos permisos.
El agente puede proponer una modificación defensiva. La aprobación para desplegarla debe pertenecer a un proceso controlado.
19. Arquitectura completa del laboratorio
20. Laboratorio 01 · Diseñar el AI Red Team
Objetivo
Diseñar conceptualmente un agente que seleccione escenarios de ataque dentro de un laboratorio aislado.
El agente debe recibir
{
"target": "LAB-NETWORK",
"allowed_actions": [
"simulation",
"emulation"
],
"forbidden_actions": [
"production_access",
"destructive_operations"
]
}Debe producir
{
"campaign": "CAMPAIGN-001",
"objective":
"validate_detection_coverage",
"scenarios": [
{
"id": "SC-001",
"category": "execution"
},
{
"id": "SC-002",
"category": "persistence"
}
]
}Pregunta
¿Qué controles pondrías entre el agente y el simulador?
Ver orientación
Scope validation, allowlist de objetivos, límites de acciones, autorización, rate limiting, logging, timeout y mecanismo de parada de emergencia.
Escenario
El laboratorio genera eventos simulados.
EVENT #001
host = LAB-WS-01
event = suspicious_execution
severity = high
source = endpoint
El agente debe:
- clasificar;
- enriquecer;
- buscar eventos relacionados;
- calcular riesgo;
- proponer respuesta.
Objetivo
Comparar la campaña ofensiva con las capacidades defensivas.
| Escenario | Ejecutado | Detectado | Respuesta |
|---|---|---|---|
| SC-001 | YES | YES | YES |
| SC-002 | YES | NO | NO |
| SC-003 | YES | YES | NO |
El alumno debe identificar los gaps.
Para cada gap:
- identifica la causa;
- determina qué telemetría existe;
- propón una detección;
- valida la detección;
- vuelve a ejecutar el escenario;
- compara los resultados.
21. Ejemplo de scoring
Podemos definir un score sencillo:
score =
detection * 0.35
+ investigation * 0.25
+ response * 0.25
+ recovery * 0.15
Supongamos:
Detection = 0.80
Investigation = 0.90
Response = 0.70
Recovery = 1.00
Resultado:
score =
0.80 * 0.35 +
0.90 * 0.25 +
0.70 * 0.25 +
1.00 * 0.15
score = 0.835
El sistema obtiene aproximadamente un 83,5%.
22. Attack Success vs Defense Success
Un error habitual consiste en medir solamente si el ataque tuvo éxito.
Debemos evaluar ambos lados.
| Pregunta | Red Team | Blue Team |
|---|---|---|
| ¿Se ejecutó el escenario? | ✓ | — |
| ¿Se generó telemetría? | — | ✓ |
| ¿Se detectó? | — | ✓ |
| ¿Se investigó? | — | ✓ |
| ¿Se respondió? | — | ✓ |
| ¿Se consiguió el objetivo? | ✓ | — |
23. Continuous Security Validation
La arquitectura que estamos construyendo puede ejecutarse de forma periódica.
De esta manera dejamos de realizar ejercicios ofensivos únicamente de manera puntual.
La seguridad pasa a validarse continuamente.
24. Riesgos del AI Red Team
Un agente ofensivo también puede cometer errores.
- interpretar mal el objetivo;
- salirse del scope;
- repetir acciones;
- generar demasiada carga;
- provocar indisponibilidad;
- utilizar una herramienta incorrectamente.
Por ello debe existir:
Valida que el objetivo pertenece al laboratorio.
Limita qué acciones puede ejecutar.
Evita campañas excesivamente agresivas.
Permite detener inmediatamente el agente.
25. Riesgos del AI Blue Team
El sistema defensivo también puede equivocarse.
- false positives;
- false negatives;
- alucinaciones;
- malas correlaciones;
- respuestas excesivas;
- interpretación incorrecta del contexto.
Por ello las decisiones críticas deben pasar por el mismo modelo de autorización estudiado en Cybersecurity-12.
26. El verdadero objetivo: Security Learning Loop
Esta arquitectura es la base conceptual de un Autonomous Security Validation Platform.
27. Ejercicios de consolidación
Ejercicio 1
¿Por qué utilizar agentes separados para Red Team y Blue Team?
Ver respuesta
Porque permite separar objetivos, permisos, herramientas y fuentes de información. Además reduce el riesgo de que un único agente tenga capacidades ofensivas y defensivas excesivamente amplias.
Ejercicio 2
¿Qué función tiene el Purple Team?
Ver respuesta
Analizar los resultados de los ejercicios ofensivos y convertirlos en mejoras defensivas. Su objetivo es cerrar el ciclo entre ataque, detección y mejora.
Ejercicio 3
¿Qué diferencia existe entre Attack Success y Detection Success?
Ver respuesta
Attack Success mide si el escenario ofensivo consiguió su objetivo. Detection Success mide si el sistema defensivo consiguió identificarlo correctamente.
Ejercicio 4
¿Por qué no debemos permitir que el Red Team AI tenga libertad absoluta?
Ver respuesta
Porque un modelo puede interpretar incorrectamente el objetivo o generar acciones no previstas. El agente debe estar limitado por scope, herramientas, políticas, rate limits y mecanismos de parada.
Ejercicio 5
¿Qué debería suceder cuando una técnica no es detectada?
Ver respuesta
Debe generarse un gap de seguridad. Posteriormente debe investigarse qué telemetría existe, por qué no fue detectada, diseñar una mejora, validarla y repetir el escenario.
Ejercicio 6
¿Por qué no es suficiente medir la cobertura?
Ver respuesta
Porque dos sistemas pueden tener la misma cobertura pero tiempos de detección y respuesta completamente diferentes. También debemos medir calidad de detección, falsos positivos, investigación, respuesta, recuperación y riesgo operacional.
28. Caso práctico completo resuelto
Situación
El Red Team AI ejecuta una campaña de cinco escenarios en el laboratorio.
| Scenario | Detection | Investigation | Response |
|---|---|---|---|
| A | YES | YES | YES |
| B | YES | YES | NO |
| C | NO | NO | NO |
| D | YES | NO | NO |
| E | YES | YES | YES |
Paso 1 · Detection Coverage
Se detectaron cuatro de cinco.
coverage = 4 / 5
coverage = 80%
Paso 2 · Identificar el principal gap
El escenario C no fue detectado.
Este escenario debe investigarse prioritariamente.
Paso 3 · Investigación
El Purple Team analiza si existía telemetría.
Supongamos que sí existía.
Entonces el problema no está en el sensor, sino posiblemente en la lógica de detección o correlación.
Paso 4 · Mejora
Se diseña una nueva detección.
Paso 5 · Retest
Se vuelve a ejecutar el escenario C.
Scenario C
Before:
Detection = NO
After:
Detection = YES
Paso 6 · Resultado
La cobertura pasa potencialmente del 80% al 100% para esa campaña.
Lo importante es construir un mecanismo capaz de detectar continuamente nuevas debilidades.
29. Reto avanzado
Construye tu propio AI Cyber Range
El alumno debe diseñar una arquitectura completa con:
- AI Red Team;
- AI Blue Team;
- Purple Team;
- orquestador;
- laboratorio aislado;
- telemetría;
- SIEM;
- detección;
- investigación;
- respuesta;
- Policy Engine;
- Knowledge Base;
- scoring;
- feedback loop.
Debe responder además:
- ¿Qué herramientas puede utilizar cada agente?
- ¿Qué información puede consultar?
- ¿Qué acciones puede ejecutar?
- ¿Dónde se requiere aprobación humana?
- ¿Cómo se registra cada decisión?
- ¿Cómo se detiene un agente?
- ¿Cómo se mide la eficacia?
- ¿Cómo se incorporan los resultados a futuras campañas?
30. Arquitectura de seguridad del AI Cyber Range
El laboratorio que estamos planteando debe tener una frontera de seguridad muy clara.
El objetivo es que los agentes trabajen dentro del Cyber Range y no puedan escapar accidentalmente hacia infraestructura no autorizada.
31. Principios de diseño
El laboratorio debe estar aislado.
Cada agente debe tener los permisos mínimos.
Todo debe quedar registrado.
Las campañas deben poder repetirse.
Debe existir capacidad de parada inmediata.
Toda campaña debe producir métricas.
32. Evaluación final
El alumno debe ser capaz de explicar y diseñar:
- Arquitectura de un AI Red Team.
- Arquitectura de un AI Blue Team.
- Función del Purple Team.
- Modelo multiagente.
- Attack Graph.
- Attack Chain.
- Detection Coverage.
- MTTD y MTTR.
- Feedback Loop.
- Knowledge Base.
- Scope Guard.
- Kill Switch.
- Policy Engine.
- Human Oversight.
Pregunta final
Imagina que dispones de un sistema donde el Red Team AI ha descubierto que una determinada técnica consigue atravesar las defensas sin generar una alerta.
Describe todo el proceso desde el descubrimiento hasta que la nueva detección ha sido validada y desplegada.
33. Checklist del alumno
| Control | Completado |
|---|---|
| AI Red Team definido | ☐ |
| AI Blue Team definido | ☐ |
| Purple Team definido | ☐ |
| Scope del laboratorio | ☐ |
| Herramientas restringidas | ☐ |
| Kill switch | ☐ |
| Attack scenarios | ☐ |
| Detection pipeline | ☐ |
| Investigation pipeline | ☐ |
| Response pipeline | ☐ |
| Scoring | ☐ |
| Knowledge Base | ☐ |
| Feedback loop | ☐ |
| Human approval | ☐ |
34. Referencias y recursos
MITRE ATT&CK
Utiliza ATT&CK como marco para representar técnicas y tácticas utilizadas en las campañas de validación.
MITRE ATLAS
Especialmente importante para estudiar ataques contra sistemas de Inteligencia Artificial y Machine Learning.
OWASP
Estudia especialmente los riesgos relacionados con LLM, agentes, herramientas y exceso de autonomía.
NIST
Revisa los conceptos relacionados con Cybersecurity Framework, Risk Management y AI Risk Management.
Conceptos adicionales para investigar
Validación continua de los controles de seguridad.
Uso de IA en escenarios ofensivos y defensivos.
Automatización progresiva de operaciones de seguridad.
Entornos controlados para entrenamiento y validación.
Diseño y validación sistemática de detecciones.
Colaboración estructurada entre ataque y defensa.
35. Conceptos que deben quedar grabados
1. El Red Team busca debilidades.
2. El Blue Team busca detectarlas y responder.
3. El Purple Team convierte los resultados en mejoras.
4. La IA puede aumentar la velocidad y escala de los tres procesos.
5. Los agentes necesitan límites.
6. Todo ejercicio debe producir métricas.
7. Los fallos de detección deben convertirse en nuevos controles.
8. La seguridad debe validarse continuamente.
9. El objetivo final no es automatizar ataques.
10. El objetivo es construir un sistema que aprenda continuamente qué ataques puede detectar y cuáles todavía no.
36. Conexión con Cybersecurity-14
En Cybersecurity-12 construimos la capacidad de respuesta automática.
En Cybersecurity-13 hemos añadido un adversario:
El siguiente paso será llevar esta arquitectura hacia uno de los problemas más importantes de los sistemas de IA: cómo asegurar los propios agentes y sus herramientas.
En Cybersecurity-14 entraremos profundamente en:
- Agent Security;
- Prompt Injection;
- Tool Poisoning;
- Indirect Prompt Injection;
- Excessive Agency;
- Identity & Access Management para agentes;
- Agent-to-Agent Security;
- memoria de agentes;
- aislamiento de herramientas;
- observabilidad de agentes;
- Agent Security Gateway.
Hasta ahora utilizábamos IA para defender sistemas. A partir de la siguiente etapa tendremos que defender la propia IA que está defendiendo nuestros sistemas.