# MacLockdown — Registro de Arquitectura y Cambios

**Versión estable:** 0.8.1  
**Fecha:** 2026-03-17  
**Estado:** ✅ Packaging comercial en producto · `P1/P2/P3` visibles · `P4` iniciado en UI y export · delta reporting activo · CTI priorizado · privilegios/fixes validados · Tahoe 26.3 calibrado · export con timestamps únicos

---

## Resumen ejecutivo

Esta iteración no cambió la base técnica del motor de checks, pero sí cambió de forma importante cómo el producto se presenta, cómo explica valor y cómo convierte estrategia en UX real.

Los cambios estructurales de esta versión son:

1. El modelo comercial `Basic / Professional / Compliance` ya está implementado en la UI, no solo documentado.
2. La narrativa de `continuous security posture` dejó de ser solo claim y pasó a expresarse con evolución visible entre scans.
3. `Compliance` dejó de sentirse como “compare + export” y pasó a mostrar tracking y delta real en `Compare` y en reportes.
4. CTI / MITRE dejó de vivir escondido en el detalle de cada check y pasó a ser un elemento visible en `Attack Surface`, upgrade flows y export.
5. `Attack Surface` ya no solo muestra exposición por vector; ahora también prioriza técnicas reales por criticidad y relevancia operacional.
6. El flujo de fixes privilegiados ya fue validado manualmente con batching y una sola elevación efectiva en un caso real (`firewall` / `stealth mode`).
7. El repo ya tiene higiene básica para evitar versionar logs, productos generados y metadata local.
8. Los exports ya no colisionan si se generan varias veces dentro del mismo minuto.
9. `P4` ya comenzó: la app y los reportes ahora muestran remediación guiada por técnica con `impact preview`.
10. La validación manual en `Tahoe 26.3` ya cerró los falsos negativos más relevantes y dejó solo `2` checks estructuralmente `unverified`.

La app sigue siendo local-first, single-device y data-driven, pero esta versión la mueve desde “herramienta de hardening” hacia “producto de postura de seguridad con remediación y evidencia”.

---

## Métricas del producto (v0.8.1)

| Métrica | Valor |
|---|---|
| Controles auditados | 39 |
| Perfiles técnicos | Basic (9) · Hardened (36) · Paranoid (39) |
| Planes comerciales visibles | Basic · Professional · Compliance |
| Frameworks visibles | CIS · NIST · Apple · PCI DSS |
| Compare | CIS + PCI DSS + delta visible |
| Export | Markdown + PDF + evolución desde scan anterior + remediación guiada por técnica |
| CTI visible | Attack Surface + ranking + report + upgrade copy + guided remediation |
| Persistencia extra | `ScanRecord.profile` + `UpsellEvent[]` |
| Estado de privilegios | On-demand + fixes privilegiados agrupados + verificación post-fix integrada |
| Estado de validación Tahoe | calibrado manualmente; `2` checks aún `unverified` |

---

## 1. Product Packaging en UI

### Objetivo alcanzado

La estrategia comercial ya no vive solo en documentos bajo `Changes/`. Ahora se refleja directamente en la app.

### Implementación

En `ContentView.swift` se introdujo un gating comercial explícito:

- `Attack Surface` bloqueado en beta apunta a `Professional`
- `Compare` bloqueado en beta apunta a `Compliance`
- `Export PDF` en beta apunta a `Compliance`
- `Fix` y `Apply All Fixes` en beta apuntan a `Professional`

### Upgrade flow

Se formalizaron dos conceptos de UI:

```text
UpgradeDestination
├── professional
└── compliance

UpgradeTrigger
├── attackSurface
├── compare
├── fix
├── fixAll
└── exportPDF
```

Esto permite que el mismo `UpgradeSheet` cambie su copy según destino y motivo real de bloqueo.

### Persistencia comercial

`PersistenceEngine.swift` ahora guarda eventos de upsell:

```text
UpsellEvent
├── destination
├── trigger
└── date
```

Eso deja trazabilidad local de intención de upgrade sin agregar aún analítica remota.

---

## 2. P1 — Continuous Posture visible

### Problema resuelto

La narrativa decía `continuous security posture`, pero la UI todavía se percibía como snapshot.

### Implementación

`SecurityViewModel.swift` ahora calcula respecto del scan anterior del mismo perfil:

- `scoreDelta`
- `improvedControlsCount`
- `regressedControlsCount`
- `postureStatus`
- `previousScore`

Además, se agregó baseline de comparación por sesión:

