# Fases de implementación completas: panel de seguridad y optimización Windows 11

**Versión del documento:** 1.0  
**Documento complementario:** `01-ANALISIS-COMPLETO-PANEL-SEGURIDAD-OPTIMIZACION.md`

Este documento define **fases**, **entregables**, **criterios de aceptación**, **órdenes de desarrollo** y el **porqué** de cada decisión, para que el equipo (o un desarrollador solo) tenga una hoja de ruta ejecutable de principio a fin.

---

## Visión de conjunto del roadmap

```mermaid
flowchart LR
  subgraph f0 [Fase 0]
    A[Requisitos y entorno]
  end
  subgraph f1 [Fase 1]
    B[Repositorio y seguridad base]
  end
  subgraph f2 [Fase 2]
    C[Agente PS solo lectura]
  end
  subgraph f3 [Fase 3]
    D[API y persistencia]
  end
  subgraph f4 [Fase 4]
    E[Panel UI]
  end
  subgraph f5 [Fase 5]
    F[Informes y export]
  end
  subgraph f6 [Fase 6]
    G[Remediación scriptada]
  end
  subgraph f7 [Fase 7]
    H[Optimización guiada]
  end
  subgraph f8 [Fase 8]
    I[QA endurecimiento release]
  end
  subgraph f9 [Fase 9]
    J[Operación y roadmap v2]
  end
  f0 --> f1 --> f2 --> f3 --> f4 --> f5 --> f6 --> f7 --> f8 --> f9
```

**Por qué este orden:** primero **datos fiables** (agente + modelo), luego **visualización**, después **informes** (valor inmediato sin riesgo), y solo al final **cambios en el SO** y **optimización** (máximo riesgo operativo).

---

## Fase 0 — Aclaración de requisitos y entorno de despliegue

### Objetivo

Evitar retrabajo: fijar **modo de despliegue** (una máquina local vs flota), **identidad**, **retención** y **límites legales**.

### Actividades

1. **Modo A — Local single-host:** PHP + DB en la misma máquina que Windows 11; agente invoca API en `127.0.0.1`.
2. **Modo B — Centralizado:** servidor en LAN/VPN; N hosts con agente.
3. Definir **roles:** `viewer`, `auditor`, `operator`, `admin`.
4. Definir **PII** en logs (nombres de usuario, rutas home, SSIDs) y política de **anonimización** en export.
5. Elegir stack UI final (**SPA vs PHP+HTMX**) según capacidad del equipo.

### Entregables

- Documento **SRS** breve (10–20 páginas máx.): historias de usuario priorizadas.
- Matriz **RACI** de remediación (quién aprueba scripts).

### Criterios de aceptación

- Aprobación explícita del modo A o B por responsable.
- Lista priorizada de **plugins de colección** para v1 (máx. 8 categorías).

### Por qué

Sin esto, es común construir un panel «genial» que nadie puede desplegar de forma segura o que viola políticas internas.

---

## Fase 1 — Cimiento del repositorio, calidad y seguridad del propio producto

### Objetivo

Base de código **auditable**: estándares, CI, secretos, dependencias.

### Actividades

1. Estructura de carpetas sugerida:

   ```
   /agent          # PowerShell module + tests Pester
   /api            # PHP backend
   /web            # Frontend SPA o vistas PHP
   /docs           # Documentación
   /schemas        # JSON Schema de findings y payloads
   ```

2. **Composer** + **PHPStan/Psalm** (nivel acordado), **PHPCS**, tests PHPUnit mínimos.
3. **Pester** para el agente PowerShell.
4. **Git hooks** o CI: secret scanning (GitGuardian/gitleaks o equivalente).
5. **.env.example** sin credenciales reales; documentar rotación de claves.

### Entregables

- Pipeline CI (GitHub Actions / otro) con lint + tests.
- Política de **versionado semántico** del agente y del API (`/v1`).

### Criterios de aceptación

- CI en verde en `main`.
- Ningún secreto en historial reciente.

### Por qué

Un panel de seguridad que es vulnerable **destruye la confianza** y se convierte en vector de ataque.

---

## Fase 2 — Agente PowerShell: colección solo lectura (el núcleo)

### Objetivo

Obtener **JSON validado** contra `schemas/findings.json` (o similar) desde Windows 11.

### Actividades

1. Crear módulo `SecurityOpsAgent` con comandos:
   - `Invoke-SecurityInventory -Profile Quick|Standard|Deep`
   - `Export-SecurityInventoryJson`
2. Implementar **plugins** v1 (mínimo viable profesional):

   | Plugin | Comando PS interno | Notas |
   |--------|--------------------|-------|
   | Services | CIM Win32_Service | Marcar `PathName`, `StartMode`, `State` |
   | ScheduledTasks | Get-ScheduledTask + Get-ScheduledTaskInfo | Filtrar por `Ready` y acciones |
   | Startup | Reg + shell:startup | Rutas y firmas si `Get-AuthenticodeSignature` no es demasiado lento |
   | LocalAdmins | Grupo Administrators | Miembros |
   | Defender | Get-MpComputerStatus, amenazas recientes | Requiere permisos |
   | ProcessesTop | Get-Process | CPU/WS ordenados |
   | NetworkSummary | Get-NetTCPConnection (top N) | Limitar y agrupar |
   | OS & patches | Get-ComputerInfo / hotfix | Versión build |

