CISA demande aux opérateurs de renforcer les automates Siemens S7. Voici comment procéder sans perturber la production

Sur un serveur conventionnel, la désactivation d’un service inutilisé est généralement une tâche de routine de renforcement. Sur un contrôleur Siemens S7, le service supposément inutilisé peut transporter le trafic d’E/S distantes, fournir des valeurs de processus à une IHM ou constituer le seul chemin d’accès de l’équipe de maintenance vers les diagnostics. Fermez-le sans vérifier ces dépendances et l’équipe de sécurité pourrait provoquer la panne qu’elle avait l’intention d’éviter.

C’est le problème de mise en œuvre de l’avis conjoint sur la cybersécurité AA26-231A, publié le 19 août par la NSA, la CISA, le FBI, le ministère de l’Énergie et l’Agence de protection de l’environnement. Les agences mettent en garde contre le ciblage actif des automates programmables Siemens S7 et recommandent l’application de correctifs, la suppression de l’exposition à Internet, le renforcement des contrôles d’accès, la surveillance des communications S7 et la désactivation des services inutiles.

Chaque recommandation est raisonnable. Plusieurs d’entre elles peuvent affecter la production si elles sont mises en œuvre sans comprendre l’usine.

L’avertissement n’est pas un avis de patch

L’avis couvre toutes les variantes de CPU des séries S7-200, S7-300 et S7-400, les CPU compactes S7-1200 répertoriées dans l’avis et toutes les variantes S7-1500, y compris les automates de sécurité de la série F. Ces générations n’assurent pas des fonctions de sécurité identiques.

Les acteurs malveillants utilisent des services d’analyse Internet pour trouver des contrôleurs exposés ou mal segmentés. Selon les agences, elles combinent des informations publiques avec des scripts et des bibliothèques assistés par l’IA tels que Snap7 et python-snap7. Les outils peuvent communiquer via S7comm, généralement via le port TCP 102, et peuvent lire ou écrire la mémoire de l’automate, les données de configuration et la logique de contrôle.

L’IA accélère le développement d’outils, mais ce n’est pas la faiblesse sous-jacente. L’avis indique que les acteurs profitent de « vulnérabilités connues, de mauvaises configurations et d’autres faiblesses ». Il ne divulgue pas une nouvelle vulnérabilité partagée par chaque S7 ni n’identifie un seul correctif qui résout la menace.

Siemens a fait la même distinction dans une déclaration à la publication spécialisée allemande Produktion. La société a déclaré que l’AA26-231A ne décrivait pas les nouvelles vulnérabilités de la série S7, mais des méthodes susceptibles d’exploiter les erreurs de configuration déjà abordées dans ses directives. Le bulletin ProductCERT mis à jour de Siemens SSB-104599 oriente les clients vers les logiciels actuels, les réseaux protégés, les mots de passe forts et la documentation spécifique au modèle.

Cela change la réponse : les opérateurs ne peuvent pas attendre une seule mise à jour d’urgence. Ils doivent réduire l’exposition des contrôleurs dotés de différents environnements matériels, micrologiciels et d’ingénierie.

Lorsque j’examine une modification de renforcement de l’OT, j’ai d’abord besoin de cinq informations : le processeur exact et les modules de communication, le micrologiciel, le processus et la fonction de sécurité, les partenaires de communication légitimes et la voie de récupération approuvée. Un contrôle disponible sur un appareil peut ne pas exister sur un autre.

« Non utilisé » doit être prouvé

Le mot le plus dangereux dans les directives est « inutilisé ». CISA recommande de désactiver les serveurs Web et les protocoles tels que Modbus TCP et PROFINET s’ils ne sont pas requis sur le plan opérationnel. La qualification est cruciale. PROFINET peut connecter la CPU à des E/S distribuées, des lecteurs ou d’autres contrôleurs. Modbus TCP peut prendre en charge un compteur, un analyseur ou un package tiers. Un serveur Web peut faire partie du flux de travail de diagnostic même s’il n’achemine pas de trafic continu.

Dix minutes tranquilles sur un capteur réseau ne prouvent pas qu’une connexion est inutile. Certaines communications apparaissent uniquement lors du démarrage, de l’arrêt, du basculement ou de la maintenance. Je demande aux équipes de prouver « inutilisé » de trois manières : depuis la configuration d’ingénierie, depuis le trafic représentatif et jusqu’à la confirmation par les propriétaires d’automatisation et de maintenance. Si ces sources ne sont pas d’accord, le service reste concerné.

La même discipline s’applique aux autres mesures de l’avis :

La périphérie du réseau est normalement le point de départ le plus sûr. CISA recommande de bloquer le port TCP 102 au niveau des pare-feu périmétriques. Le bloquer sans discernement à l’intérieur d’une cellule peut interrompre le trafic S7 légitime. En interne, l’accès doit être limité aux paires de communication connues. L’assistance à distance doit se terminer au niveau d’une passerelle gérée avec une authentification individuelle, une fenêtre horaire définie et une journalisation de session.

