Modelado de amenazas: convierta la arquitectura en decisiones de seguridad

El modelado de amenazas se pregunta qué podría salir mal en un sistema concreto y qué debería hacer el equipo al respecto. Su resultado útil no es un catálogo de posibilidades alarmantes. Es un conjunto de decisiones de diseño e implementación ligadas a la arquitectura, con responsables y evidencias de que las defensas elegidas funcionan.

Para un CTO, la pregunta central es si ingeniería puede explicar cómo se mantienen las propiedades de seguridad importantes frente al comportamiento real del sistema: reintentos, tareas en segundo plano, acciones privilegiadas de soporte, caídas de proveedores y entradas maliciosas. Un diagrama hace concretas esas conversaciones. Un modelo de amenazas mantenido convierte las conclusiones en trabajo de entrega.

La guía de modelado de amenazas de OWASP ofrece una base útil: entender el sistema, identificar las amenazas, decidir cómo responder y valorar si el trabajo es suficiente. El flujo de trabajo siguiente aplica ese razonamiento a las decisiones de ingeniería.

Describa el sistema antes de hablar de ataques

Empiece por una capacidad acotada, como las exportaciones de clientes, la iniciación de pagos o las actualizaciones de dispositivos. Modelar toda una plataforma de una vez suele producir observaciones superficiales, porque nadie puede explicar cada dependencia con el detalle suficiente.

Formule los activos y los objetivos de seguridad en términos operativos. «Proteger los datos de los clientes» es demasiado amplio. «Un usuario autenticado solo puede exportar registros que pertenezcan a su cliente (tenant) autorizado» da al equipo una propiedad que probar. Otros objetivos pueden referirse a la integridad de las transacciones, la disponibilidad del servicio, la recuperación o la atribución de las acciones administrativas.

Identifique usuarios, servicios, almacenes de datos, dependencias externas, puntos de entrada y límites de confianza. Dibuje los flujos de datos importantes, incluidos el procesamiento asíncrono y las vías administrativas. Etiquete los flujos con los datos que transportan, el mecanismo de autenticación y el contexto de autorización cuando influyan en el análisis.

Un límite de confianza marca un cambio de supuestos o de autoridad, no necesariamente un perímetro de red. Un navegador que llama a una API cruza un límite. Un worker compartido que actúa en nombre de un cliente cruza otro, aunque ambos servicios se ejecuten en el mismo clúster.

En una aplicación multicliente (multi-tenant), muestre dónde se establece la identidad del cliente y cómo llega a las comprobaciones de autorización, las tareas en segundo plano y las exportaciones. Incluya las identidades de servicio, el acceso al almacenamiento de objetos, las herramientas de soporte y las devoluciones de llamada externas. De lo contrario, el diagrama puede describir el camino feliz y omitir precisamente las vías con más probabilidades de eludir el aislamiento.

Registre los supuestos por separado de los hechos. «Los clientes no pueden escribir en la cola» necesita evidencias de configuración que lo respalden. Las incógnitas deben convertirse en tareas de investigación, no en defensas aceptadas en silencio.

Elija un método que ayude al equipo a razonar

Un método aporta preguntas guía y estructura. No determina qué amenazas importan más, no demuestra que un diseño sea seguro ni sustituye al conocimiento del sistema.

STRIDE para preguntas sistemáticas

STRIDE examina seis categorías. Aplíquelas a los componentes, flujos y límites pertinentes, en lugar de forzar todas las categorías sobre cada elemento del diagrama.

Un mismo escenario puede abarcar varias categorías. Cuando proceda, mantenga un único registro accionable en lugar de crear tickets duplicados para satisfacer la taxonomía.

Otros métodos para otras preguntas

PASTA, el Process for Attack Simulation and Threat Analysis, ofrece un enfoque de siete fases orientado al riesgo que conecta objetivos de negocio, alcance técnico, descomposición, análisis de amenazas y vulnerabilidades, modelado de ataques y tratamiento de riesgos. Es adecuado para análisis más profundos en los que el comportamiento del atacante y las consecuencias para el negocio requieren una atención explícita.

