Planteamiento y alcance
Revise una arquitectura donde un navegador accede a una aplicación web multi-tenant. ¿Cómo trazaría los límites y los flujos de datos, identificaría activos y fuentes de amenazas, distinguiría entre amenazas de objetivo, de implementación y externas, y convertiría las respuestas en invariantes de seguridad verificables?
El W3C Security Interest Group publicó el borrador de Group Note de Threat Model for the Web el 26 de mayo de 2026. Es informativo y no normativo, destinado a respaldar las revisiones de seguridad de nuevas especificaciones web. Su visión simplificada incluye un navegador, DNS, un Web Server, usuarios y operadores de red. La entrevista evalúa el método y la cadena de evidencias, no la memorización del borrador.
Qué evalúa el entrevistador
El entrevistador busca ver una imagen del sistema y del flujo de datos antes de una lista de vulnerabilidades; activos, partes interesadas y fuentes de amenazas explícitos; una distinción clara entre amenazas, vulnerabilidades, impactos y respuestas; y objetivos de seguridad expresados como invariantes comprobables. Explique cómo evoluciona el modelo y cómo nutre los documentos de diseño y revisión. Una respuesta sólida establece límites de abstracción, suposiciones del atacante que no están modeladas y cómo se transfieren las dependencias fuera de alcance.
Preguntas aclaratorias antes de responder
- ¿Estamos revisando la plataforma del navegador, una aplicación web o una nueva Web API entre ellos?
- ¿Están dentro del alcance las credenciales, los datos de usuario, el código, las sesiones, los metadatos de red y la disponibilidad?
- ¿Incluyen los flujos scripts de terceros, CDNs, DNS, proveedores de identidad y solicitudes cross-site?
- ¿Se trata de una revisión de arquitectura, una revisión de seguridad previa al lanzamiento o una revisión de cambios operativos?
- ¿Qué dependencias y amenazas externas quedan explícitamente fuera de alcance y quién es el responsable del seguimiento?
Marco de respuesta de 30 segundos
“Comienzo con un diagrama de flujo de datos con identificadores únicos para componentes, almacenes, flujos y partes interesadas. Enumero activos y fuentes de amenazas, y luego registro prerrequisitos, flujos afectados, impacto, controles existentes y riesgo residual para cada amenaza. La clasifico como una amenaza de objetivo, amenaza de implementación o dependencia externa. Cada respuesta se convierte en un invariante de seguridad con evidencia de prueba o auditoría, un responsable y un desencadenante de actualización. El modelo comienza con los casos de uso y evoluciona junto con el diseño para que haya una versión lista antes de la revisión formal de seguridad.”
Análisis detallado paso a paso
1. Dibujar primero el límite del sistema
Comience con un escenario mínimo utilizable: proceso y almacenamiento del navegador, servicio DNS, Web Server, usuario, administrador del sitio y operador de red. Asigne a cada componente un identificador único corto y un diccionario en prosa que describa su responsabilidad y límite de confianza. Si está revisando una nueva API, ubique sus entradas, salidas, permisos y dependencias en esta imagen en lugar de crear un diagrama aislado.
2. Enumerar activos y partes interesadas
Los activos pueden incluir credenciales, tokens de sesión, contenido del usuario, scripts, identidad de origen, resultados de DNS, disponibilidad y metadatos de privacidad. Las partes interesadas incluyen usuarios finales, operadores de sitios, operadores de red, proveedores de aplicaciones y funcionarios públicos. Separe a los afectados de quienes podrían atacar; tratar a los usuarios únicamente como activos oculta decisiones de seguridad importantes.
3. Registrar fuentes de amenazas y amenazas de alto nivel
Para cada amenaza, indique su fuente, activo objetivo, ruta de ataque e impacto. Suplantación de identidad (spoofing), manipulación (tampering), divulgación de información, denegación de servicio y elusión de autorización pueden organizar la lista, pero cada entrada debe asociarse a un flujo concreto. Clasifique las amenazas como amenazas de objetivo abordadas por la especificación, amenazas de implementación conocidas por los implementadores pero inadecuadas para restricciones normativas, o amenazas externas procedentes de dependencias y despliegue.
4. Convertir respuestas en invariantes
Un invariante de seguridad es una condición que debe cumplirse para cada ejecución permitida, como “una respuesta cross-origin nunca entrega una credencial a un invocador no autorizado” o “una redirección no puede eludir los límites de script-origin ni de permisos”. Vincule cada invariante a un control y a evidencia de prueba, registro o auditoría. Indique si es una garantía de especificación, una garantía de implementación o una suposición de despliegue.
component/flow -> asset -> threat source -> impact
-> invariant -> control -> evidence -> owner5. Gestionar dependencias y amenazas externas
La Web depende de DNS, TLS, HTTP, certificados, enrutamiento, scripts y otras capas. No intente fingir que un solo modelo cubre cada dependencia. Enumere las suposiciones heredadas y los puntos de transferencia. La suplantación de DNS, la manipulación de recursos o la vigilancia de la red pueden estar fuera de la especificación actual, pero cite el modelo de amenazas de la tecnología relacionada y registre la suposición en la que se basa.
6. Mantener el modelo alineado con el ciclo de vida
Inicie el modelo de amenazas con casos de uso, documentos explicativos (explainers) y el primer borrador de diseño; luego, actualícelo a medida que cambien las características y los flujos. Los desencadenantes incluyen nuevos puntos de entrada, cambios de permisos, nuevas dependencias, modificaciones en los límites del proceso del navegador e incidentes reales. Gestione las versiones del modelo, las notas de revisión y las diferencias (diffs) para que los equipos puedan saber si un riesgo se agregó, se cerró o se reclasificó. Debe existir una versión completa antes de la revisión de seguridad horizontal formal.
7. Demostrar que las respuestas funcionan
Utilice pruebas unitarias y de integración, pruebas de seguridad del navegador, simulación de ataques, verificaciones de configuración y consultas de registros. Para un invariante que no se pueda probar directamente, proporcione una justificación auditable, el riesgo residual y un responsable que lo acepte. “No se encontraron vulnerabilidades” no es una prueba; detalle el alcance de observación, las condiciones de prueba y las áreas no cubiertas.
Ejemplo de respuesta de alta calidad
Definiría un escenario mínimo de acceso por navegador con identificadores únicos para el proceso y almacenamiento del navegador, DNS, Web Server, usuario y operador de red, y proporcionaría un diccionario para cada flujo. Enumeraría credenciales, sesiones, contenido de usuario, scripts, resultados de resolución y metadatos de privacidad como activos. Cada amenaza incluiría fuente, prerrequisitos, flujo afectado e impacto, y luego se clasificaría como amenaza de objetivo, de implementación o de dependencia externa. Cada respuesta se convertiría en un invariante comprobable vinculado a controles, pruebas, registros o evidencia de auditoría y a un responsable. El modelo comenzaría con los casos de uso y el primer borrador de diseño, se actualizaría cuando cambien los puntos de entrada, las dependencias o los permisos, y se versionaría antes de la revisión de seguridad. Para DNS, TLS, scripts y enrutamiento citaría modelos relacionados y haría explícitos los riesgos residuales. Esto hace que la revisión sea útil tanto para la implementación como para futuros cambios.
Errores comunes
- Listar solo nombres de vulnerabilidades → no hay límite ni flujo → dibuje primero los componentes, los flujos y los límites de confianza.
- Mezclar amenazas, vulnerabilidades e impactos → las respuestas no se pueden verificar → registre por separado la fuente, los prerrequisitos, el impacto y los controles.
- Poner cada riesgo en la especificación actual → el alcance se vuelve falso → clasifique las amenazas en de objetivo, de implementación y externas.
- Crear un único modelo justo antes del lanzamiento → se pasan por alto los cambios de diseño → comience con casos de uso y defina desencadenantes de actualización.
- Redactar objetivos de seguridad como eslóganes → no existe evidencia de aceptación → reescríbalos como invariantes vinculados a pruebas, registros o auditorías.
- Ignorar el riesgo residual → no se pueden rastrear las decisiones → indique áreas no cubiertas, responsables de aceptación y acciones de seguimiento.
Preguntas de seguimiento y respuestas
¿Por qué no enumerar primero a cada atacante?
Definir primero componentes, activos y flujos evita la dispersión del alcance. Se puede añadir un modelo de atacante, pero las suposiciones sobre motivos no pueden sustituir el análisis de límites y controles verificables.
¿Cómo maneja los scripts de terceros?
Incluya en el modelo la fuente del script, el flujo de carga, las credenciales accesibles y los permisos de ejecución. Defina restricciones de origen, aislamiento e invariantes de monitoreo; si un proveedor es responsable de un control, registre la evidencia de transferencia y el riesgo residual.
¿Cuándo una dependencia externa se convierte en un riesgo del proyecto?
Cuando su suposición de seguridad afecta directamente a un activo o invariante dentro del alcance, o el proyecto no puede verificar la promesa de la dependencia, regístrelo como un riesgo actual con una mitigación o un responsable de aceptación en lugar de dejarlo como una nota al pie.
¿Qué ocurre si el modelo de revisión de seguridad es demasiado complejo?
Mantenga un diagrama mínimo que cubra los riesgos principales, divida el detalle del protocolo o del despliegue en submodelos vinculados y preserve la trazabilidad con identificadores de componentes y flujos. No reduzca la complejidad eliminando un límite crítico.
¿Cómo explica el riesgo residual a un product owner?
Describa los activos afectados, las rutas plausibles, los controles actuales, la evidencia de pruebas y el impacto en el negocio. Ofrezca opciones con costo, plazo y un responsable explícito que lo acepte; evite términos como “absolutamente seguro” o afirmaciones de probabilidad sin respaldo.