La sécurité de l’IoT industriel consiste à protéger les capteurs, les contrôleurs, les passerelles et les plateformes cloud qui relient les équipements physiques aux réseaux, pour que les mesures soient fiables et que personne ne puisse modifier un procédé physique sans autorisation. Elle concerne l’atelier et le système de contrôle-commande tout autant que les services cloud vers lesquels transitent désormais les données de l’usine.

Connecter des équipements au cloud en vaut la peine, mais cela change aussi qui peut atteindre ces équipements. Un responsable OT ou IT qui prépare cette connexion a besoin d’une vision claire de ce que font les attaquants dans les environnements industriels, des faiblesses qu’ils exploitent et des mesures qui font la différence. Cet article passe en revue chacun de ces points, des réseaux SCADA jusqu’à la plateforme cloud.

L’essentiel

  • Les incidents industriels les plus fréquents commencent dans l’IT, par hameçonnage, vol d’identifiants d’accès à distance ou rançongiciel, et gagnent la production parce que les réseaux ne sont pas séparés.
  • Les systèmes SCADA sont vulnérables à cause de protocoles anciens sans authentification, de réseaux à plat, de comptes partagés et de logiciels impossibles à corriger rapidement.
  • Sécuriser un système SCADA commence par un inventaire des actifs et la segmentation du réseau, puis passe par la maîtrise des accès à distance, des comptes et des sauvegardes.
  • L’IEC 62443 et le NIST SP 800-82 sont les principaux référentiels ; côté cloud, ce qui compte le plus, ce sont des accès individuels, des clés au périmètre limité et un historique des accès.

Quelles sont les principales menaces pour la sécurité de l’IoT industriel ?

Les incidents industriels attirent l’attention quand ils sont spectaculaires, mais les menaces qui causent le plus de dégâts sont banales. Chacune des menaces pour la sécurité de l’IoT industriel présentées ci-dessous a un précédent réel.

Le rançongiciel qui démarre dans l’IT est le problème le plus fréquent. En mai 2021, un rançongiciel a frappé les systèmes de gestion de Colonial Pipeline aux États-Unis. Les systèmes de contrôle de l’oléoduc n’ont pas été signalés comme chiffrés, et pourtant l’entreprise a arrêté l’exploitation de l’oléoduc pendant plusieurs jours par précaution, car elle ne pouvait pas être sûre que l’attaque ne se propagerait pas et ne pouvait pas facturer normalement. Des pénuries de carburant ont suivi sur la côte Est des États-Unis, le tout à cause d’un incident dans l’informatique de bureau.

Le vol ou la faiblesse des accès à distance suit de près. Les fournisseurs et les intégrateurs ont souvent besoin d’atteindre les équipements, et un outil de bureau à distance ou un compte VPN au mot de passe partagé devient aussi, pour un attaquant, la porte d’entrée la plus facile.

Les identifiants par défaut des appareils connectés sont une autre porte d’entrée courante. En 2016, le botnet Mirai a pris le contrôle de centaines de milliers de caméras, de routeurs et d’autres appareils IoT simplement en essayant les noms d’utilisateur et mots de passe d’usine, puis s’en est servi pour des attaques massives par déni de service. Les passerelles et capteurs industriels livrés avec des identifiants par défaut présentent le même risque.

Les attaques ciblées contre les systèmes de contrôle-commande sont plus rares et plus graves. Stuxnet, découvert en 2010, manipulait des automates Siemens pour endommager des centrifugeuses d’enrichissement d’uranium en Iran tout en affichant des valeurs normales aux opérateurs. Triton, découvert en 2017 dans une usine pétrochimique en Arabie saoudite, visait un système instrumenté de sécurité Triconex de Schneider Electric, la couche censée mettre un procédé à l’arrêt en toute sécurité.

Enfin, il y a l’initié et l’accident : un sous-traitant disposant de plus d’accès que nécessaire, ou un ingénieur qui branche un ordinateur portable sur le réseau de contrôle-commande pour « juste vérifier quelque chose ».

Les appareils connectés ajoutent une catégorie de plus : l’accès physique. Une passerelle montée dans une armoire extérieure non verrouillée, ou un capteur dont le port de configuration est accessible avec un tournevis, peut être réinitialisé, remplacé ou utilisé comme porte d’entrée sur le réseau. Les sites distants comme les stations de pompage et les postes électriques sont rarement visités : une manipulation peut donc y passer inaperçue pendant des semaines, à moins que des contacts de porte ou des interrupteurs d’armoire ne la signalent.

Failles de sécurité courantes des systèmes SCADA

La sécurité des systèmes SCADA est difficile pour des raisons structurelles, pas parce que les exploitants sont négligents. Les mêmes faiblesses reviennent d’un secteur à l’autre.

Les protocoles sans authentification sont la faiblesse la plus ancienne. Le Modbus classique et le DNP3 d’origine ont été conçus pour des réseaux série fermés ; tout appareil capable d’atteindre un contrôleur peut lui envoyer une commande valide. Des variantes sécurisées existent, mais les équipements anciens ne peuvent souvent pas les utiliser.

