Le contact tracing passera par une vaste base de données gérée par Sciensano. Pour deux experts, le projet ne présente pas toutes les garanties de sécurités, loin de là.

Le contact tracing se met en place. Les données de santé des patients présentant un diagnostic confirmé ou suspect de COVID-19 auprès de différents prestataires de soins ou organisations actives dans le secteur de la santé seront récoltées. Le gouvernement fédéral en a confié la tâche à Sciensano. Ces données seront traitées dans une banque de données. Outre les données de patients, celle-ci contiendra également les données de personnes avec lesquelles ces patients ont été en contact. Le projet s’inscrit dans le cadre de l’Arrêté Royal du 4 mai 2020.

En découvrant le projet présenté par le Comité de sécurité de l’information Chambre sécurité sociale et santé, Maxime Rapaille, Cyber Security Director chez Cyber Security Management, éprouve des doutes en matière de cybersécurité. «Sans remettre en cause le projet, lequel est mené dans l’urgence compte tenu des circonstances, j’ai le sentiment que la sécurité pourrait en être le parent pauvre. En tant que citoyen, cela me gêne. Par l’ensemble des informations rassemblées, cette banque de données sera -de loin- la plus sensible, et donc celle qui fera l’objet de toutes les attentions malveillantes…»

Un cloud privé n’est pas un gage de sécurité

Les inquiétudes Maxime Rapaille portent sur divers aspects. Le premier est le support de la banque de données, à savoir un cloud privé. «Ce n’est pas nécessairement un gage de sécurité. Qui plus est, il apparait aussi que Sciensano exploite le cloud public d’AWS, qui peut offrir, en fonction du budget, le meilleur comme le pire en sécurité. Au client, aussi, d’activer les bons mécanismes. S’il ne le fait pas, on se trouve dans un système globalement peu protégé…»

Maxime Rapaille : «On aura donc des accès par internet, avec tous les risques que cela suppose…”

Ces messages, renseigne le Comité de sécurité de l’information Chambre sécurité sociale et santé, sont envoyés de manière cryptée au moyen d’un eFORM qui est disponible dans certains logiciels médicaux. Les données enregistrées dans l’eForm seront converties en un fichier csv, lequel sera ensuite envoyé via la eHealthBox à la banque de données centrale. Si un eForm ne constitue pas une option pour le fournisseur de données concerné, il pourra directement transmettre un fichier json ou un fichier cvs via la eHealthBox. Par ailleurs, Sciensano prévoit aussi la possibilité d’envoyer des fichiers directement via le serveur SFTP.

Les risques d’internet

Ce n’est que lorsque les autres solutions ne sont pas possibles que le fournisseur de données aura la possibilité de charger manuellement les fichiers csv sur une page HTTPS au moyen d’un compte et d’un mot de passe.

«On aura donc des accès par internet, avec tous les risques que cela suppose, poursuit Maxime Rapaille. De nombreux scénarios se présentent. Si le corps médical est sensible à la protection des données des patients, il ne l’est pas forcément aux risques technologiques et au management de l’information. A chacun son métier ! Or, ici, ces professionnels pourraient bien être le maillon faible du système.»

Le cryptage du canal est une chose, mais quid en amont et en aval, s’interroge aussi le spécialiste. Si l’effort de transparence est évident, il n’est pas palpable sur toute la chaine d’information. Ainsi, à propos du stockage offline des backups. Rien n’est indiqué sur son effacement. Tiens, tiens…

«On piétine le GDPR»

Du flou, encore, avec l’usage des données. Le Comité estime que les données peuvent être conservées par Sciensano sous forme pseudonymisée pendant une période de 30 ans à compter du décès du patient. A l’issue de cette période, elles pourront uniquement être conservées sous forme anonyme, c’est-à-dire sous une forme qui ne permet pas de les mettre en relation avec une personne identifiée ou identifiable. «Mais comment savoir, au départ de données pseudonymisées, si et quand la personne est décédée ?»

Des doutes, aussi, sur la protection des données. «Il n’est nulle part question de PIA (Privacy Impact Assessment)», constate Jean-Pierre Heymans, Data Protection Director, chez Cyber Security Management. Pour rappel, un PIA repose sur deux piliers. Un : les principes et droits fondamentaux, «non négociables», qui sont fixés par la loi et doivent être respectés, quels que soient la nature, la gravité et la vraisemblance des risques encouru. Deux : la gestion des risques sur la vie privée, qui permet de déterminer les mesures techniques et d’organisation appropriées pour protéger les données.

Le PIA, on l’a compris, s’inscrit dans une démarche d’accompagnement des responsables de traitement dans la mise en œuvre des obligations du GDPR. «On piétine le GDPR», regrette Jean-Pierre Heymans, par ailleurs expert judiciaire auprès des Tribunaux.

