¿Existe un certificado para indicar el nivel de seguridad de los dispositivos IoT?

11

¿Existe algún certificado confiable para dispositivos IoT que pueda usarse para comparar la seguridad proporcionada de estos dispositivos? 1

Actualmente, el panorama de IoT está completamente disperso con diferentes protocolos, estándares y soluciones patentadas. Por otro lado, los dispositivos IoT caen en botnets como moscas . ¿Existe algún estándar en el que los clientes puedan confiar para que el dispositivo cumpla con un cierto nivel de seguridad? ¿Quizás incluso un certificado que garantice la seguridad proporcionada?

Si no existe un estándar actual, ¿existen iniciativas prometedoras para crear dicho estándar?


1: Descargo de responsabilidad: Esto se basa en esta pregunta del Área 51 de un usuario que aparentemente no se comprometió con el sitio en la etapa de compromiso. Quiero publicarlo para ayudar a definir el alcance del sitio.

Helmar
fuente

Respuestas:

10

UL (anteriormente Underwriters Laboratories) proporciona el Programa de garantía de ciberseguridad para certificar que un dispositivo de Internet de las cosas está, en su opinión, protegido de la mayoría de las amenazas principales.

UL parece ser muy respetado en sus procesos de certificación, según Ars Technica :

UL, la organización de normas de seguridad de 122 años cuyas diversas marcas (UL, ENEC, etc.) certifican las normas mínimas de seguridad en campos tan diversos como el cableado eléctrico, los productos de limpieza e incluso los suplementos dietéticos, ahora está abordando la ciberseguridad de Internet de Dispositivos Things (IoT) con su nueva certificación UL 2900.

UL describe su certificación como involucrando:

  • Pruebas fuzz de productos para identificar vulnerabilidades de día cero en todas las interfaces
  • Evaluación de vulnerabilidades conocidas en productos que no han sido parcheados usando el esquema de Enumeraciones de Vulnerabilidad Común (CVE)
  • Identificación de malware conocido en productos
  • Análisis de código fuente estático para debilidades de software identificadas por Enumeraciones de Debilidad Común (CWE)
  • Análisis binario estático para las debilidades del software identificadas por Common Weakness Enumerations (CWE), software de código abierto y bibliotecas de terceros
  • Controles de seguridad específicos identificados para su uso en productos que reducen el riesgo de seguridad [...]
  • Pruebas de penetración estructuradas de productos basadas en fallas identificadas en otras pruebas.
  • Evaluación de riesgos de mitigación de seguridad del producto diseñada en productos.

Sin embargo, el proceso exacto en el que UL examina los dispositivos no está claro (a menos que pague para comprar el conjunto completo de especificaciones), como señala Ars Technica (y critica):

Cuando Ars solicitó una copia de los documentos de UL 2900 para ver más de cerca el estándar, UL (anteriormente conocido como Underwriters Laboratories) se negó, lo que indica que si deseamos comprar una copia, el precio de venta, alrededor de £ 600 / $ 800 por el total conjunto, fuimos bienvenidos a hacerlo. Los investigadores de seguridad independientes también son, debemos asumir, bienvenidos a convertirse en clientes minoristas de UL.

Aunque se respeta a UL, no podemos suponer que su certificación sea particularmente sólida en términos de seguridad sin un mayor escrutinio, aunque sí satisface la pregunta original.

Desafortunadamente, no pude encontrar estándares / certificaciones abiertas para la seguridad, aunque esto es probable porque los recursos necesarios serían demasiado grandes para una asociación sin fines de lucro.

Aurora0001
fuente
3

Quiero agregar a la respuesta de Aurora0001 que solo podemos proteger contra amenazas conocidas.

Recientemente, hemos visto los ataques Spectre y Meltdown contra el hardware . Si bien las CPU de Intel no se usan comúnmente en dispositivos IoT, probablemente encontraremos problemas de seguridad con el hardware IoT en el futuro. Anteriormente hemos visto Rowhammer y Heartbleed , como errores generales de clase de sistema, que afectan a un gran número de sistemas. A medida que IoT crezca, creo que será más común ver tales vulnerabilidades.

Por lo tanto, me centraría menos en las certificaciones de seguridad y más en:

  • Apertura, para que terceros puedan evaluar el software.
  • Duración de soporte declarada, donde el fabricante garantiza actualizaciones de seguridad
  • Capacidad de actualización, incluidas las actualizaciones automáticas como configuración predeterminada.

Si se declara que un dispositivo está bajo soporte durante mucho tiempo, y el valor predeterminado es la actualización automática del software cuando se producen nuevas versiones, el impacto de los problemas de seguridad se reducirá. La certificación solo le indicará que no había errores de seguridad conocidos cuando se envió el producto.

vidarlo
fuente
Heartbleed puede ser un error de clase de sistema desde el punto de vista de la implementación del sistema, pero sigue siendo un error en un software específico que solo necesita actualizarse. Mejores ejemplos serían los ataques al protocolo en sí, como BEAST y CRIME.
Gilles 'SO- deja de ser malvado'
El punto es que se pueden encontrar errores en lugares poco probables (CPU) y en software conocido (Heartbleed), por lo que necesitamos parches y actualizaciones de software. Pero sí, hay una gran cantidad de errores para elegir.
vidarlo
Las certificaciones podrían incluir soporte de por vida o la posibilidad de actualizaciones de firmware, incluso apertura. Entonces, si bien tiene razón en que esos son puntos muy importantes, no entiendo por qué son incompatibles con las certificaciones en general.
Helmar
2
@Helmar Desafortunadamente, las certificaciones serias son prácticamente inherentes a un proceso pesado. Certificar la versión inicial y el proceso de actualización es una cosa, pero certificar cada actualización antes de que se implemente agrega una sobrecarga significativa, lo que dificulta establecer un buen proceso de certificación (donde las actualizaciones de seguridad tendrían que certificarse después del hecho, lo que va en contra de el grano de la certificación, ya que significa que el dispositivo ejecutará versiones no certificadas).
Gilles 'SO- deja de ser malvado'
@Gilles Estoy de acuerdo en que uno solo podría certificar los procesos de calidad del desarrollo de software o algo así. Certificar cada versión de software no es realmente una opción.
Helmar