Les réseaux à plat aggravent la situation. Dans de nombreuses usines, le réseau bureautique, les serveurs SCADA et les automates se trouvent sur un même réseau sans pare-feu entre eux : un seul ordinateur portable infecté peut tout atteindre.

Les comptes partagés sur les IHM et les postes d’ingénierie font que chaque opérateur se connecte en tant qu’« opérateur », ce qui rend impossible de savoir qui a fait quoi.

Les correctifs arrivent lentement. Les serveurs SCADA tournent souvent sur des systèmes d’exploitation anciens parce que le logiciel SCADA ou un pilote n’est certifié que pour cette version, et une usine ne peut pas redémarrer un procédé en marche tous les mois.

L’exposition à Internet est un constat récurrent. Les moteurs de recherche qui scannent Internet, comme Shodan, trouvent régulièrement des IHM, des automates et des passerelles d’accès à distance directement accessibles depuis n’importe où.

Les supports amovibles et les ordinateurs portables d’ingénierie sont une voie plus discrète. Les postes d’ingénierie contiennent le logiciel capable de reprogrammer chaque contrôleur de l’usine, et ce sont souvent les machines auxquelles les sous-traitants se connectent avec leurs propres ordinateurs portables et clés USB. On pense que Stuxnet a atteint son réseau cible isolé par des supports amovibles, et c’est pourquoi de nombreuses usines analysent désormais les périphériques USB sur une borne avant de les autoriser à approcher un système de contrôle-commande.

L’attaque de décembre 2015 contre des distributeurs d’électricité ukrainiens a exploité plusieurs de ces faiblesses à la fois. Les attaquants sont entrés par des e-mails d’hameçonnage sur les réseaux bureautiques, ont récupéré des identifiants, se sont déplacés vers l’environnement de contrôle-commande et ont ouvert des disjoncteurs à distance, privant d’électricité environ 225 000 clients pendant plusieurs heures.

Comment sécuriser un système SCADA ?

Aucun produit ne sécurise à lui seul un système SCADA. Les étapes ci-dessous suivent l’ordre que recommandent la plupart des référentiels, car chacune facilite la suivante.

  1. Établir un inventaire des actifs. Listez chaque contrôleur, serveur, poste de travail, passerelle et connexion réseau, avec les versions de firmware.
  2. Segmenter le réseau. Séparez le réseau de gestion du réseau de contrôle-commande, avec entre les deux une DMZ (une zone tampon) pour tout ce dont les deux côtés ont besoin, comme une copie de l’historien. N’autorisez que le trafic nécessaire, dans le sens où il est nécessaire.
  3. Supprimer l’exposition directe à Internet. Rien sur le réseau de contrôle-commande ne doit être accessible depuis Internet. Les données envoyées vers des services cloud doivent sortir par des connexions sortantes depuis une passerelle située dans la DMZ.
  4. Maîtriser les accès à distance. Utilisez un point d’entrée unique et géré, avec authentification multifacteur, des comptes individuels pour les fournisseurs et un accès activé uniquement en cas de besoin.
  5. Donner à chacun son propre compte. Remplacez les identifiants partagés par des comptes personnels et le moindre privilège nécessaire à chaque fonction.
  6. Corriger quand c’est possible, compenser quand ça ne l’est pas. Testez les mises à jour sur un système de rechange ; quand une machine ne peut pas être corrigée, restreignez ce qui peut communiquer avec elle.
  7. Surveiller le réseau. Les outils de détection d’intrusion industriels apprennent le trafic normal entre contrôleurs et signalent les nouveaux appareils ou les commandes inhabituelles.
  8. Sauvegarder et s’entraîner à restaurer. Conservez des copies hors ligne des programmes d’automates, des configurations SCADA et des images de serveurs, et testez leur restauration.

La cybersécurité des systèmes SCADA dépend aussi des personnes. Les opérateurs et les ingénieurs doivent savoir comment signaler un e-mail suspect ou une clé USB trouvée sur le parking, et le plan de réponse aux incidents doit préciser qui décide de maintenir ou non le procédé en marche.

Avec un budget limité, l’ordre compte davantage que l’exhaustivité. Une usine qui dispose d’un inventaire et d’un pare-feu entre les réseaux bureautique et de contrôle-commande, qui n’est pas directement exposée à Internet et qui utilise des comptes personnels avec un accès à distance multifacteur a supprimé les chemins empruntés dans la plupart des incidents décrits plus haut. La surveillance du réseau et les niveaux de sécurité formels valent la peine d’être ajoutés ensuite, pas à la place.

Normes de sécurité de l’IoT industriel

Deux référentiels dominent les normes de sécurité de l’IoT industriel. L’IEC 62443 est une série de normes internationales pour la sécurisation des systèmes d’automatisation et de contrôle industriels. Elle introduit les zones (des groupes d’actifs ayant les mêmes besoins de sécurité) et les conduits (les connexions contrôlées entre elles), définit des niveaux de sécurité de 1 à 4 face à des attaquants de plus en plus compétents, et comporte des parties distinctes pour les propriétaires d’actifs, les intégrateurs de systèmes et les fournisseurs de produits.