Los árboles de ataque parten de un objetivo del atacante y lo descomponen en rutas alternativas o combinadas. Para «obtener la exportación de otro cliente», las alternativas podrían incluir eludir la autorización de la API, confundir el contexto de cliente del worker o robar una credencial de descarga. Las relaciones AND representan condiciones que deben darse a la vez; las relaciones OR representan alternativas.

VAST (Visual, Agile, and Simple Threat modeling) pone el acento en un modelado escalable desde las perspectivas de aplicación y de operaciones. Los equipos que lo consideren deben examinar si sus herramientas y su proceso de desarrollo pueden mantener esas vistas de forma coherente.

Una recomendación práctica para empezar es un diagrama de flujo de datos más STRIDE, seguido de un árbol de ataque para el escenario de mayores consecuencias. Más metodología solo es útil cuando mejora las decisiones.

Organice la revisión en torno a escenarios concretos

Reúna a las personas que entienden la implementación y la operación: un desarrollador, un arquitecto o responsable técnico, un revisor de seguridad y alguien que conozca el comportamiento en producción. Incluya a especialistas de producto, privacidad o proveedores cuando su conocimiento afecte al alcance.

Antes de la sesión, distribuya el diagrama, los objetivos de seguridad, la configuración pertinente y los supuestos sin resolver. Durante la revisión, recorra una solicitud o un suceso desde la entrada hasta su finalización. Pregunte dónde cambia la identidad, dónde persisten los datos, qué se reintenta y qué componente tiene autoridad para aprobar una acción.

Redacte las amenazas como escenarios, no como etiquetas. «Problema de autorización» no es lo bastante útil. Una formulación más sólida es: «Un usuario autenticado sustituye el identificador de exportación de otro cliente; el endpoint de descarga comprueba el inicio de sesión pero no la propiedad del objeto, lo que expone registros de clientes».

Separe tres conceptos:

• Una amenaza describe una acción o un suceso adverso, como la obtención no autorizada de una exportación.
• Una vulnerabilidad es una debilidad que podría hacerla posible, como la falta de una comprobación de propiedad.
• El riesgo considera la probabilidad y la consecuencia del escenario en el entorno real.

Puede merecer la pena investigar una amenaza antes de confirmar una vulnerabilidad. Del mismo modo, encontrar una debilidad no demuestra que todos los ataques imaginables sean viables.

Incluya el uso indebido por parte de usuarios legítimos, personal interno con privilegios, errores de configuración y fallos de proveedores junto con los ataques externos. Pregunte qué ocurre cuando una dependencia agota el tiempo de espera o devuelve una respuesta inesperada. Los comportamientos que fallan en abierto (fail-open) y los reintentos incoherentes suelen surgir de estas conversaciones.

Ejemplo práctico: una canalización de exportación multicliente

El siguiente ejemplo es ilustrativo. Supongamos que una aplicación SaaS tiene un cliente de navegador, una API, una base de datos compartida, una cola de tareas, un worker de exportación y un almacenamiento de objetos. Los usuarios de cada cliente solicitan exportaciones en CSV; el worker genera los archivos y la API emite enlaces de descarga temporales. Los administradores de soporte tienen una interfaz de diagnóstico independiente.

Los objetivos de seguridad son el aislamiento entre clientes, la iniciación autorizada de exportaciones, un consumo de recursos acotado y acciones de soporte atribuibles. Supongamos que el worker tiene un acceso a la base de datos lo bastante amplio como para atender a varios clientes. Eso convierte su manejo del contexto de cliente en una decisión central, y no en un detalle menor de implementación.

Siga la autoridad a lo largo del flujo

