Données sensibles: manquements aux obligations de sécurité

Photo de Sebastiaan Stam sur Pexels.com

Introduction

Il ne se passe pas un jour sans que la presse ne se fasse l’écho de violations plus ou moins importantes de la sécurité des données, que ce soit auprès d’acteurs économiques privés ou publics, d’institutions diverses et variées, de différents prestataires de services, etc. Encore tout récemment, ce sont des données médicales « siphonnées » de cabinets médicaux neuchâtelois qui se sont retrouvées sur le darknet (https://www.20min.ch/fr/story/dossiers-medicaux-hackes-les-patients-peuvent-se-rebiffer-327444964063).

Il importe de comprendre que ces incidents, parfois très sérieux et dommageables pour les personnes concernées, reposent certes sur l’activité criminelle de leurs auteurs, mais aussi (et j’allais dire surtout) sur des manquements aux obligations de sécurité chez les responsables de traitements. Il existe en effet une interaction entre la protection des données et leur sécurité. La protection des données relève de la protection de la personnalité de l’individu. Quant à la sécurité des données, elle vise généralement les données présentes chez un responsable du traitement ou chez un sous-traitant et englobe le cadre organisationnel et technique général du traitement des données. La protection de la personnalité de l’individu n’est donc possible que si des mesures techniques et organisationnelles ont été prises pour assurer la sécurité des données le concernant au préalable. (Message du 15 septembre 2017 concernant la loi fédérale sur la révision totale de la loi fédérale sur la protection des données et sur la modification d’autres lois fédérales, FF 2017 6565, 6650-6651)

Comment définir alors concrètement les mesures techniques et organisationnelles requises, tout particulièrement quand on traite des données sensibles ? On verra qu’il est difficile de donner des règles générales, valables dans tous les cas de figure, mais qu’il est possible de faire une analyse de la sécurité centrée sur le risque, en s’inspirant des standards généralement reconnus et des décisions européennes en la matière. Il ne s’agira évidemment pas ici de demander que les responsables RH, les juristes ou les DPO se muent en informaticiens chevronnés, mais de préciser les standards et les exigences que l’on peut attendre des différentes parties (responsables de traitement, co-responsables, sous-traitants, mandataires).

Les obligations de sécurité en droit suisse

A teneur de l’art. 7 al. 1 de la loi fédérale du 19 juin 1992 sur la protection des données (RS 235.1 ; LPD) les données personnelles doivent être protégées contre tout traitement non autorisé par des mesures organisationnelles et techniques appropriées. C’est le principe de sécurité, dont la violation entraîne la présomption d’une atteinte illicite à la personnalité des personnes concernées selon l’art. 12 al. 2 let. a LPD. L’art. 7 al. 2 LPD prévoit que le Conseil fédéral édicte des dispositions plus détaillées sur les exigences minimales en matière de sécurité des données. Le Conseil fédéral a donc développé la matière plus avant aux art. 8 à 11 de l’ordonnance du 14 juin 1993 relative à la loi fédérale sur la protection des données (RS 235.11 ; OLPD).

La nouvelle loi fédérale du 25 septembre 2020 sur la protection des données (nLPD ; FF 2020 7397), qui devrait entrer en vigueur courant 2023, prévoit aussi en son art. 8, que les responsables du traitement et les sous-traitants doivent assurer, par des mesures organisationnelles et techniques appropriées, une sécurité adéquate des données personnelles par rapport au risque encouru. Il s’agit d’une approche fondée sur le risque : plus le risque d’une atteinte à la sécurité des données est élevé, plus les exigences auxquelles doivent répondre les mesures à prendre seront élevées. Les mesures doivent permettre d’éviter toute violation de la sécurité des données (art. 8 al. 2), soit toute violation de la sécurité entraînant la perte de données personnelles, leur modification, leur effacement ou leur destruction, leur divulgation ou un accès non autorisé à celles-ci, et ce indépendamment de savoir si la violation est intentionnelle ou non, licite ou illicite. Les mesures peuvent viser par exemple à pseudonymiser des données, à assurer la confidentialité et la disponibilité du système ou de ses services, ou encore à élaborer des procédures visant à tester, à analyser et à évaluer régulièrement l’efficacité des mesures prises. Selon le même mécanisme que pour la LPD actuelle, le Conseil fédéral édicte par ailleurs des dispositions sur les exigences minimales en matière de sécurité des données.

Ces dispositions figurent aux art. 1 à 5 de l’Avant-projet d’Ordonnance relative à la loi fédérale sur la protection des données (nOLPD), dont la procédure de consultation a abouti provisoirement à une révision – toujours en cours – dudit projet [cf. OFJ, Révision totale de l’ordonnance relative à la loi fédérale sur la protection des données, Rapport explicatif relatif à la procédure de consultation, 23 juin 2021, pp. 14-22]. Selon l’OFJ, il a été renoncé à inscrire des exigences minimales strictes dans la nOLPD car la loi suit une approche fondée sur le risque et qu’il est impossible de fixer des exigences minimales générales applicables à chaque branche. L’approche suivie repose plutôt sur le fait qu’il incombe en premier lieu au responsable du traitement de déterminer les mesures nécessaires dans un cas précis, et de les prendre. Ces mesures ne peuvent donc être prises qu’au  cas par cas, et leur portée dépend du risque encouru. En toute logique, les exigences sont ainsi plus élevées pour un hôpital qui traite régulièrement des données sensibles que pour une boulangerie ou une boucherie qui traite les données de ses clients ou de ses fournisseurs. La nOLPD contient donc surtout des lignes directrices permettant de déterminer les mesures à prendre. Cela permet de garantir la flexibilité nécessaire pour couvrir le large éventail de cas et éviter un excès de réglementation, en particulier pour les entreprises pour lesquelles les traitements de données sont rares et présentent peu de risques. Les mesures spécifiques pour la garantie de la sécurité des données prévues dans le droit en vigueur sont par ailleurs conservées (journalisation, règlements de traitement).

La nature des données traitées, et particulièrement leur caractère sensible, est évidemment un facteur important dans l’appréciation du risque. Rappelons donc ici que l’art. 3 let. c LPD définit les données sensibles comme des  données personnelles sur: 1. les opinions ou activités religieuses, philosophiques, politiques ou syndicales, 2. la santé, la sphère intime ou l’appartenance à une race, 3. des mesures d’aide sociale, et 4. des poursuites ou sanctions pénales et administratives. La nLPD (art. 5 let. c) évoque 1. les données sur les opinions ou les activités religieuses, philosophiques, politiques ou syndicales, 2. les données sur la santé, la sphère intime ou l’origine raciale ou ethnique, 3. les données génétiques, 4. les données biométriques identifiant une personne physique de manière univoque, 5. les données sur des poursuites ou sanctions pénales et administratives, et 6. les données sur des mesures d’aide sociale.

Définir le contenu concret des obligations de sécurité

Peut-on, pour définir concrètement dans un cas d’espèce ce que peuvent être les mesures techniques et organisationnelles appropriées et aptes à assurer la sécurité des données, s’inspirer du droit européen et des décisions prises par les différentes autorités de contrôle ?

La réponse nous apparaît être très largement positive. En effet, on peut déjà relever que, selon le Conseil fédéral, les exigences de sécurité de la nLPD devraient correspondre à celles découlant du RGPD et être compatibles avec elles (Révision totale de l’ordonnance relative à la loi fédérale sur la protection des données, Rapport explicatif, 23 juin 2021, p. 10). Par ailleurs, les décisions relatives à la sécurité se basent également sur les nombreux standards de la branche (normes ISO27000, NIST, NCSC, etc.)  dont le juge suisse s’inspirera aussi.

C’est dire l’intérêt de la décision prise par l’Information Commissioner’s Office (ICO) le 10 mars 2022 concernant certaines mesures de sécurité en rapport avec le traitement et le stockage de données sensibles [Information Commissioner’s Office, Tuckers Sollicitors LLP monetary penalty notice, 10 mars 2022 : https://ico.org.uk/action-weve-taken/enforcement/tuckers-solicitors-llp-mpn/, ci-après abrégée ICO MPN, puis le numéro des considérants]. Elle illustre, très concrètement, ce que peuvent être les obligations de sécurité d’un responsable de traitement de données sensibles, et ce qu’il peut être attendu de lui en matière de mesures techniques et organisationnelles, étant toutefois rappelé que chaque cas est un cas particulier en la matière.

Les faits et leur appréciation

Tuckers Sollicitors LLP est une grande étude d’avocats présente dans plusieurs villes en Grande-Bretagne et qui est active principalement dans le droit pénal. Elle a été victime d’un piratage qui a (i) crypté des données présentes sur un serveur et (ii) publié certaines de ces données sur le darkweb, étant rappelé que les données concernées étaient des données sensibles.

L’ICO, après une instruction fouillée, met en avant plusieurs violations aux obligations de sécurité, concernant l’authentification multifacteur, le « patch management » et le cryptage des données stockées.

Concernant l’authentification multifacteur, elle se caractérise par le fait que l’utilisateur ne se soumet pas qu’à un seul mécanisme d’authentification (mot de passe p.ex.) mais à plusieurs (mot de passe, puis envoi et saisie d’un code par SMS p.ex.). [Voir par exemple : (https://www.cnil.fr/fr/securite-utilisez-lauthentification-multifacteur-pour-vos-comptes-en-ligne; Guide ANSSI, Recommandations relatives à l’authentification multifacteur et aux mots de passe, version 2.0 du 08.10.2021 https://www.ssi.gouv.fr/guide/recommandations-relatives-a-lauthentification-multifacteur-et-aux-mots-de-passe/]

Le problème de l’authentification simple est que la sécurité repose alors sur un seul facteur. Par conséquent, si cet unique facteur d’authentification est compromis, un pirate pourra agir librement. Cela explique d’ailleurs que les premières cibles d’attaque des pirates informatiques sont le plus souvent les identifiants de connexion (identifiant de compte – le plus souvent une adresse mail – et le mot de passe). L’authentification multifacteur permet donc de renforcer la sécurité grâce à l’ajout d’un ou de plusieurs facteurs d’authentification. Elle est parfois désignée par le sigle « 2FA » (pour l’anglais « 2-factor authentication », authentification à deux facteurs), par « validation en deux étapes » ou encore « MFA » (pour l’anglais « multi-factor authentication », l’authentification multifacteur).

Dans le cas d’espèce, les données traitées étaient particulièrement sensibles. Il n’était donc pas admissible que l’accès aux données ne soient protégées que par la simple indication d’un « username » et d’un mot de passe :

«Taking into consideration the highly sensitive nature of the personal data that Tuckers was processing, as well as the state of the art of MFA, and the costs of implementation, Tuckers should not have allowed access to its network using only a single username and password. In doing so, it did not ensure appropriate security, including protection against unauthorised and unlawful processing of its personal data, as required by Article 5(l)(f) GDPR. » (ICO, MPN N 49)

Pour ce qui est du « patch management », un patch ou correctif est une section de code que l’on ajoute à un logiciel pour y apporter des modifications. Les éditeurs y recourent par exemple pour corriger des vulnérabilités de sécurité mises à jour dans leurs produits. Les utilisateurs doivent alors installer le patch dans leurs systèmes pour atteindre l’objectif poursuivi. C’est ce qui s’est passé dans le cas d’espèce, l’éditeur ayant indiqué au mois de janvier 2020 avoir identifié une vulnérabilité et mis à disposition un patch… que le responsable de traitement n’a installé qu’au mois de juin, soit plus de quatre mois après que le patch soit disponible. L’identification, par l’éditeur, avait été mise sur son site internet, et différents acteurs avaient publiés sur cette question ou étaient intervenus pour signaler le problème.

Pour l’ICO, les standards généralement reconnus imposent que l’on se fixe des délais de mises en œuvre pour installer les patch une fois que le problème est reconnu et dûment communiqué par l’éditeur et/ou par des tiers. Une vulnérabilité importante dans une système traitant des données sensibles aurait dû pousser le responsable de traitement à installer le patch dans un délai de 14 jours au plus  dès sa mise à disposition, étant par ailleurs relevé que ledit patch était mis à disposition gratuitement. Plus généralement, le responsable de traitement doit avoir édicté des directives concernant la gestion des patch et les mises à jour logiciel pour s’assurer qu’ils soient mis en œuvre efficacement et sans retard. (ICO MPN N 57 ss)

Enfin, s’agissant du cryptage des données stockées, l’ICO souligne que cela n’aurait certes pas empêché la violation de sécurité, mais bel et bien limité ses conséquences :

« This is because effective encryption management, with appropriate protection of the decryption keys, can prevent an unauthorised party such as a malicious attacker from being able to read the personal data once they have obtained access to systems. Such encryption would therefore have upheld the principles of confidentiality of the personal data, even in its exfiltrated form. » (ICO MPN N63)

Les standards généralement reconnus recommandent le cryptage des données sensibles, ce qui est possible grâce à des solutions techniques facilement disponibles. La pratique semble également généralement reconnue dans les études d’avocats pour les données sensibles des clients. Et l’ICO de conclure sur ce point :

« Taking into consideration the highly sensitive nature of the personal data that Tuckers were processing, as well as the state of the art of encryption, and the costs of implementation, Tuckers should not have been storing the archive bundles in unencrypted, plain text format. In doing so, it did not ensure appropriate security, including protection against unauthorisedand unlawful processing of its personal data, as required by Article S(l)(f) GDPR. » (ICO MPN N 67)

Me Philippe Ehrenström, avocat, LLM, CAS, Genève et Onnens (VD)

A propos Me Philippe Ehrenström

Ce blog présente certains thèmes juridiques en Suisse ainsi que des questions d'actualité. Il est rédigé par Me Philippe Ehrenström, avocat indépendant, LL.M. (Tax), Genève et Yverdon.
Cet article, publié dans nouvelle LPD, Protection de la personnalité, Protection des données, RGPD, est tagué , , , , , , , , . Ajoutez ce permalien à vos favoris.

Votre commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s