Aegis/AegisTestPlan_v3.md

Aegis v3 — Plan de Tareas: Plataforma Avanzada de Validación de Seguridad

Instrucciones de uso: Cada tarea (T-XXX) es una unidad de trabajo independiente que debe resultar en un commit. Están ordenadas secuencialmente — cada tarea puede depender de las anteriores pero nunca de las posteriores. Cada tarea incluye una sección de validación: no hagas commit hasta que todos los checks pasen.

Contexto: Este plan se ejecuta DESPUÉS de completar el plan v2 (T-100 a T-134). El v2 establece el flujo base Red Team / Blue Team con pestañas, validación dual, templates de Atomic Red Team y notificaciones. El v3 eleva Aegis a una plataforma de validación de seguridad de nivel enterprise, incorporando funcionalidades inspiradas en Validato, Cymulate, Picus Security, AttackIQ, y fuentes de datos open-source como Sigma Rules, MITRE D3FEND, LOLBAS, GTFOBins, MITRE CALDERA y la Adversary Emulation Library.

---

Lo que aporta V3 sobre V2

Área	V2 ya cubre	V3 añade
Fuentes de tests	Atomic Red Team	+Sigma Rules, +LOLBAS, +GTFOBins, +CALDERA, +Adversary Emulation Library, +Elastic Detection Rules
Defensa	Evidencias Blue Team	+MITRE D3FEND mapping, +Sigma rule sugerida por test, +detection rule validation
Threat actors	Ninguno	Perfiles de grupo APT, campañas, priorización por sector/geografía
Métricas	Pipeline y cobertura	+MTTD, +MTTR, +Detection Efficacy, +tendencias temporales
Visualización	Matriz ATT&CK básica	+Heatmap estilo Navigator, +capas superpuestas, +export de layers
Compliance	Ninguno	Mapeo a NIST 800-53, DORA, NIS2, ISO 27001, reportes de compliance
Kill chain	Tests individuales	+Campañas (cadenas de tests), +attack path visualization
Scoring	Estados binarios	+Score de cobertura por técnica, +score global, +benchmark
Comparativa	Ninguna	+Comparar snapshots temporales, +antes/después de remediación
Automatización	Manual	+Scheduling de campañas, +re-test automático post-remediación

---

Fuentes de Tests Adicionales (Investigación)

Tras investigar extensamente, estas son todas las fuentes open-source de las que Aegis puede obtener tests mapeados a MITRE ATT&CK:

Fuentes para Red Team (Procedimientos de Ataque)

Fuente	Descripción	Formato	Tests aprox.	URL
Atomic Red Team	Tests atómicos individuales por técnica	YAML	1,500+	GitHub
MITRE CALDERA	Abilities (acciones) ejecutables por agente	YAML	400+	GitHub
Adversary Emulation Library	Planes completos de emulación de APTs (APT29, FIN6, etc.)	YAML/JSON/PDF	15+ planes	GitHub
LOLBAS	Binarios legítimos de Windows que pueden ser abusados	YAML/JSON	400+	GitHub
GTFOBins	Binarios legítimos de Unix/Linux que pueden ser abusados	Markdown/JSON	350+	GitHub
MITRE ATT&CK Procedures	Procedimientos documentados en la propia framework	STIX/JSON	1,000+	TAXII Server

Fuentes para Blue Team (Reglas de Detección)

Fuente	Descripción	Formato	Reglas aprox.	URL
SigmaHQ	Reglas de detección genéricas para SIEM, mapeadas a ATT&CK	YAML	3,000+	GitHub
Elastic Detection Rules	Reglas de detección de Elastic SIEM (KQL)	TOML	1,000+	GitHub
MITRE D3FEND	Framework de contramedidas defensivas mapeado a ATT&CK	OWL/JSON	200+ técnicas	d3fend.mitre.org
Splunk Security Content	Reglas de detección para Splunk	YAML	1,500+	GitHub

Fuentes de Threat Intelligence

Fuente	Descripción	Formato	URL
MITRE CTI	Datos de ATT&CK en STIX 2.0 (grupos, software, campañas)	STIX/JSON	GitHub
MISP	Plataforma de compartición de threat intelligence	JSON	misp-project.org
MITRE ATT&CK Groups	Perfiles de 140+ grupos APT con sus TTPs	STIX	attack.mitre.org/groups

---

FASE 21 — Fuentes de Tests Múltiples: Importación y Unificación

T-200: Modelo unificado de fuente de datos (DataSource)

Objetivo: Crear un sistema de gestión de fuentes de datos que permita registrar, configurar y monitorizar las distintas fuentes de tests y reglas de detección.

Archivo a crear: backend/app/models/data_source.py

Campos:

Campo	Tipo	Restricciones
id	UUID	PK, default uuid4
name	String	unique, not null (ej: "atomic_red_team")
display_name	String	not null (ej: "Atomic Red Team")
type	String	not null (attack_procedure / detection_rule / threat_intel / defensive_technique)
url	String	nullable (URL base del repositorio/API)
description	Text	nullable
is_enabled	Boolean	default True
last_sync_at	DateTime	nullable
last_sync_status	String	nullable (success/error/in_progress)
last_sync_stats	JSONB	nullable ({"imported": X, "updated": Y, ...})
sync_frequency	String	nullable (daily/weekly/monthly/manual)
config	JSONB	nullable (configuración específica de la fuente)
created_at	DateTime	default utcnow

Generar migración.

Seed de fuentes iniciales: crear un script que registre todas las fuentes conocidas.

Validación:

• alembic upgrade head crea la tabla data_sources
• El seed crea las fuentes iniciales (atomic_red_team, sigma, lolbas, gtfobins, caldera, d3fend, elastic_rules, mitre_cti)
• Cada fuente tiene tipo, URL y configuración correctos
• Se pueden activar/desactivar fuentes individualmente

---

T-201: Servicio de importación de Sigma Rules

Objetivo: Importar reglas de detección Sigma del repositorio SigmaHQ y almacenarlas como templates de detección asociados a técnicas MITRE.

Archivo a crear: backend/app/services/sigma_import_service.py

Modelo a crear: backend/app/models/detection_rule.py

Campos de DetectionRule:

Campo	Tipo	Restricciones
id	UUID	PK, default uuid4
mitre_technique_id	String	not null
title	String	not null
description	Text	nullable
source	String	not null (sigma, elastic, splunk, custom)
source_id	String	nullable (ID en la fuente original)
source_url	String	nullable
rule_content	Text	not null (contenido YAML/KQL de la regla)
rule_format	String	not null (sigma_yaml, kql, spl, custom)
severity	String	nullable (informational, low, medium, high, critical)
platforms	JSONB	nullable, default []
log_sources	JSONB	nullable (ej: {"product": "windows", "service": "sysmon"})
false_positive_rate	String	nullable (low, medium, high)
is_active	Boolean	default True
created_at	DateTime	default utcnow

