Modelado de amenazas: arquitectura, escenarios de ataque y controles
Sytance · Actualizado
El modelado de amenazas es un método estructurado para identificar cómo podría atacarse un producto y elegir medidas que reduzcan el riesgo. El análisis parte de la arquitectura del producto y explica cómo podría tener éxito un ataque, a qué afectaría y cómo se comprobará la protección propuesta.
Versión del producto e implementación
Un modelo de amenazas se aplica a una versión y una implementación concretas del producto. Una pasarela conectada a Internet y esa misma pasarela en una red de mantenimiento aislada pueden tener distintos puntos de entrada e hipótesis operativas.
Invite a las personas que conocen la arquitectura, el desarrollo, el uso del producto y la seguridad. Antes de la sesión, reúna material suficiente para explicar una operación normal de principio a fin.
- La versión, la implementación compatible y los usuarios previstos.
- La arquitectura, las interfaces externas y los datos intercambiados.
- Los privilegios de cada usuario, servicio y proceso local.
- Los datos sensibles, las credenciales y las funciones del producto que deben protegerse.
- Los controles existentes y las hipótesis que aún deben confirmarse.
Flujos de datos y límites de confianza
Un diagrama de flujo de datos (DFD) muestra entidades externas, procesos, almacenes de datos y su circulación. Un límite de confianza señala un cambio en la confianza o la autoridad. Puede existir entre un navegador y una API, entre dos cuentas del sistema operativo o entre un dispositivo y un servicio remoto.
Indique para cada flujo la dirección, una descripción de los datos y el mecanismo de protección. Una caja etiquetada «nube» oculta demasiados detalles si varios servicios tienen identidades y permisos distintos. Divida la caja cuando esa diferencia cambie el análisis.
Para el ejemplo de la pasarela industrial, empiece por el navegador del operador, la API de gestión de la pasarela, el almacén de configuración local, el controlador local, el servicio de telemetría y el servicio de actualización. Represente la gestión y la telemetría como conexiones TLS. Considere la verificación de la firma de las actualizaciones como un control propuesto hasta que se confirme su implementación.
De las categorías STRIDE a los escenarios de ataque
STRIDE agrupa las amenazas en suplantación, manipulación, repudio, divulgación de información, denegación de servicio y elevación de privilegios. Utilice estas categorías para plantear preguntas sobre cada proceso y flujo pertinente. El nombre de una categoría, por sí solo, no describe un ataque.
Por ejemplo: un usuario con acceso de solo lectura envía directamente a la API de gestión una solicitud para cambiar la configuración. Si la API comprueba el inicio de sesión, pero no el permiso para realizar esa acción, el usuario puede cambiar la configuración de la pasarela. El ejemplo identifica un actor, un punto de entrada, un control ausente y un impacto.
Vincule cada escenario con la interfaz, el proceso o el flujo correspondiente del diagrama. Los escenarios con condiciones de ataque o controles distintos requieren análisis separados. Si se desconoce una condición, como la autenticación de la interfaz del controlador, registre qué debe confirmarse.
Prioridades de riesgo y controles de seguridad
Las prioridades de riesgo dependen del acceso y la capacidad que necesita un atacante, de la probabilidad de éxito y de las consecuencias para el producto. Un método de riesgo acordado aporta coherencia a estas valoraciones. Explicar el razonamiento tras una puntuación permite que otras personas la revisen.
Elija una respuesta que el equipo pueda implementar. Para el escenario de cambio de configuración, exija que la API aplique los permisos de quien realiza la solicitud en cada operación de escritura. Asigne un responsable, una versión objetivo y una comprobación que demuestre si el control funciona.
TLS protege una conexión de transporte, pero no determina si una persona que ha iniciado sesión puede cambiar la configuración. Evalúe el control frente al paso exacto del ataque que debe impedir. Si el equipo acepta un riesgo residual, conserve el motivo y la identidad de la persona autorizada para tomar esa decisión.
Verificación y actualización del modelo
Un control propuesto y uno verificado son estados distintos. Vincule cada control implementado con el cambio correspondiente y su resultado de verificación. Para el ejemplo de la API, envíe una solicitud de escritura con un usuario de solo lectura y confirme tanto su rechazo como la ausencia de cambios en la configuración.
Revise el modelo si cambia una interfaz, un permiso, un componente, una implementación o un mecanismo de actualización. La nueva información sobre vulnerabilidades también puede invalidar una hipótesis anterior. Conserve el modelo previo para que el equipo pueda explicar a qué versiones se aplicaba una decisión.