Publicité en cours de chargement...

Publicité en cours de chargement...

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

04 mai 2021 - 10:54,
Tribune - Cédric Cartau
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 

Avez-vous apprécié ce contenu ?

A lire également.

Illustration Cloud souverain : le décret SREN durcit le cadre pour les données sensibles du secteur public

Cloud souverain : le décret SREN durcit le cadre pour les données sensibles du secteur public

27 avril 2026 - 09:16,

Actualité

- Rédaction, DSIH

Le décret d’application de l’article 31 de la loi visant à sécuriser et réguler l’espace numérique vient enfin préciser les conditions d’hébergement des données sensibles dans le cloud. Pour les établissements de santé, les administrations et les opérateurs publics, le texte marque une nouvelle étap...

Illustration Le DLP, ou l’archétype du techno-solutionnisme béat

Le DLP, ou l’archétype du techno-solutionnisme béat

20 avril 2026 - 10:27,

Tribune

-
Cédric Cartau

On n’est pas exactement dans un matraquage publicitaire de haute intensité, mais cela revient tout de même assez régulièrement, comme la grippe de saison ou les allergies aux plastiques des tongs d’été. En tout cas, régulièrement, il se trouve un commercial lambda pour nous ressortir une offre préte...

Illustration L’IA, fossoyeur de l’IT ? Pas si simple, et certainement pas tout de suite

L’IA, fossoyeur de l’IT ? Pas si simple, et certainement pas tout de suite

07 avril 2026 - 07:40,

Tribune

-
Cédric Cartau

Dans la première moitié du XIXe siècle, les usines textiles, qui avaient déployé massivement des métiers à tisser mécaniques, utilisaient les ouvriers pour contrôler le tissu sortant de la chaîne de production : absence de fil cassé, etc. Un ouvrier pouvait piloter 2 machines en même temps, et à un ...

Illustration Du séjour au domicile : le SMS comme brique du système d’information hospitalier

Du séjour au domicile : le SMS comme brique du système d’information hospitalier

07 avril 2026 - 07:30,

Actualité

- Pierre Derrouch, DSIH

La réduction continue des durées de séjour hospitalier déplace une part du risque clinique vers le domicile. En chirurgie ambulatoire, les réhospitalisations entre un à trois jours après l’intervention figurent parmi les indicateurs de sécurité suivis par la Haute Autorité de Santé dans le cadre des...

Lettre d'information.

Ne manquez rien de la e-santé et des systèmes d’informations hospitaliers !

Inscrivez-vous à notre lettre d’information hebdomadaire.