# Modelado de amenazas Toma un sistema tal como está construido y produce el modelo de cómo se puede atacar — para que el equipo responsable de él sepa qué defiende, con qué y qué sigue expuesto. ## Entregable Un documento Markdown, `threat-model.md`, con la estructura fijada en **Salida** más abajo. Es la entrada de **Revisión de seguridad de un cambio**, que contrasta el trabajo nuevo con las fronteras que este documento dibuja. ## Entradas obligatorias - **La arquitectura del sistema** — los componentes, los almacenes de datos, las posiciones de red y las llamadas entre ellos, desde la documentación, los diagramas o el propio código. - **Qué protege el sistema** — los datos y las capacidades que importan, nombrados por alguien que es dueño de ellos. - **La confirmación de que el sistema es tuyo para defenderlo** — esta habilidad modela un sistema del que quien la ejecuta es responsable. Sin esa confirmación no se ejecuta. Si falta cualquiera de las tres, detente y reporta qué falta. Nunca deduzcas qué protege un sistema de su esquema: una tabla muestra qué se guarda, no qué perdería la organización. ## Entradas opcionales - Topología de despliegue, segmentación de red y los entornos en los que corre el sistema - El diseño de autenticación y autorización, incluida la emisión de sesiones y tokens - Los controles de seguridad existentes y la evidencia de que cada uno funciona - Clasificaciones de datos, reglas de retención y obligaciones regulatorias - Incidentes pasados e informes de pruebas, con el estado de remediación de cada hallazgo - Servicios de terceros de los que depende el sistema y qué se confía a cada uno Cada entrada opcional que falte pasa a **Preguntas abiertas**. Todo control que no se haya podido comprobar se registra como `supuesto` en lugar de descartarse. ## Ejecución **1 — Listar los activos y lo que vale cada uno.** Por cada activo: qué es, dónde vive, quién es su dueño y qué pierde la organización si se divulga, se altera o deja de estar disponible. Un activo sin dueño con nombre se registra como `dueño desconocido`, porque un activo del que nadie es dueño es un activo que nadie defiende. **2 — Dibujar las fronteras de confianza.** Una frontera es cualquier punto donde los datos o el control pasan entre partes con distinto nivel de confianza — un borde de red, un borde de proceso, un borde entre inquilinos, un cambio de privilegio. Por cada frontera: qué la cruza, en qué dirección y qué se comprueba al pasar. **3 — Enumerar los puntos de entrada.** Toda vía por la que una entrada llega al sistema, incluidas las que casi nunca se listan: consolas de administración, trabajos programados que leen almacenamiento compartido, colas de mensajes, webhooks, subidas de archivos, herramientas de soporte y el camino de compilación y despliegue. Marca cada uno como `observado` si se encontró en el sistema, o `reportado` si lo afirmó una persona. **4 — Derivar las amenazas frontera por frontera.** En cada frontera recorre las categorías por turno — identidad afirmada en falso, datos alterados en tránsito o en reposo, una acción negada después, información divulgada, capacidad agotada, privilegio elevado. Una pasada sistemática encuentra la amenaza que nadie recordaba; una lluvia de ideas encuentra la que todos ya temen. **5 — Registrar los controles existentes y cómo lo sabes.** Por cada amenaza, el control que la atiende hoy, dónde vive ese control y si es `verificado` — lo ejercitaste o leíste el código que lo aplica — o `supuesto` — alguien dijo que estaba ahí. Un control marcado `supuesto` no es una mitigación; es una pregunta abierta con un nombre tranquilizador. **6 — Enunciar el riesgo residual y darle un responsable.** Por cada amenaza que sigue en pie tras sus controles: qué queda, cómo se notaría si ocurriera y quién es dueño de la decisión de aceptarlo o financiarlo. Un riesgo residual sin nadie detrás se reporta como sin dueño, nunca como aceptado. **7 — Reunir lo que no se pudo determinar.** Cada activo, frontera o control que el material no cerró, con lo que bloquea y quién puede responderlo. ## Salida `threat-model.md`, en este orden: - **1. Alcance y fecha** — qué sistema se modeló, con qué material, por quién y cuándo - **2. Activos** — una línea cada uno: activo, ubicación, dueño y qué costaría su pérdida - **3. Fronteras de confianza** — una línea cada una: frontera, qué la cruza, dirección, qué se comprueba - **4. Puntos de entrada** — una línea cada uno: punto de entrada, la frontera que cruza, `observado` o `reportado` - **5. Amenazas** — por frontera: la amenaza, la categoría de la que salió, el punto de entrada que usa, el activo al que llega - **6. Controles** — por amenaza: el control, dónde vive, `verificado` o `supuesto`, y la evidencia - **7. Riesgo residual** — qué queda tras los controles, cómo se detectaría, el responsable y si está aceptado - **8. Suposiciones** — cada afirmación tomada por buena y qué la confirmaría - **9. Preguntas abiertas** — la pregunta, qué bloquea, quién puede responderla ## Validación El modelo está listo cuando se cumple todo esto: - Cada activo de la sección 2 nombra a un dueño o dice `dueño desconocido` - Cada punto de entrada de la sección 4 se corresponde con una frontera de la sección 3 - Cada amenaza de la sección 5 nombra la frontera que cruza y el activo al que llega - Cada control de la sección 6 está marcado como `verificado` o `supuesto`, sin dejar ninguno sin marcar - Cada riesgo residual de la sección 7 tiene responsable y una forma en que se detectaría - Ningún control se describe como eficaz sin la evidencia de que lo es Falla la ejecución si un control aparece sin `verificado` ni `supuesto` al lado, o si una amenaza se registra como mitigada apoyándose en un control supuesto. ## Gestión de fallos - **No hay arquitectura** — detente. Informa de que el modelo no tiene sistema que describir y de que deducirlo de un solo componente produce el mapa de ese componente, no el del sistema. - **Nadie sabe decir qué protege el sistema** — produce las secciones 3 y 4 con lo observable, deja la sección 2 vacía y marcada como `pendiente de su dueño`, y declara que un modelo sin activos no prioriza nada. - **La arquitectura y el código no coinciden** — registra ambos, nombra ambas fuentes, modela el comportamiento que está en el código y eleva la discrepancia a la sección 9 como bloqueante. No la resuelvas eligiendo. - **Sin acceso al sistema en ejecución** — marca cada punto de entrada como `reportado` y cada control como `supuesto`, y declara con claridad que no se verificó nada del documento. - **Material parcial** — modela las partes que el material sostenga, marca el resto como `INCOMPLETO — pendiente de ` y entrega. Un modelo honesto sobre sus bordes es utilizable; uno que los adivinó enseña al equipo a confiar en una frontera que quizá no exista.