3. **Normalización:** cada plugin devuelve array de `Finding` con IDs estables (`svc:<name>`, `task:<path>`).
4. **Telemetría de ejecución:** duración por plugin, errores capturados sin tumbar el lote.
5. **Modo offline:** `Export-Clixml` o JSON a archivo para import manual en el panel (air-gapped).

### Entregables

- Paquete del módulo versionado (`SecurityOpsAgent.1.0.0.zip`) + `CHANGELOG.md`.
- Documentación de instalación: `Install-Module` o copia en `Program Files`.

### Criterios de aceptación

- `Invoke-SecurityInventory -Profile Quick` termina en < 60 s en máquina de prueba documentada.
- JSON valida contra esquema en CI (test de contrato).

### Por qué

Sin agente sólido, el panel es solo cosmética. El **contrato JSON** permite evolucionar backend y UI en paralelo.

---

## Fase 3 — API backend y persistencia

### Objetivo

Ingesta, autenticación, almacenamiento y consulta de inventarios.

### Actividades

1. Endpoints REST versionados:
   - `POST /v1/hosts/register` — alta de host + token.
   - `POST /v1/hosts/{id}/runs` — crea «run» de escaneo.
   - `POST /v1/runs/{runId}/findings` — carga masiva (chunked si > N MB).
   - `GET /v1/runs/{runId}` — estado y metadata.
   - `GET /v1/findings?runId=&severity=` — listado paginado.
2. **Autenticación:**
   - Usuarios del panel: sesión PHP + password hash **Argon2id** (o framework equivalente).
   - Agente: token largo + **HMAC** del cuerpo con timestamp anti-replay.
3. **Modelo relacional mínimo:**

   - `hosts`, `users`, `runs`, `findings`, `scripts` (plantillas generadas), `audit_log`.

4. **Idempotencia:** reenvío de chunk no duplica hallazgos (clave `run_id` + `finding_id`).

### Entregables

- OpenAPI/Swagger publicado en `/docs/openapi.yaml`.
- Migraciones de base de datos versionadas.

### Criterios de aceptación

- Pruebas de integración: registro → subida → consulta.
- Prueba de **rate limit** y rechazo de token inválido.

### Por qué

La API es el **contrato de confianza** entre agente y operadores; debe ser estricta y observable.

---

## Fase 4 — Panel web (UI/UX profesional)

### Objetivo

Experiencia usable para **auditoría diaria** y **briefing** a no técnicos.

### Actividades

1. **Design system:** tipografía, colores por severidad, modo oscuro, accesibilidad teclado.
2. Pantallas definidas en el análisis (dashboard, inventario, detalle, comparador, admin).
3. **Estados vacíos** y **errores** claros (agente desconectado, run fallido).
4. Internacionalización: **es-ES** primero; preparar i18n si hay intención multi-idioma.

### Entregables

- Storybook o equivalente (si SPA) para componentes críticos.
- Guía de usuario en PDF corto (opcional fase 5).

### Criterios de aceptación

- Lighthouse accesibilidad > 90 en vistas principales (objetivo orientativo).
- Flujo completo sin consola del navegador para errores no controlados.

### Por qué

Si la UI falla, los hallazgos no se **accionan**; el producto muere por adopción.

---

## Fase 5 — Informes y exportación

### Objetivo

Salida **para archivo**, **compliance** y **comparación histórica**.

### Actividades

1. Export **JSON** (run completo), **CSV** (tabla plana), **HTML** autocontenido con gráficos estáticos.
2. **PDF** opcional (fase posterior si complica despliegue).
3. **Marca de agua** y **hash SHA-256** del JSON en portada del informe.
4. Comparador servidor-side: diff de `finding_id` entre dos runs.

### Entregables

- Plantilla HTML oficial del informe.
- Job asíncrono para informes grandes (cola).

### Criterios de aceptación

- Mismo run genera mismo hash (determinismo de ordenación documentado).

### Por qué

Los informes son el **entregable** que justifica el proyecto ante terceros (cliente, IT manager).

---

## Fase 6 — Remediación asistida (scripts y rollback)

### Objetivo

Convertir hallazgos en **acciones revisables**, nunca silenciosas.

### Actividades

1. Motor de **plantillas** Mustache/Blade para generar `.ps1` por tipo de hallazgo (ej. deshabilitar tarea no Microsoft marcada por el usuario).
2. Flujo UI:
   - Usuario selecciona hallazgos → «Generar paquete de remediación» → descarga ZIP con `README`, `rollback.ps1`, `apply.ps1`.
