Existe-t-il un certificat pour indiquer le niveau de sécurité des appareils IoT?


11

Existe-t-il un certificat fiable pour les appareils IoT, qui peut être utilisé pour comparer la sécurité fournie par ces appareils? 1

Actuellement, le paysage IoT est complètement parsemé de différents protocoles, normes et solutions propriétaires. D'un autre côté, les appareils IoT tombent sur des réseaux de zombies comme des mouches . Existe-t-il une norme dans laquelle les clients peuvent faire confiance pour que l'appareil se conforme à un certain niveau de sécurité? Peut-être même un certificat attestant de la sécurité fournie?

S'il n'y a pas de norme actuelle, existe-t-il des initiatives prometteuses pour créer une telle norme?


1: Avertissement: Ceci est basé sur cette question de la zone 51 d'un utilisateur qui ne s'est apparemment pas engagé sur le site au stade de l'engagement. Je veux le poster pour aider à définir la portée du site.

Réponses:


10

UL (anciennement Underwriters Laboratories) propose le programme d'assurance de la cybersécurité pour certifier qu'un appareil Internet of Things est, à leur avis, protégé contre la plupart des menaces majeures.

UL semble être très respecté dans leurs processus de certification, selon Ars Technica :

UL, l'organisation de normes de sécurité vieille de 122 ans dont les différentes marques (UL, ENEC, etc.) certifient des normes de sécurité minimales dans des domaines aussi divers que le câblage électrique, les produits de nettoyage et même les compléments alimentaires, s'attaque désormais à la cybersécurité de l'Internet des Things (IoT) avec sa nouvelle certification UL 2900.

UL décrit leur certification comme impliquant:

  • Tests Fuzz de produits pour identifier les vulnérabilités Zero Day sur toutes les interfaces
  • Évaluation des vulnérabilités connues sur les produits qui n'ont pas été corrigés à l'aide du schéma CVE (Common Vulnerability Enumerations)
  • Identification des logiciels malveillants connus sur les produits
  • Analyse de code source statique pour les faiblesses logicielles identifiées par Common Weakness Enumerations (CWE)
  • Analyse binaire statique des faiblesses logicielles identifiées par Common Weakness Enumerations (CWE), logiciels open source et bibliothèques tierces
  • Contrôles de sécurité spécifiques identifiés pour une utilisation dans des produits qui réduisent le risque de sécurité [...]
  • Tests de pénétration structurée de produits basés sur des défauts identifiés dans d'autres tests
  • Évaluation des risques d'atténuation de la sécurité des produits conçue dans les produits.

Cependant, le processus exact dans lequel UL examine les appareils n'est pas clair (sauf si vous payez pour acheter l'ensemble complet des spécifications), comme le note Ars Technica (et le critique):

Quand Ars a demandé une copie des documents UL 2900 pour examiner de plus près la norme, UL (anciennement connu sous le nom de Underwriters Laboratories) a refusé, indiquant que si nous souhaitions acheter une copie - prix de détail, environ 600 £ / 800 $ pour le plein ensemble - nous étions invités à le faire. Les chercheurs indépendants en sécurité sont également, nous devons le supposer, les bienvenus pour devenir des clients de détail UL.

Bien que les UL soient respectés, nous ne pouvons pas supposer que leur certification est particulièrement solide en termes de sécurité sans un examen plus approfondi, bien qu'elle réponde à la question d'origine.

Malheureusement, je n'ai pas trouvé de normes / certifications ouvertes pour la sécurité, bien que cela soit probablement dû au fait que les ressources nécessaires seraient beaucoup trop importantes pour une association à but non lucratif.


3

Je veux ajouter à la réponse d'Aurora0001 que nous ne pouvons protéger que contre les menaces connues.

Récemment, nous avons vu les attaques Spectre et Meltdown contre le matériel . Bien que les processeurs Intel ne soient pas couramment utilisés dans les appareils IoT, nous trouverons probablement des problèmes de sécurité avec le matériel IoT à l'avenir. Auparavant, nous avons vu Rowhammer et Heartbleed , comme des bogues généraux de classe système, affectant un grand nombre de systèmes. À mesure que l'IoT se développe, je pense qu'il sera plus courant de voir de telles vulnérabilités.

Je me concentrerais donc moins sur les certifications de sécurité et plus sur:

  • Ouverture, afin que des tiers puissent évaluer le logiciel.
  • Durée de vie du support indiquée, où le fabricant garantit les mises à jour de sécurité
  • Évolutivité, y compris les mises à niveau automatiques comme paramètre par défaut.

Si un périphérique est déclaré comme étant pris en charge pendant une longue période et qu'il est par défaut mis à jour automatiquement le logiciel lorsque de nouvelles versions se produisent, l' impact des problèmes de sécurité sera réduit. La certification vous dira seulement qu'il n'y avait aucun bogue de sécurité connu lors de l'expédition du produit.


Heartbleed peut être un bogue de classe système du point de vue du déploiement du système, mais c'est toujours un bogue dans un logiciel spécifique qui doit juste être mis à niveau. De meilleurs exemples seraient une attaque contre le protocole lui-même, comme BEAST et CRIME.
Gilles 'SO- arrête d'être méchant'

Le fait est que des bogues peuvent être trouvés dans des endroits improbables (CPU) et dans des logiciels bien connus (Heartbleed), nous avons donc besoin de patcher et de mettre à jour les logiciels. Mais oui - il y a une pléthore de bugs à choisir.
vidarlo

Les certifications pourraient très bien inclure la durée de vie du support ou la possibilité de mettre à jour le micrologiciel, voire l'ouverture. Donc, si vous avez raison, ce sont des points très importants, je ne vois pas pourquoi ils sont incompatibles avec les certifications en général.
Helmar

2
@Helmar Malheureusement, les certifications sérieuses sont à peu près intrinsèquement un processus lourd. Certifier la version initiale et le processus de mise à jour est une chose, mais certifier chaque mise à jour avant son déploiement ajoute une surcharge importante, ce qui rend difficile l'établissement d'un bon processus de certification (où les mises à jour de sécurité devraient être certifiées après coup - ce qui va à l'encontre de le grain de la certification, car cela signifie que l'appareil fonctionnera des versions non certifiées).
Gilles 'SO- arrête d'être méchant'

@ Gilles J'accepte que l'on ne puisse que certifier les processus qualité du développement logiciel ou quelque chose comme ça. Certifier chaque version du logiciel n'est pas vraiment une option.
Helmar
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.