Retrofit OT : ajouter plutôt que modifier

On s'est régulièrement frotté à la question de « sécuriser » une machine industrielle, et la première idée qui venait consiste à chercher les moyens prévus par le constructeur pour modifier un module ou modifier le logiciel des cartes électroniques.
Nous avons fini par faire un choix différent parce qu'une fois mis bout à bout ses effets sur le coût, la conformité et la sécurité, il nous a semblé le plus raisonnable. Voici le cheminement qui nous y a conduits.
Une machine industrielle ne se gère pas comme un serveur
Des équipements pensés pour durer
Là où l'informatique de gestion se met à jour, se redémarre et se remplace à un rythme de quelques années, un automate des années 2000, un frigo ou une presse hydraulique ont été conçus pour durer quinze ou vingt ans.
Ils l'ont été à une époque où personne n'imaginait qu'il faudrait un jour leur adjoindre une authentification forte.
Aucune prise naturelle pour la cybersécurité
Ces équipements ne sont pas obsolètes pour autant : ils font exactement ce qu'on attend d'eux. Mais ils n'offrent aucune fonctionnalité propre aux mécanismes de sécurité modernes.
Et les remplacer n'est, le plus souvent, ni souhaitable ni finançable. C'est précisément à partir de ce constat que, selon nous, le retrofit reste possible et mérite d'être repris avec des composants additionnels dédiés.
Modifier l'existant : un coût rarement anticipé
La tentation est de mettre la machine « à niveau » en intervenant directement dessus. Or toucher au cœur d'un équipement industriel entraîne une série de conséquences que l'on sous-estime souvent au moment de la décision purement financière ("il ne faut pas que ça coûte plus cher que racheter une machine récente") ou technique ("si déjà on peut y arriver, ce sera bien suffisant").
La conformité remise en cause
Une machine porte un marquage CE et une évaluation de sûreté qui reposent sur une configuration précise. Ouvrir l'armoire, recâbler ou insérer un module dans le circuit peut suffire à remettre cette conformité en cause, voire à imposer une nouvelle analyse de risque.
La responsabilité déplacée
Intervenir sur l'équipement d'un fabricant revient fréquemment à endosser une part de sa garantie. Ce qui relevait de sa responsabilité devient, dès l'ouverture du capot, un peu de la vôtre.
La disponibilité mise à mal
Une intervention sur un équipement en production se traduit par un arrêt, un planning et un risque. Sur un site critique, cela n'a rien d'anodin.
La dette de maintenance
Chaque modification finit par devenir un cas particulier, qu'il faudra documenter, maintenir et comprendre pendant toute la durée de vie de la machine.
Additionnées, ces contraintes font qu'on hérite bien souvent du problème que l'on cherchait à résoudre.
Le module « dans l'armoire » ne résout rien, il déplace le problème
Une variante paraît plus habile : plutôt que de reprendre la machine, on y ajoute un module intelligent.
Entrer dans la machine, c'est la modifier
Mais dès l'instant où l'on pénètre dans l'équipement, on le modifie — avec exactement les mêmes conséquences que précédemment.
Deux maîtrises que l'on abandonne
Ce faisant, on renonce en prime à deux formes de maîtrise.
Celle du coût, d'abord, puisque chaque intégration devient un travail sur mesure, difficilement réplicable d'un site à l'autre
.
Celle de la sécurité, ensuite, puisqu'on greffe un composant à l'intérieur d'un système que l'on ne connaît jamais entièrement. Sur le terrain le plus exigeant qui soit, cela fait beaucoup d'inconnues.
Notre choix : des équipements annexes, à la frontière de la machine
Nous avons donc préféré une autre voie, qui consiste à déposer des boîtiers autonomes venant s'intercaler à la frontière de l'équipement — sur le câble d'alimentation, sur la liaison radio, sur le bus série ou sur le port réseau — plutôt qu'en son sein.
Une ancre, des satellites
Le modèle que nous suivons tient en une image : une ancre et des satellites. Un boîtier de décision, que nous appelons le Cube, tient lieu d'ancre de confiance pour une zone. Des effecteurs, les satellites, appliquent la décision, à raison d'un par interface.
On n'entre jamais dans la machine
L'équipement existant, lui, n'est jamais touché. Sa conformité demeure intacte, son fabricant reste seul responsable de son cœur, et l'ensemble du dispositif peut être retiré sans laisser la moindre trace.
Un parti pris, pas une loi universelle
Ce n'est pas une règle absolue, et d'autres approches se défendent. C'est un choix — mais un choix que nous assumons, parce qu'il préserve ce qui fonctionne déjà.
Le moins de développement spécifique possible
Ce choix n'aurait qu'un intérêt limité s'il nous obligeait à réinventer chaque brique. Nous nous imposons donc une règle complémentaire : réduire au strict minimum les développements spécifiques, en assemblant des modules déjà éprouvés plutôt qu'en concevant du sur-mesure.
L'exemple Shelly : beaucoup de fonctions dans un très petit boîtier
Le module Shelly illustre bien pourquoi nous préférons assembler plutôt que concevoir. Dans un composant minuscule et peu coûteux se trouvent déjà réunis le WiFi, le Bluetooth Low Energy, des protocoles dédiés comme Matter, la mesure de puissance et un relais de coupure.
Le tout est capable de tenir dans un boîtier étanche muni de deux simples presse-étoupes — l'un pour l'arrivée, l'autre pour le départ — ce qui suffit à protéger un équipement en extérieur ou en milieu humide.
Le rapport entre le prix et les fonctions embarquées est, très honnêtement, difficile à égaler avec un développement maison.
Les protocoles de sécurité que l'on peut empiler dessus
Ce petit module ne se contente pas d'être polyvalent : il offre déjà plusieurs couches de sécurité sur lesquelles s'appuyer, et d'autres que l'on peut activer ou ajouter par-dessus. Nous les résumons ici, car ils mériteront un article à part entière.
Au niveau réseau, le WiFi en WPA2 / WPA3 et le MQTT protégé par mTLS chiffrent et authentifient les échanges. Matter apporte son propre modèle, avec une attestation de l'appareil fondée sur des certificats et un appairage sécurisé lors de la mise en service.
Le firmware d'origine, lui, se met à jour par un canal signé, ce qui limite le risque d'altération à distance.
L'accès local — interface web, appels RPC — peut être authentifié, et l'entrée physique découplée du relais, de sorte que le bouton signale sans jamais commander directement.
Par-dessus cet existant, nous ajoutons enfin notre propre couche : des capacités éphémères signées, une décision prise localement, et un comportement à l'arrêt par défaut en cas de doute.
L'essentiel, à ce stade, est de constater qu'un module standard peut porter une sécurité sérieuse sans développement spécifique lourd. Nous détaillerons ces protocoles, et la manière de les combiner, dans un prochain article.
Ce que nous en gardons
De ce module, nous ne conservons que le comportement souhaité : la commande passe par notre boîtier, l'entrée physique se contente de signaler, et le relais n'obéit qu'à la décision locale. Nous pouvons désactiver toutes les fonctionnalités annexes, notamment le Cloud propriétaire ou la commande par une application sur smartphone.
Le matériel est éprouvé, son fabricant documenté, et son protocole ouvert nous évite de repartir d'une feuille blanche. Nous pouvons appliquer la même logique avec beaucoup de composants, issus de l'IoT parfois même en accès grand public, en les réduisant à notre contexte industriel hors réseaux et en y ajoutant notre savoir-faire.
Des briques open source, logicielles et matérielles
Pour le reste, nous privilégions les briques open source, aussi bien logicielles que matérielles.
Les firmwares que nous développons sont publiés sous licence libre et reposent sur des cadres ouverts et audités, comme le ESP-IDF d'Espressif ou le Zephyr RTOS de la Linux Foundation.
Côté matériel, nous bâtissons sur des plateformes ouvertes — cartes à microcontrôleur documentées, conceptions partagées, modules cellulaires open hardware comme Walter, dont les schémas et l'empreinte KiCad sont publiés — qui nous permettent de comprendre exactement ce que nous déployons.
Le développement propre se limite à la chaîne de confiance
Le travail que nous conservons en propre se concentre alors sur ce qui fait réellement notre valeur : la chaîne de confiance qui relie ces briques entre elles, et non la plomberie qui les fait fonctionner.
Le double effet : coût et sécurité
Ce parti pris a un double effet, et c'est pour cela que nous y tenons. Il maîtrise le coût, puisqu'un module standard a un prix connu d'avance et réplicable d'un site à l'autre.
Il maîtrise également la sécurité, puisqu'un composant que nous avons choisi, dont nous connaissons le firmware et le comportement, se laisse auditer et durcir.
S'interfacer avec un maximum de matériels
Un même schéma, interface par interface
L'autre mérite de l'approche annexe est qu'elle reste largement agnostique quant à la machine protégée, un même schéma se déclinant interface par interface : couper une alimentation 230 V, filtrer un clavier ou une souris USB, proxifier un périphérique sans fil, segmenter un port Ethernet, ou s'intercaler sur un bus série RS-485 / Modbus.
Enrôler du legacy sans le modifier
Dans chaque cas, on enrôle un équipement ancien sans le modifier : on l'observe, on l'entoure, et l'on agit à sa frontière.
Ce qui fonctionne aujourd'hui, ce qui vient
Précisons que l'effecteur aujourd'hui pleinement opérationnel est la coupure d'alimentation. Les autres interfaces figurent sur notre feuille de route et reposent sur le même principe. La primeur aux clients qui nous solliciteront sur un nouveau cas particulier !
Des briques concrètes, et où les trouver
Pour rendre tout cela tangible, voici quelques exemples de ce que l'on peut faire sans toucher à la machine, et les solutions — commerciales ou open source — sur lesquelles s'appuyer.
Quelques exemples
Couper l'alimentation d'un variateur récalcitrant au moyen d'un Shelly Pro 1PM posé sur le rail DIN de l'armoire, sans jamais ouvrir le variateur lui-même.
Repérer un traceur BLE isolé, ou une télécommande 433 MHz suspecte, à l'aide d'une passerelle radio d'écoute.
Isoler un segment automate derrière une passerelle réseau, sans avoir à reconfigurer l'automate.
Dialoguer en lecture seule avec un automate Modbus ancien pour l'inventorier, sans jamais y écrire.
Une petite boîte à outils
Coupure et mesure d'énergie — Shelly (modules du commerce, du rail DIN à la prise), avec pour firmware libre alternatif ESPHome ou Tasmota.
Embarqué open source — ESP-IDF et Zephyr RTOS pour le logiciel ; Walter et ses dépôts QuickSpot pour un matériel cellulaire ouvert.
Racine de confiance matérielle — l'élément sécurisé STSAFE-A120 de STMicroelectronics, sur une plateforme certifiée Critères Communs EAL5+, complété par le cadre IoT SAFE de la GSMA.
Écoute BLE et sub-GHz — OpenMQTTGateway (BLE et 433 / 868 MHz) et les décodeurs rtl_433.
Réseau et bus de terrain — OpenWrt pour segmenter un port Ethernet, libmodbus pour s'interfacer avec un bus RS-485 / Modbus.
Conception des satellites — l'outil de CAO électronique libre KiCad, qui nous sert d'ailleurs à publier nos propres schémas.
Aucune de ces briques n'est un secret, et c'est précisément l'intérêt. Le sur-mesure, nous le réservons à ce qui fait vraiment la différence : la chaîne de confiance qui les relie.
Un retrofit réussi tient plus de la couche que de la greffe
Réversible plutôt que définitif
Greffer un organe, c'est toujours prendre le risque du rejet. Ajouter une couche, c'est au contraire rester réversible, chiffrable et maîtrisé.
Sans prétendre rendre la machine neuve
Nous ne prétendons pas, ce faisant, rendre la machine « neuve ». Un accès physique prolongé demeure un accès physique, et nous préférons le documenter plutôt que de le nier.
La façon la plus honnête de sécuriser un parc installé
Cette approche a le mérite de ramener de la confiance là où il n'y en avait pas, sans rien imposer à ce qui fonctionne déjà. C'est, à nos yeux, la manière la plus honnête de sécuriser un parc installé que l'on ne peut pas remplacer.
Envie de voir le principe en fonctionnement ? Lors d'une démonstration, vous prenez la place de l'intrus : vous tentez de mettre le système en échec, il réagit sous vos yeux, et vous repartez avec le journal d'audit signé de vos propres essais.