Lógica de importación:

1. Clonar/descargar el repo SigmaHQ (o usar GitHub API para ficheros YAML)
2. Para cada regla .yml:
   • Parsear YAML (título, descripción, logsource, detection, tags)
   • Extraer tags de ATT&CK: attack.t1059.001 → T1059.001
   • Extraer severidad del campo level
   • Almacenar como DetectionRule con source = "sigma"
3. No duplicar reglas existentes (comparar por source_id)
4. Actualizar data_source.last_sync_at y stats

Validación:

• La importación crea DetectionRules en la BD
• Cada regla tiene su técnica MITRE mapeada
• El contenido YAML de la regla se almacena completo
• Ejecutar dos veces no duplica
• Se importan al menos 500+ reglas
• Las severidades se mapean correctamente

---

T-202: Servicio de importación de LOLBAS y GTFOBins

Objetivo: Importar binarios y técnicas de "living off the land" desde LOLBAS (Windows) y GTFOBins (Linux) como templates de ataque.

Archivo a crear: backend/app/services/lolbas_import_service.py

Lógica para LOLBAS:

1. Descargar JSONs desde la API de LOLBAS (lolbas-project.github.io/api/)
2. Cada entrada contiene: Name, Description, Commands, Paths, MitreAttackTechniques
3. Por cada binario y cada técnica MITRE asociada:
   • Crear TestTemplate con source = "lolbas", platform = "windows"
   • El attack_procedure incluye los commands documentados
   • El tool_suggested es el nombre del binario
4. No duplicar

Lógica para GTFOBins:

1. Parsear datos desde la API/JSON de GTFOBins
2. Cada entrada contiene: nombre del binario, funciones (shell, file-upload, file-download, etc.)
3. Por cada binario y función:
   • Crear TestTemplate con source = "gtfobins", platform = "linux"
   • El attack_procedure incluye los ejemplos de comandos

Validación:

• LOLBAS importa templates para Windows
• GTFOBins importa templates para Linux
• Cada template tiene su técnica MITRE mapeada
• Los comandos de ejemplo se almacenan en attack_procedure
• No se duplican en ejecuciones posteriores

---

T-203: Servicio de importación de MITRE CALDERA abilities

Objetivo: Importar abilities (acciones ejecutables) del framework CALDERA como templates de tests.

Archivo a crear: backend/app/services/caldera_import_service.py

Lógica:

1. Descargar abilities desde el repositorio de CALDERA en GitHub
2. Cada ability es un YAML con: id, name, description, tactic, technique.attack_id, platforms, executors
3. Por cada ability:
   • Crear TestTemplate con source = "caldera"
   • Mapear a técnica MITRE
   • Incluir los executors como attack_procedure
   • Incluir las platforms soportadas

Validación:

• Se importan abilities de CALDERA
• Cada template tiene la técnica MITRE correcta
• Las plataformas soportadas se registran
• Los comandos de ejecución se almacenan

---

T-204: Servicio de importación de Elastic Detection Rules

Objetivo: Importar reglas de detección del repositorio open-source de Elastic como DetectionRules.

Archivo a crear: backend/app/services/elastic_import_service.py

Lógica:

1. Descargar reglas TOML desde el repo elastic/detection-rules
2. Cada regla TOML contiene: name, description, query (KQL), threat (con ATT&CK mapping), severity
3. Por cada regla:
   • Parsear TOML
   • Extraer mappings de ATT&CK del campo threat
   • Crear DetectionRule con source = "elastic", rule_format = "kql"
   • Almacenar el query KQL completo

Validación:

• Se importan reglas de Elastic
• Cada regla tiene su técnica MITRE mapeada
• El KQL se almacena completo y correctamente
• Las severidades se mapean

---

T-205: Endpoint unificado de importación y panel de fuentes

Objetivo: Crear un panel de administración centralizado para gestionar todas las fuentes de datos.

Archivos a crear/modificar:

• backend/app/routers/data_sources.py
• frontend/src/pages/DataSourcesPage.tsx

Endpoints:

Método	Ruta	Auth	Descripción
GET	/data-sources	admin	Listar todas las fuentes
PATCH	/data-sources/{id}	admin	Activar/desactivar, cambiar config
POST	/data-sources/{id}/sync	admin	Ejecutar importación de una fuente
POST	/data-sources/sync-all	admin	Importar de todas las fuentes activas
GET	/data-sources/{id}/stats	admin	Estadísticas de la fuente

Frontend — Panel de fuentes:

• Tabla con todas las fuentes: nombre, tipo, estado, última sync, stats
• Toggle para activar/desactivar
• Botón de sync individual con progreso
• Botón de "Sync All" con progreso
• Estadísticas: total de items importados por fuente, última fecha, errores

Validación:

• El panel muestra todas las fuentes registradas
• Se puede activar/desactivar cada fuente
• Sync individual ejecuta la importación correcta
• "Sync All" ejecuta todas las fuentes activas secuencialmente
• Las estadísticas se actualizan tras cada sync
• Solo admin puede acceder

---

FASE 22 — Perfiles de Amenaza (Threat Actor Profiles)

T-206: Modelo ThreatActor

Objetivo: Crear un modelo para almacenar perfiles de grupos de amenaza (APTs) con sus TTPs asociadas, permitiendo priorizar qué tests ejecutar según las amenazas relevantes para la organización.

Archivo a crear: backend/app/models/threat_actor.py

Campos:

Campo	Tipo	Restricciones
id	UUID	PK, default uuid4
mitre_id	String	unique, nullable (ej: "G0016" para APT29)
name	String	not null
aliases	JSONB	nullable, default [] (nombres alternativos)
description	Text	nullable
country	String	nullable (país de origen atribuido)
target_sectors	JSONB	nullable, default [] (sectores objetivo)
target_regions	JSONB	nullable, default [] (regiones geográficas)
motivation	String	nullable (espionage, financial, destruction, etc.)
sophistication	String	nullable (low, medium, high, advanced)
first_seen	String	nullable (año/fecha de primera actividad)
last_seen	String	nullable
references	JSONB	nullable, default [] (URLs de referencia)
mitre_url	String	nullable
is_active	Boolean	default True
created_at	DateTime	default utcnow

Modelo ThreatActorTechnique (tabla intermedia):

Campo	Tipo	Restricciones
id	UUID	PK, default uuid4
threat_actor_id	UUID	FK → threat_actors.id, not null
technique_id	UUID	FK → techniques.id, not null
usage_description	Text	nullable (cómo el grupo usa esta técnica)
first_seen_using	String	nullable