3. **Registro de auditoría:** quién generó, qué IDs, checksum.
4. (Opcional avanzado) **Ejecución remota firmada** vía agente con cola de «acciones aprobadas» — solo si hay demanda y hardening extra.

### Entregables

- Biblioteca inicial de **5–10** remediaciones seguras (bajo riesgo).
- Lista explícita de **hallazgos no remediables** automáticamente (documentación).

### Criterios de aceptación

- Ningún script se genera sin listar **comandos** y **reversión** en cabecera.
- Prueba en VM: apply + rollback sin dejar sistema inconsistente.

### Por qué

Aquí está el **riesgo máximo**; la lentitud y la fricción son **características**, no bugs.

---

## Fase 7 — Optimización guiada de Windows 11

### Objetivo

Mejorar rendimiento **sin** comprometer estabilidad; integrado con inventario.

### Actividades

1. **Cuestionario** de perfil de uso (oficina, dev, gaming, servidor ligero).
2. **Mapas de recomendación:** enlazan hallazgos (tareas de vendor X, apps de inicio Y) a acciones.
3. Integración con **Storage Sense** / limpieza de temporales vía script documentado (no borrar arbitrariamente `%UserProfile%`).
4. Sección **servicios:** solo educación + enlace a `services.msc` / export de lista; evitar toggles masivos en v1.

### Entregables

- «Playbooks» de optimización versionados (Markdown + scripts asociados).

### Criterios de aceptación

- Cada playbook tiene **prueba en VM** y sección **rollback**.

### Por qué

La optimización mal hecha genera **costes de soporte** superiores al beneficio.

---

## Fase 8 — QA de seguridad del producto, empaquetado y release

### Objetivo

Listo para uso en entorno real con **checklist de release**.

### Actividades

1. **OWASP ZAP** o Burp baseline contra el panel.
2. **Revisión de permisos** de archivos del agente y del servidor web.
3. **Empaquetado:** instalador del agente (MSI opcional) o script `Install-Agent.ps1` firmado.
4. **SBOM** de dependencias PHP/JS.
5. Política de **CVE** y ventana de parcheo.

### Entregables

- `SECURITY.md` con proceso de divulgación responsable.
- Release `v1.0.0` con notas.

### Criterios de aceptación

- Sin hallazgos críticos abiertos en escaneo acordado.
- Guía de despliegue probada en máquina limpia.

### Por qué

El «go-live» sin esto es **deuda de incidentes** esperando ocurrir.

---

## Fase 9 — Operación, métricas y roadmap v2

### Objetivo

Producto **vivo**: feedback, plugins nuevos, integraciones.

### Actividades

1. Tablero interno de **falsos positivos** por categoría.
2. Plugin **Eventos de seguridad** (muestreado).
3. Plugin **WMI persistence** (avanzado, documentado).
4. Integración import **Autoruns / Sigcheck** (archivo subido).
5. Sección **Cursor / VS Code:** export de checklist `settings.json`, `.cursor/rules`, recomendación de extensiones — sin modificar IDE sin confirmación.

### Entregables

- Roadmap público o interno por trimestre.

### Criterios de aceptación

- KPIs del análisis (tiempo de scan, satisfacción) medidos al menos 1 mes.

### Por qué

La madurez viene de **iteración** con datos reales, no de más toggles en la UI.

---

## Dependencias entre equipos / perfiles

| Fase | Perfil principal |
|------|------------------|
| 0 | Producto / seguridad / legal |
| 1 | DevOps / backend |
| 2 | SecOps + PowerShell |
| 3 | Backend |
| 4 | Frontend |
| 5 | Full-stack |
| 6 | SecOps + backend |
| 7 | Sistemas Windows |
| 8 | AppSec + QA |
| 9 | Producto + ingeniería |

---

## Estimación orientativa (orden de magnitud)

Los números dependen del modo SPA y del tamaño del equipo; útiles solo para planificación inicial.

| Fase | Duración relativa |
|------|-------------------|
| 0 | 3–7 días |
| 1 | 5–10 días |
| 2 | 15–25 días |
| 3 | 15–25 días |
| 4 | 20–35 días |
| 5 | 7–15 días |
| 6 | 15–25 días |
| 7 | 10–20 días |
| 8 | 10–20 días |
| 9 | continuo |

**En paralelo posible:** Fase 4 puede arrancar cuando Fase 3 tenga **mock API** alineado con el esquema JSON de Fase 2.

---

## Checklist final antes de declarar v1 «completa»

- [ ] Agente + API + UI funcionando en Modo A o B elegido.
- [ ] Informe HTML oficial reproducible.
- [ ] Al menos **50** tipos de hallazgo distintos mapeados y documentados.
- [ ] Remediaciones de bajo riesgo con rollback probado en VM.
- [ ] `SECURITY.md` y guía de despliegue publicados.
- [ ] Copia de seguridad de la base y procedimiento de restauración documentado.

---

*Fin del documento de fases de implementación.*