Comment concilier les politiques d’application des correctifs IT avec les exigences de disponibilité OT ?

Concilier les politiques de correctifs IT avec les exigences de disponibilité OT consiste généralement à remplacer une règle générique du type « appliquer tous les correctifs chaque mois » par une approche conjointe, fondée sur les risques. Vous n’obtiendrez pas un calendrier unique satisfaisant les deux parties ; il faut un compromis structuré qui traite l’OT différemment de l’informatique bureautique tout en prenant en compte le risque cyber.

1. Mettre en place une gouvernance conjointe, et non un contrôle uniquement IT

Commencez par faire de l’application des correctifs une responsabilité partagée entre l’IT, l’OT/ingénierie et la qualité, plutôt qu’une activité pilotée par l’IT :

En pratique, cela se rattache aux preuves de sécurité industrielle lorsque les équipes doivent transformer la réponse en habitudes d’exécution répétables.

• Créer un forum transverse sur les correctifs (sécurité IT, ingénierie OT, opérations, qualité/validation le cas échéant).
• Définir qui peut approuver, reporter ou refuser des correctifs sur des systèmes réglementés ou validés.
• Documenter les critères de décision et conserver les enregistrements pour l’auditabilité et les revues d’incidents futures.

Sans gouvernance conjointe explicite, l’IT optimisera la posture cyber et l’OT optimisera la disponibilité ; chacun aura « raison » dans son propre cadre, et l’usine se retrouvera avec un risque non maîtrisé et des conflits.

2. Élaborer une politique de correctifs propre à l’OT

Appliquer telle quelle la politique IT d’entreprise dans les environnements de production fonctionne rarement. Il faut une politique spécifique à l’OT, alignée sur l’IT mais non identique :

• Périmètre : Préciser que les règles de correctifs OT s’appliquent aux PLC, HMI, SCADA, systèmes d’historisation, nœuds MES, systèmes de laboratoire et contrôleurs d’équipement, et pas seulement aux clients Windows/Linux standard.
• Approche fondée sur les risques : Relier l’urgence d’un correctif à l’exploitabilité, à l’exposition (p. ex. DMZ ou cellule isolée) et à l’impact sur la sécurité et la qualité, et pas seulement aux niveaux de sévérité indiqués par les fournisseurs.
• Contraintes de validation : Pour les systèmes réglementés et validés, définir quand un correctif nécessite une revalidation ou des essais de régression, ainsi que les preuves acceptables pour conclure à une absence d’impact.
• Règles de report : Définir explicitement quand et comment les correctifs peuvent être reportés, pour quelle durée, et quels contrôles compensatoires sont requis.

Cette politique doit reconnaître que certains actifs OT ne peuvent pas être corrigés selon les calendriers IT en raison de la charge de validation, des limites de support fournisseur ou d’un impact élevé sur les arrêts de production.

3. Classer les actifs et la criticité des correctifs

Tous les systèmes n’ont pas besoin de la même cadence d’application des correctifs. Créez un modèle de base des actifs et de leur criticité, puis alignez les attentes de correctifs par classe :

• Niveau 1 : actifs de cybersécurité exposés ou critiques (pare-feu, serveurs de rebond, passerelles d’accès distant, Active Directory, serveurs DMZ). Ils doivent suivre les cycles de correctifs IT aussi étroitement que possible, avec un niveau élevé de rigueur dans les tests.
• Niveau 2 : serveurs et infrastructure OT (MES, historiseurs, serveurs batch, serveurs OPC) ayant un impact sur la production mais pouvant être redémarrés dans des fenêtres planifiées. Utilisez des cycles mensuels ou trimestriels, avec approbation de l’usine et possibilités de retour arrière.
• Niveau 3 : IHM au niveau ligne, postes d’ingénierie et contrôleurs, pour lesquels les arrêts et la requalification sont coûteux. L’application des correctifs peut être trimestrielle, semestrielle ou alignée sur les grandes opérations de maintenance, selon le risque et les recommandations du fournisseur.
• Niveau 4 : systèmes anciens ou verrouillés par le fournisseur, pour lesquels les correctifs ne sont pas disponibles ou compromettraient le support.

L’essentiel est que les politiques IT reconnaissent explicitement ces niveaux, au lieu de traiter tous les systèmes comme un ordinateur portable d’entreprise.

4. Utiliser des fenêtres de maintenance et des vagues de correctifs

Pour concilier disponibilité et sécurité, formalisez quand et comment vous intervenez sur les systèmes OT :

• Fenêtres de maintenance standard : Convenez de fenêtres fixes hebdomadaires ou mensuelles par zone ou par ligne, même si elles ne sont pas toujours utilisées. Cela permet à l’IT de planifier les travaux sans gestion permanente des urgences.
• Vagues de correctifs : Déployez d’abord sur des systèmes de test ou de criticité moindre, puis sur les actifs à forte criticité une fois la stabilité confirmée. Par exemple, appliquez d’abord les correctifs aux équipements de laboratoire ou pilotes, puis aux lignes de production.
• Contraintes saisonnières : Respectez les périodes d’interdiction connues (par exemple, pic de production, campagnes de qualification), documentées dans le plan d’application des correctifs.

Les fenêtres de maintenance resteront néanmoins limitées dans de nombreuses usines, en particulier dans les sites à forte utilisation ou à procédés continus ; les attentes quant à ce qui peut réellement être corrigé à chaque fenêtre doivent donc rester réalistes.

5. Toujours tester et prévoir des plans de retour arrière

Dans les environnements OT, des correctifs non testés peuvent provoquer des non-qualités passées au travers des contrôles ou des arrêts prolongés, et pas seulement des réclamations utilisateurs. Réduisez ce risque en :

