Helpdesk : la sécurité vous y avez pensé ?

Effectivement, ils présentent de nombreux avantages.
Ils permettent en premier lieu de désencombrer les lignes téléphoniques des services supports. Les incidents sont traités plus rapidement puisque l’ensemble des équipes reçoit la demande. Ils peuvent être priorisés et transmis plus rapidement au niveau de support supérieur car c’est l’utilisateur lui-même qui a saisi sa demande : pas besoin de la ressaisir.

Ils permettent un suivi ; le demandeur ainsi que l’ensemble de la DSI connaissent l’état d’avancement du traitement de sa demande. L’ensemble des tickets peut servir de base de connaissance aux équipes.
Et pour le plus grand plaisir de nos directeurs, ils permettent d’avoir une traçabilité ! De donner des chiffres, de justifier tous ces ETP [2] « qui s’amusent derrière leurs ordinateurs toute la journée ».
Bref, pour résumer, ces outils permettent à tous de gagner du temps (si tout le monde joue le jeu) et de justifier notre travail auprès de la DG [3].
Pour couronner le tout, on peut trouver bon nombre de ces outils en « Open Source » [4], comme Gestup, GLPI, Mantis, BugZilla et bien d’autres, ce qui va encore vous faire marquer des points auprès de la DG !

Tout cela est parfait, me direz-vous, mais la sécurité, vous y avez pensé ?

La sécurité devrait être prise d’autant plus au sérieux que l’outil ne se limite pas forcément à un usage interne. Prenons l’exemple des éditeurs, intégrateurs et autres prestataires qui travaillent avec le secteur de la santé et qui proposent (ou imposent) l’utilisation de leur outil « Helpdesk » en mode « Extranet » [5].

•  Contexte réglementaire

Sur ces outils, les utilisateurs (côté « fournisseur » comme côté client) peuvent être identifiés nominativement, une déclaration CNIL est donc obligatoire, sauf si le « fournisseur » dispose d’un CIL [6].
Travaillant dans le secteur de la santé, il faut pousser la réflexion un peu plus loin.
Les outils que nous utilisons dans nos établissements hébergent des données de santé à caractère personnel, nos demandes de support peuvent donc intégrer ces dernières elles aussi, que ce soit dans le descriptif du problème ou encore dans une capture d’écran (j’en ai vu).
Nous ne sommes donc plus sur une simple déclaration, mais bien sur une demande d’autorisation à réaliser auprès de la CNIL.
De plus le « fournisseur », qu’il soit établissement de santé ou non (des établissements de santé peuvent être éditeurs), va donc héberger des données de santé à caractère personnel « appartenant » à des tiers, il devra donc s’affranchir de l’agrément HDS [7] ou installer son outil chez un hébergeur disposant de l’agrément.

•  Contexte technique

Ces outils (tous ceux que je connais en tout cas) se présentant sous la forme de plateformes Web consultables à l’aide d’un navigateur Internet, un minimum de sécurité technique est à prévoir. Si la connexion à la plateforme ne se fait pas par le biais d’un tunnel VPN [8] et si elle est accessible à tous sur la toile, il me paraît impératif d’utiliser le protocole HTTPS [9] !
De plus, avec l’arrivée récente de l’autorité de certification Let’s Encrypt proposant des certificats SSL gratuits, le coût d’un certificat n’est plus un argument pour esquiver le passage au chiffrement.

Tous les prestataires avec lesquels il m’a été donné de travailler à ce jour utilisent encore le protocole HTTP pour leurs outils « Helpdesk ».

L’utilisation du protocole HTTP sans chiffrement laisse transparaître tous les échanges entre machines clientes et serveur « en clair » : les identifiants et mots de passe lors de l’authentification, les textes lus et saisis, idem pour les pièces jointes. Lorsque l’on échange sur un problème relatif au dossier d’un patient sur le « Helpdesk » de son prestataire, tout cela passe donc « en clair » sur Internet. Sur une attaque de type « man in the middle » [10], la personne malveillante verrait donc passer « en clair » tous les échanges entre votre machine et le serveur hébergeant l’outil « Helpdesk » et donc potentiellement les données de santé que vous pourriez y inscrire. Pire encore, elle verrait passer votre identifiant et votre mot de passe « en clair » ; elle pourrait donc se connecter à votre place facilement et accéder à tous vos tickets ouverts chez votre prestataire.

Et si vous utilisez ce même mot de passe un peu partout sur Internet, c’est du pain béni pour le cybercriminel. Je vous invite à lire l’article Mot de passe : technique et bon sens indissociables si vous l’avez raté.

Alors, éviter de citer les noms des patients et masquer toutes les informations à caractère personnel sur les captures d’écran permet de « préserver » la confidentialité, mais ce n’est pas une solution pérenne car tous les utilisateurs ne le feront pas.

Il est grand temps que les éditeurs et intégrateurs du secteur de la santé se mettent au boulot !

[1] Directions des systèmes d’information.
[2] Équivalents temps plein.
[3] Direction générale.
[4] Logiciels libres pouvant être utilisés (et modifiés) gratuitement, même à titre commercial.
[5] Extension du système d’information du « fournisseur » à ses clients au-delà de son réseau. L’accès se fait via Internet par une connexion « sécurisée » (ou pas) avec un mot de passe.
[6] Le correspondant Informatique et Libertés est l’intermédiaire entre le responsable du traitement (l’entreprise ou l’établissement déclarant) et la Cnil.
[7] Une personne morale souhaitant héberger des données de santé à caractère personnel pour un tiers est contrainte par le décret du 4 janvier 2006 de disposer de l’agrément Hébergeur de données de santé. Les décisions d’agrément sont rendues par le ministre en charge de la Santé. L’Asip Santé actualise régulièrement la liste des hébergeurs agréés ici : http://esante.gouv.fr/services/referentiels/securite/hebergeurs-agrees[8] Virtual Private Network (ou Réseau privé virtuel en français) : liaison point à point sécurisée (chiffrée) au travers d’Internet.
[9] Le protocole HTTPS est un protocole d’échange entre serveur Web et machines clientes sécurisé par le biais du chiffrement.
[10] Dans une attaque « man in the middle », l’attaquant vient s’interconnecter sur la liaison établie entre une machine cliente et un serveur et absorbe les données qui transitent. Si elles transitent « en clair », pas besoin pour lui d’aller plus loin, il peut les lire aisément.