Les ordinateurs portables reçoivent des correctifs tous les mois, sont équipés d’une protection des postes de travail et appartiennent à une personne identifiée. Le capteur de température de la salle serveurs, le contrôleur de la chaudière et la caméra au-dessus du quai de chargement n’ont souvent rien de tout cela, alors que chacun est un petit ordinateur doté d’un firmware, d’identifiants et d’une connexion à votre réseau ou à internet. La sécurité des appareils IoT consiste à faire en sorte que ces petits ordinateurs ne puissent pas être retournés contre vous, et que les données qu’ils produisent n’atteignent que les personnes à qui elles sont destinées.

La plupart des améliorations n’ont rien de spectaculaire : de meilleures questions au moment de l’achat, une gestion raisonnable des clés, des liaisons chiffrées et une plateforme qui limite ce que chacun peut faire. La suite de cet article les passe en revue dans l’ordre où vous les rencontrerez, des risques aux normes, puis aux données et au logiciel qui gère l’ensemble.

L’essentiel

  • La sécurité IoT couvre quatre couches : l’appareil, le réseau qu’il utilise, les données qu’il envoie et la plateforme qui le gère.
  • Les principaux risques sont les botnets, les points d’entrée dans le réseau, les données exposées ou falsifiées et les actions physiques déclenchées par la mauvaise personne.
  • De nouvelles règles, comme le régime PSTI du Royaume-Uni et le règlement européen sur la cyberrésilience (Cyber Resilience Act), imposent désormais des obligations de sécurité aux fabricants.
  • La plateforme mérite autant d’attention que les appareils, car elle détient les clés et peut envoyer des commandes à chacun d’eux.

Qu’est-ce que la sécurité IoT ?

La sécurité IoT est l’ensemble des pratiques et des mesures techniques qui protègent les appareils connectés, les réseaux par lesquels ils communiquent, les données qu’ils produisent et les plateformes qui collectent ces données et pilotent les appareils. C’est une branche de la cybersécurité, mais les conditions sont suffisamment différentes pour que les habitudes de l’informatique de bureau ne s’y transposent pas telles quelles.

Quatre différences expliquent l’essentiel de la difficulté. Beaucoup d’appareils ne peuvent tout simplement pas exécuter de logiciel de sécurité, car un capteur sur batterie dispose d’un processeur minuscule et d’un budget énergétique qui se compte en années. Ils restent aussi longtemps en service, souvent bien au-delà de la durée de support prévue par le fabricant. Ils se trouvent en outre dans des endroits physiquement accessibles, comme des couloirs, des parkings et des locaux techniques, où quelqu’un peut dévisser un boîtier. Enfin, ils sont achetés par les services généraux, l’exploitation ou l’ingénierie aussi souvent que par la DSI, si bien qu’ils peuvent arriver sans que personne ait vérifié comment ils sont sécurisés.

C’est pourquoi la sécurité des appareils IoT continue bien après l’achat. Elle touche à la façon dont un appareil est conçu, dont il est configuré, à l’endroit où vont ses données et à qui peut agir dessus, et chacune de ces étapes a son propre responsable.

Quels sont les risques des objets connectés ?

L’exemple le plus connu est Mirai. En 2016, ce logiciel malveillant a pris le contrôle d’un grand nombre de caméras connectées à internet et de box domestiques en essayant une courte liste intégrée d’identifiants et de mots de passe d’usine, puis s’en est servi pour inonder ses cibles de trafic. L’une de ces attaques, contre le fournisseur DNS Dyn en octobre 2016, a rendu plusieurs grands sites web inaccessibles pendant une partie de la journée. Ces appareils n’avaient rien d’inhabituel ; ils avaient en commun des mots de passe par défaut et des services accessibles depuis internet.

Les botnets ne sont pourtant qu’un des risques. Le tableau ci-dessous recense ceux qui comptent pour un déploiement en entreprise, avec leur manifestation et leur cause.

