Le zéro confiance fonctionne bien dans l’informatique d’entreprise. Dans les environnements IoT et OT, ses hypothèses échouent discrètement. Et l’échec se produit souvent d’une manière que les défenseurs ne voient qu’après un incident.
Le zéro confiance résout le mauvais problème en OT
La confiance zéro est devenue le discours de sécurité dominant de la dernière décennie, et à juste titre. Ses principes fondamentaux : ne jamais faire confiance, toujours vérifier ; supposer une violation ; appliquer le moindre privilège, ont remodelé la façon dont les organisations envisagent l’identité, l’accès et les mouvements latéraux. Dans les environnements informatiques d’entreprise, ces principes ont produit des gains mesurables. L’identité est plus forte. L’accès est plus délibéré. La confiance implicite a été réduite.
Pourtant, lorsque le modèle Zero Trust est appliqué aux environnements IoT et OT, les résultats sont inégaux. Des contrôles sont déployés. Les diagrammes d’architecture semblent rassurants. Ensuite, des incidents surviennent. Cela se produit souvent à travers des systèmes qui n’ont jamais été considérés comme faisant partie du modèle de confiance en premier lieu.
Le modèle Zero Trust est conçu pour régir les décisions d’accès. Dans les environnements IoT et OT, la plupart des pannes à fort impact se propagent via des chemins de confiance hérités et de contrôle partagés, qui échappent au champ d’application du Zero Trust.
Il ne s’agit pas d’un échec de mise en œuvre. C’est une inadéquation de modèle.
La confiance zéro suppose que la confiance est explicite, centrée sur l’identité et applicable en permanence. Les systèmes IoT et OT (et IA) violent les trois hypothèses dès leur conception. En conséquence, la confiance zéro régit souvent les mauvaises surfaces tout en laissant non modélisées les chemins les plus conséquents.
L’angle mort de l’IoT et de l’OT
Les environnements IoT et OT présentent systématiquement trois caractéristiques qui créent des angles morts persistants en matière de sécurité.
Premièrement, la visibilité est incomplète par conception. Les appareils sont fréquemment déployés par les équipes des installations, les groupes d’ingénierie ou les intégrateurs tiers plutôt que par les organisations de sécurité. Les inventaires d’actifs sont en retard sur la réalité. La télémétrie est rare, propriétaire ou intermittente. De nombreux appareils ne communiquent que pendant des états de fonctionnement spécifiques, laissant de longues périodes de silence que les outils de sécurité interprètent comme d’habitude.
La CISA a averti à plusieurs reprises que les appareils non gérés, la visibilité limitée et les protocoles opérationnels existants restent parmi les faiblesses les plus courantes des environnements IoT et OT, en particulier là où les systèmes n’ont jamais été destinés à être surveillés en permanence ou gouvernés de manière centralisée.
Deuxièmement, les réseaux sont fonctionnellement plats même lorsqu’ils semblent segmentés. Les protocoles de découverte de diffusion, les passerelles partagées et les contrôleurs centralisés sapent les hypothèses d’isolement. Les appareils qui ne communiquent jamais directement peuvent néanmoins s’influencer mutuellement via une infrastructure partagée. La segmentation existe sur le papier, mais le couplage persiste en opération.
Troisièmement, la confiance est implicite et durable. Les appareils font confiance aux contrôleurs parce qu’ils l’ont toujours fait. Les contrôleurs font confiance aux plateformes de gestion parce qu’elles sont « autorisées ». Les services cloud font confiance aux identités des appareils intégrées dans le micrologiciel. Ces relations de confiance sont rarement documentées et rarement revisitées une fois les systèmes opérationnels. La confiance zéro suppose que la confiance peut être continuellement remise en question. Les systèmes OT supposent que la confiance persiste jusqu’à ce que quelque chose se brise.
Pourquoi la topologie échoue en tant que modèle de sécurité
Les équipes de sécurité sont formées à raisonner sur la topologie : sous-réseaux, pare-feu, zones et chemins d’accès. Cette approche fonctionne raisonnablement bien dans l’informatique d’entreprise, où les systèmes sont conçus autour d’une connectivité routable et d’une authentification explicite.
Il échoue dans les environnements IoT et OT car la compromission ne se propage pas principalement via des chemins routés.
Dans Le modèle de liaison unifiée : une nouvelle perspective pour comprendre le cyber-risque, j’ai présenté un ULM comme moyen d’analyser le risque de sécurité basé sur les relations fonctionnelles, la contiguïté, l’héritage et la confiance, plutôt que uniquement sur la topologie du réseau. Cette distinction est essentielle dans les environnements OT, où les diagrammes de connectivité reflètent rarement la dépendance opérationnelle.
Deux systèmes peuvent être complètement isolés au niveau de la couche réseau tout en étant fonctionnellement inséparables. Les contrôleurs partagés, les traducteurs de protocole et les plateformes de gestion créent des dépendances que la topologie ne capture pas. Lorsqu’un système change d’état, que ce soit à cause d’une compromission, d’une mauvaise configuration ou d’une mise à jour, l’autre change avec lui.
L’ULM se concentre sur les conséquences et la connexion. C’est cette focalisation qui manque à la confiance zéro dans les contextes OT.
Où les attaques se propagent réellement
La plupart des violations de l’IoT et de l’OT ne se produisent pas sous la forme de défaillances d’identité ou de contournements de segmentation. Ils se propagent via des contrôleurs partagés, des micrologiciels hérités, des mécanismes de mise à jour et des plates-formes de gestion, des lieux où la confiance existe déjà.
Les directives fédérales du NIST soulignent depuis longtemps que les micrologiciels, les services de mise à jour et les infrastructures partagées représentent des sources durables de risques hérités que les contrôles axés sur le périmètre ne traitent pas. Ces composants sont placés sous les contrôles d’accès et persistent lors des reconfigurations, des changements de propriété et même des transitions de fournisseurs.
Une fois compromis, ils propagent automatiquement la confiance. Aucun mouvement latéral n’est requis. Aucune information d’identification ne doit être volée dans les systèmes en aval. L’attaquant se déplace avec le grain de l’architecture.
C’est pourquoi les incidents proviennent si souvent des systèmes d’automatisation des bâtiments, des interfaces de maintenance ou des services gérés par les fournisseurs. Ces composants sont rarement surveillés en tant qu’actifs critiques pour la sécurité, mais ils agissent comme un tissu conjonctif dans des environnements que les défenseurs estiment isolés.
Du Zero Trust à la cartographie de la confiance
Le zéro confiance régit l’accès. Il ne modélise pas les conséquences.
Les défenseurs doivent donc compléter la confiance zéro par un moyen de comprendre comment la confiance se propage réellement dans les systèmes IoT et OT. Le modèle de liaison unifiée lui-même est né de travaux antérieurs sur la propagation des risques basée sur les liaisons dans les environnements d’entreprise et industriels, avant d’être appliqué plus directement à la prise de décision en matière de sécurité dans des systèmes complexes.
ULM distingue trois formes de liens qui sont importantes sur le plan opérationnel :
- Proximitécréé par des contrôleurs partagés, des passerelles, des courtiers et des traducteurs de protocole
- Héritagecréé par le micrologiciel, les SDK, les services de mise à jour et les plates-formes des fournisseurs
- Propagation de la confiancecréé par une gestion déléguée, une autorisation implicite et des informations d’identification de longue durée
Ces liens déterminent la manière dont les échecs se cascadent. Les liens montrent pourquoi les appareils perçus comme à faible risque servent régulièrement de catalyseurs en amont d’un impact disproportionné sur la mission. Ils expliquent également pourquoi les contrôles centrés sur l’identité ne parviennent souvent pas à interrompre les attaques une fois la confiance déjà établie.
La confiance zéro répond à la question
ULM répond à la question
Les deux questions comptent. Ils ne sont pas interchangeables.
Pourquoi l’application est centralisée dans l’OT
Une autre raison pour laquelle le Zero Trust rencontre des difficultés dans les environnements OT est la localité d’application.
Les systèmes OT donnent la priorité au déterminisme, à la disponibilité et à la sécurité. Les boucles de contrôle ne peuvent pas s’arrêter pour évaluer les politiques. La latence compte. Les appareils ne peuvent pas tolérer des réauthentifications fréquentes ou une surcharge de télémétrie. En conséquence, l’application de la loi s’étend vers l’extérieur : vers les passerelles, les plateformes de gestion et les services cloud.
Ces points d’application deviennent des points d’étranglement. Une fois approuvés, ils sont rarement revalidés. S’ils sont compromis, ils contournent simultanément toutes les hypothèses de confiance zéro en aval.
La confiance zéro suppose que l’application est partout. Les systèmes OT le centralisent.
Ce que les responsables de la sécurité devraient faire différemment
Il ne s’agit pas d’un appel à abandonner la confiance zéro. C’est un appel à le définir correctement.
La confiance zéro reste efficace là où les identités sont fortes et où l’application est continue. Dans les environnements IoT et OT, les dirigeants doivent également tenir compte de la confiance héritée et des chemins de contrôle centralisés que la confiance zéro ne modélise pas.
Cela signifie mapper explicitement les dépendances fonctionnelles. Cela signifie identifier les composants qui propagent la confiance entre les domaines. Cela signifie protéger de manière disproportionnée les plans de gestion, les mécanismes de mise à jour et les passerelles de protocole, non pas parce qu’ils constituent des cibles attrayantes, mais parce qu’ils sont des amplificateurs structurels.
Cela signifie également repenser le risque lié aux fournisseurs. Les fournisseurs doivent être évalués non seulement sur ce qu’ils fournissent, mais aussi sur le degré de confiance dont ils héritent et se propagent à travers les systèmes une fois intégrés.
Le vrai risque est ce que vous ne modélisez pas
La confiance zéro concerne les décisions d’accès. Cela n’explique pas comment le compromis se propage une fois que la confiance existe déjà. Dans les environnements OT, cette distinction est décisive.
L’analyse basée sur les liens comble cette lacune. En rendant explicites la contiguïté, l’héritage et la confiance, il expose le réseau invisible sous les systèmes IoT et OT. Pour les responsables de la sécurité responsables de la résilience opérationnelle, cette visibilité est un levier.
Les failles de sécurité de l’IoT et de l’OT persistent, non pas parce que les défenseurs manquent d’outils, mais parce qu’ils s’appuient sur des modèles qui ne reflètent plus la réalité.
Cet article est publié dans le cadre du Foundry Expert Contributor Network.
Voulez-vous nous rejoindre ?



