Ejemplo de STRIDE: una pasarela industrial
Sytance · Actualizado
STRIDE utiliza seis categorías de amenazas para analizar cómo podría atacarse un sistema. La pasarela industrial ficticia que se muestra a continuación ilustra un escenario por categoría, con un control propuesto y un criterio de prueba. Estos ejemplos describen posibles ataques y pruebas planificadas.
La pasarela y sus límites de confianza
Un operador utiliza un navegador para llamar a la API de gestión de la pasarela. La API lee y escribe en un almacén de configuración local. Un controlador local envía datos operativos a la pasarela, que reenvía la telemetría a un servicio remoto. Un servicio de actualización independiente suministra paquetes de firmware.
En este ejemplo, las conexiones de gestión y telemetría utilizan TLS. La autenticación de la interfaz del controlador y el mecanismo de confianza de las actualizaciones siguen siendo cuestiones de diseño abiertas. La ubicación en una red local no demuestra por sí sola la identidad ni la autoridad del emisor.
- Navegador → API de gestión: sesiones, solicitudes de estado y cambios de configuración.
- API de gestión → almacén de configuración: ajustes almacenados y acceso a secretos.
- Controlador local → pasarela: entradas operativas procedentes de la red del emplazamiento.
- Pasarela → servicio de telemetría: identidad del dispositivo y datos de telemetría.
- Servicio de actualización → pasarela: metadatos del paquete y contenido del firmware.
Suplantación de identidad en la interfaz del controlador
Un atacante en la red del emplazamiento envía mensajes que dicen proceder del controlador local. Si la pasarela solo confía en una dirección de origen, podrían introducirse datos operativos falsificados en el flujo de telemetría.
Control propuesto: establecer una identidad del dispositivo y verificarla antes de aceptar mensajes. Si el controlador no admite autenticación, evalúe otras formas de proteger la interfaz y los ataques que sigan siendo posibles. Un segmento de red por sí solo no demuestra el origen de un mensaje.
Criterio de verificación: se rechazan los mensajes de una identidad de prueba no reconocida, mientras que los del controlador aprobado siguen funcionando. Capture el rechazo y confirme que el valor falsificado no llegó al servicio de telemetría.
Manipulación del firmware antes de su instalación
Un atacante sustituye un paquete obtenido a través de un punto de distribución comprometido. El cifrado del transporte hasta ese punto no demostraría que el fabricante hubiera autorizado el paquete.
Control propuesto: verificar la firma del paquete con respecto a un ancla de confianza autorizada antes de instalarlo. Vincule la verificación con los bytes que se instalarán y con el producto permitido. Decida por separado cómo gestionar versiones firmadas antiguas y claves de firma revocadas.
Criterio de verificación: se rechazan antes de la instalación tanto un paquete modificado como uno firmado con una clave no confiable. Tras el rechazo, la pasarela debe permanecer en el estado operativo o de recuperación especificado.
Cambios de configuración sin trazabilidad
Un operador autorizado cambia el destino de telemetría, pero el registro no incluye la identidad individual ni el resultado. El equipo no puede atribuir el cambio de forma fiable ni distinguir una escritura correcta de una solicitud rechazada.
Control propuesto: registrar la identidad autenticada, la acción, el objetivo, la hora y el resultado. Proteja el acceso a los registros y defina el comportamiento cuando se llene el almacenamiento. No incluya contraseñas ni tokens de acceso en el registro.
Criterio de verificación: un cambio controlado genera el registro correspondiente, un usuario no autorizado no puede editarlo y el comportamiento de auditoría cuando el almacenamiento está lleno coincide con la política documentada.
Exposición de secretos mediante lecturas de configuración
Un endpoint de estado devuelve el objeto de configuración completo, incluida la credencial de telemetría. Un usuario autorizado a consultar el estado recibe información que no necesita para su función.
Control propuesto: devolver una respuesta específica para el propósito con los campos secretos omitidos y aplicar permisos a las lecturas de configuración. El cifrado en tránsito no evita que una respuesta revele datos excesivos.
Criterio de verificación: inspeccione las respuestas para cada función admitida y confirme que los valores secretos no aparecen en la respuesta, los errores ni los registros.
El procesamiento de entradas agota la pasarela
Un emisor envía mensajes del controlador demasiado grandes o repetidos. El análisis y el almacenamiento en búfer consumen recursos que la pasarela también necesita para gestionar la telemetría.
Control propuesto: limite el tamaño de los mensajes y las colas, valide las entradas antes de realizar operaciones costosas y aísle el procesamiento crítico. Establezca límites a partir de la capacidad medida y del comportamiento requerido del producto durante una sobrecarga.
Criterio de verificación: en un entorno de prueba autorizado, ejercite los casos de sobrecarga acordados y observe la memoria, la profundidad de las colas, la disponibilidad del servicio y la recuperación. Los límites de aceptación proceden de los requisitos de este producto; no se supone que exista una tasa universal.
Un usuario de solo lectura accede a una operación de escritura
Un usuario puede iniciar sesión y consultar el estado. Llama directamente a una API de escritura de configuración, sin pasar por la interfaz. Si la API solo comprueba la autenticación, el usuario obtiene una capacidad reservada a los administradores.
Control propuesto: aplicar en el servidor permisos sobre acciones y recursos en todas las vías de escritura. Mantenga la misma regla para las solicitudes normales, las operaciones masivas y los endpoints de mantenimiento.
Criterio de verificación: las solicitudes directas de escritura desde una cuenta de solo lectura fallan y la configuración almacenada no cambia. Repita la prueba con una cuenta autorizada para confirmar que la operación prevista sigue funcionando.
Cobertura y riesgos restantes
Las seis categorías se basan en las definiciones STRIDE de Microsoft. Los escenarios de ataque y los controles dependen de la arquitectura de la pasarela descrita anteriormente.
Un producto real puede tener varios escenarios de ataque dentro de una categoría, y un mismo ataque puede corresponder a varias categorías. El análisis también debe abarcar las interfaces de fabricación, mantenimiento y recuperación si el producto las incluye.
Tras implementar y probar un control, evalúe los ataques que siguen siendo posibles con respecto a los criterios de riesgo acordados. La decisión resultante se aplica a la versión del producto analizada.