La sécurité au bout de la prise électrique...

Pourquoi le dernier point d'application de la politique de sécurité que nous devons implémenter est la prise de courant.

Ce que le Cube entend

Radio en atelier : ce qu'on peut savoir, ce qu'on ne peut pas, et comment détecter qu'on nous ment Un atelier industriel est un endroit bruyant. Pas seulement pour les oreilles : entre les téléphones des intervenants, les capteurs sans fil, les télécommandes de pont roulant, les traceurs oubliés dans une caisse à outils et les modems des machines récentes, un local de production émet en permanence sur une douzaine de bandes de fréquences. Cet article explique ce que notre matériel écoute, comment il distingue une présence d'une intoxication, et où sont les limites. Il est technique, mais chaque terme est expliqué au passage : aucune connaissance en radio n'est nécessaire pour le lire. Trois questions différentes, souvent confondues Avant les protocoles, une distinction qui structure tout le reste. « Faire de la détection radio » recouvre trois besoins qui n'ont ni les mêmes moyens ni les mêmes limites. La question Ce qu'il faut La difficulté principale Ce badge est-il ici, maintenant ? Écouter une balise connue et suivre sa présence Distinguer une vraie proximité d'un signal relayé Qu'est-ce qui émet dans cette pièce ? Inventorier tout ce qui passe, connu ou non Les adresses changent en permanence, et le RGPD s'applique Est-ce qu'on essaie de m'aveugler ? Mesurer l'état du spectre lui-même Un brouillage réussi ressemble beaucoup à une panne Notre système répond à la première en continu, à la deuxième en option, et à la troisième par construction — parce que c'est celle qui protège les deux autres. Niveau 1 : le BLE, le plus simple et le plus trompeur Ce qu'un appareil Bluetooth raconte sans qu'on lui demande Le Bluetooth Low Energy fonctionne par annonces : un appareil qui souhaite être découvert émet, toutes les quelques centaines de millisecondes, un petit paquet contenant son adresse, parfois un nom, parfois des données de service. Ces paquets circulent en clair sur trois canaux dédiés que n'importe quel récepteur peut écouter sans se connecter à quoi que ce soit. C'est ce qui rend la détection facile. Notre Cube en mode écoute voit passer les montres connectées, les écouteurs, les traceurs d'objets, les capteurs de température, les téléphones en mode découverte et surtout, c'est le point qui nous intéresse, les badges que nous avons enrôlés. À chaque paquet reçu s'ajoute une mesure : le RSSI , la force du signal reçu. C'est un indicateur en décibels qui décroît quand on s'éloigne. C'est ce qui donne l'illusion d'une mesure de distance, et nous verrons plus bas pourquoi c'en est une mauvaise. Un système de détection naïf compte les adresses et croit compter les appareils. Il se trompe massivement, parce que les appareils modernes changent d'adresse en permanence. Le mécanisme s'appelle RPA — Resolvable Private Address , adresse privée résoluble. Un téléphone ou une montre tire une nouvelle adresse toutes les quinze minutes environ. Pour un observateur extérieur, il devient un appareil différent quatre fois par heure. Un tableau de bord qui affiche « 47 appareils détectés ce matin » dans un atelier qui a vu passer six personnes ne ment pas volontairement : il compte des adresses. Donc forcément, c'est pas comme ça qu'il faut faire. Mais ce mécanisme a une propriété que l'on peut exploiter, et c'est elle qui fait toute la différence entre un appareil enrôlé et un inconnu. Chaque adresse privée est calculée à partir d'une clé, l' IRK ( Identity Resolving Key ), échangée une seule fois lors de l'appairage. Qui possède l'IRK peut vérifier qu'une adresse apparemment aléatoire appartient bien à l'appareil qu'il connaît. Qui ne la possède pas ne voit qu'une suite de nombres sans lien entre eux. Concrètement : nos badges enrôlés restent suivis en continu malgré leurs changements d'adresse, et les appareils que nous ne connaissons pas restent, par construction, non pistables. Ce n'est pas une politique de confidentialité que nous avons écrite : c'est une propriété du protocole, et nous la considérons comme un avantage plutôt qu'un obstacle. On peut l'étendre à d'autres appareils si on veut aussi faire de la logistique avec le Cube : suivre du matériel mobile et vérifier ce qui est sorti et ce qui est disponible. Ou mieux s'organiser avant de partir sur un chantier en ayant oublié juste la petite malette mise à recharger la veille au soir (on l'a tous vécu). Entrées et sorties : le piège du seuil unique Décider qu'un badge « est entré » quand son RSSI dépasse une valeur, et « est sorti » quand il repasse en dessous, produit un système inutilisable. Le RSSI fluctue de dix à vingt décibels quand quelqu'un se retourne, passe derrière une machine ou pose son badge sur un établi métallique. Un seuil unique génère des dizaines d'entrées-sorties par heure pour une personne assise. Trois mécanismes classiques corrigent cela, et ils valent pour n'importe quel système de ce type : L'hystérésis. Deux seuils au lieu d'un : on entre à −65 dBm, on ne sort qu'en dessous de −80 dBm. La zone grise entre les deux ne produit aucun événement. La fenêtre de persistance. Un badge n'est déclaré absent qu'après plusieurs cycles d'annonce manqués consécutifs, pas au premier paquet perdu. Une salve d'interférences ne coupe donc pas un accès en cours. Le lissage temporel. On travaille sur une moyenne glissante des dernières mesures, jamais sur la valeur instantanée. Le réglage de ces trois paramètres est propre à chaque local, car un atelier d'usinage avec des machines en fonte n'a pas la même signature qu'un laboratoire d'électronique. C'est précisément ce que le mode Observation mesure avant que quoi que ce soit ne soit armé. Niveau 2 : le Wi-Fi, le plus riche et le plus réglementé Ce qu'on voit sans se connecter Un module Wi-Fi placée en mode moniteur — un mode d'écoute passive où elle capte tout ce qui passe sur un canal sans rejoindre aucun réseau — voit une catégorie de trames que le chiffrement ne protège pas : les trames de gestion . Balises des points d'accès, requêtes de découverte des terminaux, demandes d'association, demandes de déconnexion. Même sur un réseau en WPA3, ces trames circulent en clair, parce qu'elles servent justement à négocier la connexion. Cela suffit pour repérer trois choses utiles : Un point d'accès non autorisé. Un boîtier 4G branché dans une armoire, un téléphone en partage de connexion posé sur une baie. Le géant du secteur Bastille rapporte un cas documenté dans un centre de données : un smartphone configuré en point d'accès, associé à un dongle raccordé à une baie serveur, avait ouvert un chemin de données passant par la liaison cellulaire du téléphone, contournant intégralement pare-feu, DLP et SIEM. Aucun outillage sophistiqué n'était nécessaire pour l'attaque, mais non plus pour la défense ! Une attaque de déconnexion. L'envoi massif de trames de déconnexion forcée est l'attaque Wi-Fi la plus répandue, et elle est triviale à détecter : un volume anormal de ces trames en provenance d'une même adresse. À noter qu'elle échoue contre les réseaux qui activent la protection des trames de gestion (norme 802.11w), ce que fait WPA3 — encore faut-il que le parc le supporte. Un jumeau maléfique. Un point d'accès qui annonce le nom d'un réseau légitime depuis un emplacement où il n'a rien à faire, ou avec une adresse matérielle qui ne correspond pas à l'équipement déclaré. La même limite qu'en BLE, en pire Depuis iOS 14 et Android 10, les terminaux utilisent une adresse matérielle aléatoire différente pour chaque réseau, et randomisent aussi leurs requêtes de découverte. Compter des adresses Wi-Fi pour compter des personnes est encore moins fiable qu'en Bluetooth. Et surtout : écouter le Wi-Fi ambiant, c'est collecter des données personnelles. Nous y revenons plus bas, parce que c'est le chapitre que la plupart des articles techniques sur ce sujet omettent. Niveau 3 : le satellite SDR, pour tout le reste Ce qu'est une radio logicielle Une SDR — software-defined radio , radio définie par logiciel — est un récepteur qui ne sait rien faire tout seul. Il numérise une tranche de spectre brute et laisse un ordinateur décider comment l'interpréter. Le même matériel écoute donc une télécommande de portail, un capteur de température, un badge sans contact ou un modem, selon le programme qu'on lui donne. C'est ce qui permet d'envisager un effecteur dédié à l'écoute : une carte SDR dans un boitier étanche avec micro-ordinateur avec l'antenne adaptée à la bande visée. Encore faut-il couvrir la bande la plus intéressante en milieu industriel, les 2,4 GHz où vivent le Wi-Fi, le Bluetooth et Zigbee. Une écoute large spectre sérieuse suppose au minimum deux radios : une pour le sub-GHz, une pour les 2,4 GHz. Ce qu'on y trouve Sur la bande sub-GHz, l'outil de référence est rtl_433 , un décodeur libre qui reconnaît plus d'un millier de protocoles de capteurs et de télécommandes du commerce, sur 315, 433, 868 et 915 MHz. Ce qu'il révèle dans un atelier est souvent une surprise : sondes de température installées par un prestataire et oubliées, télécommandes de pont roulant, capteurs de porte, stations météo, et de temps en temps un équipement qui ne figure sur aucun inventaire. C'est là que la détection radio rejoint la conformité. Un parc dont on ne connaît pas les émetteurs est un parc dont l'inventaire des actifs est incomplet — et l'inventaire des actifs est une exigence explicite de NIS 2. Détecter qu'on nous aveugle Ce qu'est un brouillage Trois familles, de la plus grossière à la plus fine : Le bruit large bande. On émet de la puissance sur toute la bande, en continu. Simple, efficace, et parfaitement visible. Le brouillage réactif. L'émetteur écoute et n'émet que lorsqu'il détecte le début d'une trame légitime, juste assez pour la corrompre. Beaucoup plus discret : le plancher de bruit reste normal. Le brouillage protocolaire. On n'émet pas de bruit, on émet des trames valides comme des déconnexions forcées en Wi-Fi, par exemple. Rien d'anormal au niveau radio mais tout est anormal au niveau logique. Les signatures qui trahissent Aucune n'est décisive seule, c'est leur conjonction qui fait un signal. Un plancher de bruit qui monte sans trafic décodable. La signature classique. Beaucoup d'énergie reçue, aucun paquet valide : quelque chose émet qui ne parle pas notre langue. Un taux d'échec de contrôle d'intégrité qui explose. Les paquets arrivent mais leur somme de contrôle échoue : ils sont corrompus en vol. C'est la signature du brouillage réactif, celle que le plancher de bruit ne montre pas. Une occupation de canal anormale. Chaque local a une signature d'occupation propre, apprise pendant la phase d'observation après déploiement du Cube. Un écart marqué par rapport à cette référence est plus parlant qu'un seuil absolu. Et la plus utile de toutes : la disparition simultanée. Nos effecteurs émettent périodiquement. S'ils cessent tous d'être entendus en même temps, l'hypothèse « quatre pannes matérielles à la même seconde » est nettement moins probable que l'hypothèse « quelque chose couvre la bande ». C'est le signal le plus fiable dont nous disposons, et il ne coûte rien : il découle du fait que le système se parle à lui-même en permanence. Ce qu'on en fait Rien de plus qu'un refus, et c'est volontaire. On ne peut pas empêcher un brouillage, mais c'est un signal clair. Un brouillage détecté fait retomber la zone en refus, avec un événement journalisé portant son motif. La contrepartie doit être dite franchement : le système est vulnérable au déni de service. Quelqu'un qui veut arrêter votre production plutôt que d'y entrer y parviendra en couvrant la bande. La réponse à cela n'est pas technique mais organisationnelle : procédure de dérogation (le QR Code à scanner pour réactiver les effecteurs du Cube), mode secours, surveillance de la disponibilité radio. Et accessoirement juridique : en France, la détention et l'usage de brouilleurs radioélectriques sont interdits hors dérogations très encadrées, ce qui ne dissuade pas tout le monde mais change la nature de l'incident. Détecter qu'on nous intoxique Le rejeu et la copie Une annonce BLE circule en clair et se recopie. C'est pourquoi nous ne traitons jamais une annonce comme une preuve d'identité : elle déclenche une conversation avec le Cube, elle n'autorise pas l'accès. L'autorisation vient d'un défi cryptographique auquel seule la clé contenue dans l'élément sécurisé du badge ou du smartphone sait répondre, et qui ne peut être rejoué. C'est la parade fiable, et elle est bien comprise. Le problème suivant l'est moins. Le relais, ou l'attaque qu'aucune signature n'arrête Un attaquant place un premier appareil près du badge légitime resté au vestiaire et un second près de la machine, puis retransmet la conversation entre les deux. Rien n'est falsifié : les messages sont authentiques, les signatures sont valides, le défi cryptographique est correctement résolu. Ce qui est fabriqué, c'est la proximité, et la proximité n'est pas une propriété qui se signe. Aucune couche cryptographique ne voit cette attaque. Seule une mesure physique la contredit. D'où notre préférence pour le smartphone avec une action physique de déverrouillage de son utilisateur, si le matériel est autorisé dans votre contexte. Les mesures physiques qui contredisent un relais La mesure de temps de vol (UWB). La référence et certainement notre prochaine phase de R&D. L'ultra-large bande, normalisée dans IEEE 802.15.4z avec sa séquence d'horodatage brouillée, mesure le temps que met un signal à faire l'aller-retour. Comme la lumière ne se laisse pas accélérer, un relais ajoute forcément du délai. C'est la seule réponse structurelle au problème. Nous ne l'avons pas aujourd'hui, et un écart visible avec le standard Aliro publié par la Connectivity Standards Alliance qui reste un très bon modèle. La cohérence multi-capteurs. Avec plusieurs récepteurs répartis dans un local, un émetteur réel produit un profil de niveaux cohérent avec sa position. Un relais produit souvent une incohérence : un signal très fort vu par un seul capteur, ou un profil qui ne varie pas alors que la personne se déplace. Ce n'est pas une preuve, c'est une invraisemblance et cela peut suffire à refuser l'accès. La radiogoniométrie. Déterminer la direction d'où vient un signal. Le KrakenSDR a rendu cette technique abordable : cinq récepteurs RTL-SDR partagés sur une horloge unique, avec matériel de calibration intégré, exploités par interférométrie corrélative, le tout avec un logiciel d'acquisition et de traitement en open source, tournant sur un Raspberry Pi 4 ou 5. Sa limite pour nous est franche : il monte à 1,766 GHz et ne couvre donc pas les 2,4 GHz du Bluetooth. Pour la direction en BLE, la voie normalisée est le Bluetooth 5.1 avec extension de tonalité constante , qui permet le calcul d'angle d'arrivée à l'aide d'un réseau d'antennes. L'empreinte radio de l'émetteur. Chaque émetteur porte des imperfections de fabrication mesurables (décalages de fréquence, bruit de phase, défauts de modulation) qui forment une signature difficile à imiter. C'est un domaine de recherche actif et prometteur. Nous le suivons avec attention. Le cas Flipper Zero Il est cité dans toutes les conversations sur ce sujet, souvent de travers. Autant poser les faits. Ce qu'il fait. Un émetteur-récepteur CC1101 couvrant les bandes 300–348, 387–464 et 779–928 MHz, avec une portée annoncée d'une cinquantaine de mètres. Sur ces bandes, il lit, enregistre et rejoue des télécommandes à code fixe : portails, barrières, interrupteurs radio, sonnettes. Contre un équipement à code fixe, il est redoutable et il a effectivement banalisé une compétence qui demandait auparavant un vrai savoir-faire. Ce qu'il ne fait pas. Il ne touche pas aux 2,4 GHz : ni Wi-Fi, ni Bluetooth, ni Zigbee. Son étage de puissance interne est faible, au point qu'une tentative de brouillage ne porte qu'à quelques dizaines de centimètres. Le Flipper seul n'est donc pas la menace universelle qu'on décrit. Ce qui change la donne. Les cartes d'extension à trois modules, vendues quelques dizaines d'euros, ajoutent un ESP32 pour le Wi-Fi, un nRF24 pour les 2,4 GHz propriétaires et un CC1101 amplifié à antenne externe. Avec cet ensemble, l'appareil accède aux attaques sur claviers et souris sans fil de la famille MouseJack, aux attaques Wi-Fi, et à un brouillage sub-GHz à bien plus longue portée. La menace n'est pas l'appareil à 170 €, c'est l'appareil plus la carte à 30 €. Comment il se voit. Chacun de ses modules laisse une trace. L'émission sub-GHz est visible d'un effecteur SDR. Le firmware Wi-Fi le plus répandu sur ces cartes produit des trames de déconnexion en volume caractéristique. Le module 2,4 GHz propriétaire émet sur des canaux et avec un format d'adressage distinctifs. Aucun de ces indices n'est une preuve d'intention mais ensemble, dans un atelier où rien de tel n'est censé se trouver, ils constituent une anomalie qui mérite une alerte. Tandis que revoilà le RGPD Écouter les ondes d'un local, c'est traiter des données personnelles. C'est la position constante de la CNIL : l'adresse matérielle d'un téléphone est une donnée à caractère personnel. L'histoire du sujet en France est instructive. En 2015, la CNIL refuse à JCDecaux un dispositif de comptage Wi-Fi sur le parvis de La Défense, au motif que l'anonymisation annoncée n'était pas irréversible, l'opérateur pouvait rejouer le procédé de hachage. En 2018, une société de mesure de fréquentation en magasin est mise en demeure. Entre-temps, la CNIL a précisé les règles applicables. Ce qu'elle demande, en substance Pour un simple comptage agrégé, une anonymisation dans les cinq minutes suivant la collecte ou bien une pseudonymisation immédiate suivie d'une anonymisation ou d'une destruction sous vingt-quatre heures, avec une information des personnes nettement plus complète. Une information visible sur place , sur le modèle de l'affichette de vidéosurveillance, renvoyant vers une information détaillée. Un droit d'opposition praticable . Et une précision qui tranche beaucoup de débats : demander aux gens d'éteindre le Wi-Fi de leur téléphone n'est pas une modalité d'opposition acceptable, puisque cela revient à les priver d'une fonction de leur appareil. Ce que nous en faisons Notre position découle plus de l'architecture que de la vertu. Nous n'avons pas besoin de suivre les inconnus. Le système doit répondre à « le porteur enrôlé est-il présent ? ». Les identifiants que nous conservons sont ceux des badges et téléphones volontairement enrôlés , dont les porteurs sont informés et dont l'IRK nous a été confié explicitement. Pour tout le reste, un compteur agrégé et une détection d'anomalie suffisent. Le mécanisme d'adresse tournante joue en notre faveur. Sans l'IRK, une adresse BLE inconnue n'est pas rattachable d'un cycle sur l'autre. Le non-pistage des tiers est une propriété du protocole, pas une promesse contractuelle. Les journaux nomment des personnes autorisées, pas des passants. Un événement d'anomalie enregistre qu'un émetteur non identifié était présent, avec son horodatage et sa bande — pas une identité de tiers reconstituée. Un dispositif d'écoute large spectre dans un local où travaillent des salariés relève par ailleurs de l'information et de la consultation du CSE. Ce n'est pas un détail de mise en œuvre mais c'est un prérequis de déploiement, et nous préférons le poser avant l'installation qu'après une réclamation. Dans notre carrière, nous avons vu de beaux projets techniques revenir à la feuille de papier pour des problèmes d'accord sur le suivi potentiel (mais non prévu par le projet) des horaires de présence, des lieux de présence voire de délai entre plusieurs positions. Ce que la détection prouve, et ce qu'elle ne prouve pas Mécanisme Ce qui est prouvé Ce qui ne l'est pas Réception d'une annonce BLE Un émetteur portant cet identifiant a émis à portée Que son porteur légitime est là Résolution d'adresse via l'IRK Cet émetteur est bien l'appareil enrôlé Qu'il n'a pas été prêté ou volé RSSI et hystérésis Une proximité radio plausible et durable Une distance réelle — le signal peut être relayé Écoute Wi-Fi en mode moniteur Présence d'un point d'accès ou d'une activité anormale Un inventaire complet des terminaux présents Balayage SDR large spectre Qu'un émetteur a été observé sur cette bande Qu'aucun autre n'a émis pendant qu'on regardait ailleurs Détection de brouillage Que la bande est devenue inexploitable Qui brouille, ni depuis où Cohérence multi-capteurs Une invraisemblance géométrique Un relais, de façon certaine, seul le temps de vol le fait Si l'on devait résumer la ligne éditoriale de ce tableau en une phrase : la détection radio corrobore une décision, elle ne la fonde jamais. Notre quatrain d'or pour Trust-Buster tient sur la détection, l'identification, la validation et l'action (DIVA), et seules les deux trois reposent sur de la cryptographie. La première est un filtre qui réduit la surface, et nous ne l'écrivons jamais autrement. Où se situe ce que nous faisons Le marché de la détection radio se lit sur trois étages, et il est utile de dire lequel est le nôtre. En haut, la surveillance d'espace. Bastille Networks en est la référence : couverture continue de la dizaine de mégahertz à plusieurs gigahertz, réseaux de capteurs passifs alimentés par le réseau filaire, localisation d'un émetteur à quelques mètres près, historique des déplacements. C'est un produit de sécurité d'installation, vendu à des clients gouvernementaux et à de grandes entreprises, et son prix correspond à sa couverture. Au milieu, les systèmes de détection d'intrusion Wi-Fi intégrés aux infrastructures réseau des grands équipementiers. Efficaces sur leur périmètre, aveugles sur tout le reste : Bluetooth, sub-GHz, propriétaire. En bas, l'outillage libre , largement suffisant pour construire un capteur honnête : Kismet, rtl_433, OpenMQTTGateway, le sniffer Nordic nRF52840 avec Wireshark, et KrakenSDR pour la radiogoniométrie. Notre objet n'est pas de surveiller un espace mais de corroborer une décision d'accès, localement, sans réseau, à côté d'une machine. Un système de surveillance d'espace vous dit qu'un téléphone est entré dans le bâtiment ; il ne coupe pas l'alimentation de la presse. Ce sont deux métiers, et ils peuvent parfaitement coexister sur le même site. La boîte à outils, ouverte comme toujours BLE — sniffer Nordic nRF52840 avec le firmware officiel et Wireshark ; OpenMQTTGateway pour la passerelle d'écoute. Wi-Fi — Kismet, adaptateur en mode moniteur, analyse des trames de gestion. Sub-GHz — rtl_433 et ses décodeurs, sur RTL-SDR ou Airspy. Large spectre — HackRF One pour couvrir 2,4 et 5 GHz, GNU Radio pour le traitement. Radiogoniométrie — KrakenSDR, logiciels d'acquisition et de traitement en open source, sur Raspberry Pi. Support d'exécution — Raspberry Pi sous Linux durci pour l'effecteur d'écoute. Rien de tout cela n'est secret, et c'est encore une fois l'intérêt. Le sur-mesure reste là où il crée de la valeur : la corrélation entre ces signaux, la décision locale qui en découle, et le journal signé qui l'atteste. Pour finir : la différence entre entendre et comprendre Un atelier bien instrumenté entend énormément de choses. Ce qui est difficile, ce n'est pas d'entendre (un récepteur à trente euros y suffirait) c'est de savoir ce qu'on a le droit d'en conclure. Une annonce reçue ne prouve pas une présence. Une présence ne prouve pas une identité. Une identité ne prouve pas une autorisation. Et un silence ne prouve pas une absence : il peut aussi vouloir dire qu'on nous a mis un coussin sur les oreilles.

Principes de sécurité OT

Démonstration de sécurité d'un contrôle d'accès d'atelier On nous demande généralement si « c'est chiffré ». La question est légitime, mais elle ne suffit pas car il y a de nombreux mécanismes pour mettre en défaut une installation de contrôle d'accès des équipements électriques. Cet article procède donc d'abord par une affirmation assez précise de ce que nous faisons pour sécuriser l'ensemble du procédé, décrit contre qui la solution est censée tenir, puis passe en revue les manières concrètes de faire démarrer une machine sans en avoir le droit. L'affirmation initiale Voici ce que nous vendons avec la première solution développée par Ops-Devices dans le contexte de machines à allumer ou couper selon les utilisateurs autorisés : Aucune mise sous tension d'un équipement protégé ne peut avoir lieu sans qu'un badge enrôlé soit présent et tant qu'il reste sur place, tout en veillant que son porteur agisse dans le créneau qui lui a été accordé, sur les machines autorisées, et que l'organe de coupure soit intègre et joignable. Toute tentative, réussie ou non, doit laisser une trace datée à l'heure de l'atelier. Le dispositif concerné Quatre machines dans une pièce, aucune intervention de modification sur les équipements protégés : un badge radio porté par l'intervenant, un boîtier de décision autonome à portée de la zone, un module de tête en armoire qui alimente et mesure chacune des voies, quatre prises pilotées sur l'alimentation des machines, et l' application mobile du responsable qui fait la navette entre la salle machine et les bureaux (pour garder un lien quotidien avec le serveur d'administration par exemple). Le boîtier n'a aucun accès réseau. Toute décision est prise localement, ce qui a une conséquence directe sur la démonstration : couper Internet ne change strictement rien au comportement du dispositif, mais par conséquent les alertes sont restreintes au local technique. Il faut donc que les règles d'accès soient bien appliquées, et parfois même très strictes si aucune confirmation d'un responsable ne peut être donnée à distance. L'adversaire contre lequel elle est faite Nous nous plaçons ici face à quelqu'un qui a un accès physique légitime ou toléré à la zone : sous-traitant, intérimaire, prestataire, visiteur laissé seul. Il dispose d'outils courants et de quelques minutes, et sa motivation est la commodité : mettre en route une machine et passer à autre chose, quite à contourner une procédure jugée lourde, pour gagner du temps. Nous ne nous plaçons pas face à un adversaire qui monterait un relais radio, clonerait une annonce après l'avoir analysée, ou substituerait un module par un clone matériel. Ces menaces sont réelles, elles relèvent d'un autre budget et d'un autre dispositif que nous avons conçu, et elles feront l'objet d'un second article. Le socle : trois frontières et une position de repli L'affirmation ci-dessus repose donc sur trois frontières distinctes, dont aucune ne peut couvrir le travail des deux autres, et sur un comportement par défaut qui rend chaque défaillance inoffensive. Frontière Question à laquelle elle répond L'humain → la décision Qui est là, et a-t-il le droit maintenant ? La décision → l'exécution Cet ordre vient-il de l'autorité, et est-il valable ? L'exécution → la machine Que peut faire cet organe, et que ne doit-il jamais faire ? On fait souvent le parallèle avec les détrompeurs sur les prises des onduleurs : tout admin système a fait la chasse aux collègues qui branchent une machine à café ou leur batterie de vélo sur les prises rouges, parce que "de toute façon on a nos priorités". Nous remplaçons donc les détrompeurs en plastique par des équipements qu'on ne pourra pas bypasser : fini la tige du stylo bic ! mais surtout, fini la production qui s'arrête, les heures d'usinage ou d'impression 3D perdues, les serveurs éteints qui n'enregistrent plus les expériences en cours, etc.. La position de repli est le refus. Les prises sont coupées tant qu'une décision positive n'a pas été prise, et non l'inverse. Panne du boîtier, perte de liaison, badge illisible, planning absent, radio brouillée : chacun de ces cas ramène au même état éteint. Ce choix a un coût d'exploitation réel : il faut que le dispositif fonctionne pour que la production tourne, et nous l'assumons, parce qu'un contrôle d'accès qui échoue en position ouverte n'est pas un contrôle dégradé mais une absence de contrôle avec un voyant vert. La sécurité est donc physique (débrancher un câble, intervertir deux appareils, leurrer les capteurs) avant même de parler de protocoles. La démonstration, attaque par attaque 1. Se présenter devant la machine et appuyer sur le bouton L'attaque. La plus fréquente, et de loin. Personne ne pirate quoi que ce soit : on se met devant une prise connectée et on appuie sur l'interrupteur. Forcément, on pensait tout piloter à distance mais même sur un matériel premier prix, il y a toujours une alternative physique. Ce qui s'y oppose. Le bouton physique des prises que nous recommandons est désolidarisé du relais par configuration. L'appui ne commande plus la sortie ; seule la couche de décision peut mettre sous tension. C'était simple mais nécessaire, et ça justifie d'y mettre 30 € au lieu de 10. Pourquoi cela tient. Parce que le lien entre le bouton et le relais n'existe plus dans le firmware de la prise - sur lequel on a gardé la main, et non pas juste parce qu'une règle logicielle le refuserait après coup. Il n'y a rien à contourner : la fonction a disparu. Sans ce réglage, tout le reste du dispositif serait décoratif, puisque n'importe qui debout devant la prise reprendrait la main sur l'équipement. Ce qui reste. Une remise à zéro d'usine du module rétablirait son comportement d'origine. Elle exige un accès physique prolongé et se signale d'elle-même — le module réapparaît sous son identité par défaut et cesse de répondre au boîtier, ce qui déclenche le mécanisme décrit au point 3 (on a un second rempart !). 2. Débrancher la prise et rebrancher la machine ailleurs L'attaque. La parade du bon sens, et celle que nous voyons le plus souvent oubliée dans les dispositifs concurrents : puisque la prise refuse, on la retire. Et la solution n'est pas d'ajouter de la colle. Ce qui s'y oppose. Chaque prise est alimentée par une voie du module de tête, dans l'armoire électrique. Si le boîtier perd la liaison avec une prise pendant plusieurs cycles consécutifs, il coupe la voie qui l'alimentait et inscrit l'événement au journal comme critique. Mais seulement après avoir tenté de la retrouver, pour ne pas réagir à une simple gêne radio : on a sélectionné des composants fiables mais abordables, le but étant de pouvoir passer à l'échelle et équiper toutes les prises. Pourquoi cela tient. Parce que la coupure se produit en amont de l'organe retiré, donc à un endroit que l'attaquant n'a pas en main lorsqu'il manipule la prise. Le contournement le plus simple se paie par une coupure et laisse une trace. Ce qui reste. D'abord, la protection ne couvre que ce qui est alimenté par le module de tête : brancher la machine sur une prise murale située hors du périmètre sort du dispositif, et relève de l'installation électrique, pas du contrôle d'accès. 3. Rejouer un ordre capturé L'attaque. Enregistrer les échanges radio pendant qu'un porteur légitime obtient l'accès, puis les rejouer plus tard pour obtenir le même effet. C'est l'attaque classique contre tout dispositif qui se contente de chiffrer. Il y a encore deux ans, c'était un contournement lourd nécessitant des connaissances. Depuis la diffusion des Flipper Zero et autres dispositifs, même votre grand-mère pourrait apprendre à le faire. Ce qui s'y oppose. Quand l'application se connecte au boîtier, celui-ci tire un aléa de trente-deux octets et attend en retour une attestation signée par l'autorité, accompagnée de la signature de cet aléa par la clé de l'appareil. L'aléa est consommé quoi qu'il arrive , que la tentative réussisse ou échoue. C'est notre contribution spécifique, cela n'existait pas dans les équipements sur étagère. Trois contrôles complètent la vérification des mises à jour de droits : une mise à jour destinée à un autre boîtier est refusée ; une mise à jour dont le numéro de séquence n'est pas supérieur au dernier appliqué est ignorée ; et la liste des porteurs autorisés est remplacée intégralement , jamais fusionnée. Pourquoi cela tient. Parce que le rejeu ne devient pas seulement inefficace, il devient impossible à répéter et il est détectable : chaque tentative brûle l'aléa en cours, et chaque paquet ancien se heurte à une séquence qui ne recule pas. Sans le remplacement intégral, un attaquant pourrait rejouer un ancien paquet pour ressusciter un porteur révoqué : c'est précisément la faille que ferme ce détail d'apparence anodine. Le refus est par ailleurs motivé : le boîtier répond en nommant la raison : aléa absent, autorité non reconnue, preuve de possession invalide, attestation périmée, porteur hors liste, de sorte qu'un rejet se distingue d'une panne, dans le journal comme sur l'écran du superviseur. On a également mis au point un code couleur qui permet en entrant dans une salle de voir d'un seul coup d'oeil ce qui est coupé, ce qui est actif et ce qui a été trafiqué. 4. Se faire passer pour l'autorité L'attaque. Fabriquer une fausse mise à jour de droits pour s'ajouter à la liste des porteurs autorisés, ou pour élargir un créneau. Ce qui s'y oppose. Le boîtier vérifie la signature de l'autorité avec une clé publique inscrite dans son firmware , que le porteur du message ne peut ni fournir ni remplacer. La vérification porte sur les octets exactement tels qu'ils ont été reçus, avant toute interprétation. Pourquoi cela tient. L'ordre des opérations n'est pas un détail : vérifier les octets reçus puis les analyser, plutôt que l'inverse, élimine toute une classe de failles où l'écriture du message diffère d'un octet de ce qui a été signé. Falsifier le contenu casse la signature, sans exception. Quant à l'ancrage de la clé dans le firmware, il impose une mise à jour logicielle pour en changer. C'est un inconvénient que nous préférons largement au risque de voir un attaquant remplacer l'autorité elle-même. Les dispositifs d'OTA (over-the-air) sans avoir à ouvrir le Cube ou ses satellites est désormais très accessibles pour un grand nombre d'équipements, et nous sélectionnons toujours des composants sur lesquels les principes de cybersécurité IT sont applicables, afin de se concentrer sur le spécifique OT. Ce qui reste. Cet ancrage ne vaut que si l'on ne peut pas reprogrammer le composant. Le verrouillage matériel du démarrage et le chiffrement de la mémoire de programme sont donc la suite logique de cette mesure. 5. Faire croire que la vérification fonctionne L'attaque. Elle n'est pas menée par un adversaire, et c'est ce qui la rend redoutable : une vérification cryptographique en panne est silencieuse. Soit elle refuse tout, ce qui se remarque immédiatement, soit bien pire elle accepte tout, et aucun essai fonctionnel du produit ne distingue une signature valide d'un code de contrôle cassé qui répondrait toujours oui. Ce qui s'y oppose. À chaque démarrage, le boîtier exécute un auto-test sur des vecteurs de référence publiés, en contrôlant qu'il accepte une signature authentique et qu'il rejette une signature falsifiée comme un message altéré. Le décodage des données et l'analyse des dates de péremption sont testés de la même manière, y compris sur des cas limites. Pourquoi cela tient. Parce que le test échoue en position sûre : si l'auto-test ne passe pas, le boîtier refuse d'ouvrir son canal d'administration plutôt que de le servir sans contrôle. Un dispositif dont la cryptographie serait défaillante ne se contente pas de le signaler, il cesse d'accepter des ordres. 6. Remonter l'horloge pour s'ouvrir un créneau L'attaque. Le planning autorise un porteur de sept heures à vingt-deux heures. Il est vingt-trois heures. Il suffit de convaincre le boîtier qu'il est quinze heures. Ce qui s'y oppose. Le réglage de l'heure est traité comme une opération modifiante , au même titre qu'une mise à jour de droits : il exige une session authentifiée. Sans elle, la demande est refusée avec son motif. Pourquoi cela tient. Parce que l'horloge n'est pas une commodité technique mais un paramètre de sécurité : elle conditionne les créneaux, la péremption des attestations et la datation du journal. La laisser librement modifiable revenait à offrir un contournement de tout le reste, et à permettre de dater n'importe quoi. Dans le monde de l'OT, c'est une arlésienne : on ne compte plus les systèmes qui sont décalés de 12h, qui sont toujours à l'heure d'hiver en plein été, qui ne connaissent pas les jours fériés. Et c'est souvent une des premières causes d'abandon, en particulier en GTB, GTC, CVC, etc... Ce qui reste. Un cas limite mérite d'être connu : au tout premier démarrage, avant qu'une heure sûre n'ait été fournie, la péremption des attestations ne peut pas être évaluée. Le boîtier laisse alors passer ce contrôle précis : la signature de l'autorité restant, elle, exigée et l'exception est inscrite au journal . C'est un compromis assumé, visible en audit, et resserrer ce comportement figure au registre selon vos exigences à venir. 7. Effacer une ligne gênante du journal L'attaque. Bricoler le système, obtenir l'accès (ou pas, c'est ce qu'on prétend) puis faire disparaître la trace. Ou, plus subtil, se servir de la navette pour égarer une remontée (une app mobile permet de récupérer les logs locaux pour les amener en zone de couverture réseau : couper l'app mobile coupe l'accès sur le serveur d'administration). Ce qui s'y oppose. La purge du journal exige une session authentifiée, et le boîtier refuse d'acquitter des entrées qui n'existent pas encore. Chaque session porte par ailleurs un identifiant tiré au démarrage, ce qui permet à l'application de détecter qu'un accusé provient d'une session antérieure et de ne pas le relayer. Sur le fond, rien n'est considéré comme transmis tant que le destinataire ne l'a pas confirmé : une entrée n'est purgée du boîtier qu'une fois l'autorité l'ayant enregistrée, et le journal des transferts affiché à l'intervenant n'inscrit une ligne qu'après l'accusé du destinataire, jamais après l'envoi. Pourquoi cela tient partiellement. Ces mécanismes empêchent la perte accidentelle et le décalage entre sessions, qui sont les causes réelles de journaux trompeurs. 8. Copier l'annonce du badge L'attaque. Écouter l'annonce d'un badge, la reproduire, se faire détecter comme son porteur. Ou tout simplement passer un badge à son collègue, parce que "c'est plus simple, le principal c'est que le travail soit fait non ?". Ce qui s'y oppose au niveau du badge. Rien. L'annonce circule en clair, elle est identique d'une fois sur l'autre, et quelqu'un qui l'écoute peut la reproduire. Nous ne présentons donc jamais le badge comme un facteur d'authentification : il répond à la question « un porteur déclarant cet identifiant est-il à proximité ? », et à aucune autre. Ce qui s'y oppose ensuite. Le badge n'est pas la barrière, il est le déclencheur. Restent en travers du chemin le planning du porteur usurpé, la persistance de la présence (l'accès se coupe dès que l'annonce disparaît) l' intégrité de l'organe de coupure, et le journal , qui enregistrera l'accès au nom du porteur légitime, à une heure où celui-ci pourra dire où il était. Pourquoi c'est acceptable ici. Parce qu'un adversaire qui analyse un format d'annonce pour le reproduire a quitté le profil de l'opportuniste. La mesure du risque n'est pas « est-ce faisable ? » puisque ça l'est, mais « est-ce que cela correspond à quelqu'un qui se présente réellement dans cet atelier ? ». C'est un jugement, il est révisable, et il change dans les contextes traités plus tard par un autre article sur les cas les plus sensibles. Ce qui reste. Le point le plus faible de l'assemblage, identifié comme tel, peut être traité sans changer de matériel par une charge d'annonce qui varie à chaque émission. Mais pour ceux qui le souhaitent, il existe de très bons badges qu'on pourrait intégrer. Ou doubler le badge dans la poche d'une carte d'identification sécurisée qu'on passe sur le Cube en NFC, mais là encore il y a le problème de prêter son badge : autant passer à la solution de confirmation sur app mobile qu'on a déjà intégrée en plus du badge déclencheur. 9. Relayer la présence d'un porteur légitime L'attaque. Retransmettre la conversation entre un porteur resté au vestiaire et la machine visée, de façon à fabriquer une présence parfaitement authentique. Ici on ne vole pas le badge, on crée une passerelle entre les deux (le retour de notre ami Flipper Zero qui a ouvert la boite de Pandore de la sécurité des systèmes cyberphysiques). Ce qui s'y oppose. Rien de cryptographique, et il faut le dire sans détour : aucune signature ne voit ce type d'attaque, puisqu'aucun message n'est falsifié. Ce qui est falsifié, c'est la proximité, et la proximité n'est pas une propriété que l'on signe. Ce qui augmente le coût, en revanche : la présence doit être maintenue pendant toute la durée d'usage, le créneau du porteur doit être ouvert au même moment, et l'accès est journalisé à son nom. Ce qui reste. Une vulnérabilité réelle, structurelle, et que seule une mesure de distance par temps de vol referme. Nous ne prétendons pas la couvrir dans notre solution actuelle, mais on peut vous expliquer les solutions à base d'UWB, pour une V2 si vous nous apportez la nécessité et le budget associé. 10. Voler le téléphone d'un intervenant L'attaque. Récupérer l'appareil qui porte l'attestation et s'en servir pour déposer de faux réglages ou purger un journal. Ce qui s'y oppose. L'application exige une validation biométrique avant les opérations sensibles, et systématiquement en mode urgence. En effet nous avons prévu un "marteau bris de glace" : si une machine doit être impérativement être mise en service (pour raison vitale disons), un code secret présenté sur place (QR code dans le livret de sécurité ou au dos d'un boitier) permet de débrayer tout le système, au prix d'une déclaration d'incident forte et d'une remise en service du système pour éviter qu'il ne devienne la règle. L'attestation de l'appareil a une durée de vie limitée, et la révocation d'un appareil prend effet dès la première mise à jour de droits appliquée, le porteur en session étant alors déconnecté logiquement séance tenante. Pourquoi cela tient. Parce que le téléphone ne décide rien : il transporte des objets signés par l'autorité et vérifiés par le boîtier. Le voler donne le droit de porter , pas celui d' émettre . Ce qui reste. La révocation ne se propage qu'au passage suivant d'un appareil autorisé car c'est le prix du fonctionnement sans réseau. Et la clé de l'appareil, si elle réside dans un stockage protégé, n'est pas encore générée dans une enclave matérielle : elle est protégée du reste de l'appareil, elle n'est pas non extractible. On rentre alors dans la cybersécurité IT classique. 11. Couper le courant du boîtier, ou brouiller la radio L'attaque. Ne pas chercher à obtenir l'accès, mais à faire tomber le dispositif en espérant qu'il s'ouvre. Ce qui s'y oppose. La position de repli. Un Cube hors tension ne commande plus rien, et les prises restent dans l'état de refus si c'était votre choix ; une radio brouillée fait disparaître la présence, ce qui coupe. Il n'existe pas de chemin par lequel une dégradation ouvre un accès non prévu. Pourquoi cela tient. Parce que la direction de la panne a été choisie à la conception, et non subie. C'est la propriété la plus importante de tout le dispositif, et celle que nous vérifions en premier. Ce qui reste. Le revers, qu'il faut assumer devant l'exploitant : ce dispositif est déniable de service . Quelqu'un qui veut empêcher la production plutôt qu'obtenir un accès y parviendra en brouillant la bande, et la réponse à cela n'est pas technique mais organisationnelle — procédure de dérogation, mode urgence, supervision de la disponibilité radio. On n'est plus dans sécurité, on est à la lutte contre la pince coupante, ce qui doit être résolu par un contrôle d'accès au bâtiment et une bonne gestion des ressources humaines. 12. Attaquer le serveur d'administration L'attaque. Ne pas se battre avec le terrain, mais viser la clé qui signe les droits distribués à tout un parc. Ce qui s'y oppose. Chaque objet signé porte l'identifiant de la clé qui l'a signé, ce qui rend une rotation possible sans réaprovisionner l'ensemble des équipements ; et le serveur refuse de signer si sa clé n'est pas présente, plutôt que d'improviser une clé volatile qui invaliderait silencieusement tout ce qui a déjà été distribué. Ce qui reste. C'est aujourd'hui le point le plus sensible de la chaîne, et il serait malhonnête de le présenter autrement : la compromission de cette clé vaut compromission de tout le parc. Sa conservation hors ligne, dans un module matériel dédié, avec une cérémonie documentée, est la mesure qui ferme ce risque. Mais là encore, c'est de la cybersécurité IT qui se traite par les moyens adéquats déjà prouvés. Ce que chaque mécanisme prouve, et ce qu'il ne prouve pas C'est le tableau que nous jugeons le plus utile à garder sous les yeux, parce qu'un dispositif solide n'est pas celui qui empile le plus de mécanismes, mais celui dont chaque mécanisme est employé pour ce qu'il prouve réellement. Mécanisme Ce qu'il prouve Ce qu'il ne prouve pas Annonce du badge Qu'un émetteur portant cet identifiant est à proximité L'identité car la charge est copiable Filtre de puissance et fenêtre de maintien Une proximité radio plausible et durable Une distance réelle : le signal se relaie Aléa à usage unique Que l'échange est frais et non rejoué Que l'interlocuteur est physiquement là Signature de l'autorité L'origine et l'intégrité des droits distribués Que la clé d'autorité est bien gardée Séquence croissante et destinataire lié Qu'un ordre ancien ou détourné ne s'applique pas — Auto-test au démarrage Que la vérification fonctionne réellement Que le firmware n'a pas été remplacé Bouton désolidarisé Que le geste local ne commande plus le relais Qu'un retour aux réglages d'usine soit impossible Surveillance de l'organe Qu'un retrait est détecté et tracé Que la machine ne soit pas rebranchée hors périmètre Journal remonté par navette Ce que le dispositif a décidé, et quand Qu'aucune entrée n'ait été retirée en chemin Position de repli au refus Qu'aucune panne n'ouvre un accès Que le dispositif reste disponible Comment le vérifier plutôt que nous croire Le problème du chiffrement déclaré Il existe, dans ce domaine, un écart entre ce que les fiches techniques annoncent et ce que les équipements font et cet écart n'est pas toujours de la mauvaise foi. Une suite cryptographique peut être déclarée dans un format de données sans être employée sur le canal ; un appairage peut être supporté sans être exigé ; une donnée peut être lisible sans authentification alors que le produit est vendu comme chiffré. Nous avons pris le parti de traiter cette question comme un problème de test plutôt que comme un problème de communication : énoncer les propriétés que le lien devrait tenir, les mesurer une par une, et faire échouer bruyamment celles qui ne le sont pas. C'est ce banc qui a produit le registre ci-dessus, et non l'inverse. Notre démarche d'accompagnement à la mise en place vise donc à reproduire sur votre installation ces mesures d'exécution des dispositifs de sécurité avant la mise en service. Pourquoi cela suffit dans la grande majorité des ateliers Reprenons les douze attaques. Sept sont fermées par construction : le bouton, l'ordre rejoué, l'autorité usurpée, la vérification défaillante, l'horloge remontée, le téléphone volé, la panne provoquée. Une est détectée et tracée en attendant d'être bloquée. Quatre restent ouvertes. Or ces quatre-là (copier une annonce après l'avoir analysée, monter un relais, écouter le canal pour en tirer parti, substituer un module) ont un point commun : elles exigent toutes de quitter le profil de l'opportuniste . Elles supposent du matériel, du temps, une intention, et le plus souvent un retour sur les lieux. C'est là que se joue notre jugement pour distinguer deux solutions, et nous vous les présentons comme telles : dans un atelier, une salle machine, un entrepôt où la menace réaliste est le raccourci de personnes légitimes mais non autorisées, il suffit que tous les raccourcis coûtent plus cher que la procédure normale, et si c'est votre cas, vous serez client. Dans un site où quelqu'un accepte de mettre le prix financier et technique pour réussir à entrer, ce raisonnement ne tient plus et il faut alors un autre dispositif, avec les solutions matérielles, procédurales et logicielles adéquates, à hauteur du préjudice potentiel. Le reste est une affaire de proportion. Quatre modules du commerce, aucune intervention sur les équipements, aucune requalification de procédé, aucune dépendance réseau, et un registre de douze lignes que l'on peut mettre sur la table. Voilà ce que nous pouvons déjà mettre en place chez vous dès à présent !

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.

IAM pour vos équipements électriques - Part 1

Pourquoi le dernier point d'application de la politique de sécurité qui vous reste à implémenter est la prise de courant. Article destiné aux praticiens de l'IAM. Vous y trouverez la transposition dans un domaine où votre discipline est indispensable et presque totalement absente. Une scène qui parlera au plus grand nombre Vendredi, 22 h 40. Dans un atelier d'usinage, une machine cinq axes se met en route. Elle tourne quarante minutes, produit onze pièces, puis s'arrête. Posez maintenant les questions que vous poseriez pour n'importe quelle ressource de votre système d'information. Qui a démarré cette machine ? Quelle source d' identité a été présentée, et authentifiée comment ? Cette identité disposait-elle d'une autorisation valide à cet instant, sur cette ressource ? Où est la trace ? Qui révoque cet accès quand l'intervenant quitte le prestataire ? Quand a eu lieu la dernière campagne de recertification sur le droit « démarrer la cinq axes » ? Sur la plupart des sites industriels où l'on prend la peine de poser ces six questions, on obtient six fois la même réponse : rien. Pas une réponse imparfaite : rien, car il n'existe ni objet, ni journal, ni politique. La machine ne sait pas qui l'utilise (à la rigueur un planning d'interventions et une présence dans les locaux) et personne n'a jamais eu de moyen de le lui demander. C'est une conséquence d'architecture et un héritage important du clivage OT/IT. C'est exactement le genre de trou pour lequel l'IAM a été inventé : sauf que l'IAM, tel qu'on le pratique, ne sait pas l'atteindre. Où votre chaîne IAM s'arrête, physiquement Rappelons la chaîne, dans le vocabulaire que nous partageons tous : une identité est établie et provisionnée, un authentifiant en prouve la détention, un PDP évalue une politique, un PEP applique la décision sur le chemin d'accès, une session est ouverte puis réévaluée, un journal produit la preuve, et une revue ferme la boucle. Cette chaîne repose sur une hypothèse que nous ne formulons plus tellement elle est acquise : il existe un chemin numérique entre le sujet et la ressource, et nous pouvons nous y insérer. Un proxy inverse, un agent, un connecteur SCIM, un broker PAM, un contrôleur de domaine, une passerelle applicative. Le PEP est un morceau de logiciel posé sur ce chemin. Retirez le chemin numérique, et la chaîne entière devient inapplicable. C'est pourtant la situation de l'écrasante majorité des équipements industriels sensibles en service aujourd'hui : Un automate installé en 2003 dont le seul contrôle d'accès est un commutateur à clé sur la face avant, avec trois clés en circulation et une quatrième perdue depuis six ans. Une armoire électrique dont l'ouverture est protégée par une clé triangle qu'on achète en ligne pour le prix d'un café. Un banc d'essai, un four, un autoclave, une presse, une machine d'électroérosion : des équipements dont l'usage non autorisé n'est pas un risque de confidentialité mais un risque de sécurité physique, de contrefaçon, de sabotage ou de détournement d'usage. Un équipement raccordé au réseau électrique du site, mais délibérément non raccordé au réseau informatique, précisément parce que son exploitant a jugé et souvent à juste titre que la connexion créerait plus de risque qu'elle n'en traiterait. Face à ce parc, la réaction réflexe du monde IT est d'exiger la connexion au réseau informatique : « connectez-le, et nous le gouvernerons ». C'est une réponse coûteuse, lente, et souvent contre-productive. Connecter une machine (et surtout chaque machine !) conçue parfois à une époque où la sécurité réseau ne figurait dans aucun cahier des charges, pour pouvoir la superviser, revient à créer une surface d'attaque... afin de pouvoir surveiller la surface d'attaque que l'on vient justement de créer ! Il existe une autre voie. Notre thèse : l'alimentation est le seul point d'application universel Tous ces équipements ont un point commun, sans exception. Ils sont alimentés en électricité. Une machine sans courant ne produit pas, ne chauffe pas, ne tourne pas, ne communique pas et ne se laisse pas reprogrammer. L'alimentation électrique est le préalable absolu à tout usage. Elle possède, du point de vue d'un architecte IAM, des propriétés remarquables : Elle est universelle. Aucune hypothèse sur le protocole, le firmware, l'âge, le constructeur ou la présence d'une pile IP. Le contrôle s'applique de la même façon à un automate Schneider de 1998 et à une machine livrée le mois dernier. Elle est antérieure à la couche logique. Un PEP logiciel s'exécute après le démarrage de la cible et dépend de son intégrité. Un PEP électrique s'applique avant que la cible n'existe fonctionnellement. Aucune vulnérabilité du firmware de l'équipement ne permet de contourner l'absence de courant. C'est un deny non contournable par la ressource elle-même, donc une propriété rare que nous ne savons obtenir dans presque aucune architecture logicielle. Elle est binaire et sans état. Pas de session à négocier, pas de contexte à maintenir dans l'équipement, pas de client à installer. Le corollaire est direct : dans une installation sensible, la prise de courant est le point d'application de politique de premier et dernier recours. Cette idée n'est pas neuve mais elle est actuellement non gouvernée. Trois précédents devraient rassurer un lecteur IAM sur le fait qu'il ne s'agit pas d'une bizarrerie conceptuelle : La consignation électrique. La procédure de consignation (en France, cadre NF C18-510) est un contrôle d'accès physique parfaitement structuré : séparation, condamnation, identification, vérification d'absence de tension, puis mise à la terre et en court-circuit. Et dans la pratique du lockout/tagout qui l'accompagne sur la plupart des sites, le cadenas personnel de l'intervenant, avec son étiquette nominative posée sur un moraillon multi-cadenas, est littéralement un jeton d'autorisation mono-porteur appliqué à l'alimentation. Avec, en prime, une sémantique de verrouillage collectif que peu de systèmes IAM savent exprimer. La discipline OT a donc inventé un IAM électrique en quelque sorte... mais cet IAM est sans annuaire, sans expiration automatique, sans journal exploitable et sans révocation à distance. C'est de l'IAM des années 1970, et il fonctionne toujours ainsi. Les PDU commutables. Dans n'importe quel datacenter, l'autorisation par prise (ou unité de distribution d'énergie, PDU) existe depuis un quart de siècle : on coupe et on rétablit un port électrique à distance. Mais le sujet de cette autorisation est un compte d'administration technique, jamais une identité métier porteuse d'une habilitation, c'est donc de l'actionneur sans politique. ISO 15118 et le « Plug & Charge ». C'est le précédent le plus intéressant, et celui que tout praticien IAM devrait apprendre à connaître. Pour la recharge des véhicules électriques, l'industrie a spécifié une authentification des deux extrémités par certificats X.509, échangés sur le câble de charge lui-même , en courant porteur sur la ligne pilote et adossée à une hiérarchie de confiance dédiée : racine V2G, certificats de contrat côté opérateur de mobilité, certificats de borne, certificats de provisionnement embarqués en usine par le constructeur. La première version (ISO 15118-2) n'authentifiait la borne qu'au niveau transport et le véhicule au niveau applicatif ; ISO 15118-20 impose désormais un TLS mutuel. Autrement dit : une PKI complète, avec son cycle de vie, dont la finalité est de décider si l'électricité doit couler, et à qui la facturer. Le monde automobile a donc déjà admis que le câble électrique est un canal d'identité . Le monde industriel, lui, en est resté au cadenas.

IAM pour vos équipements électriques- Part 2

Les cinq réflexes IAM qu'il faut désapprendre C'est ici que le transfert d'application du domaine IT au notre devient délicat : cinq principes que vous appliqueriez sans les repenser deviendraient faux, ou dangereux. 1. « En cas de doute, on refuse » n'est plus une règle universelle En IT, l'échec fermé est la position par défaut et l'arbitrage est presque toujours tranché en faveur de la sécurité. En OT, refuser peut tuer . Couper l'alimentation d'un système de ventilation, d'un groupe de refroidissement, d'un circuit de sécurité ou d'un équipement en phase critique de cycle est une décision de sûreté avant d'être une décision de sécurité. Conséquence pratique : la sémantique du refus doit être définie équipement par équipement , et cet arbitrage n'appartient pas à l'équipe sécurité. Il appartient conjointement à la sécurité, à l'exploitation et au HSE. Certains équipements seront en fail-secure (on coupe), d'autres en fail-safe (on laisse, on trace, on alerte), d'autres en fail-degraded (on autorise une fonction réduite). Un modèle de politique OT qui ne sait pas exprimer ces trois issues est inutilisable. C'est une nuance que le Zero Trust, dans sa formulation IT canonique, n'a jamais eu à traiter. 2. La connectivité n'est pas une hypothèse Vous concevez vos architectures en supposant que le fournisseur d'identité IdP est joignable. En environnement industriel ou de défense, l'hypothèse s'effondre : sites isolés par conception, coupures WAN de plusieurs jours, locaux blindés, air-gap, contextes où la connectivité est activement indésirable. Un PDP qui appelle un service distant pour décider est un PDP qui refuse de décider quand ça compte. La décision doit être rendue localement, hors ligne, et rester nominale, pas dégradée. Vous connaissez déjà ce compromis sous une autre forme : la validation locale d'un jeton signé sans introspection auprès de l'émetteur. Mêmes questions, mêmes réponses : politique signée et versionnée, durée de vie bornée, liste de révocation à fraîcheur maximale explicite, source de temps de confiance, réconciliation à la reconnexion. Ce qui change dans notre contexte, c'est l'enjeu : ici, un jeton périmé accepté à tort ne donne pas accès à une API, il donne accès à une machine capable de blesser quelqu'un. 3. L'identité de l'équipement ne peut pas être déclarative En IT, nous faisons confiance à ce que la ressource déclare d'elle-même, parce qu'un agent atteste. En OT, l'équipement ne sait pas qui il est et ne peut rien attester. Pire : il est parfaitement remplaçable. Rien n'empêche de débrancher la machine autorisée et d'en brancher une autre à sa place. D'où un renversement contre-intuitif mais fécond : on n'identifie pas l'équipement, on identifie le point d'alimentation, et on caractérise en continu ce qui y est raccordé. La signature électrique et radioélectrique d'un équipement branché est un attribut observable — et sa modification devient un événement d'identité à part entière. Cela crée une primitive qui n'existe pas en IAM classique : la détection de recâblage comme signal de sécurité. Un intervenant légitime, avec une habilitation valide et un ordre de travail conforme, qui branche un équipement non prévu sur un point contrôlé, produit un événement que votre politique doit savoir qualifier. 4. La preuve doit survivre à l'auditeur, pas au SIEM Votre journalisation est conçue pour la détection : volume élevé, valeur unitaire faible, rétention courte, chemin réseau vers un collecteur. Ici, c'est l'inverse. Le volume est faible : quelques dizaines d'événements par machine et par mois. La valeur unitaire est très élevée. Et l'usage n'est presque jamais la détection temps réel : c'est la preuve rétrospective , examinée dix-huit mois plus tard par un assureur, un client donneur d'ordre, une autorité ou un juge d'instruction, pour répondre à une question simple : qui a mis cette machine sous tension le 14 mars à 22 h 40, et sur quel fondement ? Un journal qui transite par le réseau vers un SIEM ne répond pas à ce besoin, parce que le réseau était justement coupé le 14 mars. Il faut un journal local, horodaté, chaîné, signé, non répudiable et exportable indépendamment de toute infrastructure. 5. Le sujet n'est ni forcément humain, ni forcément votre Vous vivez déjà la vague des identités non humaines : comptes de service, charges de travail, secrets qui prolifèrent, agents autonomes. Le monde OT ajoute une couche que l'IT connaît peu : une part majoritaire des sujets légitimes n'appartient pas à l'organisation . Intérimaires, sous-traitants de rang 2, techniciens du constructeur en déplacement depuis un autre continent, prestataires de maintenance mandatés par le mainteneur lui-même. Vous devez donc fédérer une identité, vérifier un attribut d'habilitation et l'associer à un ordre d'intervention, sans jamais avoir provisionné la personne, souvent sans annuaire côté fournisseur, et sans réseau au moment de la décision. Ce n'est pas un problème résolu ailleurs et recopié ici. C'est un problème IAM ouvert, et il est passionnant. Ce que les textes disent déjà, et que peu de gens ont lu L'idée que l'IAM appartiendrait au monde IT et la sûreté de fonctionnement au monde OT ne résiste pas à la lecture des normes. IEC 62443. Le référentiel de sécurité des systèmes d'automatisation industrielle est structuré autour de sept exigences fondamentales. La première s'intitule Identification and Authentication Control . Elle distingue explicitement trois catégories de sujets : human user , software process et device , et décline des exigences de gestion des comptes, des identifiants, des authentifiants, de la robustesse des secrets, et de l'usage de certificats à clé publique. En clair : la norme OT de référence place l'IAM en tête de ses priorités, et le fait depuis des années. Ce n'est pas une importation du monde IT ; c'est un chapitre que l'industrie n'a jamais réellement appliqué faute de moyen technique sur le parc existant. Cyber Resilience Act. Le règlement européen est entré en vigueur le 10 décembre 2024. Les obligations de notification des vulnérabilités activement exploitées et des incidents graves s'appliquent depuis le 11 septembre 2026, et l'application pleine interviendra le 11 décembre 2027. Son annexe I demande, sur la base de l'analyse de risque et lorsque cela est pertinent, que les produits comportant des éléments numériques soient protégés contre les accès non autorisés « par des mécanismes de contrôle appropriés, incluant sans s'y limiter l'authentification, les systèmes de gestion des identités ou des accès », et qu'ils rendent compte des accès non autorisés éventuels. La formulation mérite d'être lue deux fois : le régulateur européen écrit « identity or access management systems » dans le corps d'un règlement produit. Le CRA cible le produit et son fabricant — mais l'exploitant qui met en service un parc hétérogène hérite de la question. NIS2 et la loi Résilience. En France, la transposition suit un chemin nettement plus lent que prévu : projet de loi adopté par le Sénat le 12 mars 2025, texte modifié adopté en commission spéciale à l'Assemblée nationale le 10 septembre 2025, mais passage en séance publique repoussé à la rentrée parlementaire de septembre 2026 au plus tôt. Ce retard a fini par coûter cher : la Commission européenne a saisi la Cour de justice de l'Union européenne contre la France, avec l'Irlande, l'Espagne et les Pays-Bas, pour défaut de transposition, en demandant des sanctions financières. L'ANSSI, elle, n'a pas attendu le législateur : elle a diffusé en mars 2026, en document de travail, son Référentiel Cyber France (ReCyF), qui structure une vingtaine d'objectifs de sécurité attendus des entités essentielles et importantes. L'agence évalue à environ 15 000 le nombre d'entités qui basculeront dans le périmètre, contre quelque 250 opérateurs de services essentiels sous NIS1 soit un facteur soixante. Mais le point important n'est pas le calendrier parlementaire. La pression réelle vient des donneurs d'ordre. Les questionnaires de sécurité et les clauses cyber des grands comptes de l'automobile, de l'aéronautique, de l'énergie et de la défense descendent déjà la chaîne de sous-traitance, et ils posent des questions auxquelles la table de correspondance ci-dessus permet de répondre ou pas. Or ces trois textes convergent sur un même point, et c'est le point aveugle : ils demandent tous une preuve. Preuve du contrôle d'accès, preuve de la traçabilité, preuve de la gestion des habilitations. Et la preuve d'un accès physique à un équipement industriel n'existe aujourd'hui presque nulle part.

IAM pour vos équipements électriques- Part 3

Que faire si vous dirigez un programme IAM Inventoriez les ressources critiques dépourvues de toute politique d'accès. Pas les serveurs, pas les applications : les machines, armoires, bancs et équipements dont l'usage non autorisé aurait un impact matériel, humain ou réglementaire, et pour lesquels vous ne pouvez produire ni liste d'ayants droit ni journal d'usage. Dans bien des organisations industrielles, cette liste rivalise en longueur avec celle des applications gouvernées. Elle n'a simplement jamais été dressée, parce qu'elle ne relevait du périmètre de personne : trop physique pour la DSI, trop numérique pour la maintenance. Définissez la sémantique du refus, équipement par équipement, avec la sûreté. C'est le livrable le plus difficile et le plus structurant. Il conditionne toute l'architecture, et il ne peut pas être produit par la seule équipe sécurité. Exigez un point d'application capable de décider hors ligne. C'est le critère qui élimine le plus vite les approches inadaptées. Toute solution qui suppose une liaison permanente vers un service central ne tiendra pas la première coupure — c'est-à-dire précisément le moment où le risque est le plus élevé. Et une chose à ne pas faire : ne connectez pas un équipement au réseau dans le seul but de pouvoir le gouverner. Le contrôle d'accès physique n'a pas besoin que la machine soit intelligente. Il a besoin que le point d'alimentation le soit. Élargir le périmètre, pas la pile L'IAM a passé quinze ans à étendre son domaine : des employés aux clients, des clients aux partenaires, des humains aux charges de travail, des charges de travail aux agents. À chaque étape, la même objection est revenue — « ce n'est pas vraiment de l'identité » — et à chaque étape, elle s'est révélée fausse. L'étape suivante est celle des ressources qui n'ont pas d'adresse IP et n'en auront jamais. Elles constituent le cœur productif des installations sensibles européennes, elles sont soumises aux mêmes exigences réglementaires que le reste, et elles sont gouvernées aujourd'hui par un trousseau de clés et un registre papier. La bonne nouvelle est que votre modèle mental fonctionne : identité, authentification, politique, application, preuve, revue. Il faut seulement accepter que le point d'application ne soit plus un morceau de logiciel sur un chemin réseau, mais un dispositif matériel sur un circuit électrique — et que la décision doive être prise localement, y compris quand plus rien ne répond. C'est ce raisonnement qui a donné naissance à Trust-Buster : un moteur de politique local qui établit l'identité et la légitimité d'une intervention à partir de son environnement physique et radioélectrique, des effecteurs qui appliquent la décision sur l'alimentation de l'équipement, et un journal de preuve exploitable en audit — le tout en fonctionnement nominal, réseau ou pas. L'IAM de l'électricité, en somme. Le même métier que le vôtre, avec un disjoncteur au bout de la chaîne. Vous travaillez sur l'IAM et vous voyez d'autres correspondances — ou d'autres ruptures — entre les deux mondes ? Le sujet est ouvert, et le dialogue entre praticiens de l'identité et gens de l'atelier est exactement ce qui nous pousse à agir aujourd'hui.

Conformité NIS2 : par où commencer concrètement

Tout démarre par un inventaire. Et cet inventaire s'arrête presque toujours à la porte de l'atelier. Se mettre en conformité avec la directive NIS 2 est devenu incontournable pour les entreprises européennes, en particulier celles qui exploitent des infrastructures critiques. La première étape est un inventaire complet de vos actifs informatiques et industriels , pour savoir où vous êtes exposé. C'est précisément à cette seconde étape que la plupart des programmes prennent un mauvais départ, non parce que l'inventaire est mal fait, mais parce qu'il s'arrête là où le réseau s'arrête. Les actifs qui n'ont jamais figuré sur aucune liste Menez l'inventaire jusqu'au bout et vous produirez deux listes. La première est familière : serveurs, applications, postes, identités, équipements réseau. Chaque élément a un propriétaire, un cycle de correctifs et, en général, une politique d'accès. La seconde, personne ne l'a jamais dressée. Machines. Armoires électriques. Bancs d'essai. Fours, presses, autoclaves, variateurs. Des équipements dont l'usage non autorisé n'est pas un problème de confidentialité mais un problème de sécurité physique, de contrefaçon ou de sabotage. Pour la plupart d'entre eux, vous ne pouvez produire ni la liste de ceux qui ont le droit de les mettre en route, ni le journal de ceux qui l'ont effectivement fait. Cette liste n'est pas absente par négligence. Elle ne relevait du périmètre de personne : trop physique pour la DSI, trop numérique pour la maintenance. Et dans une entreprise de production, d'énergie ou de traitement de l'eau, mais aussi chez un industriel agroalimentaire ou un laboratoire pharmaceutique, etc.. elle est fréquemment plus longue que la liste d'applications gouvernées à côté de laquelle elle se trouve. La dresser est la chose la plus utile que vous puissiez faire pour commencer sainement, parce que tout ce qui suit (analyse de risque, politique de contrôle d'accès, classification des incidents, clauses fournisseurs) est cadré par elle. Ce que l'article 21(2) demande réellement NIS 2 énumère dix catégories de mesures de gestion des risques. Trois d'entre elles concernent directement l'atelier, et méritent d'être relues en pensant à une presse plutôt qu'à un serveur : c) continuité des activités et gestion des crises. Un démarrage non autorisé en plein cycle est un événement de continuité, pas seulement de sécurité. i) sécurité des ressources humaines, politiques de contrôle d'accès et gestion des actifs. Notez l'association. Politique d'accès et gestion des actifs sont nommées dans le même souffle et c'est exactement cette association qui se rompt quand l'actif est une presse munie d'un simple interrupteur, ou même d'un commutateur à clé. j) authentification à plusieurs facteurs ou authentification continue. Écrite pour l'accès logique, certes. Mais rien dans le texte ne l'y confine, et l'authentification continue est précisément ce dont une machine sous tension aurait besoin et ne dispose presque jamais. La directive présente par ailleurs l'ensemble de l'article 21(2) comme une approche tous risques , visant à protéger les systèmes d'information et l'environnement physique de ces systèmes . Cette formule travaille plus dur que la plupart des programmes de conformité ne le reconnaissent. Le mot « physique » est quasi absent de l'article 21 d'où l'angle mort Lisez l'article 21 en cherchant la sécurité physique : vous ne la trouverez presque pas. Cette absence a conduit beaucoup de programmes à conclure, assez raisonnablement, que NIS 2 traite des réseaux et laisse les portes et les machines à quelqu'un d'autre. La Commission ne le lit pas ainsi. Son règlement d'exécution (UE) 2024/2690, adopté en octobre 2024, décline l'article 21(2) en plus d'une centaine d'exigences techniques auditables et l'une des treize sections de son annexe est consacrée à la sécurité physique et environnementale : sécurisation des services support, contrôles d'accès périmétriques et physiques, surveillance, et révision périodique de ces mesures. Le règlement rattache cela aux points c), e) et i) de l'article 21, alors même que la sécurité physique n'y est pas nommée. Soyons précis sur le périmètre, parce que c'est là que les commentaires deviennent approximatifs. Ce règlement d'exécution ne lie qu'un sous-ensemble d'entités : fournisseurs DNS, registres de noms de domaine de premier niveau, services d'informatique en nuage, centres de données, réseaux de diffusion de contenu, fournisseurs de services gérés et de services de sécurité gérés, places de marché en ligne, moteurs de recherche, plateformes de réseaux sociaux, prestataires de services de confiance. Si vous exploitez une usine, il ne s'applique pas à vous. Ce qu'il vous donne en revanche, c'est la lecture que fait la Commission elle-même de l'article 21(2), écrite noir sur blanc et directement applicable quelque part dans l'Union. Le guide technique de mise en œuvre publié par l'ENISA en juin 2025 en reprend la structure et détaille le type de preuve qu'un auditeur s'attendra à voir. Quand votre autorité nationale ou l'auditeur de votre client vous demandera à quoi ressemblent des « mesures appropriées » en matière de contrôle d'accès et de gestion des actifs, c'est la réponse la plus autorisée actuellement disponible par écrit, et elle traite l'alimentation électrique et le périmètre physique comme faisant partie du sujet. Planifier en supposant que l'accès physique aux machines est hors du champ de NIS 2, c'est parier contre le sens du courant. Mais certains veulent encore espérer une simple déclaration d'incompétence sur le sujet et être exonéré. Le plan de réponse à incident, à l'épreuve de l'atelier Un plan de réponse à incident solide est une pierre angulaire de la conformité NIS 2. Il doit décrire des procédures claires de détection, de notification et de traitement et la directive y attache un chronomètre. La cascade 24 h / 72 h / un mois L'article 23 impose une alerte précoce sous 24 heures à compter de la connaissance d'un incident important, une notification plus complète sous 72 heures incluant une évaluation initiale de la gravité et de l'impact, puis un rapport final sous un mois . Ce sont les exercices réguliers qui rendent ces fenêtres tenables ; un plan jamais répété est un document, pas une capacité. On ne peut pas notifier ce qu'on ne sait pas attribuer C'est ici que les actifs industriels font céder le plan, et il vaut mieux le découvrir à froid qu'en situation. Notre cas d'école qu'on reprendra dans nos prochains articles de mise en oeuvre de Trust-Buster est très simple à visualiser. Vendredi, 22h40 . Une machine cinq axes tourne quarante minutes et produit onze pièces : ressources consommées, peut être une douzième emportée, et aucune explication fournie dans les cahiers de production. Lundi, quelqu'un s'en aperçoit et a un doute. Le chronomètre démarre. Sous 24 heures, vous devez une alerte précoce. Sous 72 heures, une évaluation initiale de la gravité et de l'impact transfrontalier. Pour produire l'une ou l'autre, il faut répondre à : qui l'a démarrée, au titre de quelle habilitation, et s'agit-il d'un usage non autorisé ou d'une erreur de planning ? Si le seul enregistrement disponible est le compteur horaire de la machine (non attribué, non signé, remis à zéro à la dernière révision) vous ne pouvez pas répondre. Vous déposerez une notification indiquant qu'un événement s'est produit et que vous investiguez, et vous direz encore la même chose un mois plus tard dans le rapport final. Ce n'est pas un échec de processus, c'est surtout un échec de principe, causé par un journal qui n'a jamais été conçu pour exister. À quoi ressemble une trace exploitable en OT Les exigences sont l'inverse de celles de votre SIEM. Le volume est faible : quelques dizaines d'événements par machine et par mois. Mais la valeur unitaire est très élevée, et le destinataire n'est presque jamais un moteur de détection temps réel : c'est un responsable, un assureur, un donneur d'ordre ou une autorité, qui lira bien plus tard. D'où quatre propriétés : Locale. Le réseau était très probablement coupé, ou absent par conception, au moment qui compte. Horodatée sur une source de temps de confiance. Une horloge OT décalée de douze heures ou restée à l'heure d'hiver en plein été rend toutes les autres propriétés sans valeur (la bise aux tenants de la GTB-GTC qui connaissent bien ce problème). Chaînée et signée , pour qu'une entrée manquante soit visible et non simplement absente. Exportable sans dépendre d'une infrastructure centrale. L'attribution est la partie difficile, et c'est un problème d'identité avant d'être un problème de journalisation. Un journal ne peut enregistrer que l'identité que le point d'application a réellement établie, raison pour laquelle contrôle d'accès et preuve doivent être conçus ensemble, et non l'un après l'autre. La chaîne de sous-traitance : la pression qui arrive avant le régulateur L'article 21(2) d) fait de la sécurité de la chaîne d'approvisionnement une obligation explicite. Traduction : les obligations de vos clients deviennent votre questionnement. En pratique, c'est cette pression-là qui atteint un directeur d'usine en premier. Les donneurs d'ordre de l'automobile, de l'aéronautique, de l'énergie et de la défense envoient déjà des clauses cyber à leurs fournisseurs de rang 2 et 3, et ces clauses demandent de plus en plus des éléments que l'atelier ne sait pas produire : la liste de qui peut exploiter tel équipement, la preuve que les habilitations étaient à jour, la trace des interventions physiques de techniciens tiers. Répondre « nous ne suivons pas cela » est donc d'abord un problème commercial bien avant d'être un problème réglementaire. Trois endroits où les réflexes habituels ne se transposent pas Brièvement, chacun mériterait son propre traitement et nous le détaillerons dans nos autres publications, sur la solution Trust-Buster ou à titre d'illustration de la problématique : L'échec fermé n'est pas automatique. En informatique de gestion, refuser en cas de doute est la position par défaut. Couper l'alimentation d'un système de ventilation ou d'un groupe de froid est une décision de sûreté avant d'être une décision de sécurité. Le sens du refus doit être défini équipement par équipement, conjointement avec l'exploitation et le HSE. Encore plus de journal et de règles mais c'est vital. La connectivité n'est pas une hypothèse. Un point de décision qui appelle un service distant est un point de décision qui s'abstient pendant une coupure c'est-à-dire exactement quand le risque culmine. La décision doit être rendue localement et rester nominale, pas dégradée. La plupart des sujets légitimes ne sont pas les vôtres. Intérimaires, sous-traitants de rang 2, techniciens constructeur venus d'un autre continent. Vous devez vérifier une habilitation et l'associer à un ordre d'intervention sans avoir jamais provisionné la personne, souvent sans annuaire côté fournisseur. Et tout ça pour laisser des interrupteurs et des prises électriques libres sans contrôle. Où en est la France, et pourquoi cela ne repousse pas votre échéance La situation française mérite d'être posée précisément, parce qu'elle est régulièrement mal résumée. Cocorico, sport national. La directive imposait une transposition pour le 17 octobre 2024. Le véhicule législatif retenu est le projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité , qui transpose d'un seul tenant trois textes européens : NIS 2, la directive REC sur la résilience des entités critiques, et des dispositions relatives à DORA. Il a été présenté en Conseil des ministres le 15 octobre 2024, deux jours avant l'échéance européenne puis adopté par le Sénat en première lecture les 11 et 12 mars 2025, puis adopté en commission spéciale à l'Assemblée nationale les 9 et 10 septembre 2025. Depuis, l'examen en séance publique n'a pas eu lieu. Le texte ne figurait pas à l'ordre du jour de la session extraordinaire de juillet 2026, ce qui reporte son examen à la rentrée parlementaire au plus tôt. Le 8 juillet 2026, la Commission européenne a saisi la Cour de justice de l'Union européenne contre la France (ainsi que l'Irlande, l'Espagne et les Pays-Bas) pour défaut de notification de la transposition complète, en demandant une somme forfaitaire et une astreinte journalière. On passe d'un retard administratif à une procédure contentieuse assortie de sanctions financières. L'ANSSI, de son côté, n'attend pas : elle a ouvert le portail Mon Espace NIS2 et encourage les entités concernées soit environ quinze mille, contre quelque deux cent cinquante opérateurs de services essentiels sous NIS 1, à s'y enregistrer. Elle précise en même temps, sans ambiguïté, que son Référentiel Cyber France reste à ce stade un document de travail et que les obligations NIS 2 ne deviendront juridiquement opérantes qu'une fois les mesures de transposition adoptées. Justement on a un bel article sur 2027 et ses joyeusetés pour les machines. Il est tentant de lire tout cela comme un répit. C'en est un sur le plan strictement juridique, et c'en est un piège sur le plan opérationnel, pour trois raisons : Les clauses de vos clients n'attendent pas un parlement. Elles arrivent déjà, et elles posent les questions de la section précédente. Si vous opérez dans plusieurs États membres, vous êtes déjà dans le périmètre ailleurs. Vingt-deux des vingt-sept ont adopté leur loi de transposition ; la Belgique, l'Italie ou l'Allemagne sont opérationnelles depuis un moment. Les obligations qui arriveront en France sont, par construction, les mêmes. Le délai ne change pas le contenu, seulement la date à laquelle vous serez interrogé dessus. À noter aussi, parce que c'est une spécificité française qui surprend : le projet de loi étend le périmètre aux collectivités territoriales : régions, départements, communes de plus de trente mille habitants et leurs groupements pour une extension nationale que la directive laissait à l'appréciation des États membres. Les organisations qui auront profité du retard pour dresser l'inventaire OT seront prêtes. Celles qui en auront profité pour attendre feront le même travail, mais au calendrier d'un superviseur impatient plutôt qu'au leur. Une séquence de travail Étendez l'inventaire aux actifs OT dépourvus de toute politique d'accès. Pas toutes les machines : celles dont l'usage non autorisé a une conséquence matérielle, humaine ou réglementaire. Définissez le sens du refus pour chacune d'elles , avec l'exploitation et le HSE autour de la table. C'est le livrable le plus difficile et il conditionne tout le reste. Exigez un point d'application capable de décider hors ligne. Ce seul critère élimine les approches inadaptées plus vite que n'importe quelle comparaison de fonctionnalités. Concevez la trace de preuve en même temps que le contrôle d'accès , pas après. Vous ne pourrez journaliser que l'identité que vous aurez réellement établie. Répétez le chronomètre des 24 heures sur un scénario OT , pas sur un scénario informatique. C'est là que le plan cassera, et mieux vaut que ce soit pendant un exercice. Et une chose à ne pas faire : ne raccordez pas un équipement au réseau dans le seul but de pouvoir le gouverner. Créer une surface d'attaque pour surveiller la surface d'attaque qu'on vient de créer est un mauvais échange. Le contrôle d'accès physique n'a pas besoin que la machine soit intelligente. Il a besoin que la prise le soit. Oui, il est temps de reparler de ce qu'on propose avec Trust-Buster. Ce que cela ne vous donne pas Le travail de conformité invite à la surenchère, alors soyons clairs sur les limites : contrôler et journaliser l'accès au niveau de l'alimentation répond aux volets contrôle d'accès, gestion des actifs et preuve de l'article 21(2). Cela ne répond ni à la segmentation réseau, ni au traitement des vulnérabilités, ni aux sauvegardes et à la reprise, ni à la politique de cryptographie, ni à l'évaluation des fournisseurs. C'est une colonne de la matrice, pas la matrice. Il se trouve simplement que c'est la colonne vide sur presque tous les sites et ce qui explique pourquoi il est utile de commencer par là, et pourquoi il est tout aussi utile de dire où cela s'arrête. Dernière révision : août 2026. Les statuts de transposition et d'application de NIS 2 évoluent ; vérifiez auprès de l'ANSSI avant de vous appuyer sur une date de cet article.