• Testant dans un environnement représentatif : idéalement un système de préproduction ou une copie virtualisée du MES/SCADA où vous pouvez tester les principaux flux de travail avec des images corrigées.
• Coordonnant avec les fournisseurs : utilisez des listes de correctifs ou des images approuvées par les fournisseurs lorsqu’elles existent. Gardez à l’esprit que certains fournisseurs accusent un retard important par rapport aux cycles de correctifs IT.
• Assurant les sauvegardes et les snapshots : effectuez des sauvegardes complètes ou des snapshots système avant d’appliquer les correctifs. Validez que les restaurations sont effectivement réalisables dans votre fenêtre d’arrêt.
• Standardisant les décisions de retour arrière : définissez les conditions qui déclenchent un retour arrière (par exemple, échec au démarrage, problèmes d’intégrité des données, régressions de performance) et qui peut l’autoriser sur un système en production.

Lorsque les systèmes font partie de processus validés, consignez les preuves issues des tests et du déploiement des correctifs dans les enregistrements de maîtrise des changements.

6. Utiliser des mesures compensatoires lorsque vous ne pouvez pas appliquer de correctifs

Certains systèmes OT ne peuvent pas être corrigés du tout, ou seulement très rarement, en raison de contraintes fournisseur, de matériel ancien ou de l’impact sur la validation. Reconnaissez-le ouvertement et appliquez des mesures compensatoires au lieu de prétendre être conforme à la politique IT :

• Segmentation et isolation réseau pour les systèmes hérités à haut risque.
• Contrôles d’accès stricts et hôtes bastion au lieu d’un accès RDP/SSH direct depuis les réseaux bureautiques.
• Liste d’autorisation des applications et configurations verrouillées sur les anciens hôtes Windows.
• Surveillance et journalisation renforcées sur les systèmes non corrigés et leurs zones réseau.
• Acceptation du risque documentée avec un calendrier de remédiation ou de remplacement à terme.

Cela n’élimine pas le risque, mais rend le risque résiduel visible et maîtrisé, plutôt que dissimulé derrière des indicateurs nominaux de conformité aux correctifs.

7. Intégrer l’application des correctifs à la maîtrise des changements et à la validation

Dans les environnements réglementés, les correctifs sont des changements susceptibles d’affecter l’état validé, l’intégrité des données et les pistes d’audit. La conciliation avec la disponibilité OT doit respecter ces contraintes :

• Faire passer les correctifs concernés par un processus formel de maîtrise des changements, avec des analyses d’impact, des approbations et des revues post-mise en œuvre documentées.
• Définir quels types de composants nécessitent une revalidation (p. ex., les serveurs applicatifs MES) par opposition à ceux qui, en général, n’en nécessitent pas (p. ex., les hyperviseurs d’infrastructure, sous réserve de certaines précautions).
• Utiliser les enregistrements de changement pour consigner ce qui a été corrigé, où et comment cela a été testé, afin d’assurer la traçabilité lors d’audits ou d’investigations futurs.

Cela peut ralentir les cycles d’application des correctifs, en particulier pour les systèmes cœur. Reconnaissez cette contrainte dans la politique IT plutôt que de chercher à la contourner de manière informelle.

8. Tenir compte de la complexité des environnements existants et des longs cycles de vie des actifs

Dans de nombreuses usines, remplacer ou mettre à niveau les plateformes OT uniquement pour faciliter l’application des correctifs n’est pas réaliste. Les raisons incluent :

• Des MES/SCADA et des contrôleurs existants avec un support fournisseur limité et des correctifs de nouveaux OS incompatibles.
• Des dépendances d’intégration entre ERP, PLM, QMS, historiens de données et intergiciels spécifiques, qui rendent les mises à niveau de plateformes risquées et coûteuses.
• La charge de qualification et de validation pour chaque changement logiciel ou matériel significatif.
• Des fenêtres d’arrêt limitées en raison d’opérations 24/7 ou de séquences de redémarrage complexes.

Étant donné qu’un remplacement complet est souvent irréalisable à court terme, une conciliation pragmatique repose largement sur la segmentation, les configurations durcies, l’application sélective des correctifs et une maîtrise des changements rigoureuse, plutôt que sur des stratégies consistant à « tout moderniser ».

9. Rendre les arbitrages explicites

Concilier l’application des correctifs IT et la disponibilité OT consiste essentiellement à rendre les arbitrages explicites, et non à accepter des compromis cachés :

• Documenter quels systèmes suivent les cycles de correctifs IT et lesquels suivent des cycles spécifiques à l’OT, avec la justification associée.
• Suivre les correctifs différés et les risques associés, y compris les vulnérabilités connues et les contrôles compensatoires.
• Réexaminer périodiquement ces décisions dans l’instance transversale, en particulier après des incidents ou des événements évités de justesse.

Cela permet à la direction de voir où le risque est assumé pour protéger la disponibilité, au lieu de supposer une conformité uniforme qui n’existe pas en pratique.

Synthèse

Concilier les politiques de correctifs IT avec les exigences de disponibilité OT nécessite une stratégie de correctifs OT dédiée, et non une version allégée d’une stratégie IT. Les éléments clés sont une gouvernance conjointe, des niveaux de criticité des actifs, des fenêtres de maintenance réalistes, des tests et des retours arrière robustes, des contrôles compensatoires lorsque l’application de correctifs est impossible, ainsi qu’une intégration étroite avec la gestion des changements et la validation. Les résultats dépendront fortement de l’inventaire actuel de vos systèmes, du support des fournisseurs, de la qualité de l’intégration, ainsi que de la maturité de vos processus de changement et de validation.