- `comparisonBaselineRecord`
- `hasCompletedSessionScan`

Eso evita falsos mensajes heredados al reabrir la app antes de completar el scan actual.

### UI resultante

En `ContentView.swift` ahora aparecen:

- `stable / improving / degrading`
- `Since last scan: ±X score · Y improved · Z regressed`
- `before X → after Y`
- mensaje de postura con tensión útil cuando hay regresión

### Persistencia necesaria

`ScanRecord` ahora guarda `profile`, para que el historial y la comparación no mezclen scans de perfiles distintos.

---

## 3. P2 — Compliance Delta Reporting

### Problema resuelto

`Compliance` podía seguir percibiéndose como export bonito o compare estático.

### Compare

La vista `Compare` ahora muestra evolución:

#### CIS

- trend card para `CIS Level 1`
- trend card para `CIS Level 2`
- score delta por benchmark
- improved / regressed / new risks

#### PCI DSS

Se añadió un bloque explícito de continuidad:

`Track, evolve, prove over time`

Incluye:

- delta
- regressed
- improved
- new risks
- trend label

### Export

`ReportEngine.swift` ahora recibe `previousRecord` y genera:

- `Posture evolution since last scan`
- `score delta`
- `risk trend`
- `new risks introduced`
- `controls regressed`
- `controls improved`

Esto aplica tanto a Markdown como a PDF.

### Resultado de producto

`Compliance` ya no comunica solo evidencia estática. Ahora empieza a comunicar seguimiento real.

---

## 4. P3 — CTI / MITRE visible

### Problema resuelto

La app ya tenía mapeo MITRE/CTI, pero seguía siendo invisible para la mayor parte de la experiencia.

### Attack Surface

`ContentView.swift` ahora hace visible CTI en dos niveles:

#### Barra superior del panel

Nuevo bloque:

`Top Exposed Technique`

Muestra:

- `TTP ID`
- técnica
- táctica
- cantidad de controles afectados
- cantidad de grupos asociados

#### Cada vector de ataque

`AttackVectorCard` ahora puede mostrar:

- técnica principal del vector
- mensaje de exposición a ataque real
- grupos asociados en el expandido

#### Segunda capa de `P3`

`AttackSurface.swift` ya expone un modelo más rico:

```text
AttackSurfaceAnalysis
├── vectors
└── rankedTechniques

ThreatTechniqueExposure
├── ttpId
├── affectedChecks
├── affectedVectors
├── groups
├── score
└── priority
```

La UI usa eso para mostrar:

- `Top Exposed Technique`
- `Technique Priority`
- top 3 técnicas ordenadas por checks expuestos, vectores afectados, grupos y peso acumulado
- prioridad legible:
  - `observe`
  - `elevated`
  - `urgent`
  - `critical`

### Upgrade copy

`UpgradeSheet` refuerza el valor CTI:

- `Attack Surface` habla de técnicas reales habilitadas por la configuración actual
- `Professional` añade “See which attack techniques your current configuration enables”
- `Compliance` añade “Link posture to real-world techniques and threat actors”

### Reportes

La sección de `THREAT ACTORS` en `ReportEngine.swift` ahora añade una explicación más explícita:

> los gaps no son solo issues de configuración; mapean a técnicas reales usadas en ataques sobre macOS

---

## 5. P4 — CTI-Guided Remediation iniciado

### Objetivo ya aterrizado

`P4` dejó de ser solo backlog y ya entró en producto.

La primera implementación conecta:

- técnica priorizada
- controles vinculados
- fix dirigido
- vista previa de impacto

### Attack Surface

En `ContentView.swift`:

- `Top Exposed Technique` ahora incluye una card de `Guided Remediation`
- muestra:
  - `Expected impact`
  - `Restored controls`
  - `Techniques reduced`
- lista controles vinculados a esa técnica
- añade CTA:
  - `FIX LINKED CONTROLS`

Además, `Technique Priority` ya no es solo ranking:

- excluye la técnica top para evitar duplicidad
- cada fila puede expandirse
- al expandirse muestra:
  - `impact preview`
  - controles vinculados
  - CTA `FIX`

Esto convierte `Attack Surface` en algo más cercano a:

`insight -> decision -> remediation`

### ViewModel

En `SecurityViewModel.swift` se añadió remediación dirigida por lista de checks:

- `applyFixes(for checkIDs:)`

Eso permite que la UI dispare fixes por técnica, no solo por control individual o `fix all`.

### Modelo CTI

