ATALAIALa mayoría de los threat models se escriben una vez. Un equipo reserva un taller, dibuja el sistema, lista amenazas con STRIDE y produce un documento. A menudo es un buen documento. Seis meses después el producto tiene nuevas integraciones, una nueva ruta de deploy y dos roles nuevos, y el documento describe un sistema que ya no existe.
Nuestra postura es que el problema no es la disciplina. Es la forma. Un único documento mezcla cosas que cambian a velocidades muy distintas y tienen responsables diferentes. Divídelo en capas y podrá seguir el ritmo.
Por qué falla un solo documento
Piensa en quién sabe qué en una organización típica. Producto sabe qué flujos mueven dinero y qué datos son sensibles. Arquitectura conoce los servicios y las fronteras. Los desarrolladores conocen las rutas de código. Plataforma conoce el pipeline y sus tokens. Operaciones sabe qué está realmente en ejecución y quién puede llegar a ello.
Un único threat model pide a todos que actualicen un solo artefacto. En la práctica nadie lo hace, porque ningún cambio parece lo bastante grande como para reabrirlo entero. Así que el modelo se desvía hasta que la siguiente auditoría o incidente obliga a reescribirlo.
Hay un segundo problema. Una amenaza en un nivel suele tener su causa en otro. Un bug de autorización en el código puede existir porque el diseño nunca dijo quién es dueño de un objeto. Un riesgo de cadena de suministro en el pipeline puede importar solo porque el runtime tiene permisos amplios en la nube. Una lista plana de amenazas oculta esos vínculos.
Las cinco capas
Mantenemos los threat models en cinco capas. Cada una tiene un responsable y un disparador claro de actualización:
| Capa | Qué contiene | Responsable | Actualizar cuando |
|---|---|---|---|
| Negocio y proceso | Activos valiosos, flujos críticos, objetivos de abuso, actores | Producto | Una nueva funcionalidad, mercado o rol |
| Arquitectura | Servicios, almacenes de datos, límites de confianza, flujos de datos | Arquitectos o tech leads | Un nuevo servicio, integración o tienda |
| Código | Puntos de entrada, lógica de autorización, parsers, uso de criptografía | Equipos de servicio | Cambios en rutas sensibles |
| Pipeline | Runners, tokens, actions, dependencias, firma | Plataforma | Un nuevo workflow, secret o destino de deploy |
| Runtime | Identidades, alcance de red, puertos expuestos, detección | Operaciones o SRE | Cambios de infraestructura o de permisos |
Cada capa es lo bastante pequeña para revisarla en una hora, y cada una cambia cuando su responsable ya tiene el contexto en la cabeza.
Amenazas que cruzan capas
Las capas no son documentos separados que se ignoran entre sí. El valor está en los vínculos. Una amenaza se registra en la capa donde se materializa y se enlaza con las capas que la facilitan o la limitan. Por ejemplo:
- NegocioObjetivo: que un cliente lea los extractos de otro cliente.
- ArquitecturaEl servicio de extractos comparte una base de datos entre tenants, filtrada por un tenant id.
- CódigoEl endpoint de exportación recibe un id de extracto y debe comprobar su tenant en cada llamada.
- RuntimeLas llamadas de exportación se registran con tenant y actor, y generan alertas ante patrones entre tenants.
Ahora un cambio en cualquier capa te dice qué volver a revisar. Si la arquitectura pasa a bases de datos por tenant, la comprobación a nivel de código se convierte en defensa en profundidad en lugar de ser el único control. Si alguien añade una exportación masiva, el responsable de la capa de código ve que un objetivo de la capa de negocio depende de ella.
Las objeciones habituales
"Esto es más trabajo."Es menos trabajo repartido de forma más uniforme. Actualizar una capa tras un cambio lleva minutos. Reescribir un modelo entero cada año lleva días y nunca queda del todo terminado.
"Nuestros equipos no lo mantendrán al día."No mantendrán al día un documento. Sí mantendrán una sección que se activa con los cambios que ya hacen, sobre todo si la plantilla de la pull request plantea la pregunta.
"No tenemos un equipo de seguridad que lo lleve."Las capas pertenecen a quienes las conocen. Seguridad, si la tenéis, revisa los vínculos y los huecos, que es donde más importa la experiencia.
Qué haríamos
- Empieza por la capa de negocio. Bastan entre cinco y diez objetivos de abuso en lenguaje llano.
- Dibuja la capa de arquitectura en una página con los límites de confianza marcados.
- Para código, pipeline y runtime, empieza solo con las partes ligadas a esos objetivos. No intentes modelarlo todo.
- Guarda cada capa como texto en el repositorio más cercano a su responsable y enlázalas por id.
- Añade una línea a las plantillas de pull request y de cambios: "¿Este cambio afecta a una capa del threat model?"
- Revisa los enlaces una vez al trimestre. Los objetivos sin enlazar y los controles huérfanos son el orden del día.
Esta es la idea detrás del layered threat model estamos construyendo en la torre: cada capa se actualiza desde los sistemas que ya la describen, y los enlaces muestran qué toca un cambio. Aun así, no necesitas una plataforma para empezar. Una carpeta de ficheros de texto cortos y un hábito te llevan la mayor parte del camino por la línea.
Dónde encaja en la línea
En la torre (en desarrollo):