Législation cyber : ce qui vous attend en 2027

Deux échéances sèches, aucune période de transition, et une clause que vous n'avez peut être pas lue Le paysage législatif de la cybersécurité a décollé depuis 2023 avec plusieurs départs : en 2027, il atterrit. Deux règlements européens entrent en application à onze mois d'intervalle, aucun des deux ne prévoit de période de transition, et ensemble ils changent ce que le marquage CE d'une machine industrielle certifie réellement. Si vous exploitez des machines en Europe, ou si vous en vendez, 2027 n'est pas une année à surveiller en attendant les élections, mais à avoir préparée avec grand soin. Vous pouvez rêver à un assouplissement pour cause de chaos mondial, ou prendre vos précautions. 2027 est une année d'échéances, pas une année de tendances La plupart des panoramas législatifs prennent des précautions et on a connu des déboires dans des secteurs connexes (Smart City, bâtiment, énergie). Celui-ci n'en a pas besoin : les deux dates qui comptent sont fixées dans des règlements publiés, et aucune ne semble plus s'accompagner d'un délai de grâce. Date Texte Ce qui change 20 janvier 2027 Règlement Machines (UE) 2023/1230 Remplace purement et simplement la directive Machines. La cybersécurité devient une exigence essentielle de santé et de sécurité pour le marquage CE. 11 décembre 2027 Règlement sur la cyberrésilience (UE) 2024/2847 Entrée en application pleine. Tout produit comportant des éléments numériques mis sur le marché de l'Union porte des obligations de sécurité sur l'ensemble de son cycle de vie. C'est l'absence de fenêtre de transition qui surprend. Une machine mise sur le marché le 19 janvier 2027 relève de l'ancienne directive ; la même machine mise sur le marché le lendemain relève du règlement. Il n'y a ni régime mixte, ni période d'option. 20 janvier 2027 : la cybersécurité devient une exigence de sécurité Le règlement Machines remplace la directive 2006/42/CE, cadre qui gouverne le marquage CE des machines depuis les années 2000. La couverture médiatique se concentre sur l'apprentissage automatique et les organismes notifiés. Pour qui travaille sur la sécurité des systèmes industriels, le changement le plus lourd de conséquences est plus discret. La cybersécurité entre dans les exigences essentielles de santé et de sécurité. L'annexe III introduit une section intitulée protection contre la corruption (§ 1.1.9), aux côtés d'exigences renforcées sur la sécurité et la fiabilité des systèmes de commande (§ 1.2.1). En substance : la connexion à d'autres systèmes ou l'accès à distance ne doivent pas créer de situation dangereuse, et les composants matériels, logiciels et données relatifs à la sécurité doivent être identifiés comme tels et protégés contre la corruption, accidentelle ou délibérée. C'est un vrai changement de nature juridique. Sous la directive, protéger une machine contre l'altération relevait de l'appréciation du fabricant. À partir de janvier 2027, c'est une condition de mise sur le marché. Les associations d'acteurs industriels ont demandé que les exigences de cybersécurité soient reportées à la date du CRA mais ce report n'a pas été accordé. La clause que presque personne n'a lue : la modification substantielle Voici la disposition qui devrait être sur le bureau de chaque responsable maintenance et méthodes d'Europe, et qui y est rarement. Le règlement Machines définit la modification substantielle dans le droit de l'Union pour la première fois. La conséquence est courte et sévère : celui qui effectue une modification substantielle devient le fabricant pour les aspects concernés — avec l'évaluation de la conformité, la documentation technique et la responsabilité qui vont avec. C'est lui qui "porte le chapeau" (pour ceux qui n'avaient pas compris l'illustration). Rapprochez cela de la manière dont les retrofits de sécurité OT se font habituellement. On ouvre l'armoire, on insère un module dans le circuit de commande relatif à la sécurité, on recâble, on referme. En 2026, c'est ("juste") une conversation sur la garantie et une question d'analyse de risque. À partir de 2027, c'est la question de savoir si votre équipe de maintenance vient de devenir fabricant de machines, dans un domaine dont les exigences incluent désormais la cybersécurité des fonctions de sécurité. Nous pourrons revenir dans un futur article sur les retrofits de sécurité, qui pour nous devraient se placer à la frontière d'une machine plutôt qu'en son sein, pour des raisons de coût et de responsabilité. Le règlement Machines ne fait pas cet argument à notre place : il fait quelque chose de plus utile, qui est d'inscrire la moitié « responsabilité » de cet argument dans un texte européen directement applicable. Tout plan de retrofit pour 2027 devrait comporter une réponse explicite à la question cela constitue-t-il une modification substantielle ? , et la réponse la plus sûre est celle où l'on n'a touché à rien à l'intérieur de la machine. Gardez vos machines non modifiables et ajoutez y les éléments de sécurité nécessaires à la conformité, et facilement remplaçables par vos équipes de maintenance lors des prochaines évolutions. 11 décembre 2027 : le CRA entre pleinement en application Le règlement sur la cyberrésilience est entré en vigueur le 10 décembre 2024. Ses obligations de notification (vulnérabilités activement exploitées et incidents graves) s'appliqueront au 11 septembre 2026. L'application pleine intervient le 11 décembre 2027, et elle est large : exigences essentielles de l'annexe I, documentation technique, traitement des vulnérabilités sur une période de support définie, et une procédure de conformité qui varie selon la classe de produit. Deux points comptent plus que les grandes lignes déjà connues (quoi que, pas très médiatique). Le texte est extraterritorial. Le CRA lie tout fabricant mettant un produit comportant des éléments numériques sur le marché de l'Union, où qu'il soit établi. Un industriel américain, japonais ou taïwanais qui vend dans l'Union est dans le périmètre et doit désigner un mandataire ou s'appuyer sur un importateur portant les obligations. Les lecteurs non européens qui ont classé le CRA au rayon « problème européen » l'ont mal classé. Les fabricants de machines relèvent des deux régimes à la fois. Les considérants du CRA indiquent clairement que les fabricants de machines doivent se conformer aux deux textes ; la Commission et les organismes européens de normalisation sont appelés à favoriser la cohérence dans la manière d'évaluer le risque cyber au titre des deux régimes. Cette cohérence reste un chantier en cours plutôt qu'un fait acquis — voir plus bas. Et sur le contrôle d'accès précisément, l'annexe I est d'une netteté inhabituelle pour un règlement produit : les produits doivent être protégés contre les accès non autorisés par des mécanismes de contrôle appropriés, incluant sans s'y limiter l'authentification, les systèmes de gestion des identités ou des accès , et doivent rendre compte des accès non autorisés éventuels. Un règlement produit qui écrit « systèmes de gestion des identités ou des accès » dans son dispositif. Normalisation : ce qu'il faut en attendre, et quand Le règlement sur la cyberrésilience instaure bien un cadre unifié d'exigences de cybersécurité, et la normalisation est effectivement la tendance à suivre mais autant être honnête sur l'état réel du chantier plutôt que de le décrire comme achevé. Les normes harmonisées sont ce qui transforme une exigence essentielle en spécification testable et donne au fabricant une présomption de conformité. Pour la cybersécurité des machines, cette couche est encore en construction : la norme EN 50742, qui traite de la protection contre la corruption dans les machines, est en cours d'élaboration, et les travaux sectoriels comme la révision 2025 d'ISO 10218-2 pour les robots industriels, commencent à intégrer des exigences de cybersécurité dans les normes de sécurité. Côté CRA, la demande de normalisation est considérable et le calendrier serré face à décembre 2027. La conséquence pratique pour un fabricant est inconfortable mais gérable : vous atteindrez peut-être une date d'application avant que la norme harmonisée sur laquelle vous comptiez ne soit citée au Journal officiel. Cela ne suspend pas l'exigence. Cela signifie démontrer la conformité par d'autres moyens, analyse de risque documentée, normes internationales reconnues comme IEC 62443, et éléments de preuve présentables à un évaluateur. La conséquence pour un exploitant est différente et plus intéressante. Les machines mises sur le marché à partir de 2027 arriveront avec une protection contre l'altération, une identité logicielle et une journalisation dont le parc actuel ne dispose tout simplement pas. Votre parc devient à deux vitesses : une minorité croissante d'actifs dotés de primitives de sécurité exploitables, et une large majorité (presses, variateurs, bancs et armoires mis en service entre les années 90 ou avant même et 2026) qui n'en aura jamais et qu'on ne peut pas équiper de l'intérieur sans se poser la question de la modification substantielle. Gouverner cette exigence n'est pas un problème qui débute en 2027 : c'est le problème que 2027 rend visible. Ce qui arrive aussi, et qu'il faut suivre Règlement IA, 2 août 2027. Les obligations relatives aux systèmes d'IA à haut risque qui sont des composants de sécurité de produits couverts par une législation sectorielle et surtout machines incluses commencent à s'appliquer. Si vous intégrez un composant de sécurité fondé sur l'apprentissage automatique, vous relevez à la fois de la procédure avec organisme notifié du règlement Machines et du règlement IA pour ce composant. NIS 2 et Directive REC (Résilience des Entités Critiques). La phase de transposition s'achève et la phase de supervision commence. La Commission est passée des procédures d'infraction aux renvois devant la Cour de justice ; les autorités nationales qui ont passé 2025 et 2026 à enregistrer les entités passeront 2027 à les contrôler. Royaume-Uni. Le Cyber Security and Resilience Bill reste un projet de loi, en examen à la Chambre des Lords à l'heure où nous écrivons. Il modifiera les NIS Regulations de 2018 et fera entrer dans le périmètre les fournisseurs de services gérés et certains fournisseurs critiques désignés. États-Unis. Tableau moins flatteur que le tableau européen, et autant le dire franchement : la règle finale de CIRCIA a largement dépassé son échéance légale, et la proposition de règle de la TSA de 2024 pour le transport de surface n'est pas finalisée. Hors du secteur électrique couvert par NERC CIP, les obligations américaines contraignantes sont plus minces que ne le laissent penser les titres. Que faire du temps qui reste Cartographiez votre gamme ou votre parc par rapport à la coupure du 20 janvier 2027. Fabricants : quels produits changent de catégorie à l'annexe I, et lesquels perdent la voie de l'autocertification. Exploitants : quelles machines vous comptez acheter après cette date, et avec quelles primitives de sécurité elles arriveront. Intégrez la question de la modification substantielle à votre processus d'approbation des retrofits avant l'ingénierie, pas après. C'est une ligne à ajouter, et elle peut éviter une erreur de catégorie coûteuse. Examinez comment l'identité logicielle et les preuves d'altération seront captées et conservées. Les deux régimes le demandent, et aucun n'accepte le compteur horaire de la machine comme réponse. Dressez l'inventaire des actifs OT si ce n'est pas déjà fait. Toutes les obligations ci-dessus sont cadrées par une liste que la plupart des organisations n'ont jamais produite. N'attendez pas les normes harmonisées pour commencer. Concevez contre IEC 62443 et documentez le raisonnement ; la norme, quand elle arrivera, sera un exercice de correspondance et non une refonte. Ce que nous ne prétendons pas Deux limites, énoncées parce que les écrits sur la conformité ont tendance à les estomper. Nous décrivons des dates publiées, nous ne prédisons pas l'intensité des contrôles. L'agressivité des autorités nationales de surveillance du marché durant la première année d'application du règlement Machines est réellement inconnue. Les dates sont certaines mais l'intensité ne l'est pas. D'où certains appels au chaos européeo-juridiques dans l'espoir de tout bazarder avant d'avoir payé pour s'adapter. Mais franchement ce serait une belle erreur. Rien de ceci ne constitue un avis juridique , et les deux règlements interagissent d'une manière que la Commission s'est elle-même engagée à clarifier par des lignes directrices. Si votre produit se situe près d'une frontière de catégorie (composant de sécurité, machine intégrant de l'apprentissage automatique, produit qui est à la fois une machine et un produit comportant des éléments numériques ) cette frontière mérite l'avis d'un spécialiste plutôt que celui que nous vous donnons. Certes ça nous arrangerait que tout le monde ait besoin de nous mais on a assez subi d'autres réglementations similaires pour être franc sur ces sujets.. Ce que nous pouvons affirmer sans réserve est plus étroit et, nous semble-t-il, plus utile : à partir de 2027, la cybersécurité des fonctions de sécurité d'une machine relève du marquage CE + ouvrir une machine pour la sécuriser emporte une conséquence juridique qu'elle n'emportait pas auparavant + le parc installé qui ne sera jamais conforme par lui-même est la part du parc qu'il faut gouverner depuis l'extérieur. Voilà notre petit vademecum estival pour bien entamer vos COMEX de septembre. Dernière révision : août 2026. Les calendriers réglementaires et l'état d'avancement de la normalisation évoluent ; vérifiez sur EUR-Lex et auprès de votre organisme notifié avant de vous appuyer sur une date de cet article.

