IoT et OT, la surface d'attaque invisible

Objets connectés, automates, capteurs : la surface d’attaque qui explose en silence aux frontières de l’IT et de l’OT.

Dans la chronique 006, nous avons ouvert la boîte noire du legacy : ces systèmes trop vieux pour être patchés, trop critiques pour être éteints. Nous avons posé la matrice Kill, Refactor, Fortress pour reprendre le contrôle de l’héritage toxique. Mais il existe une catégorie d’actifs encore plus redoutable que le vieux serveur oublié dans la salle machines.

Ce sont les objets connectés. Capteurs de température, caméras IP, automates programmables, compteurs intelligents, terminaux de badge, sondes environnementales. Ils sont partout. Dans les usines, les hôpitaux, les entrepôts, les bâtiments tertiaires. Et dans la grande majorité des cas, ils échappent au radar de la DSI.

L’IoT pose la même question que le cloud (chronique 002) ou l’open source (chronique 003) : quelle dépendance crée-t-on, et en est-on conscient ? Sauf qu’ici, la dépendance n’est pas logicielle ou contractuelle. Elle est physique, diffuse, et souvent invisible.

La question structurante de cette chronique : comment gouverner une surface d’attaque qu’on ne voit pas, qu’on ne maîtrise pas, et qui touche directement le monde physique ?

1. Le legacy en pire : l’IoT industriel, angle mort des organisations

Un automate programmable (PLC) installé en 2012 sur une chaîne de production fonctionne encore très bien. Il fait ce qu’on lui demande, jour après jour. Problème : il communique en clair sur un protocole Modbus sans authentification, son firmware n’a jamais été mis à jour, et l’éditeur qui l’a conçu a été racheté deux fois depuis.

C’est le même problème que le legacy classique — en pire. Car un serveur Windows 2008, aussi obsolète soit-il, reste dans le champ de vision de la DSI. Un capteur IoT sur un climatiseur ou un portique de sécurité ? Il est géré par les services généraux, la maintenance ou un prestataire externe. Il n’apparaît sur aucun inventaire IT.

Côté IoT grand public (caméras, thermostats, assistants vocaux), la logique est inverse mais le résultat identique : des objets produits à bas coût, avec des cycles de vie très courts, sans stratégie de mise à jour ni de support. Résultat : un océan d’objets vulnérables, rarement corrigés, qui deviennent autant de portes d’entrée.

L’IoT n’est pas un « nouveau sujet ». C’est le prolongement direct du problème legacy, avec un facteur aggravant : l’invisibilité pour les équipes de sécurité.

2. La convergence IT/OT : une frontière qui n’existe plus

Pendant des décennies, les mondes IT et OT vivaient séparés. L’IT gérait les données, l’OT pilotait les machines. Le réseau SCADA était physiquement isolé. Cette époque est révolue.

Aujourd’hui, la télémaintenance, l’intégration avec l’ERP, le pilotage à distance, les jumeaux numériques et l’analyse prédictive imposent des connexions entre ces deux mondes. Les frontières tombent. Et avec elles, l’illusion d’isolation qui protégeait l’OT.

Colonial Pipeline en 2021 l’a démontré de manière spectaculaire : le ransomware n’a même pas touché les systèmes OT. Mais la décision de couper l’exploitation — par précaution, faute de visibilité sur l’étendue de la compromission — a paralysé la distribution de carburant pendant plusieurs jours. L’interconnexion IT/OT n’a pas été exploitée techniquement. Elle l’a été stratégiquement : l’incertitude a suffi.

La convergence IT/OT n’est pas un choix technologique. C’est un fait accompli. La question n’est plus de savoir si vos réseaux sont connectés, mais si vous savez comment.

3. Trois mythes à déconstruire

Mythe 1 : « L’OT est isolé, donc protégé ». C’était vrai il y a vingt ans. Aujourd’hui, la quasi-totalité des environnements OT sont connectés, ne serait-ce que pour la télémaintenance ou la supervision à distance. L’air gap logique est devenu une fiction confortable.

Mythe 2 : « Un capteur, c’est trop petit pour être dangereux ». Le botnet Mirai a transformé des caméras et des routeurs en arme de déni de service capable de faire tomber des pans entiers d’Internet. Un objet connecté compromis n’est pas une menace individuelle. C’est un point d’appui pour une attaque à grande échelle.

Mythe 3 : « Sécuriser l’IoT, c’est comme sécuriser l’IT ». Non. En IT, on patche, on redémarre, on segmente. En OT, on ne redémarre pas une raffinerie. En IoT, on ne patche pas un capteur médical en plein fonctionnement. La disponibilité prime sur la confidentialité. Les approches de sécurité doivent s’adapter à cette réalité, pas l’inverse.