En `AttackSurface.swift`, `ThreatTechniqueExposure` ahora expone:

- `affectedCheckIDs`

Ese dato hace posible conectar técnica -> checks -> acción sin duplicar lookup ad hoc en la UI.

### Export

En `ReportEngine.swift` se añadió una nueva sección:

`Guided Remediation by Technique`

Incluye, para las técnicas priorizadas:

- prioridad
- razón de prioridad
- `expected impact`
- `techniques reduced`
- `restored controls`
- controles vinculados

Con esto, `P4` ya no vive solo dentro de la app; también queda reflejado en evidencia exportable.

### Estado real

`P4` no está completamente cerrado todavía.

Sí quedó implementado:

- técnica -> controles vinculados
- técnica -> impacto esperado
- técnica -> CTA de remediación
- export con remediación guiada

Queda para siguiente fase profundizar:

- tendencia histórica por técnica
- alerting por técnica
- sugerencia más explícita de remediación posterior a la acción

---

## 6. Fricción de privilegios

### Mejora implementada

Se redujo la fricción de prompts agrupando fixes privilegiados en batch durante `Apply All Fixes` y evitando lecturas privilegiadas durante scans background.

Además:

- `FixEngine` ahora puede aplicar y verificar fixes privilegiados en el mismo flujo
- `SecurityViewModel` reutiliza ese resultado sin depender siempre de un recheck separado
- `ScanEngine` expone interpretación reutilizable para output ya capturado

Eso reduce fricción y baja la probabilidad de terminar en `unknown` después de un fix privilegiado exitoso.

### Validación manual

Se validó manualmente un caso real:

- inicio con `firewall` deshabilitado
- scan inicial sucio
- fix aplicado
- una sola solicitud de contraseña
- score `93 → 100`
- controles recuperados:
  - `Firewall`
  - `Stealth Mode`

Esto quedó reflejado también en reportes reales exportados durante la prueba.

### Estado actual

La UX es mejor, pero la solución sigue basada en AppleScript y no en un helper privilegiado formal del sistema.

### Decisión

Esto quedó documentado como backlog técnico en `EXECUTION_PRIORITIES_v01.md`, y no bloquea esta versión.

Backlog futuro:

- `Authorization Services`
- helper tool firmado
- `secure execution layer`
- `trusted fix engine`

Diseño técnico de referencia:

- `PRIVILEGED_HELPER_ARCHITECTURE_v01.md`

No forma parte de esta entrega.

---

## 7. Validación Tahoe 26.3

### Objetivo

Cerrar la calibración real de los `39` checks actuales contra una máquina de referencia en `macOS Tahoe 26.3`.

### Resultado

La validación manual dejó confirmado que la mayor parte del set actual ya está correctamente alineado con la evidencia del sistema.

Checks confirmados con evidencia manual:

- `secure_token`
- `auto_login`
- `firewall`
- `stealth_mode`
- `airdrop`
- `wake_on_network`
- `audit_logging`
- `bonjour_advertising`
- `screensaver_timeout`
- `bluetooth_sharing`
- `diagnostics_sharing`
- `remote_login`
- `printer_sharing`
- `guest_user`
- `media_sharing`
- `xprotect`
- `mrt`
- `rapid_security_response`
- `disable_captive_portal`
- `screen_lock`
- `sudo_timeout`
- `sip`
- `gatekeeper`
- `auto_updates`
- `filevault`

Checks informativos que siguen siendo útiles, pero no justifican más calibración crítica en esta fase:

- `login_items_audit`
- `wifi_autojoin`
- `location_services`
- `icloud_drive`
- `lockdown_mode`

### Ajustes aplicados

Durante esta validación se corrigieron dos puntos concretos:

1. `remote_management`
   - `ScanEngine.swift` ya no trata como activo un `LaunchAgent` presente pero inactivo
   - si `launchctl print` devuelve `state = not running` o `runs = 0`, el check ahora interpreta `PASS`

2. `sudo_timeout`
   - `checks.json` ya no usa `sudo` para el `checkCommand`
   - eso evita que el scan background lo degrade a `unknown` innecesariamente

### Estado final en Tahoe

Después de la calibración, la app queda en un estado más estable:

- score `100/100` posible sin falsos `unknown` relevantes
- `remote_management` deja de caer como falso negativo
- `sudo_timeout` deja de aparecer como `unverified`

Persisten `2` checks estructuralmente `unverified` en esta versión:

- `Safari Suggestions disabled`
- `TCP timestamps disabled`