En la API, el principal autenticado se asocia con su pertenencia a los clientes permitidos. Un identificador de cliente facilitado por el navegador es una solicitud de selección, no una prueba de autorización. La API comprueba la pertenencia y el permiso de exportación antes de crear un registro de tarea inmutable que contiene el cliente autorizado, el solicitante y el alcance de exportación permitido.

El mensaje de la cola hace referencia a ese registro. El worker valida la tarea y aplica un acceso a datos limitado al cliente al generar la exportación. Los metadatos del almacenamiento asocian el objeto resultante con la tarea y el cliente. Antes de emitir un enlace de descarga, la API comprueba la autorización del solicitante actual frente a esa asociación.

Este diseño sigue necesitando decisiones explícitas sobre la revocación del acceso: ¿debe conservar el acceso al archivo completado un usuario que pierde su pertenencia después de solicitar una exportación? El equipo debe definir esa política e implementarla de forma coherente.

Convierta los escenarios en controles y pruebas

Los enlaces temporales introducen una ventana de exposición residual: según el mecanismo, poseer el enlace puede permitir el acceso hasta su caducidad. El equipo debe decidir si eso es aceptable para los datos en cuestión o si las descargas necesitan un intermediario autenticado con comprobaciones de autorización actuales.

No cierre el modelo tras probar solo la API síncrona. Verifique las tareas diferidas, los reintentos, las solicitudes canceladas, las pertenencias caducadas, los clientes eliminados y los fallos parciales. Por ejemplo, una tarea reintentada no debe reutilizar un objeto asociado a otro cliente ni publicar como satisfactoria una exportación incompleta.

El entregable resultante es una arquitectura revisada, un registro de amenazas, tareas de implementación y resultados de verificación vinculados. No es simplemente el diagrama.

Priorice según la exposición y las consecuencias

Priorice los escenarios plausibles según la exposición, el impacto, las condiciones previas y las defensas existentes. Distinga un fallo de autorización directamente alcanzable de un escenario que requiere varios compromisos no demostrados. Tenga en cuenta los datos afectados, la interrupción del servicio, las consecuencias financieras, las implicaciones para la seguridad física y la dificultad de recuperación cuando proceda.

Utilice una escala sencilla y coherente si ayuda al equipo, pero registre la justificación de la calificación. Una puntuación numérica con entradas sin explicar crea una falsa precisión. CVSS puede orientar la evaluación de una vulnerabilidad concreta; no sustituye a la comprensión del impacto en el negocio ni a un caso de abuso arquitectónico.

Entre las opciones de tratamiento figuran cambiar el diseño, reducir la exposición, añadir controles preventivos o de detección, renunciar a la capacidad o aceptar el riesgo restante. Los contratos con proveedores pueden repartir responsabilidades, pero no eliminan los modos de fallo técnicos.

El riesgo residual debe tener una persona que decide identificada, un motivo, una caducidad o un desencadenante de revisión y, en su caso, unas condiciones de funcionamiento. La finalización de ingeniería y la aceptación del riesgo son decisiones distintas. Un ticket puede estar terminado y seguir existiendo un riesgo relevante.

Lleve el modelo a la entrega y a las evidencias

Para cada escenario relevante, registre su identificador, los componentes afectados, las condiciones previas, la consecuencia, las defensas existentes, el tratamiento, el responsable y el método de verificación. Vincule el registro con la versión de la arquitectura y el trabajo de implementación pertinente para que los revisores sepan qué diseño se evaluó.

Traduzca los tratamientos en criterios de aceptación comprobables. «Mejorar el control de accesos» es vago. «El cliente A no puede solicitar, consultar, cancelar ni descargar la exportación del cliente B a través de ningún endpoint compatible» identifica un comportamiento que ingeniería puede verificar.

Utilice evidencias adecuadas a cada afirmación:

• La revisión de código puede establecer dónde se aplica la autorización.
• La inspección de la configuración puede establecer los permisos de los servicios y la exposición del almacenamiento.
• Las pruebas de integración negativas pueden ejercitar los límites entre clientes y de privilegios.
• Las pruebas de carga y de inyección de fallos pueden examinar la disponibilidad y el comportamiento ante fallos.
• Las pruebas de penetración específicas pueden investigar vías de ataque que requieren una exploración independiente.