Ces mythes coûtent cher. Ils justifient l’inaction et entretiennent l’illusion que le problème ne nous concerne pas.

4. La surface d’attaque invisible : cartographie d’une menace diffuse

Ce qui rend l’IoT particulièrement redoutable, c’est sa dispersion. Un SI classique a un périmètre. Un réseau OT a des zones. L’IoT, lui, est partout et nulle part.

Quelques chiffres pour mesurer l’ampleur :

• 30 milliards d’objets connectés attendus d’ici 2030, selon plusieurs études industrielles.

• La durée de support de sécurité moyenne d’un objet IoT grand public est de 2 à 3 ans. Sa durée de vie en exploitation est souvent de 7 à 10 ans.

• Un automate industriel reste en service 15 à 30 ans. Ses protocoles de communication n’ont souvent jamais été conçus pour résister à une attaque.

• La majorité des organisations n’ont aucun inventaire fiable de leurs objets connectés, encore moins de leur exposition réseau.

Sans inventaire, pas de gouvernance. Sans gouvernance, pas de résilience. La première action est toujours la même : savoir ce qu’on a.

5. L’enjeu de gouvernance : qui est responsable de ce qui ne figure sur aucun schéma ?

C’est là que le sujet bascule du technique au stratégique. La sécurité de l’IoT n’est pas (uniquement) un problème d’équipe SOC. C’est un problème de gouvernance.

Qui décide de déployer un capteur connecté dans un bâtiment ? Souvent, les services généraux ou la maintenance, sans impliquer la DSI. Qui gère le cycle de vie d’un automate industriel ? L’équipe OT, parfois déconnectée des politiques de sécurité SI. Qui surveille les flux réseau de ces objets ? Personne, la plupart du temps.

On retrouve ici le fil rouge de la chronique 004 sur la résilience et les décideurs : sans implication du management, la sécurité de l’IoT reste un sujet technique traité par personne. Car il tombe entre les mailles de toutes les organisations existantes.

Le dialogue doit avoir lieu entre DSI, RSSI, directions métier, maintenance et achats. Il ne s’agit pas de tout centraliser, mais de rendre visible et arbitrable un risque aujourd’hui fantomâtique.

La vraie question n’est pas technique. C’est : qui porte la responsabilité de sécuriser ce qui n’appartient à aucune équipe ?

6. Le cadre réglementaire change la donne

L’Europe a décidé de ne plus laisser le marché s’auto-réguler. Le Cyber Resilience Act (CRA), entré en vigueur fin 2024, impose désormais aux fabricants de « produits à éléments numériques » — incluant l’IoT — des exigences de sécurité native, de support dans la durée et de notification des vulnérabilités. Les obligations de signalement des incidents s’appliqueront dès septembre 2026. La pleine application est prévue pour décembre 2027.

Parallèlement, NIS2 élargit le champ des obligations de cybersécurité aux secteurs industriels et de santé, touchant directement les opérateurs d’OT. Et la directive RED (Radio Equipment Directive) impose depuis août 2025 des exigences de cybersécurité pour tout équipement radio connecté à Internet.

Le signal est clair : la résilience IoT n’est plus une bonne pratique. C’est une exigence légale. Et comme nous l’avons vu dans la chronique 005 sur le Security by Design, la conformité peut devenir un levier de transformation — à condition de ne pas la traiter comme une simple case à cocher.

Le CRA transforme l’IoT de « déployer et oublier » à « maintenir et rendre des comptes ». C’est un changement de paradigme pour les fabricants comme pour les utilisateurs.

7. Grille de maturité IoT/OT : où en êtes-vous ?

Pour passer du constat à l’action, voici une grille d’évaluation rapide en cinq dimensions. Elle permet de situer son organisation et de prioriser les efforts.

Dimension Niveau 1 — Subi Niveau 2 — Structuré Niveau 3 — Maîtrisé —————— — — —————————————————– Inventaire Aucun inventaire des objets connectés Inventaire partiel, maintenu manuellement Inventaire automatisé, intégré au CMDB Segmentation IoT et OT sur le même réseau que l’IT Zones séparées, règles de pare-feu basiques Micro-segmentation, flux contrôlés et supervisés Surveillance Aucune supervision spécifique Logs collectés mais peu exploités Détection d’anomalies adaptée aux protocoles OT Gouvernance Pas de responsable identifié Rôles définis, processus en construction Intégration dans la politique de sécurité globale Cycle de vie Déployé et oublié Suivi des versions, patching opportuniste Gestion du cycle de vie, clauses d’achat sécurisées

Si la majorité de vos réponses se situe en colonne « Niveau 1 », vous ne gérez pas votre risque IoT. Vous le subissez.

8. Construire la résilience IoT/OT : le plan en 5 briques

