Dans l’industrie, la cybersécurité a longtemps été considérée comme relevant de l’informatique de bureau. Pare-feu, antivirus, mots de passe, sauvegardes — tandis que le système de production ou énergétique fonctionnait à part, selon sa propre logique technique.
Avec la convergence IT/OT, cette ligne de séparation a disparu. Automates programmables (PLC), onduleurs, gestion technique du bâtiment, SCADA, passerelles et connexions de télémaintenance peuvent aujourd’hui faire partie du même espace de risque numérique. Les conséquences, elles, restent physiques : production à l’arrêt, régulation défaillante, coupure de l’alimentation énergétique ou service indisponible.
C’est pourquoi la NIS2 élève la gestion du risque cyber au niveau de la direction et de l’organisation. L’IEC 62443 apporte, de son côté, une approche de la sécurité industrielle et un référentiel d’exigences qui permettent d’organiser l’environnement OT également sur le plan technique.
La NIS2 n’est pas une liste d’achats technologiques
La directive NIS2 de l’Union européenne a instauré un cadre de cybersécurité plus harmonisé pour 18 secteurs critiques. Les moyennes et grandes entreprises relevant de son champ d’application doivent mettre en place des mesures appropriées de gestion des risques ainsi que des processus de notification des incidents. La directive souligne en outre explicitement la responsabilité des organes de direction.
C’est un changement important : la cybersécurité ne peut pas être déléguée sans limite à un administrateur système ou à un prestataire externe. La direction doit comprendre et maîtriser les dépendances numériques qui menacent le fonctionnement essentiel.
La NIS2 ne dit pas quel pare-feu de quel fabricant il faut acheter. Elle attend un fonctionnement fondé sur les risques, qui couvre notamment :
- la gestion des incidents ;
- la continuité des activités et la reprise ;
- la sécurité de la chaîne d’approvisionnement ;
- la gestion des vulnérabilités ;
- le contrôle d’accès ;
- la cryptographie et la sécurité des communications ;
- la sensibilisation à la sécurité ;
- l’évaluation de l’efficacité des mesures.
La question de savoir si une organisation donnée relève effectivement du champ d’application, et quelles exigences nationales lui sont applicables (en Hongrie, la directive NIS2 est transposée par la loi XXIII de 2023), doit être tranchée au cas par cas, en fonction du secteur, de la taille, du service fourni et du droit national applicable. La maîtrise des risques techniques reste néanmoins dans l’intérêt de l’entreprise, même si celle-ci n’est finalement pas assujettie.
Pourquoi le risque OT est-il particulier ?
Les systèmes OT ont une longue durée de vie. Il n’est pas rare de rencontrer des équipements de dix ou vingt ans, des systèmes d’exploitation qui ne sont plus pris en charge ou des automates difficiles à mettre à jour sans arrêter la production.
De plus, dans l’OT :
- la disponibilité et la sûreté physique priment ;
- les modifications doivent être testées en raison du risque pour le procédé ;
- de nombreux équipements n’ont jamais été conçus pour un environnement réseau hostile ;
- l’accès à distance du fabricant ou du mainteneur est fréquent ;
- l’inventaire des équipements est souvent incomplet ;
- la responsabilité est partagée entre l’IT, l’automatisme, l’exploitation et les fournisseurs.
C’est pourquoi il ne suffit pas de recopier une politique de sécurité IT classique.
Le rôle de l’IEC 62443
La série de normes ISA/IEC 62443 traite la cybersécurité des systèmes d’automatisation et de contrôle industriels sur l’ensemble de leur cycle de vie. Elle ne vise pas uniquement l’exploitant : elle définit également des exigences et des rôles pour le fabricant d’équipements, l’intégrateur de systèmes et le propriétaire de l’actif (asset owner).
L’un des piliers de cette approche est la définition de zones fondées sur les risques et de liaisons de communication maîtrisées entre ces zones (conduits).
Une zone peut regrouper des équipements présentant des risques et des besoins de sécurité similaires. Les flux de données entre zones ne peuvent emprunter que des chemins et des protocoles définis, selon des règles établies.
Cette façon de penser est bien plus précise que « nous avons un pare-feu côté Internet ». Une attaque ou une panne peut en effet aussi partir de l’intérieur : d’une connexion de télémaintenance, de l’ordinateur portable d’un fournisseur ou d’un système IT compromis.
Première tâche ingrate : l’inventaire des équipements et des liaisons de données
On ne peut pas protéger ce dont on ignore l’existence.
La première étape concrète de la sécurité OT n’est donc généralement pas l’installation d’un nouveau produit, mais la cartographie de l’environnement réel :
- quels automates, IHM, compteurs, onduleurs et passerelles sont en service ;
- avec quelle version de firmware et de logiciel ;
- sur quel réseau ils sont accessibles ;
- avec qui et par quel protocole ils communiquent ;
- qui peut y accéder sur place et à distance ;
- quel processus métier ou physique en dépend ;
- ce qui se passe en cas de panne ou de compromission.
L’inventaire ne doit pas rester un simple tableau Excel figé. Il est utile de rattacher aussi les modifications, les responsabilités, les événements et les documents à un système traçable.
L’accès à distance, un point faible typique
Les systèmes industriels nécessitent souvent l’assistance du fabricant ou de l’intégrateur. Le problème n’est pas l’accès à distance en soi, mais l’accès non contrôlé, permanent et direct.
Une solution défendable doit préciser :
- qui peut initier la connexion ;
- si une authentification multifacteur est requise ;
- quel système précis est accessible ;
- dans quelle plage horaire ;
- si une validation locale ou de la direction est nécessaire ;
- si la session peut être journalisée ;
- comment l’autorisation peut être révoquée ;
- ce qui se passe à la fin du contrat avec le fournisseur.
Une solution du type « AnyDesk est installé sur le poste, au cas où » est pratique, mais ce n’est pas une architecture de sécurité.
La chaîne d’approvisionnement fait partie de l’OT
Dans un système industriel, la sécurité ne dépend pas uniquement de l’équipe interne. Le fabricant du matériel, le fournisseur du firmware, l’intégrateur, l’opérateur de télécommunications et la plateforme cloud peuvent tous faire partie de la chaîne de risque.
Le cahier des charges technique et les contrats doivent donc aussi préciser, par exemple :
- la durée du support et des mises à jour ;
- les modalités de signalement des vulnérabilités ;
- les exigences en matière d’accès et de journalisation ;
- les informations sur les composants et les versions ;
- la coopération pendant un incident ;
- la restitution des données et des configurations.
C’est ici que la logique de chaîne d’approvisionnement de la NIS2 rejoint l’approche de l’IEC 62443 fondée sur le cycle de vie et les rôles.
Une sécurité qui fonctionne plutôt que la seule conformité
Cocher une liste d’audit n’arrête pas, à lui seul, une attaque. Le véritable objectif est que l’organisation connaisse ses processus critiques, réduise sa surface d’attaque, détecte les anomalies, en limite la propagation et soit en mesure de rétablir le fonctionnement de manière démontrable.
Dans ce contexte, OrigSmart ne se résume pas à une plateforme de visualisation de données. La gestion conjointe des équipements de terrain, des passerelles, des connexions réseau, des identités, des événements et des processus exécutables aide à transformer les exigences de sécurité en fonctionnement technique.
Dans les projets gérés par OrigSmart, la sécurité doit être conçue comme une composante de l’architecture : connexions segmentées, moindre privilège, événements journalisés, accès à distance contrôlé, fonctionnement local de repli et actions traçables.
La NIS2 indique que le risque cyber doit être pris au sérieux à l’échelle de l’organisation. L’IEC 62443 aide à traduire cette exigence dans la réalité technique des systèmes OT.
Parlons de votre projetSources
- Commission européenne – Directive NIS2
- Directive (UE) 2022/2555 du Parlement européen et du Conseil
- ISA/IEC 62443 Series of Standards
- NIST SP 800-82 Rev. 3 – Guide to Operational Technology Security
Remarque : cet article constitue une information professionnelle générale et non un conseil juridique ou en matière de conformité.