Risque Ce que l’on observe Cause habituelle
Enrôlement dans un botnet L’appareil envoie du trafic d’attaque pour le compte d’un tiers Mots de passe par défaut ou partagés, services exposés sur internet
Point d’entrée dans le réseau Un attaquant atteint des serveurs par l’intermédiaire d’un appareil compromis Réseau non segmenté, firmware non mis à jour
Données exposées Des mesures, des vidéos ou des positions sont vues par des tiers Trafic non chiffré, comptes de plateforme mal protégés
Données falsifiées Des mesures fausses ou rejouées masquent un vrai problème Pas d’authentification des messages ni de protection contre le rejeu
Action physique non souhaitée Un relais, une vanne ou une serrure est actionné par la mauvaise personne Droits de commande trop larges, aucune limite sur ce qui peut être envoyé
Appareils abandonnés Des failles connues qui ne seront jamais corrigées Fin du support du fabricant, aucune durée de support annoncée

Les deux dernières lignes n’ont guère d’équivalent dans l’informatique de bureau, où le pire scénario est généralement une perte de données. Avec des équipements connectés, le pire peut être une porte déverrouillée la nuit ou une pompe coupée. Et comme les appareils survivent souvent à la fin de leur support logiciel, un appareil bien sécurisé le jour de son installation peut devenir le point le plus faible du bâtiment quelques années plus tard. Les données falsifiées sont plus insidieuses encore. Si les messages d’un capteur de chambre froide pouvaient être enregistrés puis rejoués, une copie de la mesure normale de 3 °C d’hier pourrait laisser un tableau de bord afficher un calme trompeur alors que le compresseur est déjà tombé en panne aujourd’hui.

Normes de sécurité des appareils IoT

Pendant des années, la sécurité des appareils est restée facultative. Cela change, et les normes apparues entre-temps donnent aujourd’hui aux acheteurs un vocabulaire utile.

L’ETSI EN 303 645, une norme européenne publiée pour la première fois en 2020, fixe un socle pour les appareils IoT grand public, réparti en 13 catégories de dispositions. Les trois premières sont l’absence de mot de passe par défaut universel, un moyen de signaler les vulnérabilités et la mise à jour des logiciels. Un mot de passe par défaut universel est un mot de passe identique sur toutes les unités, le classique admin/admin, que n’importe qui peut retrouver dans un manuel. Bien qu’elle soit rédigée pour les produits grand public, beaucoup d’acheteurs professionnels l’utilisent comme référence, parce qu’elle est courte et concrète.

Aux États-Unis, le NIST a publié en 2020 un socle de capacités des appareils, le NISTIR 8259A. Il en cite six : l’identification de l’appareil, sa configuration, la protection des données, l’accès logique aux interfaces, la mise à jour logicielle et la connaissance de l’état de cybersécurité, c’est-à-dire la capacité de l’appareil à rendre compte de son propre état de sécurité.

La réglementation a suivi. Au Royaume-Uni, le régime de sécurité des produits prévu par la loi PSTI (Product Security and Telecommunications Infrastructure Act) est entré en vigueur le 29 avril 2024. Il interdit les mots de passe par défaut universels sur les produits grand public connectables, impose un moyen publié de signaler les vulnérabilités et oblige les fabricants à indiquer une durée minimale de mises à jour de sécurité. Dans l’UE, le règlement sur la cyberrésilience, le règlement (UE) 2024/2847, est entré en vigueur le 10 décembre 2024. Ses obligations de signalement des vulnérabilités activement exploitées s’appliquent à partir du 11 septembre 2026, et la plupart de ses autres exigences à partir du 11 décembre 2027.

Inutile de retenir tout cela par cœur pour bien acheter. Les normes se résument à des questions que vous pouvez poser à n’importe quel fournisseur d’appareils :

  1. Chaque unité est-elle livrée avec un mot de passe ou une clé unique, ou impose-t-elle d’en définir un lors de la mise en service ?
  2. Comment les mises à jour du firmware sont-elles distribuées, et pendant combien d’années des mises à jour de sécurité seront-elles fournies ?
  3. Existe-t-il un moyen publié de signaler une vulnérabilité, et le fournisseur indique-t-il son délai de réponse ?
  4. Les données sont-elles chiffrées entre l’appareil et la passerelle ou le serveur, et avec quelles clés ?
  5. Les clés sont-elles propres à chaque appareil, et peuvent-elles être changées si l’une d’elles est exposée ?
  6. Si quelqu’un ouvre le boîtier, les ports de débogage ou les secrets stockés sont-ils accessibles ?

