Estándares para mantener actualizada la seguridad de los dispositivos

Dado que los dispositivos IoT generalmente se construyen con bajos márgenes de beneficio y especificaciones de baja potencia, la funcionalidad generalmente se limita a lo que se necesita. Pero para un dispositivo que se espera que dure varios años, habrá vulnerabilidades de seguridad y problemas que deben corregirse (vea la botnet Mirai como ejemplo)

Como fabricante de IoT, ¿cómo puedo habilitar el parcheo o la actualización de algoritmos de encriptación o protocolos de seguridad de forma remota, o simplemente asegurarme de que el dispositivo se mantenga seguro? ¿Qué estándares debo seguir?

¿Cómo permiten los fabricantes de IoT parchear o actualizar algoritmos de encriptación o protocolos de seguridad de forma remota o simplemente para garantizar que el dispositivo se mantenga seguro?

Una gran cantidad de fabricantes de IoT tienen una solución simple para esto: "no molestarse" . Estos tienden a ser los mismos desarrolladores que agregan contraseñas predeterminadas (o incluso inmutables) a sus dispositivos, lo que llevó a Mirai en primer lugar.

Como se menciona en la respuesta de Rory , existen costos considerables para proporcionar tanto los mecanismos como el tiempo de desarrollo real para diseñar e implementar las soluciones. Sospecho firmemente que sin la presión reguladora (o la demanda del consumidor, que no parece ser el caso), no habrá ningún incentivo para que un fabricante aumente los precios de sus productos para mayor seguridad. Australia parece estar dando este paso al considerar un sistema obligatorio de clasificación de seguridad para todos los dispositivos IoT.

Creo que para la mayoría de los fabricantes, la mejor idea es conseguir que otra persona maneje la seguridad. Así como la mayoría de los desarrolladores web usan marcos establecidos como Django y Ruby on Rails para evitar cometer los mismos errores una y otra vez, los desarrolladores de IoT deberían hacer lo mismo. Existen varias opciones, según la complejidad de su dispositivo:

• Los dispositivos de gama alta podrían usar sistemas operativos como Ubuntu IoT o Windows 10 IoT Core, donde las actualizaciones de seguridad las realiza el desarrollador del sistema operativo y se envían automáticamente. Gran parte de esto no es específico de IoT, pero es mucho más preferible que cada dispositivo IoT use un sistema operativo interno personalizado que es poco probable que reciba mantenimiento.

• Los dispositivos de gama baja como los módulos ESP8266 son quizás más limitados, ya que no pueden ejecutar sistemas operativos tan complejos y tienden a ejecutar código desarrollado específicamente para ese dispositivo. Todavía hay opciones como Mongoose OS que ofrecen actualizaciones de firmware por aire

Los fabricantes de IoT generalmente deberían aprovechar las soluciones existentes donde estén disponibles. Los desarrolladores web no suelen recrear un marco web para cada nuevo sitio web, entonces, ¿por qué IoT debería ser sustancialmente diferente? La respuesta de Rory ofrece una excelente lista de características que debe implementar un buen sistema operativo para IoT, y solo usar un "IoT OS" no solucionará todos sus problemas. Como explica esta guía de Windows IoT , uno debe tomar medidas para garantizar que el hardware y el firmware estén asegurados, así como el sistema operativo mismo. Las ideas en la respuesta de Rory son bastante completas a este respecto.

Aquí hay algunos ejemplos de los sistemas operativos que sugerí sobre qué sistemas usan para actualizar la seguridad:

• Windows IoT:

  • Funciones automáticas y actualizaciones de seguridad cuando está conectado a Internet
  • Con Azure IoT Suite, cada dispositivo tiene un certificado X.509 para autenticarse en el concentrador. Esto también asegura que si un dispositivo se ve comprometido, otros no se ven afectados

• Ubuntu Core :

  • Actualizaciones automáticas desatendidas para seguridad
  • "Actualizaciones inalámbricas transaccionales, con funciones completas de reversión"

Moran publicó este borrador de IETF titulado Una arquitectura de actualización de firmware para dispositivos de Internet de las cosas el 30 de octubre de 2017.

Un resumen clave delineado en Bleeping computer es

• El mecanismo de actualización debe funcionar igual incluso si el binario del firmware se entrega a través de Bluetooth, WiFi, UART, USB u otros medios.
• El mecanismo de actualización debe funcionar en un tipo de entrega de difusión, permitiendo que las actualizaciones lleguen a múltiples usuarios a la vez.
• La seguridad de extremo a extremo (criptografía de clave pública) debe usarse para verificar y validar las imágenes de firmware.
• Se deben evitar los ataques de reversión.
• Toda la información necesaria para que un dispositivo tome una decisión sobre la instalación de una actualización debe caber en la RAM disponible de un dispositivo IoT restringido. Esto evita el agotamiento de la escritura flash.
• Una falla de energía en cualquier momento durante el proceso de actualización no debe causar una falla del dispositivo.
• El mecanismo de actualización de firmware no debe requerir cambios en los formatos de archivo de firmware existentes.
• El nuevo mecanismo de actualización de firmware debe poder funcionar con un pequeño gestor de arranque, específico para la mayoría de los dispositivos IoT.
• El mecanismo de actualización debe tener en cuenta múltiples permisos. Por ejemplo, el autor del firmware y el propietario / operador del equipo deberán firmar una actualización de firmware para equipos de infraestructura crítica.
• La nueva arquitectura de actualización de firmware de IoT debe admitir archivos de manifiesto.

Esto es en gran medida un borrador, ya que esta es un área nueva. Mi expectativa es que se regirá más por la regulación que por la demanda del consumidor, ya que a los consumidores realmente no les importan las actualizaciones o la seguridad a menos que les afecten directamente. Cualquier mejora en esta área afectará el costo de los dispositivos.

Si el firmware de su dispositivo puede hacerse menos complejo que el gestor de arranque requerido para una actualización remota segura, entonces no implemente la actualización remota .

Sé que el consenso es tener un gestor de arranque seguro y robusto, con una sólida autenticación de cifrado público, mecanismos seguros de reinversión, tal vez una pila de red básica, y luego poner encima un RTOS, con una pila de red IP + TLS completa, luego agregar Además de eso su aplicación. Esto es pura locura para un dispositivo de bajo costo y bajo consumo. En mi humilde opinión, esto lleva a productos que se actualizan cada semana más o menos, que tienden a molestar a los usuarios porque a veces las actualizaciones comienzan en el momento equivocado, fallan o rompen algo. Las actualizaciones también consumen mucha energía, por lo que el usuario debe cargar más a menudo. Y la seguridad aún está lejos de estar garantizada ya que la superficie de ataque es grande.

Su dispositivo está haciendo una detección / actuación básica, ¿tal vez alguna activación / visualización local pero no mucho? Salta todo eso.

Escriba código simple, use una pila muy básica, audítelo a fondo, haga alguna verificación formal si es posible Y luego puede estar relativamente seguro de que su dispositivo no tendrá problemas de seguridad durante la próxima década.

Si todo lo que tienes es un martillo, todo parece un clavo. Y es por eso que la mayoría de los codificadores intentan escribir código para asegurar su código existente no seguro. Escribir menos código no siempre es algo natural.