La messagerie en établissement de santé : le casse-tête du RSSI
Le courriel, email, mail, mél, ou tout autre nom que l’on voudra bien lui attribuer, fait aujourd’hui partie de notre quotidien à tous. Qui l’aurait cru il y a encore quelques décennies ?
Sûrement pas son inventeur, le regretté Ray Tomlinson1 qui réussit cet exploit d’envoyer un message d’un poste A à un poste B reliés à un même réseau, un jour d’automne 1971. N’oublions pas qu’à cette époque, les réseaux n’étaient pas encore interconnectés, que le réseau Arpanet n’en était qu’à ses prémices, que Louis Pouzin2 n’avait pas encore inventé le principe de commutation de paquets et que TCP/IP n’avait pas encore vu le jour.
Ce n’est qu’en 1980 que le protocole SMTP3, que l’on utilise toujours aujourd’hui commença à se répandre dans les réseaux TCP/IP avec l’apparition de Sendmail4.
À cette époque, Internet n’existait pas encore.
Le fait est qu’aujourd’hui, c’est toujours ce bon vieux protocole SMTP qui est utilisé pour l’échange des messages entre les différents serveurs et relais de messagerie répartis sur le réseau Internet mondial.
On lui connaît trois principales vulnérabilités :
- une absence totale de confidentialité puisque les messages transitent « en clair » sur les réseaux
- l’impossibilité d’assurer l’authenticité d’un message, puisque l’adresse expéditrice est un simple champ texte dans lequel il est possible d’écrire ce que l’on souhaite
- l’impossibilité d’assurer l’intégrité du contenu d’un message
Des recommandations de paramétrage et des solutions de protection se sont donc greffées autour de ce protocole, dans le but d’améliorer la sécurité des échanges. En France par exemple, l’AFA, devenue aujourd’hui l’AFPI (Association Française des Prestataires d’Internet) a recommandé en 2006 à l’ensemble des FAI (fournisseurs d’accès Internet) de bloquer l’expédition de messages depuis leurs relais SMTP aux utilisateurs non authentifiés (via leur IP ou SMTPS), ce qui a grandement limité la diffusion de messages de spams et l’usurpation d’adresses de messagerie, même si nous en recevons toujours beaucoup trop.
Alors, comment améliorer la sécurité de sa messagerie en 2018 ?
1. La solution « facile », confier sa messagerie à un prestataire
Une fausse bonne idée à mon sens, en particulier pour un établissement de santé. Pourquoi ? Tout d’abord car la messagerie est avant tout utilisée pour communiquer en interne et des informations de santé à caractère personnel y seront forcément échangées. Alors, vous me direz, tous les fournisseurs proposant ce type de service utilisent des protocoles de chiffrement pour sécuriser les échanges de messages entre votre SIH et leur infrastructure. Certes, mais très peu sont hébergeurs de données de santé (HDS). Donc en faisant le choix d’héberger sa messagerie chez Google ou sur Office 365, il est quasi certains que vous ne respectiez pas le décret HDS. Quel DSI, RSI, RSSI peut affirmer être sûr à 100 % qu’aucun utilisateur de son établissement n’échangera de données patients sur sa messagerie professionnelle (non MSSanté), ne serait-ce qu’avec des collègues en interne.
Si vous vous dites qu’aucun établissement de santé n’aurait pu faire ce choix, et bien, détrompez-vous.
Ici un établissement de santé français dont la messagerie est hébergée chez Google, avec potentiellement des données de santé qui se baladent sur des serveur outre-Atlantique
Ici un établissement qui a fait le choix d’héberger sa messagerie chez Microsoft, avec le même risque potentiel.
Le deuxième risque important de l’externalisation est selon moi, la perte d’accès à cet outil de communication interne en cas d’impossibilité d’accès à Internet, dont les causes peuvent être multiples, attaque DDoS5, travaux, panne opérateur, panne interne, catastrophe naturelle etc.… ou encore une panne de l’hébergeur…
Ça arrive même aux grands !
Une indisponibilité totale de la messagerie dans un établissement de santé est aujourd’hui, difficilement acceptable. Il faut bien avoir en tête qu’en 2018, une indisponibilité de la messagerie au sein d’un établissement de santé peut avoir un impact sanitaire important, car la messagerie n’est pas seulement utilisée par des humains, mais peut également l’être par des automates pour l’envoi de résultats d’analyses, les commandes de poches de sang à l’EFS etc...
2. Quelques pistes pour sécuriser sa messagerie hébergée en interne
La messagerie hébergée en interne est la première porte ouverte sur la « jungle » que peut représenter le réseau Internet mondial. Alors voici quelques réflexions pour essayer d’améliorer sa sécurité.
- Sécuriser les accès :
- Restreindre les machines autorisées à utiliser votre / vos serveur(s) de messagerie comme relais SMTP
- Forcer l’authentification utilisateur pour l’envoi de messages
- Utiliser des protocoles s’appuyant sur une solution de chiffrement pour l’émission (SMTPS), réception (IMAPS, POPS) et accès Web (HTTPS)
- Limiter les accès externes au SIH. Privilégier l’utilisation de terminaux appartenant à l’établissement, maîtrisés par la DSI.
- Utiliser un reverse proxy pour les accès Web externes.
- Limiter le spam, phishing et autres pièges :
- Interdire la réception depuis l’extérieur, de messages en provenance de son / ses propre(s) nom(s) de domaine. Cela permet d’éviter de recevoir des messages avec des adresses expéditrices usurpées de son établissement. Croyez-moi, ce genre d’arnaques se pratique toujours, et neuf fois sur dix les utilisateurs tombe dans le panneau.
- Activer SPF6 sur votre nom de domaine afin de permettre aux destinataires utilisant une solution « anti spam » de s’assurer que les messages en provenance de votre nom de domaine ont bien été envoyés depuis les serveurs que vous avez autorisés.
Je constate de plus en plus de noms de domaine pour lesquels SPF est activé, mais la configuration est souvent incohérente, ce qui fait que les « anti spam » placent directement les messages en quarantaine. Alors, s’il vous plaît, avant de mettre en place SPF sur votre nom de domaine, allez faire un tour sur le site d’Open SPF7 ou utilisez un générateur comme SPF Wizard8.
- Activer SPF sur votre solution « anti spam » pour vous assurer de ne pas recevoir de messages en provenance de domaine usurpés (à condition que SPF ait été configuré correctement par les expéditeurs).
- L’utilisation du mécanisme de signature des messages DKIM9 peut s’avérer également un excellent complément à SPF.
- Utiliser une solution de chiffrement :
L’utilisation du mécanisme de chiffrement et signature numérique PGP / GPG reste un excellent moyen d’assurer la confidentialité de ses correspondances. Parfois fastidieux à mettre en place, il permet de pallier aux vulnérabilités de base du protocole SMTP : confidentialité, authenticité et intégrité des données. Pour intégrer nativement le chiffrement des messages envoyés depuis votre serveur de messagerie à partir du moment où l’expéditeur a mis à disposition sa clé publique dans un annuaire, vous pouvez aller jeter un coup d’œil du côté du projet Zeyple10.
Dommage que PGP / GPG soit toujours sous utilisé aujourd’hui, il pourrait être un excellent pilier d’une MSSanté 2.0 et permettrait de repousser ses limites, dont la principale est de ne pas pouvoir échanger avec des correspondants non MSS...
1 https://fr.wikipedia.org/wiki/Ray_Tomlinson
2 https://fr.wikipedia.org/wiki/Louis_Pouzin
3 https://fr.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol
4 https://fr.wikipedia.org/wiki/Sendmail
5 https://fr.wikipedia.org/wiki/Attaque_par_déni_de_service
6 https://fr.wikipedia.org/wiki/Sender_Policy_Framework
7 http://www.openspf.org/SPF_Record_Syntax
8 https://www.spfwizard.net
9 https://fr.wikipedia.org/wiki/DomainKeys_Identified_Mail
10 https://github.com/infertux/zeyple