Speaker #0Ces derniers jours, j'ai regardé Retour vers le futur avec une de mes filles de 12 ans. Et je ne pensais pas qu'elle aimerait. En fait, elle a tellement aimé qu'on s'est fait la trilogie. Et ce que je retiens de cela, est que cela a surtout été un échange entre nous, sur la partie des années 80. Elle a découvert des objets qui n'existaient plus aujourd'hui, et au fur et à mesure, j'ai expliqué ce que moi, j'utilisais à son âge. À 12 ans. Elle s'est projetée, et moi aussi du coup. Nostalgie. Donc je t'emmène d'abord avec moi. On retourne quelques années en arrière, en 1987. Je vais te raconter l'histoire d'un petit garçon de 12 ans qui voulait faire de l'informatique. Et bienvenue aussi dans Compliance Without Coma, le podcast qui parle de cybersécurité, de gouvernance et d'ISO 27001, sans te plonger dans le coma. Je suis Fabrice De Paepe et depuis plus de 20 ans, j'accompagne des organisations à mettre en place des systèmes de management qui fonctionnent vraiment. Et aujourd'hui, on quitte un peu les écrans pour regarder ce qu'il y a derrière. Des machines, des chaînes de production, des installations qui font fonctionner notre quotidien. Qui a dit les frigos ? Sortez, monsieur ! Bref, j'avais prévu de développer ces sujets en 2027, on va prendre un peu d'avance. Parce que lorsqu'on parle de NIS2, de fournisseurs et de cyber, il faut aussi regarder ce qui tourne dans l'atelier, dans les locaux techniques, ou au bout d'une connexion de maintenance. Et oui, tu l'as deviné, on va parler d'OT. A 12 ans, j'ai commencé l'informatique sur un Commodore 64 sur une TV. charger des jeux sur cassette pendant des heures, laisser tourner, jouer avec les copains dehors en attendant, on devait être patient. L'écran était bleu, mais il n'y avait pas encore de core dump Windows. J'ai appris l'anglais avec le dictionnaire Harraps sur mes genoux, pour déchiffrer toute la doc en anglais au fur et à mesure. J'ai aussi appris à programmer en basic. J'ai connu les floppy disks et les programmes dans les revues spécialisées. Tu sais, ceux qui ne marchaient pas quand tu les recopiais ligne après ligne. Et puis... La frustration grandissant, j'ai commencé à lire des livres sur le basic, et c'est ainsi que j'ai commencé la programmation. Je me rappelle de ma chambre d'enfant avec des montages de Lego partout sur les étagères. Six ans plus tard, j'ai commencé des études d'informatique industrielle. Et là, le programme ne restait plus seulement dans l'ordinateur, il faisait bouger quelque chose. Un moteur, un automate, un bras de robot. Et quand tu te trompais, tu pouvais le voir, très concrètement. Et je me rappelle ce bras de robot... en labo, qu'on devait manipuler en forth. Ouais, c'est un langage. On y avait couplé une caméra. Eh oui, déjà. Pour reconnaître des cubes éparpillés et les empiler. Faire un stack, en fait. Et on s'est trompé dans la manip à maintes reprises. Ça arrive. Ça fait partie de l'apprentissage. Et entre notre analyse papier faite à la maison et le labo, qui est en fait une simulation de la vie réelle, en quelque sorte, il y avait de gros écarts. Et notre robot avait reçu une mauvaise instruction. Les pièces qu'il devait déplacer ont fini par voler. A l'époque, c'était une erreur de programmation. Aujourd'hui, la question qui m'intéresse, c'est celle-ci. Que se passe-t-il quand quelqu'un modifie volontairement les instructions ? Bienvenue dans le monde de l'OT. Alors, l'OT, c'est quoi ? OT signifie Operational Technology. En français, on parle de technologie opérationnelle. Pour faire simple, l'IT traite, transporte et stocke de l'information. L'OT surveille ou commande des processus physiques. Ton logiciel de facturation traite une commande. L'automate de la ligne de production commande un moteur. Un capteur mesure une température. Un contrôleur compare cette mesure à ce qu'on attend. Et tu peux également avoir un actionneur qui va ouvrir une vanne, démarrer une pompe ou modifier un mouvement. Et derrière ton écran, quelque chose se passe réellement. Et tu entendras aussi parler de PLC, les automates programmables industriels, d'interface home machine ou de SCADA, des systèmes qui permettent de superviser et de piloter des installations. Tiens, est-ce que tu savais que j'avais fait des études dans ce domaine ? Je parie que non. J'ai programmé en assembleur et en C. Je me suis mangé des cours d'électricité et d'électronique pour être capable de programmer des pilotes pour ces machines. Mais j'ai dit PLC... PLC çà me dit quelque chose... Mais oui ! Stuxnet en 2010 ! Un code avec une complexité incroyable et une des premières cyberarmes mondiales. Il aurait physiquement dégradé des centrifugeuses iraniennes en infectant les contrôleurs à logique programmable, les PLC, et donc en les sabotant. Mais ça c'est en 2010. Tout va bien. On parlait pas encore du détroit d'Hormuz, mais donc. Tu vois l'ampleur des dégâts sur un programme nucléaire ? C'était de l'OT, hein ? Donc retiens surtout la chaîne. Mesurer. Décider. L'OT n'est pas le contraire de l'IT. Les deux se rencontrent de plus en plus. Et une application IT peut être indispensable au fonctionnement d'un processus industriel, sans être elle-même un automate. Tu pilotes ton automate au travers de ton Windows, moi je pilotais bien des vérins hydrauliques et pneumatiques avec mes programmes. Petite distinction quand même, OT n'a rien à voir avec IoT. Ce ne sont pas les synonymes. IoT, c'est l'Internet des objets. Mais certains te diront même Internet of Threats, l'Internet des menaces. Certains objets connectés participent à un environnement OT, par contre. Mais tout, tout l'OT n'est pas connecté à Internet. Et ici, j'aimerais bien que tu regardes un petit peu autour de toi. Tiens, quand on dit industriel, tu imagines peut-être une usine avec de grosses armoires électriques. C'est une partie du paysage, mais seulement une partie. Parmi les secteurs couverts par NIS2, prends l'énergie. Des équipements de production, des postes électriques, des systèmes de conduite de réseau. Prends les transports. La signalisation ferroviaire, les aiguillages, les installations portuaires, les systèmes techniques d'un aéroport. Mais tout ce qui peut permettre aussi de gérer l'atterrissage et le décollage d'un avion. L'eau potable et les eaux usées, des pompes, des vannes, des sondes, des installations de traitement, la santé. Les installations techniques d'un hôpital, la ventilation, l'alimentation de secours, les dispositifs médicaux connectés, ajoutent encore d'autres contraintes, au-delà de leurs propres exigences de sécurité. On a également l'agroalimentaire, la production, l'embouteillage, pas les bouchons, hein. La température, la chaîne du froid. Qui a dit frigo ? Sortez, monsieur ! La chimie et la fabrication. Des procédés, des robots, des machines et des contrôles de qualité. On a également les déchets, des chaînes de tri, des convoyeurs, des installations de traitement. Et on a également les services postaux, le tri automatisé des colis. Mais même un centre de données, en fait, repose sur des équipements physiques. Son refroidissement, son alimentation électrique, ses systèmes techniques. Je ne vais pas te lire toutes les annexes de la NIS 2. Et je t'ai parlé d'embouteillage. Eh bien, j'ai aussi visité l'embouteillage à Chimay. Rien à voir avec l'embouteillage quotidien à Bruxelles ou sur le périph' à Paris. Non, je te parle de l'embouteillage de l'une de nos bières belges bien connues. Et là, t'imagines si le stroboscope à l'embouteillage à Chimay était incapable de reconnaître les défauts dans les bouteilles en verre ? Et si lui, il bypassait ainsi tout le service qualité ? Les dégâts que ça pourrait faire ? Dans le pire des cas, des gens iraient boire des morceaux de verre. Mais, retour à mes études, parce que le code... avait un effet physique. Bon, à la base, je suis donc informaticien industriel. Et quand j'ai choisi mes études, j'hésitais vraiment entre l'informatique de gestion et l'informatique industrielle. Et dans les cursus que je regardais, la première m'évoquait surtout le COBOL et la COMPTABILITE, et la seconde m'attirait parce que je pouvais voir ce que je programmais. On travaillait sur des automates, notamment du SAIA, de l'ALEN BRADLEY, du SIEMENS, on faisait du GRAFCET, de l'électronique, du C, de l'assembleur. et de la programmation des microcontrôleurs. On avait aussi du PROLOG. Oui, on abordait déjà l'intelligence artificielle, bien avant qu'un chatbot ne te propose de refaire ta stratégie d'entreprise entre deux recettes de cuisine. Mais surtout, on apprenait à penser avec des contraintes physiques et temporelles. Un résultat correct qui arrive trop tard peut devenir un problème. Une jolie boucle de programme ne vaut pas grand chose si elle ne respecte pas le rythme du procédé. Et puis... Il y a eu ce robot au labo. Et puis aussi longtemps, beaucoup d'environnements industriels ont été moins connectés aux réseaux de gestion et à Internet qu'aujourd'hui. Ça ne les rendait pas invulnérables. Un intervenant, un ordinateur de maintenance ou un support amovible pouvaient créer déjà un passage en fait. Mais les possibilités de connexion se sont multipliées. On veut surveiller à distance, anticiper une panne, comparer la production de plusieurs sites. Faire intervenir le fournisseur sans attente qu'il prenne sa voiture, ce sont des vrais bénéfices. Seulement, chaque nouveau lien pose une question. Qui peut passer par là ? Et pour faire quoi ? Tu peux aussi entendre parler de cloud, d'edge ou de fog computing. Le fog, le brouillard, c'est pas simplement le nouveau nom du cloud dans l'industrie. L'idée en fait est de répartir certains traitements plus près des équipements, plutôt que de tout envoyer vers un centre distant. Mais je vais pas te laisser dans le brouillard pendant 10 minutes, ni dans le coma d'ailleurs. Le sujet qui nous intéresse c'est la maîtrise des échanges entre ces différentes couches. Une vieille faiblesse jusque là difficile à atteindre, peut devenir beaucoup plus exploitable quand on ajoute un chemin d'accès. L'équipement n'a pas forcément changé. Son exposition, oui. Et une consigne, ce n'est pas un détail. Je te prends un exemple simple de régulation. En boucle ouverte, tu commandes une action sans utiliser une mesure de son résultat pour la corriger. Tu fais fonctionner un chauffage pendant un temps donné. En boucle fermée, tu mesures la température, tu la compares à une consigne, puis le système ajuste son action. La boucle corrige l'écart sans non-conformité, puisque c'est la valeur que tu lui as rentrée. Mais encore faut-il que la consigne à la mesure soit fiable. Imagine qu'un attaquant obtienne le droit de modifier une consigne de température. Qui a dit des frigos ? Sortez, monsieur ! Ou que cet attaquant falsifie la mesure affichée à l'opérateur. Le procédé peut sortir de sa plage normale, ou l'équipe peut prendre une décision sur la base d'une information fausse. Ça ne veut pas dire qu'un simple clic permet de faire... Tout et n'importe quoi. Il existe des limites physiques, des alarmes, et parfois des protections indépendantes. Justement, il faut savoir lesquelles, et vérifier ce qu'elles protègent réellement. Pour une chambre froide, la question n'est pas seulement de remettre le logiciel en route. Il faut aussi déterminer ce qu'il est advenu des produits pendant l'incident. Perte sèche, quoi. Tu peux restaurer une confique. Tu ne treccert pas une marchandise avec une sauvegarde. Et t'imagines ? Si c'est ton fournisseur avec qui tu travailles depuis 20 ans, qui lui n'est pas NIS2, il sait même pas c'est quoi. Et qui lui subit une supply chain attack. Ouais, je sais. Ça n'arrive qu'entre les états, les grandes nations, et dans le domaine militaire. Et je reviens vers une de mes anciennes missions, tiens, quand j'étais encore SYSADMIN et encore employé. Où, je me rappelle que je surveillais la température des CPU de mes serveurs. En fait... j'avais un script dans un scheduler qui m'envoyait des messages au-delà d'un certain seuil. Et ça envoyait ça vers ma mailbox Gmail. Je sais, c'est pas pro. Mais on n'avait ni laptop, ni télétravail à l'époque, ni garde. Les canicules étaient moins fréquentes. Internet était quand même présent, par contre. Mais ce long week-end-là, heureusement que mon script tournait. Car canicule, pseudo-clim, panne dans la salle informatique. C'était pas un DC. et la température était à 34°C dans la salle machine. Tous les CPU ont alors chopé en moyenne 12°C. Décidément, 12°C, c'est une numérologie ou quoi ? Les CPU avaient dépassé le seuil de consigne que j'avais fixé, et j'ai été notifié. Quand ils arrivaient à un autre seuil plus haut, les serveurs Sun Microsystems de l'époque, les coupaient net, shutdown, pour protéger le hardware. J'ai ensuite notifié le concierge du bâtiment pour qu'il aille voir dans la salle et fasse quelque chose. Ah oui, j'étais pas censé faire ça. J'étais pas de garde. Tu jugeras qui de moi ou de l'employeur n'était pas pro. Mais cette température de salle, de couloir dans un DC, de moteur... N'oublie pas les frigos ! Ça va, je pense qu'on a compris, là. Cette température de salle, donc... Cette température, c'est l'OT, quelque part. Il y a une régulation, des microcontrôleurs... Bon, j'étais pas de garde, ça n'existait pas. Et si j'avais aussi reçu un email à 3h du matin, je ne l'aurais pas vu. Mais ceci te montre un truc. Il faut parfois mettre en place plusieurs contrôles pour réaliser un objectif. Je te renvoie à mon podcast numéro 44, tiens, sur les badges. C'est le même principe, ce qui représente plus ou moins un delta de 50°. Ah, pardon, 50 épisodes, c'est pas fait exprès. Entre notre valeur de consigne d'aujourd'hui et celle des lecteurs de badges. L'autre, avec ses frigos, il va finir par me mettre une idée en tête pour cet épisode. Et là, tu peux, par exemple, placer des contrôles automatiques, manuels, donc humains, techniques, hybrides. Tout dépend de ce que tu veux protéger, en fait. Et de si quelqu'un dort à 3h du matin ou pas. Et oui, tout ça à un cout. Et là, je te renvoie à une BIA, un Business Impact Analysis, qui te permettra très probablement de justifier le choix de tes contrôles. Ça n'empêchera pas les attaques. mais ton dwelling time sera réduit. Dwelling time. Question d'examen, tiens. C'est le temps pendant lequel un pirate informatique reste et passe inaperçu dans un réseau infiltré. De l'attaque initiale jusqu'à sa détection. Ou, de manière plus générale, le temps entre l'occurrence de l'incident et sa détection. Mais revenons sur ma visite à Chimay et son embouteillage. Les bouteilles, les contrôles, les étiquettes sur les bouteilles, les casiers, la palétisation avec un robot. Des équipements qui enchaînent des opérations avec des techniciens et des ingénieurs autour pour faire fonctionner l'ensemble. Je casse un peu le mythe marketing de « c'est géré par des moines » . Mais ce qui m'avait vraiment marqué, et nous sommes alors en 98, c'était cette coordination entre les machines et les personnes. Maintenant, prenons un scénario hypothétique. Sans l'attribuer à cette entreprise, que se passerait-il si un contrôle automatisé de qualité était neutralisé ? Est-ce qu'un autre contrôle détecterait le problème ? Est-ce que la production s'arrêterait ? Ou est-ce qu'on produirait de la merde ? Saurait-on retrouver les lots concernés et les rappeler ? Voilà des questions de cybersécurité qui rejoignent la qualité, la traçabilité et la sécurité des consommateurs. Et sans être exhaustif, c'est la même chose dans certains procédés thermiques ou continus, un arrêt brutal peut endommager l'installation ou rendre le redémarrage long et complexe. Le scénario dépend du procédé. On ne peut pas appliquer la même recette à tous les fours et à toutes les usines. Le fameux « on éteint et on rallume » de l'IT, mais là, tu perds tes traces si tu fais ça. Eh bien, ce fameux « ok, on démarre » mérite donc une petite réunion avant d'appuyer sur le bouton. Et on arrive à un sujet que tu connais. Si tu es un fervent coma breaker et que tu écoutes régulièrement le podcast, j'ai nommé les fournisseurs. Tu peux avoir fait beaucoup d'efforts chez toi, Si ton prestataire possède un accès de maintenance, sa sécurité entre aussi dans ton équation. Oui, mais on travaille avec lui depuis 20 ans. Très bien, mais son compte est-il nominatif ? Son accès reste-t-il ouvert en permanence ? Qu'il valide ? Peut-on le retirer rapidement ? Et sait-on ce qu'il a fait ? Ce ne sont pas des accusations contre ton prestataire, ce sont des questions sur une relation de confiance qui donne accès à un système critique. Il faut donc distinguer les chemins possibles. Un compte de maintenance compromis, une mise à jour altérée, ou un fournisseur indisponible ne produisent pas exactement le même problème. Mais chacun peut affecter ton activité. Et si ce fournisseur ne répond plus pendant trois jours, comment fais-tu ? Là, on rejoint le BIA, le Business Impact Analysis, sur tes activités. Il aide à comprendre les conséquences d'une interruption, les dépendances et les priorités de reprise. Il ne prouve pas à lui seul que ton fournisseur est mature, ou que ton code dégradé, ou que ton mode dégradé, pardon, fonctionne. Pour ça, il faut des vérifications et des exercices. Alors peut-on continuer à produire ? A quel rythme ? Avec quel contrôle de qualité ? Et à partir de quand faut-il s'arrêter ? Un mode dégradé doit rester un mode maîtrisé. J'ai donc commencé à 12 ans avec un Commodore 64, puis j'ai appris à écrire des programmes qui faisaient bouger des machines. Je n'aurais jamais pensé que tout cela m'amène à parler de... OT dans un épisode de podcast. Aujourd'hui, je regarde ces mêmes sujets à travers la gouvernance, les risques et la cyber. Je ne vais pas te vendre 30 ans de pratiques continues de l'OT, c'est pas mon parcours. Mais ma formation m'a donné des bases et des souvenirs très concrets. Et pour parler des installations d'aujourd'hui, je veux aussi donner la parole à celles et ceux qui la conçoivent, les exploitent et les sécurisent. Il y aura donc très certainement d'autres épisodes OT en 2027 dans Compliance without coma. puisque c'est l'un des nouveaux thèmes que je vous réserve. Et aussi avec NIS2, les accès fournisseurs et les attaques par la chaîne d'approvisionnement, on n'a pas fini d'en entendre parler. Si tu travailles dans l'OT, la maintenance, la production ou la sûreté industrielle, viens m'en parler. C'est aussi avec vos expériences qu'on va construire la suite. Abonne-toi, partage cet épisode avec quelqu'un qui travaille de l'autre côté de cette porte et rejoins les Coma Breakers. Parce qu'un ordinateur qui plante, c'est déjà pénible. Une machine qui continue à tourner avec les mauvaises instructions, la mauvaise valeur de consigne, ou un problème d'intégrité, ça c'est une autre histoire. Et puis, je ne sais pas si je dois me réjouir, en fait, ou non, de ce genre d'épisode. Je ne suis pas là pour tirer sur des ambulances. C'est aussi ma ligne éditoriale. Pas de putaclic. Est-ce que cet épisode te sera utile dans 5 ans ou 10 ans ? Très sincèrement, je pense que oui. C'est ma stratégie Evergreen. C'est aussi pour ça que je ne réagis pas à chaud sur l'actu. Je laisse décanter. Et j'essaye. mais vraiment en toute modestie, d'apporter ma pierre à l'édifice. En te gardant éveillé, ça, il y a plusieurs sens, et tu le sais, en te faisant réfléchir, peut-être que cela pourra t'arriver, ou arriver à un de tes clients. Et si tu veux vraiment soutenir le podcast, prends 30 secondes de ton temps si tu me découvres, laisse 5 étoiles sur Spotify ou Apple Podcast, et va jeter un oeil à la version YouTube. La narration y est différente. Si tu vois passer quelque chose dans ton fil LinkedIn, n'hésite pas à partager, à commenter. D'ailleurs, on a créé une page LinkedIn dédiée au média. Car oui, Compliance without coma n'est pas qu'un podcast. Merci d'être toujours plus nombreux à rejoindre les Coma Breakers. On se retrouve vendredi prochain, déjà, pour un nouvel épisode de Compliance Without Coma. D'ici là, prends soin de toi, Coma Breaker. Qui a dit les frigos ? Sortez, monsieur !