Generar migración.

Validación:

• Las tablas se crean correctamente
• Se puede asociar un threat actor a múltiples técnicas
• Una técnica puede estar asociada a múltiples threat actors
• Los campos JSONB aceptan arrays

---

T-207: Importación de Threat Actors desde MITRE CTI

Objetivo: Importar perfiles de grupos de amenaza desde el repositorio MITRE CTI (STIX 2.0).

Archivo a crear: backend/app/services/threat_actor_import_service.py

Lógica:

1. Descargar datos STIX desde https://github.com/mitre/cti (enterprise-attack)
2. Filtrar objetos de tipo intrusion-set (grupos APT)
3. Para cada grupo:
   • Extraer name, description, aliases, external_references
   • Extraer el MITRE ID de external_references
4. Buscar relaciones uses entre el grupo y attack-pattern (técnicas)
5. Crear ThreatActor y sus ThreatActorTechnique asociados
6. No duplicar en re-ejecuciones

Validación:

• Se importan 140+ threat actors
• Cada actor tiene sus técnicas asociadas
• Las relaciones actor-técnica son correctas (verificar con datos de MITRE)
• Los aliases y descriptions se importan
• Re-ejecutar no duplica

---

T-208: Endpoints y UI de Threat Actors

Archivos a crear:

• backend/app/routers/threat_actors.py
• frontend/src/api/threat-actors.ts
• frontend/src/pages/ThreatActorsPage.tsx
• frontend/src/pages/ThreatActorDetailPage.tsx

Endpoints:

Método	Ruta	Auth	Descripción
GET	/threat-actors	autenticado	Listar con filtros
GET	/threat-actors/{id}	autenticado	Detalle con técnicas y cobertura
GET	/threat-actors/{id}/coverage	autenticado	Porcentaje de cobertura contra este actor
GET	/threat-actors/{id}/gaps	autenticado	Técnicas del actor sin tests validados
POST	/threat-actors/{id}/generate-campaign	red_tech, admin	Generar campaña de tests para cubrir gaps

Filtros del listado:

• country, target_sectors, motivation, sophistication
• search (busca en name, aliases, description)

Página ThreatActorsPage:

• Grid de cards con: nombre, país (bandera), sectores, motivación, nº técnicas, cobertura %
• Filtros laterales por sector, región, motivación
• Buscador

Página ThreatActorDetailPage:

• Header con perfil del grupo (nombre, aliases, descripción, country, motivación)
• Heatmap de técnicas: mini-matriz ATT&CK mostrando solo las técnicas de este actor, coloreadas por estado de cobertura
• Coverage gap analysis: lista de técnicas NO cubiertas
• Botón "Generate Test Campaign": crea tests para cubrir las gaps usando templates disponibles
• Lista de tests existentes vinculados a técnicas de este actor

Validación:

• El listado muestra threat actors con filtros funcionales
• El detalle muestra el perfil completo con heatmap
• El coverage calcula correctamente qué % de las técnicas del actor están cubiertas
• El gap analysis identifica técnicas sin tests validados
• "Generate Campaign" crea tests desde templates disponibles
• La ruta se añade al sidebar: "Threat Actors"

---

FASE 23 — MITRE D3FEND: Contramedidas Defensivas

T-209: Modelo y importación de D3FEND

Objetivo: Integrar el framework MITRE D3FEND para mapear cada técnica ATT&CK a las contramedidas defensivas recomendadas, dando al Blue Team una guía de qué mecanismos de defensa validar.

Archivo a crear: backend/app/models/defensive_technique.py

Campos:

Campo	Tipo	Restricciones
id	UUID	PK, default uuid4
d3fend_id	String	unique, not null (ej: "D3-AL")
name	String	not null
description	Text	nullable
tactic	String	nullable (D3FEND tactic: Detect, Isolate, etc.)
d3fend_url	String	nullable
created_at	DateTime	default utcnow

Modelo DefensiveTechniqueMapping (mapeo ATT&CK → D3FEND):

Campo	Tipo	Restricciones
id	UUID	PK, default uuid4
attack_technique_id	UUID	FK → techniques.id, not null
defensive_technique_id	UUID	FK → defensive_techniques.id, not null

Servicio de importación backend/app/services/d3fend_import_service.py:

