Close

IoT : la question du maintien en condition de sécurité

Parmi les problématiques de sécurité qui minent l’Internet des Objets (IoT) figure la difficulté, voire parfois l’impossibilité, d’assurer leur maintien en condition de sécurité (MCS) : il n’est pas toujours possible pour l’utilisateur de corriger les failles de sécurité découvertes à l’aide d’une mise à jour logicielle.

Les caractéristiques de ces dispositifs qui les rendent attractifs sont également celles qui rendent difficile leur sécurisation : faible coût, faible taille, accessibilité à distance. Conséquence de cela, un nombre important de ces objets sont produits en masse par des entreprises qui se focalisent sur la réduction des coûts, sans perspective de maintenance logicielle. Les objets qui avaient vocation à avoir un très long cycle de vie, comme des interrupteurs ou des serrures, sont remplacés aujourd’hui par des objets connectés qui deviennent obsolètes en quelques années.

Si cet état de fait est moins problématique pour des objets très basiques qui ont vocation à être jetables et donc disparaître avant de se révéler porteurs de vulnérabilités exploitables, ceci est plus difficilement acceptable pour les dispositifs plus complexes et au cycle de vie plus long. Il existe pourtant des exemples d’objets connectés qui bénéficient d’un réel suivi. On peut citer l’exemple des smartphones, pour lesquels l’industrie a beaucoup progressé dans ce domaine. On se situe ici dans le haut du panier en termes de valeur et de capacités pour un objet connecté, et il reste beaucoup à faire pour les objets intermédiaires au cycle de vie indéfini, qui peut aussi bien être déterminé par des critères d’obsolescence (subjectif) que de panne.

Pour demain, l’arrivée de la 5G laisse entrevoir une accélération du déploiement d’objets connectés directement à Internet, sans dispositif intermédiaire de sécurité. À l’aube de cette nouvelle vague, quel est l’état de l’art de la maintenance en condition de sécurité des objets connectés ? Quelles difficultés sont à surmonter et quelles sont les perspectives pour l’avenir ?

1.   Les difficultés de maintenance logicielle des objets connectés

Du côté du fabriquant, les plus petits dispositifs sont contraints par les très faibles ressources en mémoire ou en capacités dont ils disposent. Certains possèdent un type de microprocesseur qui ne contient qu’un jeu limité d’instructions, rendant certaines opérations impossibles. Ces limites empêcheront généralement le déploiement de solutions de détection de menace sur le dispositif lui-même (endpoint) et l’utilisation de chiffrement, renforçant encore davantage le risque et les possibilités de mise à jour.

D’autres dispositifs plus puissants voient leur capacité de mise à jour limitée par le régime juridique qui les encadre. Certains objets sont effectivement soumis à des certifications, qui ne valent que pour un produit défini, statique d’un point de vue matériel et logiciel : il ne sera pas possible de faire évoluer ce dernier sans que le produit final ait également été certifié. Ceci va concerner par exemple les dispositifs médicaux.

Du côté opérateur/utilisateur final, il existe plusieurs difficultés de maintien de contrôle :

  • La multiplication des dispositifs dans l’environnement rend difficile le maintien d’un inventaire et d’une cartographie des objets déployés ;
  • La difficulté à disposer d’une solution de suivi unificatrice : l’Internet des objets rassemble de nombreuses technologies de communication différentes (Cellulaire, WiFi, bluetooth, Zigbee, Sigfox, LoRaWAN, NFC, etc.) ;
  • Le risque de perte de fonctionnalité, notamment du côté de l’interopérabilité, voire l’échec du processus de mise à jour menant à une panne définitive.

2.   Quel mode de maintenance ?

Trois types de maintenance logicielle peuvent être distinguées :

  • Un système de mise à jour manuel. L’opérateur final doit réaliser une veille sur l’existence de nouvelles versions du micrologiciel de l’objet, et décider ou non de procéder au téléchargement et à l’installation de la nouvelle version. Étant donnée la multiplication de ces objets, cette option n’apparait pas satisfaisante.
  • Un système de mise à jour semi-automatique. Le dispositif final vérifie automatiquement l’existence d’une mise-à-jour et le notifie à l’utilisateur, qui doit faire le choix de procéder ou non à celle-ci. Ceci prévient le risque d’interruption des opérations en cours (ou futures dans le cadre d’une perte de fonctionnalité due à la mise à jour), mais fait porter le risque d’un report prolongé d’une mise à jour qui aurait pu permettre d’éviter un incident de sécurité. Les constructeurs de smartphone choisissent généralement cette méthode.
  • Un système de mise à jour automatique. Dans ce cadre, l’utilisateur final est retiré de la boucle de décision, en définissant un processus où le choix par défaut est l’installation du patch. C’est par exemple le choix de Microsoft par exemple pour ses systèmes d’exploitation. Il reste néanmoins possible pour l’utilisateur final de modifier cette configuration, mais ce système est pertinent pour la majorité des cas d’usage, notamment pour le grand public.

