On observe une tendance récurrente dans les environnements de production qui mettent en œuvre des programmes de cybersécurité des technologies opérationnelles (OT). L'audit se déroule sans encombre. Les contrôles sont documentés. Tous les critères du référentiel sont cochés. Et pourtant, quelque chose ne va pas sur le terrain : les opérateurs trouvent des solutions de contournement, les temps de réponse se sont allongés, ou une fenêtre de maintenance est devenue plus complexe qu'elle ne devrait l'être.
Le système a été validé. Mais le fonctionnement ne s'est pas amélioré.
Il ne s'agit pas d'un problème d'exécution. C'est un décalage structurel, qui est au cœur même de la conformité en matière de cybersécurité des systèmes OT, et auquel la plupart des cadres de sécurité n'ont jamais été conçus pour remédier.
Des normes telles que la CEI 62443 et des exigences réglementaires comme la directive NIS2 ont été élaborées pour instaurer une cohérence là où elle faisait défaut. Elles définissent les contrôles à mettre en place, la documentation à conserver et les structures de gouvernance à mettre en œuvre. Pour les organisations qui cherchent à rendre des comptes — aux auditeurs, aux autorités de régulation, aux conseils d'administration —, elles remplissent un rôle bien précis.
Mais les cadres de référence répondent à une question précise : les éléments pertinents ont-ils été définis ?
Ils ne répondent pas à la question suivante : que se passera-t-il lorsque cette mise à jour sera déployée sur une chaîne de production qui utilise le même micrologiciel de PLC depuis onze ans ?
Les environnements OT ne sont pas des systèmes homogènes prêts à être sécurisés. Il s'agit d'ensembles d'équipements stratifiés, hétérogènes et souvent mal documentés, dont les interdépendances n'ont pas été cartographiées lors de leur installation et n'ont pas été réexaminées depuis. Les systèmes hérités prédominent. Les temps d'arrêt se traduisent par des coûts de production réels. Et les relations entre les systèmes — qui communique avec quoi, dans quelles conditions, avec quelle tolérance au changement — ne sont souvent comprises que par les personnes qui les exploitent depuis des années.
Les cadres de conformité partent du principe qu'il existe un certain degré de normalisation, ce qui n'est tout simplement pas le cas dans la plupart des environnements de production existants. C'est cette hypothèse qui est à l'origine du fossé.
Un cadre adapté aux besoins de production, destiné aux fabricants qui doivent sécuriser leurs opérations sans les perturber.
Dans la pratique, on lui donne un nom, même s'il apparaît rarement dans les rapports de sécurité : conforme mais instable.
Toutes les mesures de contrôle requises sont en place. Les critères d'audit sont respectés. Sur le papier, le niveau de sécurité semble solide. Et pourtant, l'exploitation de l'usine est plus difficile qu'auparavant. Pas de manière spectaculaire — aucune mesure de contrôle n'a à elle seule entraîné un effondrement — mais sur le plan opérationnel, quelque chose a changé.
Trois situations illustrent ce schéma de manière cohérente.
La segmentation des réseaux OT constitue, à juste titre, un élément de contrôle fondamental dans tout dispositif de sécurité OT digne de ce nom. L'objectif est le confinement : limiter l'ampleur des dégâts en cas d'incident. Mais dans un environnement industriel où certains systèmes communiquent entre des zones que le dispositif définit désormais comme distinctes, une mise en œuvre rigide perturbe les flux existants. Les dérogations manuelles deviennent monnaie courante. Les opérateurs s'adaptent, mais chaque contournement ajoute des frictions et sape la logique de gouvernance que la segmentation était censée garantir.
L'application de correctifs aux systèmes OT devient de plus en plus obligatoire dans le cadre de normes telles que la norme CEI 62443-2-1 et des exigences dérivées de la directive NIS2. Un calendrier est établi, documenté et respecté. Cependant, les systèmes de production dans le secteur manufacturier ne disposent pas de fenêtres de maintenance qui coïncident avec les cycles de publication des fournisseurs. L'application de correctifs dans des environnements en production au mauvais moment entraîne une instabilité — et cette instabilité a souvent des répercussions opérationnelles plus durables que la vulnérabilité qu'elle était censée corriger.
La réduction des privilèges est une bonne pratique en matière de sécurité. Accès basé sur les rôles, sessions limitées dans le temps, architecture du principe du moindre privilège : toutes ces mesures sont justifiables et vérifiables. Mais lorsque les politiques d'accès sont appliquées sans tenir compte de la manière dont les opérateurs et les fournisseurs interagissent réellement avec les systèmes dans des conditions de production réelles, le résultat est prévisible : des comptes partagés apparaissent, les contrôles d'accès sont contournés, et le modèle de gouvernance qui semblait solide sur le papier s'est déjà écarté de la réalité sur le terrain.
Dans chaque cas, les contrôles sont corrects en théorie. Le problème réside dans la mise en œuvre — plus précisément, dans l'absence de validation opérationnelle avant le déploiement.
Ce qui rend la situation particulièrement difficile, c'est que les environnements OT ne réagissent pas de la même manière que les environnements informatiques lorsqu'un changement survient. En informatique, une amélioration de la sécurité s'ajoute généralement aux mesures existantes. Une mesure de contrôle est mise en place, le système s'adapte et la posture de sécurité s'améliore. Il y a certes des conséquences imprévues, mais elles sont généralement maîtrisées et réversibles.
En OT, les moindres changements ont des répercussions. Un flux de communication qui a fonctionné de manière fiable pendant des années repose sur des hypothèses de synchronisation qui ne sont consignées nulle part par écrit. Une règle de segmentation qui semble claire sur un schéma de réseau interfère avec une procédure d'échange de données SCADA héritée que seul un ingénieur du fournisseur comprenait. Une mise à jour de micrologiciel validée en laboratoire se comporte différemment dans une usine qui exécute le même lot de production depuis six jours sans redémarrage.
Ces interdépendances sont bien réelles. Elles ne sont souvent pas documentées. Et les cadres de conformité ne les modélisent pas — car ils en sont incapables. Aucune norme ne peut anticiper la logique opérationnelle spécifique des systèmes d'une installation donnée.
C'est pourquoi la stabilité opérationnelle constitue le principal indicateur de la réussite en matière de sécurité dans les environnements OT, et non les résultats des audits. Un programme de sécurité qui assure la conformité au détriment de la stabilité n'améliore pas la situation de l'organisation face aux risques : il ne fait que les déplacer.
Les programmes de sécurité des technologies opérationnelles (OT) axés sur la conformité qui négligent l'impact opérationnel ont pour conséquence à long terme une forme particulière de dérive organisationnelle.
Les équipes de sécurité veillent au respect de la structure de conformité. Les équipes opérationnelles s'adaptent aux frictions que cela engendre — au niveau local, de manière informelle, sans documentation. Les contrôles sont modifiés au niveau de l'usine. Des solutions de contournement s'intègrent dans le fonctionnement quotidien. La gouvernance et la réalité opérationnelle s'écartent peu à peu l'une de l'autre.
Au bout d'un certain temps, ce qui est consigné dans le cadre de conformité et ce qui se passe réellement sur le terrain sont deux choses bien distinctes. L'audit est toujours validé, car les contrôles documentés existent toujours. Mais la posture de sécurité réelle de l'organisation, celle qui compte lorsque quelque chose tourne mal, est gérée de manière informelle par des personnes dont la principale préoccupation est d'assurer la continuité de la production.
Ce n'est pas un manque de rigueur. C'est une conséquence structurelle de l'application de la logique des frameworks à des environnements pour lesquels ils n'ont pas été conçus.
Le changement requis ne consiste pas à passer de la conformité à la non-conformité. La mise en conformité avec les normes NIS2 et CEI 62443 est une obligation légitime pour les entreprises manufacturières opérant dans des secteurs critiques, et la responsabilité qu’elle impose au niveau de la direction est justifiée. La question n’est pas de savoir s’il faut se conformer, mais de comprendre pourquoi la conformité à elle seule ne suffit pas.
Au-delà de la simple question « sommes-nous en conformité ? », les responsables de la sécurité des systèmes opérationnels (OT) dans le secteur manufacturier doivent se poser les questions suivantes :
Ces questions ne vont pas à l'encontre de la conformité. Elles sont au contraire ce qui garantit la pérennité de la conformité — ce qui empêche le fossé entre le modèle de sécurité et l'environnement de production de se creuser avec le temps.
Les programmes de cybersécurité des systèmes OT qui tiennent compte de la séquence des opérations, des contraintes de production et du comportement réel des systèmes ne se contentent pas d'assurer la conformité. Ils la maintiennent, car les mesures de contrôle qu'ils mettent en œuvre sont celles que l'usine est réellement en mesure de respecter.
Contactez-nous
