"Chef, tenemos un agujero de seguridad!"
- Bueno, al menos algo está a salvo con nosotros ...Hola Habr!
En los comentarios
a la publicación anterior sobre InoThings ++, expresaron la opinión de que en Internet de las cosas hay un área de discusión más importante que la intervención del gobierno: esta es el área de garantizar la seguridad del dispositivo. Desde todos los puntos de vista.
Puedo argumentar aquí con una sola cosa: que una discusión de los problemas de seguridad debe llevarse a cabo en un formato de mesa redonda; Por esta razón, dejaremos la mesa redonda tal como está, sobre la necesidad (o innecesaria) de las normas nacionales y, en general, la interferencia del gobierno en la industria, pero hablaremos sobre la seguridad por separado.
¿Por qué la seguridad generalmente se considera en IoT como algo separado y específico, a diferencia de la seguridad en los sistemas de TI clásicos?
Sí, en general, porque los sistemas IoT son similares a los clásicos solo por parte del usuario que ve hermosas imágenes en la pantalla del monitor o controla una bombilla desde un teléfono inteligente, pero en el interior, a un nivel bajo, son completamente, completamente diferentes.
Y, desafortunadamente, todavía nos tragamos muchas veces con autores de productos que no entienden las diferencias de enfoque y problemas.
El "Internet de las cosas" es, ante todo, una historia sobre dispositivos asequibles, baratos, compactos, económicos y, por lo tanto, extremadamente masivos conectados a redes de datos locales o globales.
¿Qué significa esto en la práctica?
• Generalmente una
conexión inalámbrica . En alambre confiamos, por supuesto, solo el alambre es costoso; aquellos que hicieron una casa inteligente con cable entienden que esto significa una revisión importante con la colocación de bajo voltaje en todos los rincones. ¿Y si no se puede tender el cable?
En realidad, el rápido desarrollo de IoT comenzó con la llegada de conexiones inalámbricas baratas, económicas y de largo alcance, desde Wi-Fi doméstico y BLE hasta LoRaWAN, Sigfox, NB-IoT, etc. Conexiones que permitieron saturar un determinado espacio con sensores sin molestarse con su potencia y conexión.
Sin embargo, la radio no es solo conveniencia, sino también una maldición. Si para conectarse al cable, los vecinos necesitan abrir las cerraduras de su puerta, entonces no solo "escuchan" su hogar inalámbrico casi siempre, sino que también pueden bloquearlo o incluso simularlo.
• Como norma,
modos de funcionamiento extremadamente
económicos del canal de radio : un dispositivo sin una fuente de alimentación constante debe estar protegido por una batería. Guardar en el canal de radio resulta en el hecho de que actualizar el firmware del dispositivo por aire es imposible o no tiene sentido debido al hecho de que un episodio de la actualización consume decenas de por ciento de la batería disponible.
En consecuencia, la calidad inicial del código y los protocolos adquiere una importancia extremadamente alta: si se descubre un agujero fatal en ellos, el fabricante, por supuesto, podrá cargar un nuevo archivo en su sitio web, pero no tendrá sentido.
• Típicamente,
procesadores de baja potencia y
baja potencia . Un sensor IoT típico hoy en día está construido en procesadores de la clase desde STM32L0 hasta el STM32L4 más joven, y simplemente debido a las limitaciones en la memoria y la potencia de procesamiento (así como el canal de radio, ver arriba) puede no tener complicados esquemas de autorización, autenticación y otros tipos de protección. . Además, la baja potencia también puede significar la ausencia de memoria "adicional" necesaria para actualizar el firmware por el aire: el canal de radio poco confiable significa la incapacidad de colocar el firmware directamente en un flash "en vivo", y puede que no haya memoria para guardarlo en un área separada con la posterior reescritura del firmware en funcionamiento .
Y sobre todo esto, la masa y la ubicuidad abren sus alas, lo que en la práctica significa que el propietario no tiene control efectivo sobre el acceso a los dispositivos.
Cuando tenía cuatro dispositivos Wi-Fi en su casa (un enrutador, una computadora portátil y dos teléfonos inteligentes), el problema de perderlos no era muy grave, porque ninguno de ellos era un incidente arrojable.
Cuando tenga tres o cuatro docenas de bombillas inteligentes, interruptores, sensores de temperatura y el demonio en su casa, ¿qué más? Lo más probable es que envíe otra quemada o simplemente una bombilla vieja a la basura sin siquiera pensar que continúa almacenando la llave de forma segura en su flash. desde su red wifi.
Además, si no estamos hablando de la escala del apartamento, sino del sitio de la cabaña, el hotel o la fábrica, ni siquiera controla el acceso a los dispositivos IoT. Cualquiera puede desenroscar la bombilla, drenar las llaves de acceso y atornillarla en media hora, y ni siquiera lo notará.
Los dispositivos pueden ser clonados. Puede leer claves y certificados desde dispositivos. El firmware modificado se puede cargar a los dispositivos.
La pregunta aquí no es que todo esto no se pueda hacer con un enrutador Wi-Fi, es posible, por supuesto. El problema es la transición de la cantidad a la calidad: con el aumento exponencial prometido en el número de dispositivos IoT, tales ataques se vuelven significativos y realizables. De hecho, la historia con las cámaras IP se repite: aunque había pocas de ellas, nadie pensó que las cámaras con el mismo orificio en el firmware serían suficientes para tener sentido escribir un script que las reúna en una botnet gigante que podría inundar GitHub con Twitter
Cómo terminó,
todos ustedes lo saben .
En la seguridad de la información clásica, se cree que si un atacante tiene acceso físico completo al dispositivo protegido, bueno, en general, este no es el final, pero todo es malo. En IoT en este contexto, "todo está mal": esto no es el resultado de los actos maliciosos de alguien, sino el estado permanente e inicial del sistema.
El problema de seguridad en IoT no es el problema de mañana. Este es un problema hoy. Si no lo resuelve, mañana no será un problema, sino un desastre.
En InoThings ++, nosotros, entre otras cosas, sin duda queremos hablar de esto también, y de cómo dejar en claro al desarrollador que IoT trae modelos de amenazas completamente nuevos y hablar sobre qué hacer al respecto.
Presentaré algunos informes.
Un informe introductorio sobre los problemas de protección de los dispositivos IoT y las nuevas amenazas específicas de IoT, con un análisis de la legislación rusa y las recomendaciones que ya se han emitido, y aún no son requisitos, de organizaciones extranjeras, incluidos
NIST ,
ENISA ,
IIC y
otras (enlaces bajo los nombres no solo enlaces, sino también los documentos relevantes: realmente, realmente recomiendo leerlos si tiene algo que ver con el desarrollo de dispositivos IoT).
Este informe es simplemente imprescindible para los integradores y desarrolladores que recientemente ingresaron al mercado de IoT y aún no se han dado cuenta de las posibles consecuencias de esto. Aquí no hay otra opción: estas son cosas que simplemente no puede ignorar sobre la existencia, y si no lo comprende hoy, mañana puede terminar en un desastre para usted y su negocio, para lo cual simplemente no tendrá tiempo para prepararse.
No es en absoluto un informe técnico, sino también importante: que ahora estamos viviendo en un momento maravilloso, cuando cada fabricante puede susurrar en sus dispositivos lo que su corazón desea, y no habrá nada para él.
Más precisamente, sobre el hecho de que esta vez pronto terminará: la necesidad de cambios legislativos relacionados con IoT y dispositivos inteligentes en general ha madurado, y la industria aún recibirá su GDPR aquí.
El primer paso (necesario, pero no suficiente) para la seguridad de los sistemas IoT es escribir código confiable. Una forma de aumentar su confiabilidad es cumplir con los estándares desarrollados en industrias que son décadas más antiguas que IoT, por ejemplo, el estándar de calidad de código MISRA C "automotriz".
El cumplimiento de MISRA C y el uso de analizadores de código estático, por supuesto, no le garantiza una fiabilidad absoluta; sin embargo, puede salvarlo de una cantidad bastante grande de errores, comenzando con descuido banal, copiar y pegar errores tipográficos. Desafortunadamente, la práctica de escribir código confiable está muy poco extendida entre los programadores integrados, y espero que Philip inspire al menos a algunos de los asistentes a la conferencia para tratar de implementar estas prácticas en su trabajo.
Otra forma de aumentar la confiabilidad del código es en lugar de alentar a disparar con sus propias piernas y otra selección natural de idiomas tipo C, cambiar a idiomas que originalmente se concibieron como más confiables y no le permiten cometer muchos errores (ahora escribo con toda responsabilidad, como persona, ayer a las dos por la noche, detectando un evento de desbordamiento de pila que ocurrió en momentos aleatorios, a veces después de decenas de minutos de operación activa del firmware).
Sin embargo, cuán brillantes son las perspectivas, la neblina y el presente de tales lenguajes, por ejemplo, Rust, el principal candidato para el papel del futuro estándar en el campo del software embebido, para la mayoría de los programadores en ejercicio pertenece a la categoría "Escuché, es genial, pero ¿qué tengo ahora?". Esto es especialmente promovido por la curva de bombo tradicional, a lo largo de la cual viaja Rust: subió a su cima, sin estar abiertamente preparado para un uso práctico serio, después de lo cual muchos desarrolladores simplemente dejaron de monitorear su futuro destino.
Entonces, de hecho, en el informe, Eugene le dirá cuál es el destino actual de Rust, por qué ya puede considerarse como un idioma de trabajo y cuántos kilómetros de terminaciones nerviosas le costará usarlo aquí y ahora.
Y, por último, un informe puramente práctico: sobre lo que se necesita para garantizar la confianza en sus dispositivos, si ya los ha instalado unos cientos de piezas, y al mismo tiempo saber con seguridad que en cualquier momento al menos varias docenas de ellos están en los gabinetes, que olvidó bloquear y en el que en cualquier momento cualquiera puede ingresar, fusionar el firmware y llenarlo con algo parecido al mismo dispositivo, pero no el suyo, pero sí.
Además, no es suficiente controlar estos dispositivos: primero deben implementarse, lo que desde el punto de vista de la autenticación también puede ser una tarea bastante no trivial.
InoThings ++ 2019
Por lo tanto, todos estos informes, así como muchos otros, se pueden escuchar en la conferencia InoThings ++, y lo que es especialmente valioso no es solo escuchar, sino finalizar sus discursos al final del discurso y llevarlos al margen para continuar la conversación. En realidad, esto es lo que hace que una visita animada a las conferencias de tecnología sea valiosa: después de seis meses mirando una grabación de una actuación o un álbum en una presentación de diapositivas con un ojo, no puede levantarse y pedir más detalles en ese momento, llevar el altavoz a una taza de café para hablar con más detalle sobre sus proyectos, y Y así sucesivamente.
Por lo tanto, ven. Las entradas
actualmente cuestan 15 mil rublos , y créanme, para una conferencia de este nivel y con tales oradores, esto es muy modesto.