1. Cartographier. Pas d’inventaire, pas de sécurité. Le premier chantier est de découvrir ce qu’on a : scan réseau passif (pour ne pas perturber l’OT), identification des protocoles, qualification des flux. L’objectif n’est pas la perfection, mais la visibilité.

2. Segmenter. Le modèle Purdue reste une référence : définir des zones (IT, DMZ, OT) et limiter strictement les flux entre elles. Comme pour le legacy (chronique 006), l’encapsulation est souvent la meilleure défense quand on ne peut pas patcher.

3. Surveiller. Déployer une supervision adaptée aux protocoles industriels (Modbus, OPC UA, BACnet). Les IDS/IPS classiques ne suffisent pas. Des solutions spécialisées permettent de détecter les comportements anormaux sans interférer avec la production.

4. Gouverner. Intégrer l’IoT/OT dans les processus existants : gestion des actifs, gestion des vulnérabilités, gestion des incidents, plans de continuité. Le pire scénario n’est pas l’attaque. C’est l’attaque sur un actif dont personne ne savait qu’il existait.

5. Exiger. Lors de chaque achat de solution connectée, poser les questions de la chronique 005 : quelle durée de support ? Quel SBOM ? Quelle réversibilité ? Le CRA donne désormais un cadre légal pour exiger ces réponses.

La résilience IoT/OT n’est pas un projet à part. C’est une extension naturelle de la démarche de résilience globale. Les outils existent. Ce qui manque, c’est la volonté de regarder.

L’Essentiel pour Agir

1. Lancez un inventaire IoT/OT cette semaine : même partiel, même imparfait. Demandez à la maintenance, aux services généraux, aux équipes OT : « quels équipements connectés avez-vous déployés ? ». Vous serez surpris par les réponses — et par les silences.

2. Désignez un propriétaire du risque IoT : tant que la sécurité IoT n’est rattachée à personne, elle n’existe pas. Un référent, une feuille de route, un reporting. Pas besoin d’un budget pharaonique. Juste d’une décision.

3. Intégrez l’IoT dans vos clauses d’achat : durée de support sécurité, capacité de mise à jour, conformité CRA. Chaque nouvel objet connecté déployé sans ces garanties est une dette de résilience supplémentaire.

Conclusion

L’IoT est le révélateur d’une tension fondamentale : nous connectons le monde physique au numérique à un rythme que nos modèles de sécurité, de gouvernance et de responsabilité ne suivent pas.

La résilience ne consiste pas à refuser la connectivité. Elle consiste à connecter en conscience : en sachant ce qu’on déploie, en mesurant ce qu’on expose, en gouvernant ce qu’on crée comme dépendance.

La prochaine étape nous amènera sur un terrain adjacent mais tout aussi structurant : celui des règles du jeu elles-mêmes. Car quand la surface d’attaque s’étend, le cadre normatif et réglementaire doit suivre. Reste à savoir s’il suit assez vite… et dans la bonne direction.

Un objet connecté sans sécurité, c’est une porte ouverte sur le réseau. Mille objets connectés sans sécurité, c’est un mur qui n’existe plus.

Bibliographie

ENISA — Guidelines for Securing the Internet of Things (2020)

https://www.enisa.europa.eu/publications/guidelines-for-securing-the-internet-of-things

Référence européenne pour la sécurité de la chaîne d’approvisionnement IoT. Couvre l’ensemble du cycle de vie des objets connectés, de la conception à la mise au rebut.

NIST — Cybersecurity for IoT Program (SP 800-213 & NISTIR 8259)

https://www.nist.gov/itl/applied-cybersecurity/nist-cybersecurity-iot-program

Programme du NIST dédié à la cybersécurité IoT. Fournit des lignes directrices pour les fabricants et les organisations fédérales sur les exigences de sécurité des objets connectés.

European Commission — Cyber Resilience Act (CRA)

https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act

Page officielle de la Commission européenne sur le CRA. Présente les objectifs, les obligations et le calendrier d’application du règlement imposant la sécurité native des produits connectés.

CISA & NCSC-UK — Secure Connectivity Principles for Operational Technology (2025)

https://www.cisa.gov/resources-tools/resources/secure-connectivity-principles-operational-technology-ot

Guide conjoint CISA/NCSC-UK proposant huit principes pour concevoir, sécuriser et gérer la connectivité des environnements OT. Particulièrement pertinent pour les opérateurs de services essentiels.

ANSSI — Cybersécurité des systèmes industriels : méthode de classification (V2, 2025)

https://messervices.cyber.gouv.fr/guides/la-cybersecurite-des-systemes-industriels

Guide de référence de l’ANSSI pour la classification et la sécurisation des systèmes industriels en France. Définit quatre classes de cybersécurité et les mesures associées, en cohérence avec la norme IEC 62443.