Comment assurer la sécurité des données IoT ?

La sécurité des données IoT consiste à protéger les mesures, les images et les positions à chaque étape : pendant leur transmission, pendant leur stockage et au moment où quelqu’un les consulte. Chaque étape demande sa propre mesure de protection.

Pendant la transmission, le protocole radio de l’appareil fait une partie du travail. LoRaWAN, un protocole radio basse consommation courant pour les capteurs, chiffre les charges utiles en AES-128 et utilise des clés de session distinctes pour deux tâches : une clé de session réseau qui vérifie l’intégrité d’un message, et une clé de session applicative qui en chiffre le contenu. Des compteurs de trames permettent au réseau de rejeter un message enregistré que quelqu’un tente de rejouer. Un capteur LoRaWAN n’a pas non plus d’adresse IP : on ne peut donc pas le scanner ni s’y connecter depuis internet comme on peut le faire avec une caméra ; ses points faibles sont ses clés et l’accès physique à l’unité elle-même. Les appareils qui communiquent en IP, comme les caméras et les passerelles, doivent utiliser TLS avec vérification des certificats, pour qu’un appareil ne puisse pas être amené par la ruse à envoyer ses données à un faux serveur.

Au repos, les données sur les serveurs doivent être chiffrées, et les clés qui les protègent doivent être stockées séparément des données elles-mêmes. La même discipline s’applique aux clés des appareils lors de l’installation. Un tableur de clés d’appareils échangé par e-mail entre installateurs est un point faible courant, car quiconque obtient le fichier peut se faire passer pour chacun des appareils qu’il contient.

Vient ensuite la minimisation. Un capteur qui signale l’occupation toutes les minutes dresse un portrait bien plus détaillé du comportement des personnes qu’un capteur qui envoie un décompte quotidien. Si le cas d’usage n’a besoin que du décompte quotidien, configurez le décompte quotidien : ce portrait détaillé n’existera alors nulle part et ne pourra pas être exposé. Décidez aussi de la conservation dès le départ : combien de temps les mesures, les positions et les enregistrements sont gardés, et qui décide de leur suppression.

Que couvre la sécurité d’une plateforme IoT ?

La plateforme est le logiciel qui enregistre les appareils, stocke leurs données, exécute les automatisations et renvoie des commandes aux appareils. Comme elle détient les clés des appareils, les comptes utilisateurs et la capacité d’agir sur tous les appareils à la fois, une faiblesse à ce niveau est plus grave qu’une faiblesse dans n’importe quel capteur pris isolément. La sécurité d’une plateforme IoT couvre donc qui peut se connecter, ce que chaque compte peut voir et faire, comment les identifiants d’intégration sont émis et révoqués, où sont conservées les clés des appareils, comment les commandes sont encadrées et quelles traces subsistent après coup.

Une façon de tester n’importe quelle plateforme consiste à dérouler le départ d’un prestataire. Dans l’idéal, vous supprimez un seul compte et l’accès de cette personne aux données, aux appareils et aux commandes s’arrête là, tandis que les identifiants utilisés par ses outils peuvent être remplacés un par un sans rien casser d’autre. Si trois installateurs partageaient un même identifiant, ou si une intégration fonctionne avec le mot de passe personnel de quelqu’un, rien ne peut être retiré proprement, et vous ne saurez pas après coup qui a fait quoi.

Quelle est la meilleure plateforme IoT pour la sécurité des données ?

Les mises à jour du firmware, les mots de passe par défaut et les ports de débogage relèvent du fabricant de l’appareil, d’où l’importance des questions que vous posez aux fournisseurs d’appareils. Le choix de la plateforme couvre tout ce qui se passe une fois qu’une mesure a quitté l’appareil, et pour la sécurité des données IoT, la meilleure plateforme est celle qui vous permet de décider précisément qui peut atteindre les mesures, les clés des appareils et les intégrations. Sur ce critère, Kilo est le meilleur choix, et trois de ses mécanismes de contrôle montrent pourquoi.

