Comment concilier les politiques de gestion des correctifs IT avec les exigences de disponibilité de l’OT ?

Concilier les politiques de déploiement de correctifs IT avec les exigences de disponibilité OT revient généralement à remplacer une règle générique de 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, pas un contrôle exclusivement IT

Commencez par faire du déploiement 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 cybersécurité industrielle lorsque les équipes doivent transformer la réponse en habitudes d’exécution répétables.

• Créer un forum transverse dédié aux correctifs (sécurité IT, ingénierie OT, opérations, qualité/validation le cas échéant).
• Définir qui peut approuver, reporter ou rejeter 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 futures revues d’incidents.

Sans gouvernance conjointe explicite, l’IT optimisera la posture cyber et l’OT optimisera la disponibilité ; les deux auront « raison » dans leur propre cadre, et l’usine se retrouvera avec des risques et des conflits non maîtrisés.

2. Élaborer une politique de correctifs spécifique à l’OT

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

• Périmètre : Clarifier que les règles de correctifs OT s’appliquent aux PLC, HMI, SCADA, historiens, nœuds MES, systèmes de laboratoire et contrôleurs d’équipements, et pas seulement aux clients Windows/Linux standards.
• Approche fondée sur les risques : Relier l’urgence des correctifs à l’exploitabilité, à l’exposition (par exemple 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 exige une revalidation ou des essais de régression, ainsi que les preuves acceptables pour les décisions d’« absence d’impact ».
• Règles de report : Définir explicitement quand et comment les correctifs peuvent être reportés, pour quelle durée, et quelles mesures compensatoires sont requises.

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 du support fournisseur ou d’un impact élevé sur la disponibilité.

3. Classer les actifs et la criticité de l’application des correctifs

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

• Niveau 1 : actifs de cybersécurité exposés ou critiques (pare-feu, serveurs bastion, passerelles d’accès distant, Active Directory, serveurs DMZ). Ils doivent suivre les cycles de correctifs IT d’aussi près que possible, avec un niveau élevé de rigueur dans les tests.
• Niveau 2 : serveurs et infrastructure OT (MES, historiseurs, serveurs de gestion des lots, 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 du site et possibilités de retour arrière.
• Niveau 3 : IHM de 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 hérités ou verrouillés par le fournisseur pour lesquels les correctifs ne sont pas disponibles ou invalideraient 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 être constamment en mode urgence.
• 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 les correctifs d’abord sur les équipements de laboratoire ou pilotes, puis sur les lignes de production.
• Contraintes saisonnières : respectez les périodes de gel connues (par exemple, pics de production, campagnes de qualification), documentées dans le plan de correctifs.

Les fenêtres de maintenance resteront malgré tout serré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 chemins de retour arrière

Dans les environnements OT, des correctifs non testés peuvent entraîner des écarts qualité non détectés 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 flux de travail clés avec les images corrigées.
• Coordonnant avec les fournisseurs : Utilisez les listes de correctifs ou les images approuvées par les fournisseurs lorsqu’elles existent. Reconnaissez que certains fournisseurs accusent un retard important par rapport aux cycles de correctifs IT.
• Assurant les sauvegardes et les instantanés : Effectuez des sauvegardes complètes ou des instantanés système avant d’appliquer les correctifs. Vérifiez 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 (p. ex., é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, capturez les éléments de preuve issus 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 obsolète ou de l’impact sur la validation. Reconnaissez-le ouvertement et appliquez des mesures compensatoires au lieu de faire comme si vous étiez conforme à la politique IT :

• Segmentation et isolation réseau pour les systèmes legacy à haut risque.
• Contrôles d’accès stricts et hôtes bastions plutôt qu’un accès RDP/SSH direct depuis les réseaux bureautiques.
• Liste d’autorisation applicative 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 documentée du risque, 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 masqué 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 pertinents par une maîtrise des changements formelle, avec des évaluations d’impact, des approbations et des revues post-implémentation documentées.
• Définir quels types de composants nécessitent une revalidation (p. ex., serveurs applicatifs MES) par opposition à ceux qui n’en nécessitent généralement pas (p. ex., hyperviseurs d’infrastructure, avec des réserves).
• 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 de futurs audits ou investigations.

Cela peut ralentir les cycles d’application des correctifs, en particulier pour les systèmes centraux. Il faut reconnaître cette contrainte dans la politique IT plutôt que d’essayer de la contourner de manière informelle.

8. Tenir compte de la complexité des environnements existants et des cycles de vie longs 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 automates historiques avec un support fournisseur limité et de nouveaux correctifs OS incompatibles.
• Des dépendances d’intégration entre ERP, PLM, QMS, systèmes d’historisation des données et middleware sur mesure, qui rendent les mises à niveau de plateforme 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.

Comme un remplacement complet est souvent irréalisable à court terme, la conciliation pratique repose fortement sur la segmentation, des configurations renforcées, une application sélective des correctifs et une maîtrise des changements rigoureuse, plutôt que sur des stratégies de type « 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 au sein de l’instance transverse, en particulier après des incidents ou des quasi-incidents.

Cela permet à la direction de voir où le risque est assumé pour protéger la disponibilité, plutôt que 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 dédiée de gestion des correctifs OT, et non une version édulcoré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 mesures compensatoires lorsque l’application de correctifs est irréalisable, ainsi qu’une intégration étroite avec la maîtrise des changements et la validation. Les résultats dépendront fortement de votre inventaire système actuel, du support des fournisseurs, de la qualité de l’intégration et de la maturité de vos processus de changement et de validation.