La mention à l’Article 14 n’est pas pertinente

Légalement, le Comité peut se retrancher derrière les exceptions de l’article 14 du GDPR. De fait, la collecte et le traitement de données sans le consentement de la personne sont licites en cas de nécessité liée à l’intérêt public. En particulier, le «traitement (…) pour des motifs d’intérêt public dans le domaine de la santé publique, tels que la protection contre les menaces transfrontalières graves pesant sur la santé» est licite. Enfin, la protection des intérêts vitaux de la personne ou d’une autre personne physique peuvent ici aussi être invoquées…

Jean-Pïerre Heymans : “Je m’interroge tout autant sur la légitimité des call centers. A-t-on les garanties suffisantes ? Je ne vois rien qui le démontre…»

L’une des obligations du GDPR est que chaque traitement de donnée à caractère personnel doit disposer d’une base juridique. La base juridique à considérer pour ce traitement est effectivement la nécessité à la sauvegarde des intérêts vitaux de la personne concernée ou d’une autre personne physique.

Le GDPR interdit le traitement de catégories particulières de données à caractère personnel, dont les données de santé font partie. Cette interdiction est soumise à des exceptions, notamment lorsque «le traitement est nécessaire pour des motifs d’intérêt public dans le domaine de la santé publique, tels que la protection contre les menaces transfrontalières graves pesant sur la santé».

Quid des call centers ? Quelles garanties ?

Certes, l’exception est ici patente. Mais quelle sécurité pour le citoyen ? Concrètement, selon le Comité, Sciensano créera et tiendra à jour une page web sur laquelle seront publiées des informations relatives à la banque de données centrale COVID19, conformément à l’article 14 du GDPR. Cette page web permettra aux différents sujets de données (patients, personnes qui ont été en contact avec le patient et les prestataires de soins) de trouver des renseignements sur le traitement des données ainsi que sur leurs droits dans le cadre de la banque de données. On l’a compris, il faudra s’en contenter.

«Je m’interroge tout autant sur la légitimité des call centers. A-t-on les garanties suffisantes ? Je ne vois rien qui le démontre», poursuit Jean-Pierre Heymans. Officiellement, les centres de contact prendront contact avec les personnes chez qui le médecin présume une infection et les personnes dont le test médical était positif et ils s’informeront auprès de ces personnes de leurs fréquentations physiques avec d’autres personnes au cours d’une période déterminée. Ces dernières seront alors contactées à leur tour afin de leur fournir des conseils adéquats quant aux actions à prendre. L’objectif de ce système est d’avertir les personnes qui ont été en contact avec des personnes (potentiellement ou effectivement) infectées, de sorte que ces personnes puissent elles-mêmes se protéger…

«Derrière cette façon de procéder, je vois un réel danger : la possibilité pour ces call centers de recevoir de l’information, de croiser ou enrichir celle-ci avec les bases de données d’organismes externes, tels que des mutuelles. Certes, des échanges nécessaires. Mais hautement sensibles. Qu’il faut encadrer, sécuriser. Et là, à nouveau, je ne vois rien…»

Un mauvais signal pour le citoyen

Globalement, ce projet n’est pas clair en termes de sécurité. Rien n’est précisé sur sa réalisation, que ce soit en termes de protocoles, de tests d’intrusion, etc. «En qualité de citoyen, je découvre de bonnes intentions, qui entretiennent toutefois un faux sentiment de sécurité, analyse Maxime Rapaille. En tant que professionnel, je me sens davantage dans le Security by Obscurity, plutôt que dans le Security by Design… comme il y a trente ans ! Et cela, je ne peux l’accepter.»

Même ressenti de Jean-Pierre Heymans. «Nulle part, le Comité ne mentionne la présence d’un DPO (Data Protection Officer). N’est-ce pas là reconnaitre que le GDPR est bafoué ? C’est, clairement, un mauvais signal pour les citoyens.»

Quid, enfin, de l’APD, l’Autorité de Protection des Données ? Nos deux experts la voudraient plus proactive, plus engagée. Après tout, n’est-elle pas là pour protéger le citoyen ?

«Des projets conduits dans l’urgence, j’en ai connus. La pression du temps, je sais ce que c’est, conclut Maxime Rapaille. Notamment les possibles rétropédalages quand ça ne va pas. Mais, ici, peut-on se le permettre ? Il ne s’agit pas d’une application commerciale, mais d’une application de santé publique. Les risques ne semblent pas avoir été évalués. Or, ils sont ici gigantesques. La question est simple : peut-on se permettre une fuite de données ?»

Alain de Fooz