Sécurité des automates et SCADA : réduire l'accessibilité des systèmes de contrôle

01Points clés à retenir

1. 01

   Les automates et les systèmes SCADA ont été conçus pour la fiabilité et la commande en temps réel, pas pour résister à une attaque réseau.

2. 02

   De nombreux protocoles industriels sont non sécurisés par conception, dépourvus d'authentification ou de chiffrement.

3. 03

   Corriger les systèmes de contrôle est difficile, car la disponibilité, la sûreté et le support éditeur limitent les changements.

4. 04

   Comme le durcissement des équipements est limité, réduire leur accessibilité est souvent la mesure la plus solide disponible.

5. 05

   L'accès d'ingénierie peut être confiné à des fenêtres délibérées, et la supervision peut éviter tout chemin entrant.

02Ce que sont les automates et le SCADA, et pourquoi ils sont fragiles

Un automate (API) est un contrôleur durci qui exécute la logique pilotant un processus physique. Les systèmes SCADA supervisent et coordonnent ces contrôleurs à l'échelle d'une zone ou d'un site, offrant aux opérateurs visibilité et commande. Ensemble, ils forment le système nerveux des opérations industrielles.

Leur fragilité n'est pas de la négligence ; c'est un héritage. Ils ont été conçus pour accomplir une tâche de manière fiable pendant des décennies, sur un réseau supposé de confiance et isolé. La confidentialité et l'authentification n'étaient pas des objectifs de conception, car le modèle de menace n'incluait pas un réseau hostile.

Les systèmes de contrôle ne sont pas non sécurisés par accident ; ils ont été conçus pour un monde où le réseau lui-même constituait le périmètre.

03Des protocoles non sécurisés par conception

Beaucoup des protocoles que parlent les systèmes de contrôle ont été créés sans fonctions de sécurité. Ils n'ont souvent aucune authentification, si bien que tout équipement capable d'atteindre un contrôleur peut lui envoyer des commandes, et aucun chiffrement, si bien que le trafic peut être lu et manipulé.

• Les commandes peuvent être acceptées de n'importe quelle source accessible sans vérification d'identité.
• Le trafic peut être observé et modifié parce qu'il n'est pas chiffré.
• Des fonctions du protocole destinées à l'ingénierie peuvent être invoquées par quiconque dispose d'un accès réseau.
• Ajouter de la sécurité à ces protocoles après coup est souvent irréalisable sur les équipements existants.

L'implication est saisissante : pour beaucoup de systèmes de contrôle, l'accessibilité réseau équivaut de fait à l'accès. Si un système peut atteindre le contrôleur, il peut souvent le commander.

04Pourquoi les correctifs sont difficiles

Le réflexe issu de l'informatique de gestion est d'appliquer des correctifs, mais les systèmes de contrôle y résistent. La production ne peut pas s'arrêter facilement, les changements font peser un risque sur la sûreté et la stabilité, et la certification de l'éditeur peut lier un système à une configuration précise.

• L'arrêt nécessaire pour appliquer un correctif peut être coûteux ou inacceptable sur le plan opérationnel.
• Les modifications apportées à un processus contrôlé comportent un risque pour la sûreté et la stabilité.
• Le support et la certification de l'éditeur peuvent limiter ce qui peut être modifié.
• Certains équipements sont tout simplement trop anciens pour recevoir la moindre mise à jour.

Les correctifs restent importants lorsqu'ils sont possibles, mais ils ne peuvent pas constituer la défense principale de systèmes qui peuvent rester des années entre deux fenêtres de maintenance sûres.

05Segmentation et accessibilité minimale

Si les équipements ne peuvent guère être durcis ni corrigés librement, le levier qui reste est l'accessibilité. Moins il y a de systèmes capables d'atteindre un contrôleur, et moins longtemps ils le peuvent, plus l'opportunité de l'attaquer se réduit.

La segmentation en zones en est le fondement : elle place les contrôleurs dans des zones étroitement contrôlées, avec des conduits délibérément limités. Pour les segments de contrôle les plus sensibles, un schéma de connectivité maîtrisée AIRGAPNET peut les maintenir déconnectés par défaut et accessibles uniquement pendant des fenêtres approuvées d'ingénierie ou de données, de sorte que l'accessibilité devienne l'exception plutôt que la règle.

06Fenêtres d'accès d'ingénierie

Les ingénieurs doivent atteindre les contrôleurs pour apporter des modifications, mais ils ont besoin de le faire ponctuellement, non en continu. Cela fait de l'accès d'ingénierie un candidat idéal pour une connectivité limitée dans le temps.

Plutôt que de laisser un chemin d'ingénierie ouvert en permanence, on peut l'ouvrir pour une tâche approuvée puis le refermer ensuite. Le contrôleur est accessible pendant les travaux et inaccessible le reste du temps, c'est-à-dire la plupart du temps.

07Superviser sans chemin entrant

La visibilité sur les systèmes de contrôle a de la valeur, mais elle ne doit pas se payer d'un nouveau chemin entrant. Les données de supervision peuvent être poussées vers l'extérieur plutôt que collectées par un outil qui va les chercher.

Transmettre la télémétrie et les événements en sens unique vers une plateforme de supervision préserve la visibilité tout en respectant le principe selon lequel rien n'initie de trafic vers le contrôleur. Observer n'a pas à signifier être accessible.

08En conclusion

Les automates et les systèmes SCADA ne deviendront pas de sitôt des équipements durcis, chiffrés et faciles à corriger. Ils sont conçus pour faire tourner un processus de manière fiable, et c'est ce qu'ils continueront de faire. Les sécuriser suppose d'accepter les équipements tels qu'ils sont et de maîtriser le réseau qui les entoure.

Réduisez qui peut les atteindre et quand, confinez l'accès d'ingénierie à des fenêtres délibérées, et supervisez sans ouvrir de chemin entrant. Pour les systèmes où l'accessibilité équivaut à l'accès, maîtriser l'accessibilité, c'est cela la sécurité.

FAQQuestions fréquentes

SRCSources de référence