Modelado de amenazas: preguntar antes de construir

Imagina un servicio comunitario de fotos. Antes de elegir herramientas, define qué protege: imágenes privadas, cuentas y retirada de permisos. Modelar amenazas convierte esos objetivos en preguntas de diseño.

Límite de confianza: Límite por el que datos o autoridad cruzan entre contextos con supuestos de seguridad diferentes.

Dibuja el sistema real

Incluye personas, servicios, almacenes, proveedores y flujos. Marca límites donde datos o autoridad pasan entre contextos con supuestos de confianza diferentes. Añade administración y recuperación, no solo el recorrido normal.

Un activo tiene valor. Una amenaza es una posible causa de daño. Una vulnerabilidad es una debilidad que puede contribuir a ese daño. Distinguirlos evita confundir una lista de herramientas con un modelo.

Describe un fallo y sus consecuencias

Por ejemplo: un antiguo miembro conserva acceso porque la caché de permisos dura más que su pertenencia al álbum, exponiendo fotos posteriores. La frase identifica actor, condición, acción e impacto y plantea una pregunta sobre invalidación.

Categorías como suplantación, alteración, divulgación o interrupción ayudan a generar preguntas. No clasifican automáticamente el riesgo ni demuestran cobertura completa. Incluye errores y fallos de dependencias además del uso deliberadamente indebido.

Convierte la respuesta en una prueba

Un control debe interrumpir parte del escenario. Define cuándo retirar pertenencia afecta a cachés y sesiones. Una prueba con álbumes ficticios puede comprobar la pérdida de acceso prevista.

Registra incertidumbre, responsable y limitaciones aceptadas. Revisa el modelo cuando cambian funciones, proveedores o datos. Un modelo pequeño mantenido vale más que un diagrama grande abandonado.

Modelo resuelto: retirar acceso exige un plazo

El responsable del servicio de fotos promete detener nuevas lecturas en línea en un máximo de dos minutos tras retirar a un miembro. Incluye imágenes añadidas después de la retirada. No promete borrar imágenes ya descargadas. Supón que los relojes de los registros ficticios están suficientemente alineados para comparar estos límites de minutos.

• T1: Se retira a Mira del álbum a las 10:00. El límite para denegar nuevas lecturas es, por tanto, las 10:02.
• T2: La caché de autorización conserva una decisión permitida creada a las 09:59, válida hasta las 10:09. El diseño indica que retirar pertenencia no la invalida actualmente.
• T3: A las 10:03, el servicio registra una nueva lectura de Mira usando esa entrada. El registro de entrega confirma devolución de la imagen añadida a las 10:02.
• T4: Mira conserva además una imagen descargada a las 09:50. El servicio no controla copias ya descargadas en clientes.

PrediceLa base de pertenencias es correcta y la caché funciona como está configurada. ¿Aun así ha fallado el requisito de seguridad?

Sí. T3 acredita una lectura nueva después de las 10:02, cuando debe denegarse. Ejecutar correctamente una caché de diez minutos no cumple una promesa de revocación de dos. El fallo es específico; no demuestra que todos los álbumes o rutas se comporten igual.

Seguir la autoridad al cruzar la caché

El activo es la imagen privada. El actor es un miembro retirado. El límite importante aparece cuando una decisión guardada se acepta como autoridad para una lectura nueva. La debilidad no es simplemente “la caché es insegura”, sino la discrepancia entre cambios de pertenencia, vigencia del permiso y plazo requerido.

Posibles respuestas incluyen invalidar decisiones pertinentes al cambiar pertenencia o volver a comprobarla antes de la lectura protegida. La elección depende de disponibilidad, consistencia y rendimiento. El requisito debe definir comportamiento seguro cuando falta información actual, sin asumir que la dependencia nunca falla.

Haz comprobable la respuesta: hora de retirada, último límite permitido, lectura denegada después y lectura correcta de un miembro vigente. Son requisitos de evidencia de aceptación, no una solicitud de probar un servicio real. Cerrar sesión no basta si otra sesión puede reutilizar una decisión de pertenencia obsoleta.

Nota modelo: T3 incumple el plazo de revocación en línea. Corrige y verifica esa decisión; trata T4 como límite distinto de compartir copias. Revisa el modelo antes de añadir enlaces públicos, acceso sin conexión u otro proveedor de entrega, porque pueden cambiar quién controla la siguiente lectura.

EXPLORA EL CONCEPTO

De preocupación vaga a decisión

Elige una afirmación sobre el servicio ficticio.

“Podrían atacarlo”

Es demasiado amplio. Especifica recurso, límite y consecuencia.

“Un antiguo miembro conserva acceso en caché”

Describe condición y consecuencia. Define la invalidación y compruébala.

“Instalamos un producto de seguridad”

El producto no es el modelo. Explica qué escenario cambia y qué supuestos permanecen.

Modelo simplificado para aprender. No se conecta a sistemas ni usa datos reales.

Llévalo a una decisión

El resultado son decisiones razonadas, no una predicción de todos los incidentes futuros.