Dans les coulisses de TB

Comment nous prenons les décisions La plateforme Ops-Devices a été conçue pour traiter nos besoins opérationnels quotidiens puis de répondre aux exigences juridiques qui arrivent avec NIS 2, le CRA et les différents règlements industriels. Beaucoup d'options s'offraient à nous, mais les technologies étant nombreuses, il était facile d'obtenir rapidement une solution conforme. Ce qui suit présente une partie plus difficile mais primordiale sur le long terme : comment les décisions se prennent, ce que nous devons refusé d'affirmer sans une démarche pérenne, et l'engagement d'architecture initiale que nous avons dû défaire quand le sol s'est dérobé sous lui. Nous tenons un registre des alternatives que nous avons écartées La plupart des équipes d'ingénierie documentent uniquement ce qu'elles ont construit. Depuis le début de cette aventure, nous documentons aussi ce que nous n'avons pas construit, et pourquoi. C'est une pratique désormais courante, et à ce sujet lisez et utilisez des ressources bien faites comme les Architecture Decision Records . Chaque choix d'architecture significatif entre dans un registre qui consigne quatre éléments : l'option retenue, les options écartées, le raisonnement au moment de la décision, et la partie qui compte le plus : le déclencheur de réévaluation . Ce dernier champ énonce par écrit ce qui devrait changer dans le monde pour que la décision soit rouverte, et pour ma part c'est ce qui me manquait le plus et faisait enchainer des revues d'architecture interminables. Cela a commencé comme une discipline de R&D ordinaire. Il s'est avéré que cela avait deux autres intérêts que nous n'avions pas anticipés. Le premier est réglementaire. Le CRA comme le règlement Machines demandent au fabricant de démontrer que la sécurité a été prise en compte dès la conception, et non affirmée après coup. Un registre daté d'alternatives écartées, avec leur raisonnement, est une bien meilleure réponse à cette question qu'une politique rédigée le mois précédant l'audit. Le second est une contrainte d'honnêteté. Écrire un déclencheur de réévaluation est inconfortable, parce qu'on s'engage à l'avance sur la condition dans laquelle il faudra reconnaître qu'une décision ne tient plus. Ce qui nous amène à celui qui s'est déclenché juste avant la commercialisation du Cube. La décision que nous avons dû défaire Notre première architecture matérielle reposait sur une chaîne de confiance européenne. La plateforme cellulaire retenue associait un microcontrôleur à un modem intégrant une enclave sécurisée dont l'IP venait de Tiempo Secure : société fondée en 2007 à Montbonnot, près de Grenoble, cocorico, dont l'élément sécurisé TESIC à cœur RISC-V a passé une évaluation Critères Communs EAL5+ auprès du laboratoire français SERMA, et qui avait été retenue pour un programme de microprocesseur de sécurité post-quantique souverain soutenu par l'État français. La ligne de modems venait de Sequans , fournisseur français, cocorico, de semi-conducteurs cellulaires. Carte européenne, modem européen, IP d'enclave européenne : une chaîne que nous pouvions décrire de bout en bout et défendre devant un acheteur de la défense. Puis les deux pièces ont changé de mains. En août 2024, Qualcomm a conclu un accord pour acquérir les actifs technologiques 4G IoT de Sequans : employés, actifs et licences, dont la gamme Monarch, une transaction finalisée le mois suivant pour environ 200 millions de dollars, Sequans conservant une licence perpétuelle lui permettant de continuer à utiliser et commercialiser la technologie. Tiempo Secure a ensuite été rachetée par Qualcomm également : opération confirmée publiquement par son cofondateur et aujourd'hui reflétée sur le site de Tiempo lui-même. Ce que cela a changé, et ce que cela n'a pas changé. Il faut être précis, parce que la version approximative de cette histoire serait plus spectaculaire que la vraie, toute proportion gardée sur les conséquences pour nous. La technologie n'a pas cessé de fonctionner et Sequans continue d'opérer et détient une licence perpétuelle. L'équipe d'ingénierie de Tiempo est toujours à Montbonnot. Aucune puce ne s'est transformée en porte dérobée pendant la nuit ! Esprit-ssif, es-tu là ? Ce qui a changé est plus étroit mais, pour nous, décisif : la phrase que nous écrivions n'était plus vraie. Nous décrivions une chaîne de confiance matérielle intégralement européenne. Après les acquisitions, l'IP d'enclave et une part substantielle de la technologie modem relevaient d'une propriété capitalistique américaine. Pour un client industriel, c'est une note de bas de page mais pour un client sensible qui évalue de plus en plus la provenance de sa chaîne d'approvisionnement, c'est toute la question. Après tout, les déboires du secteur automobile à l'été 2022 (salut TI !) sont passés par là. Ce que nous avons fait. Nous avons déprécié cette plateforme comme ancre de souveraineté et déplacé l'ancre ailleurs : un microcontrôleur STM32, un porteur cellulaire Nordic, et un élément sécurisé discret approvisionné séparément plutôt qu'hérité via un modem. Le chemin de prototypage passe désormais par une plateforme de développement Nordic associée à un élément sécurisé STSAFE, avec un composant de niveau d'assurance supérieur prévu sur le chemin de production. Ce que nous en avons appris , et c'est la partie qui mérite d'être généralisée : la souveraineté n'est pas une propriété d'un composant, c'est la propriété d'une affirmation qu'il faut maintenir vraie. La propriété de l'IP semi-conducteur change de mains à un rythme bien plus court que la durée de vie d'une machine industrielle. Toute architecture qui adosse sa différenciation à la nationalité d'un fournisseur a besoin d'un déclencheur de réévaluation explicite, parce que ce déclencheur finira par se déclencher, et l'alternative à s'en apercevoir soi-même... est qu'un client s'en aperçoive à votre place ! Notre registre porte désormais ce déclencheur sur chaque décision d'approvisionnement qui soutient une affirmation de provenance. Trois affirmations que nous refusons de faire Le marketing adjacent à la conformité a une pente naturelle vers la surenchère. Voici les trois endroits où nous avons décidé à l'avance de ne pas la suivre, écrits pour qu'un lecteur puisse nous y retenir le moment venu. EAL5+ est hérité, pas obtenu. Quand nous - pour ops-devices surtout - mentionnons une évaluation Critères Communs EAL5+, elle appartient à un composant élément sécurisé et au laboratoire qui l'a évalué. Ops-Devices ne détient aucune certification de ce type et n'en revendique aucune. Un produit contenant un composant certifié n'est pas un produit certifié, et la distinction compte précisément pour les clients qui s'intéressent à la certification. La force du signal radio est un portail, pas une preuve. Notre système utilise le niveau de signal reçu comme condition d'entrée du processus de contrôle d'accès : sous un certain seuil, l'échange ne s'engage pas. Ce n'est pas un facteur d'authentification. Un signal RSSI s'amplifie, se relaie et se falsifie, et aucun filtrage ne le transforme en mesure de distance. La mesure par temps de vol en ultra-large bande (UWB) le ferait correctement mais nous n'en disposons pas aujourd'hui, et nous le disons plutôt que de laisser entendre qu'un seuillage soigneux serait équivalent. Espérons qu'on puisse intégrer les prototypes rapidement, et un cas client y aidera certainement (car pour le moment, ça fonctionne tellement bien que la demande sera certainement sur une niche). Nous ne pouvons pas revendiquer une détection exhaustive. Aucun système de surveillance radioélectrique ne peut démontrer l'absence d'un signal qu'il n'a pas vu. La détection est un signal de corroboration dans une décision, pas le point d'ancrage. Tout fournisseur annonçant une couverture de détection complète dans un environnement radio non maîtrisé décrit une ambition, pas une mesure. Chacune de ces trois phrases rend la diapositive un peu moins impressionnante dans notre "deck" mais... chacune survit très bien à l'évaluation technique d'un client, ce que la version impressionnante ne fait pas. Collaboration et innovation Notre processus de développement suppose un dialogue continu avec l'extérieur. Nous concevons contre des normes publiées et nous ne siégeons pas dans les organismes qui les écrivent. IEC 62443 structure notre architecture, le CRA et le règlement Machines structurent notre documentation, IEEE 802.1AR, ISO 15118 et les travaux de l'IETF sur les environnements contraints éclairent des choix de conception précis. Nous sommes lecteurs de ces normes et, quand c'est pertinent, nous préparons des réponses structurées pour les équipes achats qui les citent. Nous ne détenons pas de sièges en commission de normalisation ni auprès d'autorités réglementaires. C'est bien dommage, car entre retard et annulation pur et simple, difficile de savoir si les entreprises auront finalement un bâton ou une carotte. Et les carottes en cybersécurité ne rendent pas aimables les DAF, qui ne vont pas débourser autant et aussi vite. Nous construisons sur l'open source, délibérément et par défaut. Firmwares sur des cadres ouverts, schémas publiés dans un format de CAO électronique libre, modules du commerce à protocole documenté plutôt que matériel sur mesure chaque fois qu'un composant standard suffit. Ce n'est pas de l'idéologie : c'est la seule façon pour une petite équipe de conserver une chaîne d'approvisionnement réellement auditable, et c'est ce qui rend la question de provenance ci-dessus tout simplement posable. L'innovation se limite à une seule couche. Assembler des composants éprouvés et des cadres ouverts n'est pas de l'innovation, et nous ne le présentons pas comme tel. Ce que nous gardons en propre, c'est la chaîne de confiance qui relie ces composants : décision locale sans connectivité, capacités éphémères signées, trace de preuve conçue pour la démonstration rétrospective plutôt que pour la détection temps réel, et application de la décision à la frontière de la machine plutôt qu'en son sein. C'est une couche étroite, celle que personne d'autre n'occupe sur la carte concurrentielle, et c'est pour cela que c'est la seule partie qui vaille la peine d'être construite par nous. Ce que la plateforme traite, et ce qu'elle ne traite pas Une plateforme ne délivre pas une conformité. La conformité est un résultat organisationnel ; un produit ne peut fermer que des exigences précises à l'intérieur d'un cadre réglementé. La plateforme Ops-Devices traite donc une colonne définie de cette matrice : le contrôle d'accès et la gestion des actifs pour des équipements dépourvus de chemin numérique (OT pas IT pour simplifier), la preuve d'intervention physique qui survit à un site hors ligne et à dix-huit mois d'écart, et l'application de la décision sans modifier la machine. Elle ne traite ni la segmentation réseau, ni le traitement des vulnérabilités, ni les sauvegardes et la reprise, ni la politique de cryptographie sur votre parc, ni l'évaluation de vos fournisseurs, ni la formation, ni le processus de réponse à incident. Ce sont de véritables obligations au titre de l'article 21(2) de NIS 2, et quiconque vous affirme qu'un seul produit les couvrirait vous vend un récit de conformité plutôt qu'une mesure (des jours de conseil plutôt qu'une solution déployable, classique non ?) La raison pour laquelle nous commençons là n'est pas que notre périmètre soit le plus important. C'est que sur presque tous les sites où nous nous sommes rendus dans nos carrières et surtout quand nous avions une responsabilité pénale au-dessus de la tête, c'est celui qui est complètement vide : aucune liste de qui peut exploiter l'équipement, aucune trace de qui l'a fait, et aucun mécanisme capable de produire l'une ou l'autre. Pourquoi nous écrivons tout cela Il existe un argument commercial simple contre le fait de publier une décision d'architecture défaite, une réserve sur une certification héritée et une liste de ce qu'un produit ne fait pas. Cela rend l'histoire moins nette. Nous le faisons à cause de ceux qui évaluent cette catégorie de solutions. Les personnes qui achètent du contrôle d'accès pour des sites industriels et de défense sont, par métier, des personnes qui cherchent l'écart entre l'affirmation et l'objet. Un fournisseur qui nomme ses propres limites en premier ne fait pas preuve de modestie : il retire de l'évaluation la ligne d'interrogation la plus improductive et ne laisse que la substance. Et à cause du registre... donc vous aussi vous y viendrez ! Une fois qu'on a écrit la condition dans laquelle une décision cesse d'être vraie, il faut faire quelque chose quand elle survient. C'est une discipline inconfortable, et c'est ce que nous avons de plus proche. La garantie que ce que nous vous dirons l'an prochain sera encore défendable même si le contexte aura largement évolué.