Publicité en cours de chargement...

Publicité en cours de chargement...

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

11 mai 2021 - 10:34,

Tribune

- Cédric Cartau
Dans le premier volet, nous avons dressé un état des lieux des systèmes Scada : définition, histoire, origine des vulnérabilités. Poursuivons.

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.

Lettre d'information.

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

Inscrivez-vous à notre lettre d’information hebdomadaire.

Contact

Nos marques

Logo DSIHLogo Thema Radiologie