Points clés
- Les erreurs d'intégration IoT les plus courantes ne sont pas techniques mais organisationnelles : acquisition sans qualification sécuritaire, déploiement hors processus IT, absence de documentation, et oubli de la décommission.
- Laisser les credentials par défaut sur les équipements IoT est la vulnérabilité la plus exploitée — documentée par Shodan, exploitée par Mirai, et toujours présente en 2024 dans la majorité des déploiements.
- Connecter un équipement IoT directement au réseau principal sans segmentation expose l'ensemble du SI à partir d'un seul équipement compromis.
- L'absence de processus de mise à jour firmware — ou l'impossibilité technique de mettre à jour — laisse des vulnérabilités connues ouvertes pendant toute la durée de vie de l'équipement.
L'acquisition sans qualification sécuritaire
L'erreur la plus fréquente et la plus structurante est l'acquisition d'équipements IoT sans évaluation de leur profil de sécurité. Le processus d'achat standard compare prix, fonctionnalités et délai de livraison — rarement la politique de divulgation des vulnérabilités du fabricant, la durée de support logiciel, la capacité de mise à jour sécurisée du firmware, ou les protocoles de communication utilisés. Résultat : des équipements fonctionnellement excellents mais sécuritairement déficients sont déployés à grande échelle, créant une surface d'attaque dont l'ampleur ne sera découverte que lors d'un premier inventaire sécuritaire — souvent déclenché par un incident. Intégrer une checklist sécuritaire dans les processus d'achat est une mesure à coût marginal faible et à impact élevé.
Les credentials par défaut : la vulnérabilité universelle
La modification des credentials par défaut est documentée comme bonne pratique depuis les années 1990. Pourtant, elle reste systématiquement omise lors des déploiements IoT. La raison est organisationnelle : les équipements IoT sont souvent installés par des équipes non IT (facilities, techniciens métiers, prestataires) qui ne sont pas formées aux pratiques de sécurité. Le manuel de l'équipement indique "admin/admin" ou "admin/password", l'installation est terminée en dix minutes, et personne ne revient sur la configuration de sécurité. Shodan indexe des millions d'équipements IoT accessibles avec les credentials par défaut. Mirai les a exploités à grande échelle. La solution est un processus de mise en service standardisé incluant obligatoirement le changement des credentials et la documentation de la configuration.
L'intégration réseau sans segmentation
Connecter un équipement IoT directement au réseau principal de l'entreprise est une erreur d'architecture qui transforme chaque équipement en vecteur de pivot potentiel. Un réseau plat permet à un équipement compromis — quelle que soit sa criticité fonctionnelle — d'atteindre n'importe quel autre équipement du même réseau. La caméra de surveillance dans le couloir et le serveur de production sont sur le même VLAN : compromettre la caméra ouvre la voie vers le serveur. La segmentation réseau — VLANs dédiés IoT par famille fonctionnelle, avec des règles de filtrage strictes — est la contre-mesure fondamentale. Elle ne doit pas être une option à envisager mais une exigence d'architecture appliquée à tout nouveau déploiement IoT.
L'absence de processus de mise à jour firmware
Les équipements IoT sont fréquemment déployés avec leur firmware d'origine et jamais mis à jour pendant toute leur durée de vie opérationnelle. Cette situation résulte de plusieurs facteurs combinés : les équipes en charge de la maintenance ne savent pas que des mises à jour sont disponibles (pas d'abonnement aux alertes de sécurité du fabricant), la mise à jour nécessite une intervention physique ou une procédure complexe que personne n'a formalisée, l'équipement est en production et personne ne veut prendre le risque d'une interruption de service. Résultat : des vulnérabilités CVE critiques, connues et corrigées par le fabricant, restent ouvertes sur des milliers d'équipements. Un inventaire IoMT incluant le suivi des CVE par équipement et une procédure de mise à jour testée sont les réponses à cette erreur structurelle.
L'absence de documentation et de décommission
La documentation des déploiements IoT est souvent inexistante ou obsolète. Quel équipement est connecté à quel port ? Quelles règles de firewall ont été créées pour son accès ? Qui est responsable de sa maintenance ? Quelle est son adresse IP ? Cette absence de documentation impacte directement la sécurité : il est impossible de réagir rapidement à un incident sur un équipement non documenté, et impossible de le décommissionner proprement sans risquer de laisser des accès résiduels ouverts. La décommission non structurée — déconnecter physiquement l'équipement sans supprimer ses comptes, ses règles de firewall, et ses entrées DNS — laisse des traces persistantes qui peuvent être exploitées par un attaquant.