Registros e informes del modelo de amenazas
Sytance · Actualizado
Un modelo de amenazas registra la arquitectura del producto, los escenarios de ataque, los controles de seguridad y los resultados de verificación. Vincular estos registros permite al revisor seguir el razonamiento desde un ataque hasta la medida elegida para abordarlo. El ejemplo de la pasarela muestra cómo encajan estos registros; las secciones siguientes explican qué registrar y cómo revisarlo.
Cómo organizar el modelo
Mantenga juntos el diagrama y el análisis, o vincúlelos mediante identificadores estables. Un documento es adecuado para una revisión pequeña; los registros estructurados resultan útiles cuando un mismo control aborda varias amenazas o el equipo necesita comparar versiones.
En Sytance, el equipo edita la arquitectura y los registros de amenazas en el espacio de trabajo y, a continuación, vincula los requisitos, diseños y registros de verificación de seguridad pertinentes. El módulo de documentación utiliza la información del espacio de trabajo para preparar informes.
Información del producto e hipótesis
Identifique la versión, la implementación, la finalidad y los usuarios del producto. Indique las partes incluidas en el análisis, las dependencias externas y cualquier exclusión que afecte a una vía de ataque.
La guía de descomposición de OWASP distingue los puntos de entrada, los activos y los niveles de confianza. Utilice esas distinciones para explicar la arquitectura en vez de convertir cada activo en un proceso independiente del diagrama.
- Contexto: producto, versión, entorno, finalidad y responsable de la revisión.
- Arquitectura: revisión del diagrama, procesos, almacenes, entidades externas y flujos.
- Objetivos de protección: datos y funciones que necesitan confidencialidad, integridad o disponibilidad.
- Hipótesis: cada condición incierta, su responsable y una forma de confirmarla.
Registre cada escenario de ataque por separado
Asigne a cada amenaza un identificador estable y vincúlela al elemento o flujo pertinente del diagrama. Describa quién podría atacar, qué acceso necesita, la acción, la debilidad y la consecuencia. Indique las condiciones de las que depende el escenario.
Ejemplo TM-01: un usuario de solo lectura de una pasarela llama a la API de escritura de configuración. Si la API comprueba la autenticación, pero no el permiso de escritura, el usuario puede cambiar el destino de telemetría. El flujo afectado va del navegador a la API de gestión, y el ataque amenaza la integridad de la configuración almacenada.
Una entrada que solo diga «elevación de privilegios, riesgo alto» no explica este escenario. Añada el razonamiento del riesgo: la cuenta necesaria, la exposición del endpoint, el impacto realista y los controles existentes que se tuvieron en cuenta.
Controles, implementación y verificación
Para TM-01, el control propuesto AC-01 exige que la API de gestión compruebe los permisos sobre acciones y recursos en cada escritura de configuración. El registro de implementación debe identificar el cambio pertinente. El registro de verificación debe incluir el resultado real de la prueba para la versión indicada.
- Decisión: reducir, eliminar o aceptar el riesgo, con el motivo y el responsable.
- Control: el comportamiento requerido y los pasos de la amenaza que aborda.
- Implementación: el componente, la referencia del cambio y la versión del producto.
- Verificación: preparación, acción, resultado esperado, resultado observado y vínculo a la evidencia.
- Riesgo restante: condiciones sin resolver y decisión de revisión autorizada.
Resultados esperados y observados
Para la pasarela ficticia, el resultado esperado es que se rechace una solicitud de escritura de solo lectura y que la configuración almacenada no cambie. El resultado observado registra lo sucedido durante la prueba. Hasta que se ejecute la prueba, el campo correspondiente permanece pendiente.
La misma distinción se aplica a los controles. «Verificación de firma planificada» y «verificación de firma implementada y probada» comunican distintos niveles de confianza. Mantenga esa diferencia al trasladar el registro a un informe u otra herramienta.
Revisión del modelo completo
Pida a un revisor que siga un ataque desde el diagrama hasta el control seleccionado y el resultado de la prueba. Si no puede seguir los vínculos, determine si falta un registro o si hay que explicar mejor el ataque.
Compruebe que la versión indicada coincida con el diagrama, que cada escenario tenga una decisión de tratamiento y que los riesgos aceptados identifiquen quién los aceptó. Mantenga las hipótesis pendientes en una lista con su responsable y una forma de confirmarlas.
Después de actualizar los registros del espacio de trabajo, abra Documentación y seleccione el informe pertinente. Según la configuración y el plan del espacio de trabajo, Sytance ofrece vistas previas HTML y exportaciones PDF o DOCX. Antes de utilizarlo en una revisión, compruebe que el informe generado corresponda a la versión actual del producto, el análisis y la evidencia de verificación.