Le NIST SP 800-82, publié par le National Institute of Standards and Technology américain, est un guide de sécurité des technologies opérationnelles. La révision 3, parue en septembre 2023, a élargi son périmètre des systèmes de contrôle industriels à l’OT en général et met ses recommandations en correspondance avec le NIST Cybersecurity Framework.

La réglementation évolue elle aussi. Dans l’Union européenne, la directive NIS2 couvre l’énergie, l’eau, l’industrie manufacturière et d’autres secteurs, les États membres étant tenus de l’appliquer à partir d’octobre 2024. Le Cyber Resilience Act de l’UE ajoute des exigences de sécurité pour les produits comportant des éléments numériques, la plupart des obligations s’appliquant à partir de décembre 2027, ce qui concernera les capteurs et passerelles connectés vendus dans l’UE.

Il est aussi utile de savoir comment ces référentiels s’articulent avec l’ISO/IEC 27001, la norme largement utilisée pour les systèmes de management de la sécurité de l’information. L’ISO/IEC 27001 décrit la façon dont une organisation gère le risque de sécurité en général, tandis que l’IEC 62443 ajoute les exigences techniques et organisationnelles propres aux systèmes de contrôle-commande. De nombreuses entreprises industrielles utilisent les deux : la 27001 pour l’entreprise et son informatique, la 62443 pour les usines.

Bonnes pratiques de sécurité de l’IoT industriel

Le côté cloud d’une connexion IoT industrielle demande la même discipline que le côté usine. Quelques bonnes pratiques de sécurité de l’IoT industriel valent quelle que soit la plateforme. Les données doivent quitter l’usine par des connexions sortantes et chiffrées, initiées par la passerelle, pour qu’aucun port entrant ne soit ouvert. Les réseaux de capteurs sans fil apportent leur propre protection : LoRaWAN, par exemple, chiffre chaque message avec des clés de session AES-128, ce qui n’aide que si les clés utilisées pour provisionner les capteurs sont manipulées avec soin. Chaque passerelle et chaque connexion a besoin de ses propres identifiants plutôt que d’identifiants partagés entre sites. Ces clés de provisionnement doivent être stockées chiffrées et visibles uniquement par les personnes qui en ont besoin. Le firmware des passerelles mérite la même attention en matière de correctifs que celui d’un automate, car la passerelle se trouve exactement à la frontière entre l’usine et Internet.

Côté plateforme, les contrôles d’accès de Kilo fonctionnent par personne et par page, avec les niveaux Modifier, Voir ou Aucun accès : un sous-traitant peut ainsi consulter des tableaux de bord sans pouvoir toucher aux règles ni aux connecteurs. Les clés API sont limitées par domaine, avec des permissions de lecture et d’écriture séparées, peuvent porter une date d’expiration, et cessent de fonctionner immédiatement lors de leur rotation. Le Journal d’audit enregistre les invitations, les changements de permissions et les retraits, pour que vous puissiez montrer qui avait accès, et à quel moment.

FAQ sur la sécurité de l’IoT industriel

En quoi la sécurité de l’IoT industriel diffère-t-elle de la sécurité informatique ?

En informatique, la confidentialité passe généralement en premier ; dans les systèmes industriels, ce sont la disponibilité et la sûreté, car arrêter un procédé peut être dangereux ou coûteux. Les équipements industriels restent aussi souvent en service 10 à 15 ans, parfois plus de 20, bien plus longtemps que l’informatique de bureau : la sécurité doit donc composer avec des appareils qu’on ne peut pas remplacer rapidement.

Qui est responsable de la cybersécurité d’un système SCADA ?

Le propriétaire de l’actif, c’est-à-dire l’organisation qui exploite l’usine, en est responsable. L’IEC 62443 répartit le travail : les fournisseurs de produits conçoivent des appareils sûrs, les intégrateurs les configurent de manière sécurisée, et le propriétaire de l’actif exploite et maintient le système de manière sécurisée tout au long de son cycle de vie.

Qu’est-ce que le zero trust dans la sécurité de l’IoT industriel ?

Le zero trust est une approche, décrite dans le NIST SP 800-207, dans laquelle aucun utilisateur ni appareil n’obtient la confiance du seul fait de sa position sur le réseau. Chaque requête est authentifiée et autorisée. Dans les usines, on l’applique généralement de façon progressive, en commençant par les accès à distance et la frontière entre IT et OT.

Avant de connecter quoi que ce soit d’une ligne de production, essayez le modèle d’accès sur un signal sans enjeu. Placez un capteur de température dans un local technique de l’usine sur l’offre gratuite de Kilo, qui ne demande aucune coordonnée de paiement, invitez un collègue avec un accès Voir uniquement, et créez une clé API avec un périmètre en lecture et une date d’expiration. Effectuez ensuite la rotation de cette clé et vérifiez qu’un script qui utilise l’ancienne valeur cesse de fonctionner.