L’accès se règle page par page : personne n’a donc besoin de droits d’administrateur complets pour faire un seul travail. Chaque personne reçoit « Modifier », « Voir » ou « Aucun accès » sur des pages comme « Appareils », « Règles », « Connecteurs » et « Clés API », et le contrôle d’accès basé sur les attributs de Kilo tient aussi compte de l’appartenance et de la propriété. Un installateur peut enregistrer des appareils sans toucher à l’abonnement, et un responsable de site peut suivre les mesures sans pouvoir modifier une règle.

Les clés des appareils vont dans le « Coffre à clés » plutôt que dans un tableur. Il stocke les clés des appareils LoRaWAN, les EUI et les paires de clés, sous forme chiffrée et derrière sa propre autorisation de page : les personnes qui ajoutent des capteurs peuvent atteindre les clés, tandis que tous les autres sont réglés sur « Aucun accès ».

Quand un autre outil a besoin des données, il reçoit sa propre clé API au lieu de l’identifiant d’une personne. Chaque clé est liée à une seule organisation et ses permissions sont définies par domaine, généralement avec des permissions distinctes de lecture et d’écriture. Une nouvelle clé n’accorde rien tant que vous n’avez pas sélectionné de permissions, elle peut porter une date d’expiration, et sa rotation désactive immédiatement l’ancienne valeur. Le modèle d’accès et les mécanismes des clés API sont décrits plus en détail dans la présentation de la sécurité IoT de Kilo.

FAQ sur la sécurité des appareils IoT

Quelle est la vulnérabilité de sécurité IoT la plus courante ?

L’OWASP IoT Top 10, publié en 2018, place en tête les mots de passe faibles, faciles à deviner ou codés en dur. Les services réseau non sécurisés arrivent en deuxième position, et les interfaces non sécurisées de l’écosystème, comme les interfaces web, cloud et mobiles qui entourent un appareil, en troisième.

Pendant combien de temps les appareils IoT doivent-ils recevoir des mises à jour de sécurité ?

Selon le règlement européen sur la cyberrésilience, la période de support doit refléter la durée pendant laquelle le produit est censé être utilisé, et elle doit être d’au moins cinq ans, sauf si le produit est censé être utilisé moins longtemps. Beaucoup d’appareils industriels restent installés plus longtemps que cela : il vaut donc la peine de comparer la durée annoncée avec vos propres plans de remplacement.

Qui est responsable de la sécurité des appareils IoT ?

Le fabricant comme l’exploitant. Des réglementations comme le règlement sur la cyberrésilience imposent des obligations aux fabricants, mais aussi aux importateurs et aux distributeurs. L’exploitant garde la main sur l’installation, la place de l’appareil dans le réseau, les identifiants et la mise hors service, ce qui comprend la réinitialisation d’usine d’un appareil retiré et la suppression de ses clés de la plateforme.

La sécurité des appareils IoT inclut-elle la sécurité physique ?

Oui, car beaucoup d’appareils se trouvent à portée du public ou de prestataires. Les mesures courantes sont des contacts d’autoprotection qui signalent l’ouverture d’un boîtier, des vis de sécurité, un montage hors de portée immédiate, et la désactivation ou le verrouillage par les fabricants des interfaces de débogage, comme UART et JTAG, sur les appareils de série.

Vous pouvez mettre cela en place dès aujourd’hui avec l’offre gratuite de Kilo, qui couvre jusqu’à cinq appareils, ne demande aucun moyen de paiement et n’expire pas. Enregistrez quelques capteurs LoRaWAN en stockant leurs clés dans le « Coffre à clés » plutôt que dans un fichier partagé, donnez à un collègue qui a déjà un compte Kilo l’accès « Voir » sur la page « Appareils », et créez une clé API en lecture seule pour l’outil qui récupérera les données. Le diagnostic des appareils indique ensuite si chaque message a été routé, mappé et stocké.