Sécurité IoT

La sécurité IoT (Internet of Things, ou Internet des objets) désigne l'ensemble des pratiques, contrôles techniques et processus organisationnels destinés à protéger les objets connectés, leurs communications et les plateformes qui les pilotent. Elle couvre la sécurisation des firmwares, le durcissement des protocoles applicatifs comme MQTT ou CoAP, la gestion des correctifs sur l'ensemble du cycle de vie du matériel, et la segmentation réseau entre les environnements bureautiques, OT et IoT.

Pourquoi l'IoT constitue une surface d'attaque à part

Un objet connecté n'est pas un serveur miniature : il cumule des contraintes qui invalident la plupart des réflexes de la sécurité informatique classique. Sa puissance de calcul et sa mémoire limitées interdisent souvent l'installation d'un agent EDR. Son cycle de vie s'étale sur dix à quinze ans, bien au-delà de la durée de support de l'éditeur. Il est fréquemment déployé en grand nombre, dans des lieux physiquement accessibles (couloirs, parkings, ateliers, sites isolés), ce qui ouvre la porte aux attaques matérielles : extraction de mémoire flash, accès au port UART ou JTAG, sniffing du bus SPI.

À cela s'ajoutent des faiblesses de conception récurrentes : identifiants par défaut codés en dur, absence de vérification de signature lors des mises à jour, clés cryptographiques identiques sur toute une série de production, services d'administration exposés (Telnet, UPnP, serveurs web embarqués obsolètes). L'OWASP recense ces défauts dans son Top 10 IoT, qui reste la référence pour cadrer un audit.

Fonctionnement technique : les trois couches à protéger

La couche matérielle et firmware. La sécurité commence par un secure boot : le bootloader vérifie la signature du firmware avant de l'exécuter, empêchant le chargement d'une image modifiée. Les secrets (clés privées, certificats d'appareil) doivent résider dans un élément sécurisé — TPM, secure element ou zone protégée type ARM TrustZone — et non dans une partition lisible. Un firmware bien conçu chiffre également sa mémoire flash et désactive les interfaces de débogage en production.

La couche communication. MQTT est un protocole de publication/abonnement léger, très répandu en IoT industriel et domotique. Non sécurisé, un broker MQTT accepte les connexions anonymes et autorise n'importe quel client à s'abonner au topic #, c'est-à-dire à l'intégralité du trafic. Le durcissement consiste à imposer MQTTS (TLS sur le port 8883), l'authentification mutuelle par certificat client (mTLS) et des ACL par topic limitant chaque équipement à ses propres canaux. CoAP, conçu pour les réseaux contraints, s'appuie sur UDP : il doit être protégé par DTLS, faute de quoi il devient à la fois interceptable et exploitable comme vecteur d'amplification DDoS.

La couche gestion. Un parc IoT sans inventaire est ingérable. Le provisionnement doit attribuer une identité unique par équipement, et le mécanisme de mise à jour OTA (Over-The-Air) doit être signé, versionné et capable de revenir en arrière en cas d'échec.

Exemples concrets

• Mirai (2016) : un ver a constitué un botnet de centaines de milliers de caméras et routeurs en testant une soixantaine de couples identifiant/mot de passe par défaut sur Telnet, avant de lancer des attaques DDoS dépassant le térabit par seconde.
• Ripple20 et Urgent/11 : des vulnérabilités dans des piles TCP/IP embarquées (Treck, VxWorks) ont affecté des centaines de millions d'équipements médicaux, industriels et réseau — illustration parfaite du risque lié à la chaîne d'approvisionnement logicielle.
• Brokers MQTT exposés : des milliers de brokers restent accessibles publiquement sur Internet, divulguant relevés de capteurs, positions GPS de flottes ou commandes d'automates.
• Compromissions de caméras de vidéosurveillance utilisées comme point de pivot vers le réseau bureautique, faute de segmentation.

Liens avec les autres domaines de la cybersécurité

La sécurité IoT recoupe la sécurité OT (systèmes industriels, SCADA, automates), avec laquelle elle partage la problématique des équipements non patchables et des protocoles historiques. Elle s'inscrit dans une démarche Zero Trust, où chaque objet est authentifié individuellement plutôt que jugé fiable parce qu'il est « dans le réseau ». Elle mobilise le NAC (contrôle d'accès réseau) pour l'admission des équipements, la micro-segmentation via VLAN et pare-feu interne, et la threat intelligence pour détecter les communications sortantes vers des serveurs de commande et contrôle. En Europe, la directive NIS 2 et le Cyber Resilience Act imposent désormais des obligations de sécurité par conception et de fourniture de SBOM aux fabricants.

Bonnes pratiques

• Inventorier exhaustivement le parc : un objet inconnu est un objet non protégé. La découverte passive du trafic complète efficacement les scans actifs, souvent mal supportés par ces équipements.
• Segmenter systématiquement : VLAN dédié par famille d'objets, filtrage inter-VLAN en liste blanche, interdiction par défaut des flux sortants vers Internet.
• Supprimer les identifiants par défaut et désactiver les services inutiles (Telnet, UPnP, serveur web embarqué) dès la mise en service.
• Chiffrer les communications : TLS/DTLS avec authentification mutuelle, rotation des certificats planifiée.
• Industrialiser les mises à jour OTA signées et suivre les avis de sécurité des fabricants ; intégrer la fin de support au plan de renouvellement du matériel.
• Superviser les comportements réseau : un capteur qui se met à scanner ou à émettre vers une adresse inhabituelle constitue un signal fort.
• Exiger contractuellement des fournisseurs un SBOM, une durée de support explicite et un canal de divulgation des vulnérabilités.