La razón no es una falla confirmada del sistema, sino falta de evidencia consistente en `Tahoe 26.3` con los comandos actuales.

La decisión correcta para esta entrega es mantenerlos como:

- `unknown`

en lugar de forzar un `FAIL` o introducir heurísticas débiles.

---

## 8. Archivos más impactados en esta iteración

| Archivo | Cambio principal |
|---|---|
| `ContentView.swift` | Packaging comercial, compare delta, attack surface CTI, upgrade flow, remediación guiada por técnica |
| `SecurityViewModel.swift` | baseline por sesión, métricas de evolución, export con baseline, verificación post-fix, fixes dirigidos |
| `ReportEngine.swift` | postura evolutiva en Markdown/PDF, refuerzo CTI, remediación guiada en export, timestamps por segundo |
| `PersistenceEngine.swift` | `UpsellEvent`, `ScanRecord.profile` |
| `AttackSurface.swift` | ranking de técnicas, prioridad, `affectedCheckIDs` y análisis reutilizable |
| `ScanEngine.swift` | calibración de `remote_management` para Tahoe; agente presente pero inactivo ya no implica `FAIL` |
| `checks.json` | `sudo_timeout` deja de depender de `sudo` en verificación background |
| `EXECUTION_PRIORITIES_v01.md` | backlog técnico del helper privilegiado |
| `NEXT_PHASE_PRIORITIES_v01.md` | backlog siguiente fase, ahora con `P4` parcialmente aterrizado |
| `.gitignore` | higiene básica de artefactos generados y metadata local |

---

## 9. Decisiones de producto ya consolidadas

- `Paranoid` sigue siendo modo técnico, no plan comercial
- `Professional` vende remediación
- `Compliance` vende evidencia + continuidad
- `Markdown` puede operar como export simple
- `PDF` queda más alineado con capa `Compliance`
- `continuous posture` ya tiene soporte visible en producto
- CTI deja de ser detalle técnico y pasa a ser parte del discurso de valor
- `Attack Surface` ya puede priorizar técnicas, no solo describir exposición
- CTI ya puede sugerir remediación con vista previa de impacto
- los fixes privilegiados ya no dependen únicamente de un recheck posterior

---

## 10. Riesgos aún abiertos

### 1. Continuidad todavía local

La narrativa de continuidad ya es visible, pero sigue siendo local-first y single-device. Eso es suficiente para esta fase, pero todavía no justifica usar `platform` públicamente.

### 2. Helper privilegiado pendiente

La reducción de prompts ya mejoró UX, pero no reemplaza una capa privilegiada formal y más robusta.

### 3. Delta sin alerting activo

La app ya muestra regressions y improvements, pero todavía no hace alertas proactivas ni monitoreo persistente.

### 4. Higiene histórica ya comprometida

La higiene futura del repo quedó resuelta con `.gitignore`, pero el historial anterior ya incluye exports y artefactos que no deberían seguir entrando en commits futuros.

### 5. Dos checks Tahoe siguen sin evidencia fuerte

`Safari Suggestions disabled` y `TCP timestamps disabled` todavía no exponen una fuente de evidencia consistente en `Tahoe 26.3`.

Mientras eso no cambie, es preferible conservarlos como `unknown` y no degradar artificialmente el score.

---

## 11. Estado de respaldo e higiene

Esta iteración ya quedó respaldada formalmente con:

- commit de release base
- tag de versión
- commit de higiene de repo
- commit adicional para segunda capa de `P3`
- commit adicional para timestamps por segundo en export

Además, el repo ahora ignora:

- `MacLockdown/Log/`
- `MacLockdown/Products/`
- `.DS_Store`
- artefactos locales de Xcode y build

---

## 12. Siguiente paso recomendado

Con `P1`, `P2`, una segunda capa de `P3` y una primera implementación real de `P4`, el siguiente bloque de valor ya no es packaging ni positioning, sino profundización funcional.

Prioridades razonables:

- profundizar `P4` con estado posterior a remediación y relación técnica -> resultado
- `P5` trend real sobre múltiples scans
- `P6` alerting o posture monitoring más activo
- helper privilegiado formal (`Authorization Services` / helper tool)

Nombre sugerido para continuidad documental:

`ARCHITECTURE_v11_RC1.md`

---

## 13. Decisión ejecutiva

Esta versión ya puede considerarse una transición real:

de

`macOS hardening utility`

a

`macOS security posture product with remediation and evidence`

Todavía no es una plataforma en sentido pleno, pero ya dejó de comportarse como una simple utilidad técnica.
