Vous êtes dans : Accueil > Tribunes libres >

Les systèmes Scada, cauchemar du RSSI hospitalier – Volet 1

Cédric Cartau, MARDI 04 MAI 2021

Il s’agit d’un sujet qui revient régulièrement dans quasiment tous les congrès ou les discussions entre spécialistes IT ou RSSI, la sécurisation des systèmes Scada peut rapidement devenir un cauchemar pour tout le monde. Petit récapitulatif.

Un système Scada (Supervisory Control and Data Acquisition) est un équipement, ou groupe d’équipements, dédié au contrôle et à la supervision d’un processus industriel, par opposition à l’informatique dite « de gestion » (terme au demeurant assez large qui englobe, au vu de cette dichotomie, à la fois les progiciels purement administratifs, telles la paye, la comptabilité ou la GEF, que les progiciels cœur de métier, tel le DPI dans un établissement de santé).

Les systèmes Scada sont très vastes en termes de catégorie : on y range traditionnellement les équipements de supervision du réseau électrique, de la protection incendie, du système de contrôle d’intrusion, etc. Mais, par extension, on y trouve aussi des équipements plus spécifiques aux métiers tels que les consoles de supervision des modalités d’imagerie lourde (scanner, IRM – la classification Scada est certes discutable), les équipements d’analyse dans les laboratoires de biologie, les systèmes de supervision de la chaîne de stérilisation ou des températures des enceintes réfrigérées, etc. L’ouvrage Informatique de santé[1] distingue trois grandes familles : imagerie, biologie et « Divers », cette dernière catégorie étant elle-même subdivisée en sept sous-catégories : flux physiques, supervision/surveillance, communication, production de soins, fonctions support, terminaux patients et IoT. La classification est bien entendu discutable, mais il est clair que les systèmes Scada interagissent à un moment donné avec un équipement physique spécifique, qui ne peut pas être considéré comme un « simple » PC (même si au final on y trouve un OS, des interfaces, etc.).

Parmi les différentes générations de systèmes Scada (voir à ce sujet l’excellent article[2] du site factoryfuture.fr), nous pouvons en retenir au moins trois :

Première génération : les systèmes isolés et autonomes ; il s’agit de systèmes qui fonctionnent sans aucun lien avec le monde extérieur : si l’opérateur ne se trouve pas physiquement devant la machine quand l’alarme se déclenche, l’alerte n’est pas connue ; typiquement, un monitoring au chevet d’un patient ;

Deuxième génération : la mise en réseau « propriétaire » des systèmes Scada ; pour reprendre le cas du monitoring, il s’agit de la mise en réseau « propriétaire » de l’ensemble des systèmes de monitorage d’un étage ou d’un service, avec un report d’alarmes dans le bureau du personnel soignant ;

Troisième génération, en cours de déploiement : l’utilisation des réseaux IP en lieu et place des anciens réseaux propriétaires.

Tant que ces systèmes étaient isolés à la fois du LAN mais aussi d’Internet, les experts de ce domaine vivaient une vie totalement parallèle à celle de la DSI, sans jamais se croiser. D’une part, les fabricants de ces systèmes utilisent maintenant des composants informatiques « classiques » pour des raisons évidentes de coût de production : OS, interface IP, etc. : la frontière entre les deux mondes a désormais tendance à s’estomper, pour le meilleur comme pour le pire. D’autre part, l’évolution du contexte cyber fait que les systèmes Scada sont devenus des cibles au même titre que les autres équipements de l’IT, voire même davantage, et ce pour quatre raisons majeures :

a) Les cycles de vie

Les systèmes Scada ont des cycles de vie (conception, maintenance, fin de support, mise au rebut) sans commune mesure avec l’informatique « classique » : il n’est pas rare de trouver des équipements de TPO (Transport de petits objets, type valisettes, balancelles ou pneumatiques) qui ont 10 ans, 15 ans d’âge, voire plus. Installés pendant ou peu après la construction d’un bâtiment, ils sont totalement isolés du reste du monde. Tant que le système fonctionne, la maintenance se résume souvent à remplacer des contacteurs ou autres éléments mécaniques. De fait, leurs composants logiciels sont rarement mis à jour.

b) La culture des fabricants

Il est assez compréhensible que, issus d’un monde totalement isolé des décennies durant des affres et des périls cyber, les fabricants ne prenaient pas ou peu en compte le volet SSI dans leurs cycles de développement. Si en janvier 2010 vous aviez interrogé un ingénieur commercial de Siemens, Schneider, Philips, GE, etc. à ce propos, il vous aurait regardé avec une totale incompréhension – l’un d’eux m’a même sorti, à peu près à cette époque, qu’il était inutile de protéger ses équipements avec un antivirus puisque les autres équipements du LAN disposaient, eux, d’un antivirus – authentique.

c) L’évolution de la menace cyber

Le changement majeur s’est produit avec Stuxnet[3] : grâce à – ou à cause de – ce malware qui ciblait les centrifugeuses Siemens utilisées au sein du programme nucléaire iranien, les grands fabricants ont massivement pris connaissance de ce sujet.

d) Les contraintes techniques inhérentes à ces dispositifs

On ne met pas à jour un patch OS avec reboot du système de commande des réacteurs d’un avion de ligne en plein vol : autant l’informatique « classique » peut se permettre de rebooter un système, autant le fonctionnement d’un système Scada ne le supporte généralement pas. Idem pour les antivirus : dans certains cas réels, un antivirus résident peut perturber le fonctionnement d’un système.

À suivre…


[1]   Informatique de santé, Eyrolles, 2015.

[2]   https://www.factoryfuture.fr/tout-savoir-systemes-scada/#Que_signifie_exactement_le_terme_SCADA 

[3]   https://fr.wikipedia.org/wiki/Stuxnet 

#rssi#hospitalier#antivirus#production#siemens