La aplicación de parches y actualizaciones es una práctica profundamente arraigada en el pensamiento, los estándares y la legislación emergente de la comunidad de seguridad de dispositivos. Sin embargo, el aislamiento mediante particionamiento es otro enfoque viable para la seguridad, que ofrece muchas ventajas.
Parches
La principal ventaja de parchear y actualizar vulnerabilidades conocidas es que estas suelen quedar corregidas de forma permanente, lo que resulta demostrable para el cumplimiento normativo y legal. Entre los problemas de este enfoque se incluyen:
- El firmware moderno de IoT contiene decenas, cientos o incluso miles de componentes, y estos suelen tener decenas de dependencias propias.
- Encontrar vulnerabilidades en los componentes de un SBOM no es un proceso sencillo; existen varias bases de datos y la identificación de componentes no es consistente.
- Lograr SBOM completos y precisos al 100% sigue siendo un objetivo difícil.
- Un alto porcentaje de vulnerabilidades en componentes no son explotables; corregir las no explotables es una pérdida de tiempo.
- Se descubren nuevas vulnerabilidades más rápido de lo que se pueden parchear: de la segunda mitad de 2020 a la primera de 2021, las vulnerabilidades ICS-CERT aumentaron un 44%.
- El desarrollo de parches lleva días o semanas, y el tiempo medio para aplicar parches críticos es de 16 días, durante los cuales el funcionamiento del dispositivo se ve afectado.
- El 60% de los clientes que sufrieron una brecha tenían un parche para la vulnerabilidad explotada, pero no lo instalaron a tiempo.
- Los parches a menudo no funcionan porque los hackers ya han desarrollado ataques más sofisticados.
- Los ataques son especialmente probables durante y después de las actualizaciones de firmware.
- Parchear puede crear nuevos errores y vulnerabilidades, especialmente si no lo realiza el programador original.
- El software de código abierto puede no actualizarse lo suficientemente rápido o no actualizarse en absoluto, y el equipo de seguridad del OEM puede no entenderlo bien para parchearlo.
- Parchear no ofrece protección contra días cero ni contra ataques internos.
- Los equipos de seguridad se ven abrumados por incidentes e informes de vulnerabilidades, hasta 500 por semana.
- El 80% de las organizaciones reportan escasez de personal de seguridad.
- En un sistema sin particiones, la violación de cualquier vulnerabilidad expone datos privados, permite interrumpir el funcionamiento normal y penetrar en el sistema mayor, equiparando todas las vulnerabilidades y aumentando la carga de trabajo del equipo de seguridad.
- Actualizar todo el firmware del dispositivo requiere detener el funcionamiento normal, pero muchos dispositivos IoT o embebidos deben funcionar 24/7.
- Los OEM de IoT no conformes enfrentan muchas consecuencias, pero según una encuesta reciente, el 76% no cumple con el primer requisito de la Ley PSTI del Reino Unido y el 95% no cumple ambos requisitos, a pesar de que la ley ya está en vigor.
Claramente algo está mal. Creo que necesitamos reexaminar el proceso de diseño en sí mismo.
Aislamiento
La figura anterior ilustra el principio principal del aislamiento mediante particionamiento para procesadores Cortex-M. El firmware primario incluye código de misión crítica, el RTOS y servicios del sistema, código de seguridad, manejadores de excepciones y otro código de confianza. Este suele ser código heredado que no solo es confiable sino también probado en campo. No necesita ser particionado y puede ejecutarse normalmente con casi ninguna modificación. El código primario se ejecuta en modo privilegiado (pmode).
Luego está la barrera pmode y, por encima, el firmware secundario que se ejecuta en modo no privilegiado (umode). Este código incluye pilas de red, sistemas de archivos, pilas USB, controladores y código de aplicación que no es fundamental para el funcionamiento del dispositivo. Puede ser muy complejo y mucho más grande que el código primario. Gran parte puede ser código de terceros y de código abierto. Este es el código que crea problemas en la cadena de suministro y que requiere la creación de listas de materiales de software (SBOM) para su gestión. Está básicamente fuera del control del OEM.
La barrera pmode es muy importante. Está implementada por el procesador Cortex-M y protege todo el código y datos por debajo de ella del código umode. Aparte de generar fallos, el código umode solo puede acceder a pmode mediante la excepción SVC, que se utiliza para llamadas al sistema del RTOS y otras. Por lo tanto, el código umode no puede acceder a datos sensibles almacenados en la RAM de pmode, ni puede hacer que el código pmode se comporte mal (suponiendo que los parámetros de las llamadas SVC se verifiquen antes de su uso y que los servicios que dañan el sistema no estén disponibles en umode).
En teoría, todo el código umode podría colocarse en una sola partición. Sin embargo, se logra una mejor seguridad si cada módulo de firmware, como la pila de red y su controlador, se coloca en su propia partición aislada. La ventaja es que si un hacker irrumpe en una partición, mediante una vulnerabilidad en esa partición o por cualquier otro medio, no puede ir más allá: no puede acceder a datos ni código fuera de la partición en la que ha irrumpido.
Desafortunadamente, esto no es suficiente. También es necesario imponer limitaciones sobre lo que se puede hacer desde dentro de una partición vulnerada para proteger el resto del sistema. Esto requiere limitaciones en tiempo de ejecución, tokens para proteger el acceso y control de objetos del sistema, límites sobre qué interrupciones se pueden controlar, niveles de privilegio de partición, listas de clientes permitidos para servidores y otras limitaciones. Al igual que las vulnerabilidades, la necesidad de nuevas limitaciones probablemente crecerá con el tiempo, pero solo necesitan implementarse en un lugar: el RTOS, y solo aplicarse a particiones no confiables.
Además de esta protección, el particionamiento ofrece muchas otras ventajas:
- Protección contra vulnerabilidades de día cero y no parcheadas.
- Protección contra ataques internos mediante el aislamiento de equipos DevOps.
- Reducción de la urgencia de los parches de seguridad.
- Modificación mínima del código de confianza (hay demostraciones disponibles).
- Apagado, recuperación y actualización por partición.
- Solución única para dispositivos que no se pueden actualizar.
- Marcos de seguridad basados en particiones con portales creados desde el inicio del desarrollo de nuevos productos.
- Traslado de código vulnerable a particiones umode, permitiendo una mejora iterativa de la seguridad en productos existentes.
Los días cero son vulnerabilidades que se ponen en acción sin previo aviso (por lo tanto, hay 'cero días' para corregirlas). En lo que respecta al particionamiento, no hay diferencia entre días cero y vulnerabilidades no parcheadas. La protección contra días cero es particularmente importante contra actores estatales, que tienen grandes inventarios de días cero, muchos de los cuales han comprado a hackers no éticos.
Los ataques internos están creciendo. Si hay grandes sumas de dinero disponibles, algunos empleados pueden ser sobornados. Para contrarrestarlo, es posible crear un marco de particiones aisladas de modo que cada programador o equipo pequeño trabaje en una partición dentro del marco y no pueda ver otro código. Las otras particiones se acceden mediante portales, y el código interno está oculto o eliminado. Solo los programadores más confiables tienen acceso a todo el código. Esto se llama siloing y también se puede aplicar al equipo de soporte.
Como se mencionó, el código pmode suele estar probado en campo y probablemente requiera pocas actualizaciones, mientras que el código umode es nuevo o es software de procedencia desconocida y, por lo tanto, probablemente contenga muchas vulnerabilidades. Por lo tanto, cuando ocurre un ataque, lo más probable es que esté en el firmware secundario, y el dispositivo puede continuar realizando sus funciones principales mientras el ataque esté aislado. Además, dado que una partición se puede apagar, eliminar el malware y reiniciar, es probable que la partición atacada se recupere y funcione con normalidad una vez que termine el ataque.
Las capacidades anteriores son cruciales para dispositivos que no se pueden actualizar. También son importantes para dispositivos que sí se pueden actualizar. Aspectos importantes de esto son:
- Reducción de la urgencia de los parches si el dispositivo puede continuar realizando su función principal y la función secundaria atacada es de baja importancia o puede recuperarse.
- Permite al equipo de seguridad clasificar las vulnerabilidades según la importancia de las particiones en las que ocurren.
- Si el SBOM del proyecto revela que ciertos módulos tienen un gran número de vulnerabilidades no parcheadas, estos módulos se pueden colocar en particiones umode aisladas de bajo privilegio. Con suerte, esto cumplirá con los requisitos regulatorios.
- Las actualizaciones solo de partición permiten que el dispositivo continúe realizando sus funciones principales durante el proceso de actualización.
- El código primario no se expone cuando se actualiza el código secundario.
El aislamiento mediante particionamiento podría parecer una solución temporal, pero si un hacker no puede lograr sus objetivos, ¿por qué perdería tiempo hackeando una vulnerabilidad en una partición? Es más probable que elija otro objetivo.
Este artículo no pretende menospreciar prácticas de seguridad como HRoT, arranque seguro, actualización segura, cifrado, firma de código, validación, codificación segura, pruebas estáticas de código, etc. Todas son partes necesarias de una estrategia de seguridad multicapa. Tampoco vemos el particionamiento como un reemplazo de los parches. Más bien, vemos el particionamiento como la creación de un espacio de decisión bidimensional para los OEM. Un eje es el número de vulnerabilidades parcheadas; el otro es el número de vulnerabilidades aisladas. Esto proporciona una solución de seguridad más flexible y práctica que el parcheo unidimensional.
Conclusión
Crear equipos de seguridad para procesar informes de vulnerabilidades, determinar qué corregir, hacer parches y actualizar dispositivos IoT y embebidos está al alcance de los grandes OEM. Sin embargo, no es el caso de los OEM pequeños y medianos. Carecen de la experiencia y los recursos financieros para hacerlo. Por lo tanto, necesitan una solución más única y completa, como la que ofrece el particionamiento. Incluso para los grandes OEM, el particionamiento podría reducir los gastos y la presión sobre sus equipos de seguridad, y ayudar con la escasez de profesionales de ciberseguridad.
Para obtener información sobre el particionamiento de MCU Cortex-M, visite www.smxrtos.com/securesmx.
