Concilier les politiques de déploiement des 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 répondant au risque cyber.
1. Mettre en place une gouvernance conjointe, et non un contrôle exclusivement IT
Commencez par faire du déploiement des correctifs une responsabilité partagée entre l’IT, l’OT/l’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 une instance transversale de gestion des 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 à des fins d’auditabilité et de revues d’incidents ultérieures.
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 un risque non maîtrisé et des conflits.
2. Élaborer une politique de correctifs propre à l’OT
Appliquer telle quelle la politique IT de l’entreprise aux environnements de production fonctionne rarement. Il faut une politique propre à 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, historiens, nœuds MES, systèmes de laboratoire et contrôleurs d’équipements, 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 sécurité/qualité, et pas uniquement aux niveaux de gravité 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 tests de régression, ainsi que les preuves acceptables pour les conclusions de type « aucun 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 échéances IT, en raison de la charge de validation, des limites du support fournisseur ou de l’impact élevé des arrêts.
3. Classer les actifs et la criticité des correctifs
Tous les systèmes n’ont pas besoin de la même cadence de correction. Créez un modèle de base des actifs et de leur criticité, puis alignez les attentes en matière de correctifs pour chaque classe :
- Niveau 1 : actifs de cybersécurité exposés ou critiques (pare-feu, serveurs de rebond, passerelles d’accès à distance, Active Directory, serveurs DMZ). Ils doivent suivre les cycles de correctifs IT d’aussi près que possible, avec une rigueur de test élevée.
- Niveau 2 : serveurs et infrastructure OT (MES, historisateurs, 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 du site 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 hérités 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 de gel connues (par exemple, pics de production, campagnes de qualification), documentées dans le plan de correction.
Les fenêtres de maintenance resteront étroites dans de nombreux sites, en particulier dans les installations à forte utilisation ou à procédé continu ; 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 provoquer des non-conformités passant au travers des contrôles qualité ou des indisponibilités prolongées, pas seulement des réclamations utilisateurs. Réduisez ce risque en procédant ainsi :
- Tester 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 sur des images corrigées.
- Coordonner avec les fournisseurs : Utilisez des listes de correctifs ou des images approuvées par le fournisseur lorsqu’elles existent. Tenez compte du fait que certains fournisseurs accusent un retard important par rapport aux cycles de correctifs IT.
- Garantir les sauvegardes et les instantanés : Effectuez des sauvegardes complètes ou des instantanés système avant d’appliquer les correctifs. Validez que les restaurations sont réellement réalisables dans votre fenêtre d’indisponibilité.
- Standardiser les décisions de retour arrière : Définissez les conditions qui déclenchent un retour arrière (par ex., échec de 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 recevoir de correctifs 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 isolement réseau pour les systèmes legacy à haut risque.
- Contrôles d’accès stricts et hôtes de rebond au lieu d’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 accrues 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 les correctifs au contrôle 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 un contrôle formel des changements, avec des analyses d’impact, des approbations et des revues après mise en œuvre documentées.
- Définir quels types de composants nécessitent une revalidation (p. ex., serveurs applicatifs MES) par rapport à ceux qui n’en nécessitent généralement pas (p. ex., hyperviseurs d’infrastructure, avec 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 d’audits ou d’investigations futurs.
Cela peut ralentir les cycles de correction, en particulier pour les systèmes cœur. Reconnaissez cette contrainte dans la politique IT plutôt que de tenter de 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 historiques avec un support fournisseur limité et de nouveaux correctifs d’OS incompatibles.
- Des dépendances d’intégration entre ERP, PLM, QMS, data historians et middleware personnalisé, 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.
Comme le remplacement complet est souvent irréalisable à court terme, la conciliation pratique repose fortement sur la segmentation, des configurations durcies, l’application sélective de correctifs et un contrôle des changements rigoureux, 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 les systèmes qui suivent les cycles de correctifs IT et ceux qui suivent des cycles spécifiques à l’OT, avec la justification correspondante.
- 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 presque-accidents.
Cela permet à la direction de voir où un risque est assumé afin de protéger la disponibilité, au lieu de supposer une conformité uniforme qui n’existe pas en pratique.
Résumé
Concilier les politiques de déploiement 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 contrôles 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 l’inventaire actuel de vos systèmes, du support des fournisseurs, de la qualité de l’intégration et de la maturité de vos processus de changement et de validation.