Introducción
¿Cómo se anticipan y mitigan los riesgos de seguridad? Los estándares de la industria ISO®/SAE® 21434 y DO-356 exigen responder a esta pregunta antes de lanzar nuevos productos al mercado. Y hacerlo puede ser difícil sin un proceso unificado para documentar, realizar un seguimiento, implementar y verificar cambios. Dependiendo del sector, este proceso se conoce como TARA (análisis de amenazas y evaluación de riesgos), SRA (evaluación de riesgos de seguridad) u otro nombre. Si emplea un marco basado en modelos para SRA (Figura 1), puede lograr una integración estrecha entre diseño, y seguridad y protección mediante un proceso guiado paso a paso. También puede adaptar, ampliar o automatizar fácilmente el proceso para ajustarlo a sus necesidades utilizando las numerosas prestaciones de MATLAB®.
Figura 1. Marco de análisis de seguridad basado en modelos.
Contexto: Robot de almacén
Este white paper presenta un ejemplo de robot de almacén con un operador remoto, arquitectura de software, modelo de planta y modelo de cámara (Figura 3). Un análisis detallado de la arquitectura de software (Figura 4) muestra los módulos planificador de tareas, planificación, control y estimación de posición.
El análisis de seguridad basado en modelos consta de los siguientes pasos (Figura 2):
- Identificación de activos y amenazas
- Cálculo de riesgos de seguridad
- Definición, implementación y verificación de contramedidas
Figura 2. Pasos del análisis de seguridad basado en modelos.
Figura 3. Modelo de arquitectura de robot de almacén.
Figura 4. Arquitectura de software de robot de almacén.
Identificación de activos y amenazas
Una pregunta importante que debe plantearse cuando se intentan identificar activos y amenazas es "¿qué necesita protección?". En un mundo perfecto, la respuesta es todo aquello que aporte valor a un sistema. Sin embargo, la complejidad y los gastos limitan la elección de proteger aquello que es necesario, como funcionalidades relevantes para la seguridad. Estas funcionalidades se conocen como activos, y cada uno de ellos posee propiedades que se deben proteger, como:
- Disponibilidad
- Integridad
- Autenticidad
- Confidencialidad
- No repudio
- Autorización
Identificación de activos: ¿Qué se desea proteger?
Existen muchos métodos para identificar activos, como evaluar su exposición a usuarios, examinar flujos de datos, revisar la lista de materiales de software (SBOM) o considerar su papel en las funcionalidades de seguridad. Como regla general, se deben tomar en consideración todos los componentes que consumen entradas externas.
Dentro de la arquitectura de software del robot, existen componentes que se basan en una señal (robotPosition) procedente de cámaras en el techo del almacén (modelo de simulación):
- Planificador de tareas
- Estimador de posición
A los efectos de este ejemplo, este informe se centrará en proteger la disponibilidad, integridad y autenticidad de esa señal en relación con estos activos. Tenga en cuenta que existen otras propiedades de estos activos que deben protegerse, y que este análisis debe realizarse con todos los activos del sistema.
Para garantizar la trazabilidad a lo largo del análisis, es importante utilizar las hojas de cálculo de Safety Analysis Manager en Simulink Fault Analyzer™. Para agregar estos activos a una hoja de cálculo, se utilizan estereotipos de System Composer™. Cuando se asigna el estereotipo de activo a estos subsistemas, se agregan automáticamente a la hoja. La hoja de cálculo realiza un seguimiento del tipo de activo, las propiedades protegidas y otra información que desee capturar (Figura 5). Con Requirements Toolbox™, también se pueden vincular los activos con las amenazas identificadas para crear un hilo digital que conecta el resto del análisis. Esto ayuda a:
- Cumplir con los requisitos de trazabilidad de los estándares de la industria.
- Realizar un análisis de impacto de los cambios.
Figura 5. Ejemplo de hoja de cálculo de activos.
Identificación de amenazas: ¿Qué podría ocurrir?
Una vez identificados los activos que se deben proteger, el siguiente paso es identificar las amenazas que acechan a estos activos. Un método común para identificar amenazas de seguridad de software es el marco de modelado STRIDE. Las propiedades deseadas de los activos se asignan directamente a sus respectivas amenazas, como se observa en la tabla 1.
| Amenaza | Propiedad deseada | Definición de la amenaza |
| Suplantación | Autenticidad | Hacerse pasar por algo o alguien que no se es |
| Manipulación | Integridad | Modificar datos en un disco, red, memoria u otro lugar |
| Repudio | No repudio | Afirmar, de forma veraz o falsa, que no se realizo una acción o no se es responsable de algo |
| Divulgación de información | Confidencialidad | Acceso a información por parte de alguien sin autorización |
| Denegación de servicio | Disponibilidad | Agotar los recursos necesarios para prestar un servicio |
| Elevación de privilegios | Autorización | Permitir que alguien haga acciones sin autorización |
Ya sea que esté empleando STRIDE u otro método, puede escribir una función de MATLAB para sugerir amenazas automáticamente a partir de las propiedades previamente identificadas del activo. Por ejemplo, la amenaza asignada a la disponibilidad es la denegación de servicio. Esta terminología es genérica, y deberá afinarla para determinar el riesgo planteado y la contramedida adecuada. Se puede recurrir a catálogos de amenazas como CAPEC™1, ATT&CK®2 y EMB3D™3 para obtener información más específica sobre cuál puede ser la amenaza; en este caso, podría consistir en provocar perturbaciones en la señal que envía la cámara al estimador de posición.
Una vez que se identifica la amenaza concreta, la hoja de cálculo de amenazas se puede actualizar con la entrada de CAPEC (por ejemplo, CAPEC-601). Al igual que la hoja de activos, la hoja de amenazas también permite la trazabilidad y análisis de impacto mediante sus vinculaciones con el resto del análisis.
Cálculo del riesgo de seguridad
Para calcular el riesgo de una amenaza determinada se deben tener en cuenta ciertos factores principales. El primero es la viabilidad, que consiste en la facilidad con que se puede llevar a cabo el ataque. El segundo es el impacto, que tiene en cuenta la gravedad de las consecuencias.
Viabilidad: ¿Cuán difícil es la tarea?
El método de potencial de ataque de ISO 18045 ofrece un marco sistemático para estimar la viabilidad de un ataque en función del siguiente conjunto de factores requeridos:
- Pericia: ¿Qué habilidades tiene quien realiza el ataque?
- Conocimiento: ¿Cuánto conocimiento interno se necesita?
- Equipamiento: ¿Qué herramientas o hardware son necesarios para ejecutar el ataque?
- Tiempo transcurrido: ¿Cuánto tiempo se tarda en identificar una vulnerabilidad y desarrollar un exploit?
- Margen de oportunidad: ¿Cuándo y dónde se puede llevar a cabo el ataque?
La hoja de cálculo de amenazas (Figura 6) tiene columnas para cada uno de los factores que se deben tener en cuenta. Una fórmula de MATLAB personalizable calcula la viabilidad automáticamente. Como se ha mencionado antes, se utiliza el método de potencial de ataque, que suma el valor enumerado normalizado de cada factor.
Figura 6. Hoja de cálculo de amenazas con factores y viabilidad destacados.
Impacto: ¿Cuán grave es?
Toda amenaza conlleva un impacto o consecuencia potencial. En este ejemplo, el impacto se determina en función de los efectos sobre la seguridad. Para ello, se recurre directamente a la evaluación de impacto proveniente de un análisis de seguridad existente, es decir, la evaluación de peligros. Tenga en cuenta que esto es una simplificación. Normalmente, también se determina el impacto en aspectos operativos, financieros y de privacidad.
En la evaluación de peligros (Figura 7), la gravedad de un fallo funcional del sensor de posición varía entre S3 y S5. Para simplificar, se considerará el valor más alto como el impacto de la amenaza de denegación de servicio (DoS).
Figura 7. Evaluación de peligros de un robot.
Cálculo y tratamiento del riesgo
Una vez que se han evaluado la viabilidad y el impacto, el riesgo se puede calcular automáticamente con otra fórmula de MATLAB. En este ejemplo, el riesgo se calcula multiplicando la viabilidad por el impacto.
Dependiendo de su tolerancia al riesgo, puede decidir cómo aplicar los tratamientos del riesgo. El tratamiento del riesgo se muestra en la hoja de cálculo (Figura 8) e indica una de las siguientes características:
- Evitar: El riesgo debe evitarse por completo, por ejemplo, eliminando la funcionalidad.
- Reducir: El riesgo debe reducirse implementando contramedidas técnicas.
- Compartir: El riesgo se transfiere al seguro, usuarios, terceros, u otros.
- Retener: El riesgo se acepta “tal cual”, sin pasos adicionales.
- No aplicable: La amenaza no existe en este sistema.
Nota: Los tratamientos para evitar y reducir el riesgo conllevan requisitos técnicos.
Figura 8. Tratamiento del riesgo en hoja de cálculo de amenazas.
El cálculo del riesgo y la relación entre amenazas, activos y otros elementos se pueden visualizar en forma de gráfico, con información sobre su contribución al riesgo general. Dado que el gráfico muestra información sobre la importancia de cada relación, se puede utilizar para priorizar tareas. Como se puede observar en la Figura 9, la DoS representa una amenaza mayor que la manipulación y, por lo tanto, debe tratarse primero. Esto se debe a que tiene un nivel de gravedad más alto (S5) que la manipulación (S4).
Figura 9. Visualización del riesgo.
Definición, implementación y verificación de contramedidas
Para reducir el riesgo de provocar perturbaciones en la señal (DoS) que envía la cámara al estimador de posición, se puede mitigar el riesgo reduciendo la viabilidad o con una contramedida. En este caso, el impacto se redujo incorporando un freno de emergencia. Esta medida tiene trazabilidad a la hoja de cálculo de amenazas con un vínculo en la hoja de contramedidas (Figura 10). Cada contramedida conduce a un objetivo de seguridad, que se traduce en al menos un requisito derivado. En este caso, el requisito es que el robot se detenga en menos de un segundo desde la detección de las perturbaciones. También está vinculado para permitir trazabilidad y un análisis de impacto.
Figura 10. Vinculación de contramedidas con amenazas.
Comprobación de congruencia e integridad
Hasta el momento, hemos identificado amenazas, evaluado sus riesgos y definido contramedidas para casos con un riesgo inaceptable. El siguiente paso es desarrollar contramedidas. Antes de entregar los objetivos de seguridad, verifique lo siguiente para asegurarse de que el modelo de amenazas y riesgos es válido:
- Se ha identificado al menos una amenaza por activo (noción de cobertura total).
- Se han revisado todas las amenazas.
- Se han asignado contramedidas cuando el riesgo es demasiado alto.
- Se han creado requisitos (por ejemplo, objetivos de seguridad) y se han vinculado con las contramedidas.
- No existen vínculos rotos entre amenazas, activos, modelos y análisis de seguridad.
Empleando una única llamada a función, es posible validar todo esto y generar una gráfica (Figura 11).
Figura 11. Validación del modelo de amenazas y riesgos.
Implementación de contramedidas
Una vez definidas las contramedidas, es el momento de implementarlas en el modelo. En el modelo de Simulink® del controlador, se utiliza MATLAB para agregar un bloque Function (Figura 12) que está vinculado con el requisito de trazabilidad.
Figura 12. Implementación de un freno de emergencia con un requisito vinculado.
Verificación y validación
Una vez realizada la implementación, el siguiente paso es modelar el ataque y verificar la funcionalidad de la contramedida. Esto se puede lograr con Simulink Fault Analyzer, que se utiliza para modelar y simular el ataque. La Figura 13 muestra la configuración utilizada para modelar el ataque.
Figura 13. Cuadro de diálogo de fallo con el activador resaltado.
Después de activar el fallo y ejecutar el modelo, se pueden observar las señales más de cerca con Simulation Data Inspector (SDI), como se muestra en la Figura 14. También puede ver las respuestas al ataque utilizando Navigation Toolbox™, como se muestra en la Figura 15. Estas herramientas permiten verificar visualmente que la contramedida funciona según lo previsto. Este flujo de trabajo se puede escalar empleando el marco de Simulink Test Manager para garantizar que toda la funcionalidad se verifica correctamente.
Figura 14. Punto en que se inyecta un ataque en Simulink Data Inspector.
Figura 15. Visualización de un ataque con contramedidas (izquierda) y sin contramedidas (derecha).
Conclusión
Un marco de análisis de seguridad basado en modelos ofrece un flujo de trabajo con trazabilidad integrada, personalización para cumplir con los estándares de conformidad correspondientes, y capacidad de automatizar tareas, lo que garantiza la congruencia entre el diseño y el análisis. Con este flujo de trabajo optimizado, puede acelerar la verificación y validación adelantándolas en el proceso de diseño para reducir el tiempo y los costes de desarrollo. Desde la detección de amenazas potenciales hasta la definición y simulación de la eficacia de las contramedidas, pasando por la cuantificación y la toma de decisiones sobre los riesgos, este enfoque integral garantiza la cobertura del proceso de seguridad.
Referencias
The MITRE Corporation. “CAPEC - Common Attack Pattern Enumeration and Classification (CAPEC™)”. Fecha de consulta: 18 de marzo de 2025.
The MITRE Corporation. “MITRE ATT&CK®”. Fecha de consulta: 18 de marzo de 2025.
The MITRE Corporation. “MITRE EMB3D™”. Fecha de consulta: 18 de marzo de 2025.