Face à l’effervescence du déploiement de ces objets, l’utilisateur/opérateur final a besoin de bénéficier d’un mode de maintenance semi-automatique ou automatique. En effet, si le processus de mise-à-jour n’est pas automatique ou semi-automatique, comment informer et permettre aux utilisateurs finaux, notamment le grand public, de réaliser ces mises-à-jour ? Dans son livre « Click Here to Kill Everybody: Security and Survival in a Hyper-connected World », Bruce Schneier compare les cas Tesla et Chrysler. Tesla assure le MCS de ses voitures connectées de façon automatique, alors que Chrysler a dû rappeler 1,4 millions de véhicules afin de corriger une faille de sécurité, car la seule alternative était d’envoyer aux propriétaires une clé USB à brancher sur le dashboard de leur véhicule.

Il faut cependant préciser que l’existence d’un système de mise à jour fait également porter un risque aux produits concernés. En effet, cela implique qu’il existe un vecteur pour remplacer le software de l’objet qui peut être exploité par un attaquant. Un système de mise à jour efficace protège de cette menace via l’utilisation de certificats, de telle sorte que l’objet n’accepte que les mises à jour signées par le constructeur. La sécurité du fournisseur devient critique car :

  • La compromission des clés privées du fabriquant permet à un attaquant de créer des updates malicieux ;
  • Dans le cas d’un déploiement piloté directement par le fabricant, sa compromission peut provoquer la compromission du parc de tous ses clients.

3.   Perspectives

Il existe des solutions sur lesquelles les fabricants et les intégrateurs peuvent se reposer pour assurer la maintenance logicielle de leurs produits, telles que Mender ou Asvin[1].

Figure 1 : Architecture de maintenance logicielle Mender[2]

 

De son côté, l’IETF (Internet Engineering Task Force) commence à appréhender le problème avec le groupe de travail SUIT[3] (Software Update for Internet of Things). Ce dernier vise à répondre au besoin d’un mécanisme de mise à jour des micrologiciels de tout objet connecté, notamment ceux dont les ressources sont restreintes.

Le processus de mise à jour du micrologiciel doit répondre aux prérequis suivants :

  • Être opérable sur des dispositifs aux ressources très limitées ;
  • Le protocole de mise à jour doit être agnostique quant au moyen de transport des images de Firmware et des Metadata associés vers l’objet ciblé (USB, UART, WiFi, etc.) ;
  • Permettre une haute fiabilité. Ceci en prévoyant soit deux instances du micrologiciel de façon à ce que l’un puisse prendre le relai en cas d’échec d’installation de l’autre (correspondant à l’architecture de Mender plus haut), soit un bootloader capable de reprendre une mise à jour interrompue ;
  • Être à l’état de l’art en matière de fonctionnalités de sécurité, à savoir notamment :
  1. L’image du micrologiciel doit être authentifiée et son intégrité protégée, de sorte à rendre impossible le mise à jour du dispositif avec une image modifiée ou provenant d’une source inconnue ;
  2. L’image du micrologiciel doit être protégée de façon à ce qu’aucun adversaire ne puisse obtenir les fichiers binaires du micrologiciel ;
  3. Une protection contre les attaques de type Rollback (installation par un attaquant d’une version plus ancienne du micrologiciel afin d’exploiter une vulnérabilité ancienne).
  • Permettre plusieurs modes de mises à jour : initialisation par le client, par le serveur, ou hybride.

Du côté juridique, le RGPD a introduit plusieurs principes qui concernent directement les objets connectés dont le Privacy by Design et le Security by Default. Aux États-Unis, le Congrès a introduit en 2019 un nouveau texte visant à imposer aux administrations un certain nombre d’exigences pour tout objet connecté qu’elles achètent, notamment le maintien en condition de sécurité[4]. Au Royaume-Uni, le gouvernement a publié en octobre 2018 le Code of Practice for Consumer IoT Security[5], qui propose aux fabricants d’indiquer explicitement la période minimale de maintenance logicielle, et a annoncé en 2019 son intention de légiférer sur cette base.

Et en attendant ? Plusieurs axes peuvent être recommandés aux opérateurs finaux :

  • La segmentation. Pour reprendre l’expression de Mike Loyd, CTO de RedSeal, il faut considérer les objets connectés comme des « bébés-bulle » : possédant un système immunitaire défaillant, il est nécessaire de les isoler dans un environnement stérile afin de les protéger des menaces[6].
  • Le monitoring constant de la surface d’exposition, notamment à Internet. On notera à ce sujet que la compagnie d’assurance cyber Coalition vient tout juste d’annoncer le rachat de BinaryEdge, un scanner de vulnérabilité de dispositifs connectés à Internet. Ce rapprochement vise à intégrer ce service à l’offre d’assurance afin de mieux évaluer le risque de l’assuré pour mieux définir le montant de sa prime, et a fortiori de le responsabiliser davantage.

 

[1] https://mender.io/ ; https://www.asvin.io/

[2] https://mender.io/overview/how-it-works

[3] https://datatracker.ietf.org/wg/suit/about/

[4] https://www.warner.senate.gov/public/index.cfm/pressreleases?ID=88A88A37-AD5E-4C01-932D-A23684AAD7AE

[5] https://www.gov.uk/government/publications/code-of-practice-for-consumer-iot-security

[6] https://www.darkreading.com/edge/theedge/what-do-you-do-when-you-cant-patch-your-iot-endpoints/b/d-id/1336196