Publicité en cours de chargement...
Les systèmes Scada, cauchemar du RSSI hospitalier – Volet 2
Après s’être totalement ignorés pendant des décennies, les experts Scada et IT se sont ensuite copieusement invectivés, chacun accusant l’autre de ne pas comprendre « la vraie vie » (ce qui semble d’ailleurs être une tradition au pays du fromage). À ce sujet, écouter l’excellent numéro du Comptoir Sécu[1] sur la SSI dans le domaine industriel.
On observe, très clairement, une grosse mutation sur la question. À titre personnel, j’ai participé à une réunion de travail très technique sur le dossier du monitoring patient avec les équipes de Philips, et l’on pourra toujours critiquer certains choix techniques, mais il faudrait être d’une sacrée mauvaise foi pour affirmer que, concernant le système que j’ai vu, la SSI n’avait pas été prise en compte : elle est clairement by design dans l’architecture du produit.
Cela étant, il subsiste toujours des fournisseurs en retard (pour quelques années encore), et des vulnérabilités inhérentes à ce type de produits (par exemple, aucune souplesse sur les mises à jour de patchs OS). Les équipes IT ne sont pas pour autant démunies face aux enjeux de sécurisation des systèmes Scada ; il existe des dispositions pas toujours coûteuses ni complexes à déployer pour les sécuriser. Liste non exhaustive.
a) Segmenter les sous-réseaux
C’est une bonne pratique de base : chaque système Scada doit être déployé sur un VLAN dédié. Attention quand le VLAN doit être propagé sur plusieurs sites, le travail des ingénieurs réseau devient un peu plus complexe.
b) Filtrer les VLAN Scada
Un VLAN Scada ne doit être relié au reste du LAN qu’au travers d’un pare-feu dédié, avec donc une cartographie des flux et des ports IP.
c) Déployer des dispositifs d’analyse AV à la volée en mode non bloquant
Trend a été le premier fournisseur AV à en proposer dans son catalogue : il s’agit de boîtiers qui se branchent en mode écoute/réplication de port sur un switch ou un routeur et qui analysent les trames du VLAN Scada.
d) Disposer d’un plan de mise à jour des équipements de chaque VLAN
On peut admettre que les patchs OS ne soient pas déployés tous les mois, pas qu’ils ne le soient jamais.
e) Déployer des bastions de prise de main à distance pour les fournisseurs dans le cadre de la maintenance
Les « gros » fournisseurs biomédicaux sont les spécialistes des demandes d’accès LAN to LAN : s’il est impossible de l’éviter (dans certains cas les contraintes de GTI/GTR ne le permettent pas), a minima déployer une authentification login/password et exiger un planning de déploiement de MFA sur ces typologies d’accès.
f) Passer régulièrement un outil de type Shodan
C’est la seule façon de vérifier qu’aucun équipement de votre LAN n’est en accès libre sur Internet.
g) Intégrer des dispositions standard de sécurité dans vos CCTP
Nulle explication nécessaire.
h) Appeler un ami
À une époque pas si lointaine, c’était le truc préféré des fournisseurs peu scrupuleux : tenter de m’expliquer que ce que je refusais, tous les hôpitaux du reste de la France l’avaient accepté sans problème, mais bon alors, M. Cartau, on ne comprend vraiment pas pourquoi vous ne voulez pas. Dans les faits, après quelques coups de fil, il s’avérait que c’était la plupart du temps entièrement faux. Après le jugement dernier, j’espère que ces gugusses se feront rôtir juste après les arracheurs de dents.
i) Être en amont des projets
Un bon RSSI va voir les ingénieurs biomed, les experts sécurité, les services techniques avant que les ennuis n’arrivent… pour mieux les anticiper.
j) Former les services
Un ingénieur biomed averti en vaut deux. Et, d’expérience, ils prétendent rarement en connaître plus que le RSSI sur les questions de sécurité et sont souvent demandeurs de connaissances.
k) Cultiver son espièglerie
Le prochain fournisseur qui me demande d’ouvrir un flux patient en HTTP (authentique), de mettre le même mot de passe d’accès VPN que tous ses autres clients (encore authentique), voire de poser une appliance sur mon LAN pour exfiltrer des données patient sans me fournir aucune doc technique à part un gribouillis sur une feuille de Sopalin (toujours authentique), juré, je déclare un incident à l’Anssi.
[1] https://www.comptoirsecu.fr/podcast/%C3%A9pisode-48-la-ssi-dans-le-monde-industriel/
Avez-vous apprécié ce contenu ?
A lire également.

Cybersécurité hospitalière : le GHT Rhône Nord Beaujolais Dombes, premier lauréat du programme CaRE
09 mai 2025 - 16:39,
Actualité
- DSIHLe programme CaRE franchit une étape clé. Moins d’un an après le lancement de son premier appel à financement dédié à la sécurisation des annuaires techniques et de l’exposition sur Internet, la direction du programme annonce la validation du premier dossier ayant atteint l’ensemble des objectifs fi...

Ce que nous enseigne la mégapanne électrique dans la péninsule ibérique
05 mai 2025 - 23:11,
Tribune
-Impossible de l’avoir ratée, la mégapanne électrique chez nos amis espagnols et portugais. Cet incident est riche d’enseignements, et force est de constater qu’il n’y a pas que des mauvaises nouvelles. D’abord, selon nos informations à ce jour, il n’y a eu aucune victime : c’est une bonne nouvelle.

Un hôpital, sous-traitant, sanctionné pour ne pas avoir déclaré les sous-traitants ultérieurs
02 mai 2025 - 16:13,
Tribune
- Alexandre Fievee, Gaétan Dufoulon et Alice Robert de Derriennic AssociésPar décision du 10 avril 2025 [1], l’autorité de contrôle espagnole a infligé une amende de 500.000 euros à un hôpital qui avait recruté des sous-traitants ultérieurs sans en informer préalablement le responsable du traitement.

Éthicovigilance numérique : premiers signaux d’alerte dans la santé connectée
24 avril 2025 - 15:14,
Actualité
- DSIHLa Délégation au numérique en santé (DNS) publie le premier rapport d’activité de la Plateforme d’éthicovigilance du numérique en santé, un dispositif inédit lancé fin 2023 pour recueillir les signalements d’usagers et de professionnels confrontés à des enjeux éthiques liés aux technologies de santé...