La sécurité de l’IOT, ce n’est pas qu’une affaire de standards, c’est aussi une démarche d’adoption : le cas MQTT.

Sécurité
Sponsorisé par IBM

Il n’est plus à s’en convaincre, le monde d’aujourd’hui est fait d’objets du quotidien qui, anciennement étrangers à la chose numérique, s’y voient désormais reliés ; ce sont les bien nommés « objets connectés ».

Les objets connectés

A l’aune des écrits de la presse spécialisée, on nous explique bien souvent que l’Internet des Objet, ou Internet of Things en langue de Shakespeare, comporte moult risques digitaux qu’il faut adresser par pléthore de remèdes pleins de technologie dernier cri.

C’est vrai. Enfin, c’est presque vrai.

Car, si la technologie propose des solutions, son usage partiel, incomplet ou encore dévoyé au profit d’autres impératifs, ruine bien souvent la bonne finalité de sécurisation initialement envisagée.

En ce sens, l’exemple de MQTT est un bon cas d’école.

Communication des objets connectés

MQTT, pour Message Queuing Telemetry Transport, est une initiative de bientôt 20 ans qui, depuis quatre ans, est devenue un standard à part entière.

MQTT sert à faire communiquer nos objets connectés simplement et efficacement.

Ainsi, la sonde de température d’unsalon envoie ses informations à un smartphone en passant par MQTT tout comme le fait ce même smartphone pour commander la descente des volets dans la chambre d’un enfant quand il s’est endormi.

Pour rentrer un peu plus dans les détails, MQTT est mis en œuvre via une infrastructure simple et légère composée de trois éléments principaux :
– Le producteur d’information (producer) ;

  • Le consommateur d’information (consumer)
  • Un orchestrateur d’ensemble nommé Broker.

Cette infrastructure fonctionne sur le principe de l’abonnement où un objet producteur d’information va pousser une information en lui associant un sujet (l’hygrométrie de la salle de bains d’un domicile : domicile/salle de bains/hygrométrie) que le broker va redistribuer aux autres objets qui se sont abonnés préalablement aux sujets qui les intéressent.

De nombreuses combinaisons sont envisageables en matière d’abonnements comme par exemple : l’hygrométrie de toutes les pièces d’un domicile ou encore tous les mesures qui peuvent être remontées de toutes les salles de bains d’un hôtel.

Les capacités sont importantes et reposent sur une logique de sélection plus ou moins étendue des informations en présence du broker.

Les risques

Maintenant que le décor est planté et que les principes sont énoncés, complexifions un peu le modèle en parlant de risques digitaux.

Car le modèle souffre de quelques faiblesses intrinsèques.

La première est que, pour mettre à disposition des environnements de tests, la communauté MQTT a créé des brokers publics tels que dev.rabbitmq.com, iot.eclipse.org ou encore test.mosquitto.org

Louable et utile initiative qui aurait dû, dans bien des cas, rester du domaine du test.

Tel n’est pourtant pas le cas puisque certains objets connectés les utilisent en production avec les conséquences en matière de sécurité comme de vie privée que l’on peut imaginer.

Ainsi, en s’abonnant et en croisant les sujets et sous-sujets des brokers susmentionnés, il n’est pas rare de voir des données sensibles voir très sensibles transiter via ces infrastructures ouvertes à tous.

Il arrive de recevoir des informations sur la planification d’une flotte de camions en Alaska avec le détail de la livraison à effectuer tout comme les coordonnées détaillées du destinataire ou encore des informations d’un système de monitoring d’un patient dans un service de réanimation quelque part en Asie.

Les exemples sont légion et font froid dans le dos quand on imagine ce que de telles informations, au-delà des problèmes liés à la vie privée, peuvent faire porter comme risques aussi bien à leurs producteurs qu’à leurs consommateurs.

MQTT souffre de défauts fondamentaux dont :

  • Un manque d’utilisation du chiffrement. Il existe pourtant une version de MQTT chiffrée via TLS ou SSL (MQTTS) mais peu de brokers l’utilisent.
  • Un manque de confidentialité. Ceci vient du fait qu’un compte inscrit auprès d’un broker peut accéder à presque tout ce qu’il souhaite. La notion de ségrégation ou de cloisonnement est faible ce qui compromet la confidentialité des données échangées.
  • Un manque d’authentification. Le mode connexion anonyme est courant et nuit à la traçabilité d’ensemble.

L’avenir

La communauté gravitant autour de MQTT en a bien pris conscience et des mesures de maîtrise des risques ont été prises.

La première vise à mettre en place le chiffrement via SSL ou TLS mais la gestion des certificats reste un vrai défi pour des objets qui parfois se prêtent mal à la gestion d’une telle solution.

La seconde vise à effectuer une gestion des identifiants et des authentifiants en phase avec les meilleures pratiques.

Et la troisième porte sur le chiffrement applicatif comme la mise en place du chiffrement réseau via des VPNs quand cela est possible.

Ces mesures de sécurité sont, somme toute, assez conventionnelles dans l’univers de la sécurité du digital.

Mais leurs adoptions restent freinées, bien souvent, par méconnaissance, par négligence ou par choix afin de favoriser la production au détriment de la sécurité.

Il faut donc encourager les acteurs de l’internet des objets à mettre en place les démarches d’adoption de ces mesures de réduction des risques.

L’évolution des mentalités permettra de prévenir les incidents de sécurité sans pénaliser l’efficacité apportée par MQTT, standard largement adopté dans la communauté des acteurs de l’IoT.

 

Auteur
En savoir plus 
Associate Partner - Security Services
IBM
Philippe Etienne est Associate Partner dans l'entité Security Services d'IBM France. Il est en charge du pilotage de programmes sécurité en environnements complexes. Il a un passé d'auditeur, de consultant mais aussi de responsable de business unit dans le domaine de la sécurité tout comme de RSSI. Diplomé de l'ESI et d'HEC Paris il a plus de 22 ans d'expérience en sécurisation des systèmes d'information.
En savoir plus 

Livres blancs A la Une