1476 lines
62 KiB
Markdown
1476 lines
62 KiB
Markdown
# 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](https://validato.io/), [Cymulate](https://cymulate.com/),
|
|
> [Picus Security](https://www.picussecurity.com/), [AttackIQ](https://www.attackiq.com/),
|
|
> 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](https://github.com/redcanaryco/atomic-red-team) |
|
|
| **MITRE CALDERA** | Abilities (acciones) ejecutables por agente | YAML | 400+ | [GitHub](https://github.com/mitre/caldera) |
|
|
| **Adversary Emulation Library** | Planes completos de emulación de APTs (APT29, FIN6, etc.) | YAML/JSON/PDF | 15+ planes | [GitHub](https://github.com/center-for-threat-informed-defense/adversary_emulation_library) |
|
|
| **LOLBAS** | Binarios legítimos de Windows que pueden ser abusados | YAML/JSON | 400+ | [GitHub](https://github.com/LOLBAS-Project/LOLBAS) |
|
|
| **GTFOBins** | Binarios legítimos de Unix/Linux que pueden ser abusados | Markdown/JSON | 350+ | [GitHub](https://gtfobins.github.io/) |
|
|
| **MITRE ATT&CK Procedures** | Procedimientos documentados en la propia framework | STIX/JSON | 1,000+ | [TAXII Server](https://cti-taxii.mitre.org/) |
|
|
|
|
### 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](https://github.com/SigmaHQ/sigma) |
|
|
| **Elastic Detection Rules** | Reglas de detección de Elastic SIEM (KQL) | TOML | 1,000+ | [GitHub](https://github.com/elastic/detection-rules) |
|
|
| **MITRE D3FEND** | Framework de contramedidas defensivas mapeado a ATT&CK | OWL/JSON | 200+ técnicas | [d3fend.mitre.org](https://d3fend.mitre.org/) |
|
|
| **Splunk Security Content** | Reglas de detección para Splunk | YAML | 1,500+ | [GitHub](https://github.com/splunk/security_content) |
|
|
|
|
### 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](https://github.com/mitre/cti) |
|
|
| **MISP** | Plataforma de compartición de threat intelligence | JSON | [misp-project.org](https://www.misp-project.org/) |
|
|
| **MITRE ATT&CK Groups** | Perfiles de 140+ grupos APT con sus TTPs | STIX | [attack.mitre.org/groups](https://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):**
|
|
|
|
```json
|
|
{
|
|
"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:**
|
|
|
|
```python
|
|
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:**
|
|
|
|
```python
|
|
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:**
|
|
|
|
```python
|
|
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:**
|
|
|
|
```python
|
|
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:**
|
|
|
|
```python
|
|
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:**
|
|
|
|
```python
|
|
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](https://validato.io/)
|
|
- **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](https://cymulate.com/)
|
|
- **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](https://www.picussecurity.com/)
|
|
- **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](https://www.attackiq.com/)
|
|
- **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.
|