Elegir un control de seguridad antes de describir el sistema puede llevar a proteger un componente irrelevante mientras quedan sin examinar datos, flujos o límites importantes. Un modelo de amenazas no es un sello de seguridad: es una forma estructurada de identificar qué se protege, qué podría salir mal y cómo se decidirá una respuesta. El valor está en el razonamiento documentado y en su revisión conforme cambia el sistema.
Acordar el alcance y los activos
OWASP describe el modelado de amenazas como una actividad para identificar, comunicar y comprender amenazas y mitigaciones en el contexto de proteger algo valioso (Threat Modeling). Su página plantea preguntas sobre qué se está construyendo, qué podría fallar, qué se hará y cómo evaluar si el análisis fue suficiente. Estas preguntas ordenan una conversación; no eliminan la necesidad de juicio especializado.
Comience por acordar qué se modela: una función, un servicio, una integración o un cambio. Identifique los activos relevantes y las personas o componentes que los usan. Como criterio de trabajo, anote también las exclusiones del análisis y quién puede confirmarlas. Un alcance limitado puede ser apropiado para una revisión acotada, si se aclara que no cubre todo el producto.
Ejemplo hipotético: un equipo agrega exportación de datos a una aplicación. El modelo podría delimitar la función de exportación, las identidades que la invocan, el almacenamiento temporal y el destino de entrega. El ejemplo no corresponde a una aplicación real y no demuestra que se hayan cubierto todas las amenazas.
Representar flujos y límites de confianza
La hoja de recomendaciones de OWASP propone modelar el sistema y comprender elementos como flujos de datos, fronteras de confianza y entidades externas antes de identificar amenazas (Threat Modeling Cheat Sheet). Un diagrama de flujo de datos es una técnica posible, no el único formato válido. Lo esencial es que los participantes puedan discutir qué cruza cada límite y qué supuestos tienen sobre esas interacciones.
Como criterio de trabajo, represente procesos, almacenes, flujos y participantes externos con un nivel de detalle que permita revisar el alcance elegido. Marque dónde cambian identidad, privilegios o responsabilidad. Registre supuestos comprobables: por ejemplo, qué componente autentica una solicitud o quién puede leer un archivo exportado. Si el supuesto no está confirmado, anótelo como pregunta y asigne una verificación.
Un dibujo desactualizado puede generar confianza falsa. La revisión debe volver al diseño o implementación que se analiza y no depender de un diagrama heredado sin validar. OWASP señala que el modelo debe mantenerse y refinarse a medida que el sistema evoluciona; nuevos cambios pueden requerir volver a examinar los escenarios.
Formular escenarios antes de escoger controles
Una vez entendido el sistema, describa cómo podría verse afectada una propiedad importante. La Cheat Sheet de OWASP menciona enfoques como STRIDE y otras técnicas para organizar amenazas, pero también indica que no existe una respuesta única para todos los casos. Una técnica debe seleccionarse por el alcance que ayuda a explorar, no para dar apariencia de exhaustividad.
Como criterio de trabajo, registre cada escenario con componente o flujo afectado, condición necesaria, consecuencia posible, evidencia y una pregunta de validación. Distinga una amenaza plausible de una vulnerabilidad confirmada. Si no se sabe si un control existe o está bien configurado, no lo marque como protección demostrada; establezca cómo comprobarlo.
Después, relacione cada respuesta con el escenario correspondiente. Puede consistir en una mitigación, una decisión de aceptación documentada, una transferencia dentro de un proceso de riesgo o una investigación adicional. La selección depende de impacto, probabilidad, obligaciones, arquitectura y capacidad de verificación. No asigne una cifra de riesgo si la metodología y los datos no sostienen esa precisión.
Convertir el modelo en una revisión útil
Una lista de amenazas sin dueño ni seguimiento no basta para dirigir el trabajo. Registre responsable, decisión, control propuesto y prueba que permitiría evaluar su funcionamiento. Si se elige una mitigación, defina qué evidencia se buscará y en qué artefacto quedará. Si se acepta un riesgo, especifique quién autorizó esa decisión y bajo qué alcance; no confunda aceptación con inexistencia de amenaza.
El estándar ASVS de OWASP ofrece una base de requisitos para probar controles técnicos de aplicaciones web y una lista de requisitos para desarrollo seguro (OWASP ASVS). Sirve como referencia para estructurar verificaciones pertinentes, pero la página general no demuestra por sí misma que una aplicación cumpla un nivel ni sustituye seleccionar y ejecutar pruebas concretas. Si se citan requisitos específicos, se debe registrar la versión y el identificador exactos.
Revisar cuando cambie el sistema
Actualice el análisis cuando cambien flujos, identidades, almacenamiento, integraciones o arquitectura, y después de aprender algo que invalide un supuesto. Una revisión puede confirmar que un escenario ya no aplica, encontrar uno nuevo o exigir ajustar la prueba de un control. Mantener historial de decisiones ayuda a saber qué cubre el modelo actual y qué quedó fuera.
Como criterio de trabajo, trate el modelo como una conversación revisable conectada al ciclo de desarrollo, no como un documento que se completa una sola vez. El alcance, técnica y nivel de detalle dependen del sistema y del riesgo que se examina. Involucre a personas con conocimiento de las partes relevantes y escale dudas que requieran análisis especializado.
Qué no cubre este artículo
Esta guía no es asesoría de cumplimiento, una auditoría de seguridad ni una garantía de que el sistema esté protegido. No selecciona controles universales ni prueba su eficacia; cada control necesita validación en el entorno y alcance correspondientes.