Ningún artefacto aislado demuestra todo el modelo. Una captura de pantalla de una configuración no demuestra que todos los workers la utilicen, y una prueba superada no demuestra una vía no probada. Registre el entorno de pruebas, el alcance, los resultados y las limitaciones.

El modelado de amenazas complementa la programación segura, la evaluación de dependencias, el escaneo de vulnerabilidades y las pruebas de penetración. Su aportación distintiva es el razonamiento arquitectónico: puede revelar una asignación peligrosa de autoridad incluso cuando los componentes individuales no tienen ninguna vulnerabilidad conocida.

Mantenga las herramientas y la automatización al servicio del modelo

Un diagrama compartido y un registro estructurado pueden bastar para una primera revisión acotada. Las herramientas especializadas resultan útiles cuando los equipos necesitan bibliotecas de componentes reutilizables, identificadores coherentes, colaboración y vínculos fiables entre las amenazas y los registros de entrega.

Evalúe si una herramienta admite límites de confianza, escenarios personalizados, historial de versiones, registros exportables, responsables y referencias a evidencias. Las amenazas generadas automáticamente son sugerencias que hay que examinar, no hallazgos confirmados. Las listas largas sin contexto pueden ocultar las pocas decisiones que importan.

La asistencia de IA puede redactar descripciones de escenarios, sugerir vías que faltan o comparar cambios con un modelo anterior. Los revisores humanos siguen teniendo que validar la arquitectura, la viabilidad, la cobertura de las mitigaciones y el riesgo residual. Mantenga los diagramas confidenciales y las credenciales fuera de servicios no aprobados. La generación de modelos de amenazas también es distinta de la detección en tiempo de ejecución; producir un modelo no establece una monitorización continua ni una corrección automatizada.

Revise cuando cambien la arquitectura o los supuestos

Actualice el modelo cuando haya nuevas integraciones, cambios de autenticación, acciones privilegiadas, categorías de datos, exposición de red o cambios importantes en las dependencias. Un incidente o un resultado de prueba inesperado también pueden invalidar un supuesto anterior.

Cada sistema necesita un énfasis distinto. Las aplicaciones cloud requieren atención a los permisos de identidad y al acceso al plano de gestión. Los clientes móviles deben tratarse como entornos controlados por el atacante y no como puntos de aplicación de confianza. Los dispositivos conectados introducen el acceso físico, la integridad de las actualizaciones, la recuperación y, potencialmente, consecuencias para la seguridad física. Las funciones basadas en IA añaden contenido no fiable y límites de uso de herramientas; la autorización debe restringir las acciones con independencia de lo que produzca el modelo.

Mida si los flujos importantes tienen modelos actuales, si los tratamientos de alta prioridad tienen evidencias de verificación, si quedan supuestos sin resolver y si los riesgos aceptados tienen revisiones vencidas. Contar amenazas sin más premia el volumen en lugar del análisis útil. Pida periódicamente a un revisor independiente que cuestione un escenario crítico y sus evidencias.

Haga la primera revisión lo bastante pequeña como para terminarla

Secani puede preservar el flujo de trabajo en torno a estas decisiones modelando los sistemas y dependencias pertinentes, asignando responsables y revisores y conectando las evidencias con requisitos, controles y decisiones. Los supuestos sin resolver se convierten en tareas; el material de origen y las aprobaciones humanas permanecen vinculados a la revisión. Cualquier sugerencia asistida por IA debe comprobarse antes de su aprobación.

Empiece con un flujo de datos crítico. Siga su autoridad de extremo a extremo, identifique unos pocos escenarios plausibles y termine con tratamientos con responsable y criterios de verificación explícitos. Programe la siguiente revisión en función de los cambios de arquitectura que podrían invalidar esas decisiones.