1. Usar la API de D3FEND (https://d3fend.mitre.org/api/) para obtener técnicas defensivas
2. Usar el endpoint de mappings ATT&CK-D3FEND para establecer relaciones
3. Almacenar técnicas defensivas y sus mapeos

Validación:

• Se importan 200+ técnicas defensivas D3FEND
• Los mappings ATT&CK → D3FEND se crean correctamente
• Desde una técnica ATT&CK se pueden consultar sus contramedidas D3FEND
• El endpoint de técnica detalle incluye las contramedidas recomendadas

---

T-210: UI de contramedidas en vista de técnica y test

Objetivo: Mostrar las contramedidas D3FEND recomendadas en la vista de detalle de técnica y en la pestaña Blue Team del test.

Archivos a modificar:

• frontend/src/pages/TechniqueDetailPage.tsx — nueva sección "Recommended Defenses"
• frontend/src/components/test-detail/TeamTabs.tsx — en pestaña Blue, mostrar contramedidas

Sección en TechniqueDetailPage:

• Lista de contramedidas D3FEND recomendadas para esta técnica
• Cada contramedida con: nombre, descripción, tactic D3FEND, link a documentación
• Indicador de si hay reglas de detección asociadas en el catálogo

En pestaña Blue Team del test:

• Panel "Recommended Detection Approaches"
• Lista de contramedidas D3FEND aplicables
• Reglas de detección Sigma/Elastic disponibles para esta técnica (del catálogo)
• Checklist de "¿Se validó esta contramedida?" (checkbox que el blue_tech marca)

Validación:

• La vista de técnica muestra contramedidas D3FEND
• La pestaña Blue Team muestra las contramedidas y reglas de detección
• Los links a documentación D3FEND funcionan
• El checklist se guarda correctamente

---

FASE 24 — Reglas de Detección Sugeridas por Test

T-211: Asociar DetectionRules a tests y templates

Objetivo: Vincular reglas de detección (Sigma, Elastic, etc.) a los tests y templates, de manera que el Blue Team sepa exactamente qué regla debería haber detectado el ataque.

Modelo a crear: tabla intermedia test_template_detection_rules:

Campo	Tipo	Restricciones
id	UUID	PK, default uuid4
test_template_id	UUID	FK → test_templates.id, nullable
detection_rule_id	UUID	FK → detection_rules.id, not null
is_primary	Boolean	default False (si es la regla principal esperada)

Lógica de auto-asociación:

• Al importar templates y reglas de detección, asociar automáticamente por técnica MITRE
• Un template de ataque T1059.001 se asocia a todas las reglas Sigma/Elastic para T1059.001
• Marcar como is_primary las reglas cuya severidad sea >= high

Endpoint nuevo:

GET /test-templates/{id}/detection-rules → reglas de detección sugeridas para este template
GET /detection-rules?technique={mitre_id} → reglas para una técnica

Validación:

• Los templates se asocian automáticamente a sus reglas de detección
• GET /test-templates/{id}/detection-rules retorna las reglas correctas
• Las reglas primarias se marcan correctamente
• Filtrar por técnica funciona

---

T-212: UI de reglas de detección en la pestaña Blue Team

Objetivo: Cuando el Blue Team evalúa un test, mostrarle las reglas de detección que deberían haber saltado, permitiéndole marcar cuáles detectaron y cuáles no.

Archivo a crear: frontend/src/components/test-detail/DetectionRuleChecklist.tsx

Contenido:

• Lista de reglas de detección asociadas al test/template
• Cada regla con: título, severidad (badge color), fuente (Sigma/Elastic), contenido expandible
• Checkbox: "This rule triggered" / "This rule did NOT trigger" / "Not applicable"
• Campo de notas por regla
• Resumen: X/Y reglas detectaron (con porcentaje)

Datos a guardar en el backend:

Crear modelo TestDetectionResult:

Campo	Tipo	Restricciones
id	UUID	PK, default uuid4
test_id	UUID	FK → tests.id, not null
detection_rule_id	UUID	FK → detection_rules.id, not null
triggered	Boolean	nullable (null = not evaluated)
notes	Text	nullable
evaluated_by	UUID	FK → users.id, nullable
evaluated_at	DateTime	nullable

Validación:

• El checklist muestra las reglas de detección correctas
• Se puede marcar cada regla como triggered/not triggered/N.A.
• Las notas se guardan correctamente
• El resumen X/Y se calcula
• Los resultados se persisten en la BD

---

FASE 25 — Campañas de Tests (Attack Chains)

T-213: Modelo Campaign

Objetivo: Crear campañas que agrupen múltiples tests en una secuencia que simula una cadena de ataque completa (kill chain), inspirado en cómo Cymulate y AttackIQ ejecutan full kill chain assessments.

Archivo a crear: backend/app/models/campaign.py

Campos de Campaign:

Campo	Tipo	Restricciones
id	UUID	PK, default uuid4
name	String	not null
description	Text	nullable
type	String	not null (custom, apt_emulation, kill_chain, compliance)
threat_actor_id	UUID	FK → threat_actors.id, nullable
status	String	default "draft" (draft, active, completed, archived)
created_by	UUID	FK → users.id, nullable
scheduled_at	DateTime	nullable (ejecución programada)
completed_at	DateTime	nullable
target_platform	String	nullable
tags	JSONB	nullable, default []
created_at	DateTime	default utcnow

Campos de CampaignTest (tests de la campaña, con orden):

Campo	Type	Restricciones
id	UUID	PK, default uuid4
campaign_id	UUID	FK → campaigns.id, not null
test_id	UUID	FK → tests.id, not null
order_index	Integer	not null (posición en la cadena)
depends_on	UUID	FK → campaign_tests.id, nullable (test previo)
phase	String	nullable (initial_access, execution, persistence, etc.)

Generar migración.

Validación:

• Las tablas se crean correctamente
• Una campaña puede contener múltiples tests ordenados
• Los tests de una campaña pueden tener dependencias entre sí
• El campo phase permite etiquetar cada test con la fase del kill chain

---

T-214: Endpoints y lógica de Campañas

Archivos a crear:

• backend/app/routers/campaigns.py
• backend/app/services/campaign_service.py

Endpoints:

Método	Ruta	Auth	Descripción
GET	/campaigns	autenticado	Listar campañas con filtros
POST	/campaigns	red_tech, admin	Crear campaña
GET	/campaigns/{id}	autenticado	Detalle con tests y progreso
PATCH	/campaigns/{id}	creador, admin	Actualizar campaña
POST	/campaigns/{id}/tests	red_tech, admin	Añadir test a campaña
DELETE	/campaigns/{id}/tests/{test_id}	creador, admin	Quitar test de campaña
POST	/campaigns/{id}/activate	red_tech, admin	Activar campaña (inicia ejecución)
POST	/campaigns/{id}/complete	red_lead, admin	Marcar como completada
GET	/campaigns/{id}/progress	autenticado	Progreso: tests por estado
POST	/campaigns/from-threat-actor/{actor_id}	red_tech, admin	Auto-generar campaña desde gaps del actor

Servicio de generación automática:

generate_campaign_from_threat_actor(db, actor_id, user):

1. Obtener técnicas del actor no cubiertas
2. Para cada técnica sin test validado, buscar el mejor template disponible
3. Crear test desde template
4. Crear campaña con los tests ordenados por kill chain (tactic)
5. Retornar la campaña con sus tests

Validación:

• CRUD de campañas funciona
• Se pueden añadir/quitar tests con orden
• Activar campaña cambia status y notifica
• El progreso se calcula correctamente
• La generación automática desde threat actor crea una campaña coherente
• Los tests se ordenan por kill chain

---

T-215: UI de Campañas

Archivos a crear:

• frontend/src/pages/CampaignsPage.tsx
• frontend/src/pages/CampaignDetailPage.tsx
• frontend/src/components/CampaignTimeline.tsx

CampaignsPage:

• Grid de cards con: nombre, tipo (badge), threat actor (si aplica), status, progreso %, nº tests
• Filtros: tipo, status, threat actor
• Botón "New Campaign" y "Generate from Threat Actor"

CampaignDetailPage:

• Header: nombre, descripción, status, threat actor linkado, dates
• Kill Chain Timeline: visualización horizontal mostrando los tests agrupados por fase (Initial Access → Execution → Persistence → ...)
  • Cada nodo es un test con color según su estado
  • Flechas de dependencia entre tests
  • Click en un nodo abre el detalle del test
• Progress Panel: barra de progreso + contadores por estado
• Tests Table: tabla con todos los tests de la campaña, reordenable

Ruta: /campaigns y /campaigns/:id — añadir al sidebar.

Validación:

• El listado muestra campañas con filtros
• El timeline visual renderiza correctamente los tests por fase
• El progreso se actualiza al cambiar estado de tests
• Se pueden añadir/quitar tests desde la UI
• El detalle es interactivo (click en nodos navega)

---

FASE 26 — Heatmap ATT&CK Avanzado (estilo Navigator)

T-216: Backend de layers para heatmap

Objetivo: Crear un sistema de "layers" (capas) que permitan visualizar la matriz ATT&CK con diferentes datos superpuestos, similar al MITRE ATT&CK Navigator.

Archivo a crear: backend/app/routers/heatmap.py

Endpoints:

Método	Ruta	Auth	Descripción
GET	/heatmap/coverage	autenticado	Capa de cobertura (status de cada técnica)
GET	/heatmap/threat-actor/{actor_id}	autenticado	Capa de técnicas usadas por un actor
GET	/heatmap/detection-rules	autenticado	Capa de cobertura de reglas de detección
GET	/heatmap/campaign/{campaign_id}	autenticado	Capa de progreso de una campaña
GET	/heatmap/comparison	autenticado	Comparar dos snapshots temporales
GET	/heatmap/export-navigator	autenticado	Exportar como JSON del ATT&CK Navigator

Formato de respuesta (compatible con ATT&CK Navigator layers):

{
  "name": "Aegis Coverage",
  "versions": {"attack": "15", "navigator": "5.0", "layer": "4.5"},
  "domain": "enterprise-attack",
  "techniques": [
    {
      "techniqueID": "T1059.001",
      "tactic": "execution",
      "color": "#00ff00",
      "score": 100,
      "comment": "Validated - 3 tests passed",
      "metadata": [...]
    }
  ]
}

Validación:

• /heatmap/coverage retorna datos para todas las técnicas
• /heatmap/threat-actor/{id} resalta solo las técnicas del actor
• /heatmap/export-navigator genera un JSON importable en ATT&CK Navigator real
• /heatmap/comparison acepta dos fechas y muestra diferencias
• Los colores se calculan correctamente según el estado

---

T-217: Frontend de heatmap avanzado

Objetivo: Rediseñar la página de matriz ATT&CK con un heatmap interactivo que soporte capas superpuestas.

Archivos a crear/modificar:

• frontend/src/pages/TechniquesPage.tsx — rediseñar
• frontend/src/components/AdvancedHeatmap.tsx
• frontend/src/components/HeatmapLayerSelector.tsx
• frontend/src/components/HeatmapLegend.tsx

Funcionalidades:

1. Selector de capas: dropdown/checkboxes para seleccionar qué capas mostrar
   • Coverage (default)
   • Threat Actor (selector de actor)
   • Detection Rules (cobertura de reglas)
   • Campaign progress
2. Capas superpuestas: poder ver coverage + threat actor simultáneamente (gradientes)
3. Zoom y scroll: la matriz es grande — zoom in/out, scrollable
4. Tooltips: hover sobre una técnica muestra resumen (status, nº tests, reglas, actors)
5. Filtros: por táctica, plataforma, status
6. Export: botón para exportar layer compatible con ATT&CK Navigator
7. Leyenda: código de colores dinámico según capas activas

Validación:

• El heatmap renderiza todas las técnicas agrupadas por táctica
• Seleccionar capas diferentes cambia la visualización
• La superposición de capas funciona visualmente
• Los tooltips muestran información útil
• Export genera un JSON descargable compatible con ATT&CK Navigator
• Zoom y scroll funcionan suavemente

---

FASE 27 — Scoring y Métricas Avanzadas

T-218: Sistema de scoring de cobertura

Objetivo: Implementar un sistema de puntuación granular que vaya más allá de estados binarios, calculando scores numéricos de cobertura por técnica, táctica, actor y organización.

Archivo a crear: backend/app/services/scoring_service.py

Lógica de scoring por técnica:

def calculate_technique_score(technique) -> float:
    """
    Score de 0 a 100 basado en:
    - Tests validados con detección (40 pts)
    - Reglas de detección validadas (20 pts)
    - Contramedidas D3FEND cubiertas (15 pts)
    - Frescura: tests recientes vs antiguos (15 pts)
    - Diversidad de plataformas cubiertas (10 pts)
    """

Lógica de scoring por threat actor:

def calculate_actor_coverage_score(actor) -> float:
    """
    Promedio ponderado de scores de las técnicas del actor,
    ponderado por frecuencia de uso de cada técnica.
    """

Lógica de scoring global:

def calculate_organization_score() -> dict:
    """
    Score global de la organización:
    - Total coverage score (promedio de técnicas evaluadas)
    - Critical technique score (técnicas de alta severidad)
    - Detection maturity score (basado en reglas de detección)
    - Response readiness score (basado en remediaciones completadas)
    """

Endpoints:

Método	Ruta	Auth	Descripción
GET	/scores/technique/{mitre_id}	autenticado	Score detallado de una técnica
GET	/scores/tactic/{tactic}	autenticado	Score promedio por táctica
GET	/scores/threat-actor/{id}	autenticado	Score de cobertura contra actor
GET	/scores/organization	autenticado	Score global de la organización
GET	/scores/history	autenticado	Historial de scores en el tiempo

Validación:

• El score de técnica se calcula correctamente (0-100)
• El score de threat actor refleja la cobertura real
• El score de organización agrega correctamente
• El historial muestra la evolución temporal
• Los pesos son configurables

---

T-219: Métricas operativas (MTTD, MTTR, Detection Efficacy)

Objetivo: Implementar métricas operativas del equipo de seguridad inspiradas en las mejores prácticas de purple teaming.

Archivo a crear: backend/app/services/operational_metrics_service.py

Métricas a calcular:

1. MTTD (Mean Time to Detect): Tiempo medio entre que Red Team ejecuta un ataque (red_executing → blue_evaluating) y Blue Team completa evaluación
2. MTTR (Mean Time to Respond/Remediate): Tiempo medio entre detección y remediación completada
3. Detection Efficacy: % de tests donde el resultado es detected vs total de tests validados
4. Alert Fidelity: Ratio de reglas de detección que realmente se activaron vs total evaluadas
5. Coverage Velocity: Tasa de nuevas técnicas cubiertas por semana/mes
6. Validation Throughput: Tests completados (validados + rechazados) por semana/mes
7. Rejection Rate: % de tests rechazados (indica calidad del trabajo)

Endpoints:

Método	Ruta	Auth	Descripción
GET	/metrics/operational	autenticado	Todas las métricas operativas
GET	/metrics/operational/trend	autenticado	Tendencia temporal (últimos 30/90 días)
GET	/metrics/operational/by-team	autenticado	Métricas desglosadas por equipo

Validación:

• MTTD se calcula correctamente a partir de timestamps
• MTTR incluye el tiempo de remediación
• Detection Efficacy es un porcentaje correcto
• Las tendencias muestran evolución temporal
• El desglose por equipo funciona

---

T-220: Dashboard ejecutivo con scores y métricas

Objetivo: Crear una vista de dashboard ejecutivo con los scores, métricas operativas y tendencias, pensada para presentar a dirección.

Archivo a crear: frontend/src/pages/ExecutiveDashboardPage.tsx

Secciones:

1. Score Card: Score global de la organización con gauge (tipo velocímetro)
2. Trend Chart: Gráfico de línea mostrando evolución del score en los últimos 90 días
3. Top 5 Threat Actors: Actors más relevantes con su % de cobertura
4. Operational KPIs: Cards con MTTD, MTTR, Detection Efficacy, Throughput
5. Coverage por táctica: Barras horizontales con % de cobertura por táctica
6. Critical Gaps: Top 10 técnicas de alta severidad sin cobertura
7. Team Performance: Comparativa Red vs Blue (tests completados, tiempos)

Ruta: /executive-dashboard — accesible para roles admin, red_lead, blue_lead.

Validación:

• El dashboard carga con datos reales
• El gauge del score global funciona y se colorea correctamente
• Los gráficos de tendencia se renderizan
• Los KPIs muestran valores correctos
• Los critical gaps enlazan al detalle de la técnica
• Solo roles de liderazgo pueden acceder

---

FASE 28 — Compliance y Reportes Avanzados

T-221: Modelo de mapeo a frameworks de compliance

Objetivo: Mapear técnicas ATT&CK y controles de seguridad a frameworks de compliance (NIST 800-53, DORA, NIS2, ISO 27001), inspirado en cómo Cymulate y Picus generan reportes de compliance.

Archivo a crear: backend/app/models/compliance.py

Campos de ComplianceFramework:

Campo	Tipo	Restricciones
id	UUID	PK, default uuid4
name	String	unique, not null (ej: "NIST 800-53")
version	String	nullable
description	Text	nullable
url	String	nullable
is_active	Boolean	default True

Campos de ComplianceControl:

Campo	Tipo	Restricciones
id	UUID	PK, default uuid4
framework_id	UUID	FK → compliance_frameworks.id, not null
control_id	String	not null (ej: "AC-2", "PR.AC-1")
title	String	not null
description	Text	nullable
category	String	nullable

Campos de ComplianceControlMapping (mapeo a técnicas ATT&CK):

Campo	Tipo	Restricciones
id	UUID	PK, default uuid4
compliance_control_id	UUID	FK → compliance_controls.id, not null
technique_id	UUID	FK → techniques.id, not null

Seed de datos: NIST 800-53 → ATT&CK mappings están disponibles en D3FEND y en el MITRE CTI.

Generar migración.

Validación:

• Las tablas se crean correctamente
• Se puede mapear un control de compliance a múltiples técnicas
• Los frameworks NIST 800-53 y DORA se seedean con sus controles
• Los mappings a técnicas ATT&CK son correctos

---

T-222: Endpoints y generación de reportes de compliance

Archivo a crear: backend/app/routers/compliance.py

Endpoints:

Método	Ruta	Auth	Descripción
GET	/compliance/frameworks	autenticado	Listar frameworks disponibles
GET	/compliance/frameworks/{id}/status	autenticado	Estado de cada control (cubierto/no cubierto)
GET	/compliance/frameworks/{id}/report	autenticado	Reporte completo de compliance
GET	/compliance/frameworks/{id}/report/pdf	autenticado	Export PDF del reporte
GET	/compliance/frameworks/{id}/gaps	autenticado	Controles con técnicas no cubiertas

Lógica del reporte:

Para cada control del framework:

1. Obtener las técnicas ATT&CK mapeadas
2. Verificar el estado de cobertura de cada técnica
3. El control está "cubierto" si todas sus técnicas tienen score > umbral
4. El control está "parcialmente cubierto" si algunas técnicas están cubiertas
5. El control está "no cubierto" si ninguna técnica está cubierta
6. Calcular % de compliance global

Validación:

• El estado de cada control se calcula correctamente
• El reporte incluye todos los controles del framework
• El export PDF se genera correctamente
• Los gaps listan controles con técnicas no cubiertas
• El % global de compliance es correcto

---

T-223: UI de Compliance

Archivos a crear:

• frontend/src/pages/CompliancePage.tsx
• frontend/src/pages/ComplianceReportPage.tsx

CompliancePage:

• Selector de framework (NIST 800-53, DORA, NIS2, ISO 27001)
• Dashboard de compliance: gauge de % global, distribución cubierto/parcial/no cubierto
• Tabla de controles con: ID, título, estado (badge color), % cobertura, nº técnicas
• Filtros: estado, categoría
• Botón de export (PDF, CSV)

ComplianceReportPage:

• Reporte formateado listo para presentar a auditoría
• Header con framework, fecha, organización
• Resumen ejecutivo con métricas
• Tabla detallada control por control con evidencias de cobertura
• Sección de gaps y plan de remediación recomendado

Ruta: /compliance — añadir al sidebar.

Validación:

• La página muestra frameworks con métricas correctas
• La tabla de controles se filtra correctamente
• El reporte PDF se descarga y es legible
• Los datos de compliance son consistentes con los scores
• La ruta aparece en el sidebar

---

FASE 29 — Comparación Temporal y Re-testing

T-224: Snapshots de cobertura

Objetivo: Crear snapshots periódicos del estado de cobertura para poder comparar en el tiempo y medir progreso.

Archivo a crear: backend/app/models/coverage_snapshot.py

Campos:

Campo	Tipo	Restricciones
id	UUID	PK, default uuid4
name	String	nullable (ej: "Pre-remediación Q1")
snapshot_data	JSONB	not null (estado completo de todas las técnicas)
organization_score	Float	not null
total_techniques	Integer	not null
validated_count	Integer	not null
partial_count	Integer	not null
not_covered_count	Integer	not null
created_by	UUID	FK → users.id, nullable
created_at	DateTime	default utcnow

Servicio backend/app/services/snapshot_service.py:

• create_snapshot(db, name, user) — captura estado actual
• compare_snapshots(db, snapshot_a_id, snapshot_b_id) — retorna diff
• Auto-crear snapshot semanal (job APScheduler)

Endpoints:

Método	Ruta	Auth	Descripción
GET	/snapshots	autenticado	Listar snapshots
POST	/snapshots	red_lead, blue_lead, admin	Crear snapshot manual
GET	/snapshots/{id}	autenticado	Detalle de un snapshot
GET	/snapshots/compare	autenticado	Comparar dos snapshots (query params)

Validación:

• Crear snapshot captura el estado actual correctamente
• Comparar dos snapshots muestra técnicas que cambiaron
• El job semanal crea snapshots automáticamente
• La comparación incluye: técnicas mejoradas, empeoradas, sin cambio

---

T-225: UI de comparación temporal

Archivo a crear: frontend/src/pages/ComparisonPage.tsx

Contenido:

• Selector de dos snapshots (date pickers o dropdown)
• Side-by-side: scores globales de cada snapshot
• Diff table: técnicas que cambiaron de estado (mejoraron/empeoraron)
• Heatmap diff: mini-matriz con colores verde (mejoró), rojo (empeoró), gris (sin cambio)
• Métricas delta: cuántas técnicas se mejoraron, % de progreso

Ruta: /comparison — accesible desde el dashboard ejecutivo.

Validación:

• Se pueden seleccionar dos snapshots
• La comparación muestra las diferencias correctamente
• El heatmap diff se renderiza
• Las métricas delta son correctas

---

T-226: Sistema de re-testing automático

Objetivo: Cuando un test se marca con remediación completada, crear automáticamente un re-test para verificar que la remediación fue efectiva, inspirado en cómo Validato permite re-testing inmediato.

Archivos a modificar:

• backend/app/services/test_workflow_service.py
• backend/app/models/test.py — añadir campo retest_of (FK a test original)

Nuevo campo en Test:

Campo	Tipo	Restricciones
retest_of	UUID	FK → tests.id, nullable
retest_count	Integer	default 0

Lógica:

1. Cuando remediation_status cambia a completed:
   • Auto-crear un nuevo test con los mismos datos del original
   • Marcar como retest_of = original_test_id
   • Incrementar retest_count
   • Estado: draft — listo para que Red Team lo ejecute de nuevo
2. Notificar al creador del test original y al red_tech asignado
3. En la UI del test, mostrar link al test original y al retest

Validación:

• Completar remediación crea automáticamente un retest
• El retest tiene retest_of apuntando al original
• El retest tiene los mismos datos base que el original
• Se genera notificación del retest
• En la UI se muestra la cadena de retests

---

FASE 30 — Scheduling y Automatización

T-227: Sistema de scheduling de campañas

Objetivo: Permitir programar campañas para ejecución periódica, de manera que los tests se puedan re-ejecutar automáticamente.

Archivos a crear/modificar:

• backend/app/models/campaign.py — nuevos campos de scheduling
• backend/app/services/campaign_scheduler_service.py

Nuevos campos en Campaign:

Campo	Tipo	Restricciones
is_recurring	Boolean	default False
recurrence_pattern	String	nullable (weekly, monthly, quarterly)
next_run_at	DateTime	nullable
last_run_at	DateTime	nullable

Servicio de scheduling:

• Job APScheduler que revisa campañas recurrentes diariamente
• Si next_run_at <= now y is_recurring = True:
  • Clonar los tests de la campaña con nuevos IDs
  • Crear nueva instancia de campaña con los tests clonados
  • Actualizar last_run_at y calcular next_run_at
• Notificar a los equipos de la nueva ejecución

Endpoints:

PATCH /campaigns/{id}/schedule — configurar recurrencia
GET   /campaigns/{id}/history  — historial de ejecuciones

Validación:

• Se puede configurar una campaña como recurrente
• El job crea instancias nuevas según el patrón
• Los tests se clonan correctamente
• El historial muestra todas las ejecuciones
• Las notificaciones se generan

---

T-228: UI de scheduling

Modificar: frontend/src/pages/CampaignDetailPage.tsx

Nuevas funcionalidades:

• Toggle "Recurring Campaign" con selector de frecuencia
• Indicador de próxima ejecución programada
• Tab "Execution History" con tabla de ejecuciones pasadas
• Cada ejecución con: fecha, nº tests, progreso, score obtenido

Validación:

• El toggle de recurrencia funciona
• Se puede seleccionar la frecuencia
• La próxima ejecución se muestra
• El historial lista ejecuciones pasadas

---

FASE 31 — Tests Automatizados V3

T-229: Tests de importación de fuentes

Archivo a crear: backend/tests/test_data_sources.py

Tests:

class TestDataSources:
    def test_sigma_import():
        """Verificar importación de reglas Sigma"""

    def test_lolbas_import():
        """Verificar importación de LOLBAS"""

    def test_caldera_import():
        """Verificar importación de CALDERA abilities"""

    def test_elastic_rules_import():
        """Verificar importación de Elastic rules"""

    def test_d3fend_import():
        """Verificar importación de D3FEND"""

    def test_threat_actor_import():
        """Verificar importación de threat actors"""

    def test_no_duplicates_on_reimport():
        """Verificar que ninguna fuente duplica al re-importar"""

Validación:

• Todos los tests pasan
• Cada importación se verifica independientemente

---

T-230: Tests de scoring y métricas

Archivo a crear: backend/tests/test_scoring.py

Tests:

class TestScoring:
    def test_technique_score_calculation():
        """Score de técnica con diferentes combinaciones"""

    def test_threat_actor_coverage():
        """Cobertura contra un threat actor"""

    def test_organization_score():
        """Score global de la organización"""

    def test_mttd_calculation():
        """MTTD se calcula desde timestamps"""

    def test_detection_efficacy():
        """Detection efficacy con datos de prueba"""

    def test_compliance_status():
        """Estado de compliance con datos de prueba"""

Validación:

• Todos los tests pasan
• Los cálculos son correctos con datos conocidos

---

T-231: Tests de campañas y threat actors

Archivo a crear: backend/tests/test_campaigns.py

Tests:

class TestCampaigns:
    def test_create_campaign():
        """CRUD básico de campaña"""

    def test_campaign_progress():
        """Progreso se calcula según estado de tests"""

    def test_generate_from_threat_actor():
        """Generación automática de campaña desde actor"""

    def test_campaign_scheduling():
        """Recurrencia de campañas"""

    def test_campaign_cloning():
        """Clonación de tests al re-ejecutar"""

Validación:

• Todos los tests pasan
• El flujo completo de campañas funciona

---

FASE 32 — Pulido Final V3

T-232: Actualizar navegación completa

Objetivo: Integrar todas las nuevas páginas en la navegación.

Archivos a modificar:

• frontend/src/App.tsx
• frontend/src/components/Sidebar.tsx

Sidebar actualizado:

📊 Dashboard
📊 Executive Dashboard (leads + admin)
🔲 ATT&CK Matrix (heatmap avanzado)
🧪 Tests
  ├─ All Tests
  ├─ My Pending Tasks
  └─ Test Catalog
📋 Campaigns
👤 Threat Actors
📜 Compliance
📈 Comparison
📄 Reports
⚙️ System (admin)
  ├─ Data Sources
  ├─ MITRE Sync
  ├─ Users
  └─ Audit Log

Validación:

• Todas las rutas funcionan
• El sidebar muestra items según rol
• La navegación es consistente
• No hay rutas rotas

---

T-233: Optimización de rendimiento

Objetivo: Asegurar que la plataforma rinde bien con volúmenes grandes de datos (3000+ técnicas, 5000+ templates, 10000+ detection rules).

Optimizaciones backend:

• Índices en BD para campos de filtro frecuente (mitre_technique_id, source, state, tactic)
• Paginación cursor-based en listados grandes
• Caché de métricas y scores (redis o in-memory con TTL)
• Queries optimizadas con selectinload / subqueryload donde sea necesario

Optimizaciones frontend:

• Virtualización de tablas/listas grandes (react-window o tanstack-virtual)
• Lazy loading de páginas (React.lazy + Suspense)
• Memoización de componentes pesados (heatmap, charts)
• Debounce en buscadores

Validación:

• El heatmap con 3000+ técnicas renderiza sin lag
• Las tablas con 5000+ filas scrollean suavemente
• Los endpoints responden en < 500ms con volúmenes grandes
• El dashboard ejecutivo carga en < 3 segundos

---

T-234: Documentación completa V3

Archivos a modificar:

• README.md
• docs/API.md
• Nuevo: docs/ARCHITECTURE.md
• Nuevo: docs/DATA_SOURCES.md

README actualizado:

• Descripción completa de todas las funcionalidades V3
• Diagrama de arquitectura
• Guía de inicio rápido
• Cómo importar datos de todas las fuentes
• Cómo configurar campañas y threat actors
• Cómo generar reportes de compliance

ARCHITECTURE.md:

• Diagrama de la base de datos completa
• Flujo de datos entre servicios
• Descripción de cada servicio y su responsabilidad

DATA_SOURCES.md:

• Lista de todas las fuentes de datos soportadas
• Cómo configurar cada fuente
• Frecuencia de actualización recomendada
• Troubleshooting de importaciones

Validación:

• Un nuevo desarrollador puede entender la arquitectura leyendo ARCHITECTURE.md
• DATA_SOURCES.md cubre todas las fuentes con instrucciones claras
• El README refleja todas las funcionalidades V3
• Swagger UI muestra todos los endpoints

---

Resumen de Fases V3

Fase	Tareas	Descripción
21	T-200 a T-205	Fuentes de tests múltiples: importación y unificación
22	T-206 a T-208	Perfiles de amenaza (Threat Actor Profiles)
23	T-209 a T-210	MITRE D3FEND: contramedidas defensivas
24	T-211 a T-212	Reglas de detección sugeridas por test
25	T-213 a T-215	Campañas de tests (attack chains / kill chain)
26	T-216 a T-217	Heatmap ATT&CK avanzado (estilo Navigator)
27	T-218 a T-220	Scoring y métricas avanzadas (MTTD, MTTR, etc.)
28	T-221 a T-223	Compliance y reportes (NIST, DORA, NIS2, ISO 27001)
29	T-224 a T-226	Comparación temporal y re-testing automático
30	T-227 a T-228	Scheduling y automatización de campañas
31	T-229 a T-231	Tests automatizados V3
32	T-232 a T-234	Pulido final y documentación V3

Total: 35 tareas = 35 commits mínimo Cada tarea es autocontenida y verificable antes de hacer commit.

---

Análisis Competitivo: Qué Copiamos de Cada Plataforma

De Validato

• Step-by-step remediation: Campo de remediación con pasos concretos (V2: T-129)
• Mapeo a MITRE SHIELD/D3FEND: Contramedidas defensivas (V3: T-209)
• Re-testing post-remediación: Verificar que la fix funciona (V3: T-226)
• Validación continua: Campañas recurrentes (V3: T-227)
• Resultados mapeados a frameworks: Compliance reporting (V3: T-221)

De Cymulate

• Full kill chain campaigns: Cadenas de tests simulando ataques completos (V3: T-213)
• Auto-generated Sigma/EDR rules: Reglas de detección sugeridas por test (V3: T-211)
• Vendor-specific remediation: Guías de remediación específicas por herramienta (V3: T-129 mejorado)
• 100,000+ attack scenarios: Múltiples fuentes de tests (V3: T-200-204)
• Daily threat updates: Sync automático de fuentes (V3: T-205)
• Detection heatmap: Heatmap de cobertura de detección (V3: T-216)
• AI Template Creator: Generación de campañas desde threat actors (V3: T-214)

De Picus Security

• Detection Rule Validation: Validar si las reglas SIEM detectan realmente (V3: T-212)
• Threat library 10,000+: Catálogo masivo de tests de múltiples fuentes (V3: T-200-204)
• Filter by geography/industry: Filtros de threat actors por sector/región (V3: T-208)
• 150+ APT scenarios: Emulación de grupos específicos (V3: T-206)
• Campaign builder: Constructor de campañas desde APT profiles (V3: T-214)
• Multi-framework compliance: NIST, DORA, HIPAA, ISO (V3: T-221)

De AttackIQ

• Assessment templates: Templates pre-construidos por escenario (V2: T-103, V3: expandido)
• MITRE ATT&CK Navigator integration: Export de layers (V3: T-216)
• Continuous testing: Campañas recurrentes programadas (V3: T-227)
• Purple team collaboration: Flujo Red/Blue con feedback en tiempo real (V2: core feature)
• Detection pipeline validation: Verificar toda la cadena de detección (V3: T-212)
• Contextual risk prioritization: Scoring basado en criticidad real (V3: T-218)

Fuentes Open-Source Únicas de Aegis

• Atomic Red Team: 1,500+ tests atómicos (V2: T-107)
• SigmaHQ: 3,000+ reglas de detección (V3: T-201)
• LOLBAS + GTFOBins: 750+ técnicas living-off-the-land (V3: T-202)
• MITRE CALDERA: 400+ abilities ejecutables (V3: T-203)
• Elastic Detection Rules: 1,000+ reglas KQL (V3: T-204)
• MITRE D3FEND: 200+ contramedidas defensivas (V3: T-209)
• Adversary Emulation Library: 15+ planes de emulación APT (V3: T-203)

Lo que Aegis NO tiene (y las plataformas enterprise sí):

Estas son funcionalidades que requieren infraestructura de agentes/endpoints y quedan fuera del scope de Aegis como plataforma de gestión:

1. Ejecución automática de ataques en endpoints (requiere agentes instalados)
2. Integración directa con SIEMs (Splunk, Elastic, QRadar) para verificar alertas en tiempo real
3. Integración con EDR (CrowdStrike, SentinelOne) para verificar detección automática
4. Sandbox de ejecución segura (entorno aislado para ejecutar payloads)
5. API de ejecución remota (ejecutar tests automáticamente en hosts)

Aegis se posiciona como plataforma de gestión y tracking del proceso de validación, no como herramienta de ejecución automática. Los equipos ejecutan manualmente (o con sus propias herramientas) y documentan resultados en Aegis.