Et si l’on rapporte ce scénario au monde de l’industrie, la situation serait encore plus cauchemardesque !
L’Industrie 4.0 repose sur une intégration étroite entre les systèmes informatiques (IT) et les systèmes opérationnels (OT). Les logiciels de planification des ressources d’entreprise (ERP) ont évolué en systèmes de gestion de la chaîne d’approvisionnement (SCM), dépassant ainsi les frontières, séparant le développement et la production des composants, et fournissant les produits finis, tout en coordonnant les règlements et surveillant les stocks à travers le monde.
Chacune de ces synergies est au service de la performance de l’activité :
Optimiser les ressources sur diverses sources ;
Minimiser les dépenses de fabrication, d’expédition et d’entreposage dans toutes les régions ;
Préserver la continuité des opérations en diversifiant les fournisseurs ;
Maximiser les ventes parmi plusieurs canaux de commercialisation au travers de la logistique associée.
La chaîne d’approvisionnement comprend non seulement les matières premières pour la fabrication, mais également les fournisseurs tiers, le personnel externe pour les fonctions commerciales non essentielles, des logiciels open source pour optimiser les coûts de développement et des sous- traitants pour effectuer des tâches de conception, d’assemblage, de test et de distribution spécialisées.
Or dans cette architecture aussi précise que sophistiquée, chaque élément de la chaîne d’approvisionnement représente une surface d’attaque potentielle…
Le développement de logiciels est depuis longtemps le fruit d’un travail d’équipe. Depuis les années 1990, les entreprises ne sont plus à la recherche du développeur solitaire au talent exceptionnel dont le code serait sans défaut, mais non documenté et impossible à maintenir. Désormais, les conceptions logicielles doivent être claires pour tous et les tests nécessitent une étroite collaboration entre les architectes, les concepteurs, les développeurs et la production. Les équipes identifient les besoins de l’entreprise, puis élaborent une solution à partir de composants provenant de bibliothèques partagées publiquement. Ces dernières peuvent contenir des dépendances supplémentaires par rapport à d’autres portions de code tiers de provenance inconnue ou non contrôlée. Les tests simplifiés reposent sur la qualité des bibliothèques partagées, mais les routines de ces dernières peuvent avoir des défauts latents (ou intentionnellement cachés) qui ne prennent vie que dans un environnement de production vulnérable. Et dans ces cas de figure, la question qui s’impose est : qui teste le logiciel de développement ? L’étendue des vulnérabilités que l’on y recense est impressionnante.
Dans le cadre des opérations de fabrication, la convergence de l’IT et de l’OT expose des surfaces d’attaque supplémentaires. Véritable révolution dans le domaine de l’industrie, les robots industriels programmés pour effectuer des tâches exigeantes en sont un bon exemple.
Avant les robots industriels programmables, les centres de production s’appuyaient sur l’Homme et des machines non programmables, qui devaient être révisées à chaque modification de produits. Les chaînes de production automobiles fournissaient un style de carrosserie unique sur plusieurs années. Les robots programmables ont changé la donne ! Ils sont désormais en mesure de produire différentes configurations de matériaux sans temps d’arrêt. Ils sont utilisés pour de multiples fonctions : dans la fabrication, l’entreposage, les centres de distribution, l’agriculture, l’exploitation minière et bientôt pour guider les véhicules de livraison. Avec eux, la chaîne d’approvisionnement devient automatisée.
Cependant, elle n’en est pas sécurisée pour autant. Les protocoles dont dépendent les robots industriels supposent que l’environnement de production ait été isolé. Un contrôleur régissait les machines à partir d’un seul endroit. La connexion entre le contrôleur et les robots gérés étant câblée, il n’était pas nécessaire d’identifier l’opérateur ou de vérifier les messages. Chaque appareil supposait que toutes ses connexions étaient vérifiées et donc fiables. Même les systèmes de sécurité supposaient que le réseau était intègre et sûr. Aucun protocole ne prévoyait de contrôles de sécurité ou de confidentialité. Par la suite, l’industrie 4.0 a adopté les communications sans fil.
Adopter les communications sans fil a permis à l’industrie 4.0 d’économiser les coûts de pose de câbles dans l’usine, mais a également ouvert ces réseaux aux attaques. Toutes les attaques possibles contre les robots industriels se produisent depuis lors. Les pirates falsifient des commandes, altèrent les spécifications, modifient les alertes ou suppriment les messages d’erreur, modifient les statistiques et réécrivent les fichiers journaux. Les conséquences peuvent être vastes, mais quasiment indétectables.
Une étude publiée récemment analyse les nouveaux vecteurs d’attaques auxquelles sont confrontés les robots d’aujourd’hui , ainsi que leurs conséquences potentielles 1 . Parmi les systèmes et machines qui pourraient être exploités, figurent les logiciels de pilotage de la production (MES), les interfaces homme-machine (HMI) et les dispositifs IIoT. Ce sont des maillons faibles de la chaîne de sécurité qui pourraient être compromis de manière à altérer les biens produits, à provoquer des dysfonctionnements ou à modifier les flux de travail pour fabriquer des produits défectueux.
Si les robots sont aujourd’hui un recours privilégié par de nombreuses industries pour prendre le relais, notamment face à la pandémie, chaque partie prenante (propriétaires et opérateurs) devraient tenir compte des avertissements de cette étude et envisager la mise en place des préconisations suggérées pour améliorer la sécurité des environnements de production connectés. Il en va de l’avenir de l’Industrie 4.0 et, en matière de sécurité, prévenir c’est guérir !