CISA recommande également la mise sur liste blanche MAC/IP sur les contrôleurs eux-mêmes. Cette instruction n’est pas universellement applicable. Les processeurs plus anciens peuvent ne pas offrir le contrôle et une liste incomplète sur une installation plus récente peut interrompre les chemins redondants de l’IHM, de l’ingénierie ou du fournisseur. La politique souhaitée devra donc peut-être être appliquée à la limite du réseau plutôt que sur l’automate.

L’avis est tout aussi imprécis lorsqu’il fait référence à une « protection complète contre le redémarrage ». Les techniciens ne trouveront pas de paramètre universel TIA Portal portant ce nom exact. Les opérateurs ont besoin de conseils spécifiques au modèle plutôt que d’un changement de configuration supposé. La protection du savoir-faire peut restreindre l’accès à des blocs sélectionnés, mais elle ne remplace pas les contrôles du réseau ni la surveillance de l’intégrité.

Traitez le durcissement comme un changement OT

Les mises à jour du micrologiciel, les niveaux de protection et les limites de connexion sont des modifications apportées à un système de contrôle de production. Elles nécessitent la même discipline d’ingénierie que toute autre modification : un état de départ approuvé, un test, une fenêtre de maintenance, une décision de restauration et une vérification opérationnelle.

« Corrigez rapidement » et « testez d’abord » ne sont pas des instructions opposées. Les automates exposés méritent la priorité, mais une mise à jour peut affecter les modules, les pilotes IHM, les bibliothèques tierces, la redondance ou les fonctions de sécurité. L’unité pertinente est le processeur exact, le micrologiciel, les modules, la version d’ingénierie et l’environnement connecté. Une sauvegarde de projet ne peut pas annuler une mise à jour et la mise à niveau peut ne pas être prise en charge.

L’avis recommande également de vérifier les changements de logique à relais. Les opérateurs devraient comparer plus que des échelles. Une application S7 peut inclure des diagrammes de blocs fonctionnels, du texte structuré, des blocs de données, une configuration matérielle et des paramètres de communication. La comparaison nécessite également une référence fiable. Un ancien répertoire appelé « final » n’est pas une copie dorée simplement parce qu’il s’agit du seul projet disponible.

Des différences inexpliquées ne prouvent pas automatiquement un compromis. Ils peuvent exposer un changement de champ légitime qui n’a jamais atteint le projet principal. Réconciliez-les, approuvez l’état actuel et conservez-le comme nouvelle référence. Les programmes de sécurité nécessitent leur processus formel de comparaison et d’acceptation de Siemens Safety ; une comparaison de routine en ligne/hors ligne n’est pas suffisante pour accepter les modifications apportées à un programme F ou à une configuration FI/O.

Le suivi doit être lié à cette référence et au processus de changement. Les signaux utiles incluent S7comm provenant d’une source non approuvée, les écritures en dehors d’une fenêtre de maintenance, les analyses du port 102 et les outils Snap7 ou Python sur un système inattendu. Snap7 lui-même est légitime ; le contexte détermine si son utilisation est autorisée.

J’utilise neuf questions pour maintenir un changement de durcissement à la fois sûr et défendable sur le plan opérationnel :

1. Quel actif exact change ? Enregistrez le processeur, le micrologiciel et la fonction du processus.
2. Quelle voie d’attaque sera fermée ? Liez l’action à une exposition ou une faiblesse spécifique.
3. Quelles fonctions légitimes en dépendent ? Incluez les opérations, l’ingénierie et l’accès aux fournisseurs.
4. Quel est l’état de départ approuvé ? Capturez la configuration et les chemins de communication pertinents.
5. Comment le changement a-t-il été testé ? Utilisez un environnement et un scénario de fonctionnement représentatifs.
6. Qu’est-ce qui déclenche la restauration ? Définissez les échecs observables plutôt que « s’il y a un problème ».
7. Le rollback peut-il réellement être exécuté ? Confirmez les outils, les informations d’identification, les fichiers, le matériel et le personnel qualifié.
8. Comment le processus sera-t-il vérifié ? Vérifiez les E/S, les valeurs IHM, les alarmes, les verrouillages, la redondance et le comportement de sécurité.
9. Quelle sera la nouvelle référence ? Archivez le résultat, les preuves et l’acceptation de l’opérateur.

Effectuez un changement significatif de contrôleur à la fois. Si le micrologiciel, les niveaux d’accès, les protocoles et les limites de connexion changent simultanément, un test échoué donne peu d’indications sur la mesure qui l’a provoqué. La séquence la plus sûre va de l’extérieur vers l’intérieur : supprimer l’exposition publique, restreindre l’accès à distance et entre zones, établir la surveillance, prouver les dépendances et ensuite seulement modifier les services du contrôleur, les paramètres de protection ou le micrologiciel dans une fenêtre planifiée.

Un renforcement réussi du PLC repose sur deux critères d’acceptation : le chemin d’attaque est fermé et le processus se comporte toujours exactement comme l’opérateur l’attend.