Près de trois quarts des sanctions prononcées par la Commission Nationale de l’Informatique et des Libertés (CNIL) ont parmi leurs causes des vulnérabilités techniques de sécurité. À partir de ce constat, et au prisme de notre expérience à la fois en cybersécurité technique et en protection des données à caractère personnel, nous avons analysé les sanctions de la CNIL publiées sur le site https://www.legifrance.gouv.fr/. Nous avons notamment établi une correspondance avec les catégories de vulnérabilités techniques identifiées dans la nomenclature du top 10 de l'OWASP 2017 (Open Web Application Security Project). Nous avons également étudié les fuites de données majeures survenues en Europe et dans le monde. Il en ressort que les vulnérabilités les plus communes sont liées à l’authentification, au contrôle d’accès et à la protection des données au repos et en transit.
Depuis l’entrée en application du Règlement Général sur la Protection des Données (RGPD) en mai 2018 jusqu'au moment de la rédaction de cet article (fin 2019), la CNIL a rendu publiques 4 sanctions. 3 d’entre elles concernent au moins un défaut de sécurité. Rapporté aux 99 articles qui composent le RGPD, force est de constater que seul l’un d’entre eux cristallise l’essentiel des sanctions, l’article 32 relatif à la sécurité. Ces sanctions illustrent en outre qu’il ne suffit pas de mettre en place une gouvernance et des procédures de sécurité pour être conforme au RGPD. Il s’agit aussi de « mettre les mains » dans les systèmes d’information pour mettre en place et contrôler les dispositifs techniques de sécurité, afin d’éviter les failles. En effet, la majorité des vulnérabilités ayant fait l’objet de sanctions auraient pu être détectées, au travers de tests d’intrusion par exemple, en amont des mises en production.
En matière de sécurité, le RGPD n’apporte pas de nouvelles exigences. La raison pour laquelle le sujet se retrouve sur le devant de la scène est l’explosion du plafond des sanctions imposables. Le règlement fixe deux plafonds : les violations et négligences les plus graves peuvent entraîner une amende de 4% du chiffre d’affaires annuel global ou 20 millions d’euros, les défauts de sécurité peuvent engendrer des amendes plafonnées à 2% du chiffre d’affaires annuel global ou 10 millions d’euros. Mais la récidive fait monter le plafond à 4% du chiffre d’affaires ou 20 millions d’euros.
Depuis 2016, la CNIL a prononcé 22 sanctions publiques dont l’une des causes était une vulnérabilité technique, sur un total de 32 sanctions publiées. Ces sanctions ont toutes ou presque débouché sur des amendes pécuniaires. Les montants des amendes dépendent des cas et de la taille de l’organisme contrôlé, et sont par conséquent fluctuants d’une sanction à l’autre, mais ils concernent au global une part croissante des chiffres d’affaires des entreprises. Notons également que tous les secteurs d’activité sont concernés.
Les vulnérabilités observées ont quant à elle quelque peu évolué. Là où en 2016, il s’agissait surtout d’exposition de données sensibles comme l’envoi de données en clair sur Internet, les vulnérabilités liées à l’authentification et au contrôle d’accès sont aujourd’hui prédominantes. Toutefois, l’un n’empêche pas l’autre. Certaines sanctions sont le résultat de plusieurs vulnérabilités simultanées. Dans la plupart des cas, l’infraction initiale qui mène à un contrôle - à distance ou sur place - de la CNIL conduit à l’identification de nouvelles vulnérabilités, qui viennent s’ajouter au socle de la sanction finale.
Les vulnérabilités mentionnées sont en phase avec les problèmes de sécurité les plus souvent constatés par la CNIL en 2018 [1], à savoir des problèmes d’authentification (faiblesse ou absence totale), de contrôle d’accès (utilisation de paramètres incrémentaux dans les requêtes) et de protection des données en transit ou au repos. Cet article élargit le champ d’analyse en regroupant l’ensemble des sanctions et en les comparant au référentiel connu par tous les professionnels de la sécurité, à savoir l’OWASP.
1. Les sanctions de la CNIL à date
Les sanctions publiques de la CNIL prononcées entre 2016 et 2019, dont 70% présentant des vulnérabilités de sécurité, montrent un nombre assez réduit de typologies de vulnérabilités sanctionnées, comme illustré dans le tableau de la figure 1. Les vulnérabilités les plus observées sont les problèmes d’authentification, des faiblesses dans le contrôle d’accès, des erreurs de configuration et un manque de protection des données au repos et en transit. En effet, sur l’ensemble des 3 années cumulées, une vulnérabilité dans l’authentification a été identifiée pour 64% des sanctions, dans le contrôle d’accès pour 46% des sanctions, l’exposition de données sensibles pour 32% des cas et une mauvaise configuration de sécurité pour 14% des sanctions.
Lorsque l’on recoupe l’ensemble des vulnérabilités avec le top 10 de l’OWASP (2017) sans distinction des sanctions, il ressort, comme illustré dans la figure 2, que les vulnérabilités de catégories « A2:2017-Broken Authentication », « A5:2017-Broken Access Control » et « A3:2017-Sensitive Data Exposure » dominent largement le paysage. Les failles d’authentification (A2:2017-Broken Authentication) observées correspondent à des défauts de robustesse de mots de passe et à l’absence de protection contre des attaques de brute force, ce qui peut permettre aux attaquants d’usurper l’identité d’utilisateurs légitimes. Les défauts de contrôle d’accès (A5:2017-Broken Access Control) sont quant à eux majoritairement liés à des problèmes de Direct Object Reference (DOR) causés par des applications web qui ne valident pas correctement qu’un utilisateur a des droits de lecture/écriture sur des objets (page web, dossier client) ou sur un objet côté serveur. Ces objets, qui contiennent souvent des données à caractère personnel, deviennent alors accessibles par la simple modification d’un paramètre de l’URL. Notons que le DOR était une vulnérabilité à part entière dans le top 10 de l’OWASP 2013 (A4:2013-Insecure Direct Object References). En troisième position viennent les défauts de protection des données au repos et en transit (A3-2017 Sensitive Data Exposure), qui sont principalement liés à l’utilisation de protocoles d’échange sans chiffrement comme HTTP, le stockage de données en clair ou encore l’utilisation de suites cryptographiques faibles.
2. Analyse des sanctions liées à des défauts dans l’authentification
Dans 64% des sanctions liées à la sécurité, la CNIL a identifié des défauts d’authentification (A2:2017-Broken Authentication) comme l’absence d’une politique robuste de mots de passe, l’absence de mécanisme de protection contre les attaques par force brute ou l’absence totale d’authentification, causant l’accès à des données utilisateur par n’importe quel internaute.
Le manque de robustesse des mots de passe arrive en tête et a fait l’objet de sanctions chez des organismes opérant dans des secteurs d’activité diversifiés tels que les transports [2] et la rénovation [3]. Ces deux sociétés ont en effet été sanctionnées sur ce fondement en 2017. Encore aujourd’hui, la CNIL continue de sanctionner sur ce motif. On peut citer un assureur automobile [4], qui a fait l’objet d’une sanction publique de la CNIL en juillet 2019, car il imposait à ses clients un format de mot de passe faible correspondant à leur date de naissance.
Néanmoins, il ne suffit pas de prévoir des mesures d’authentification, encore faut-il sécuriser le stockage des informations de connexion. Ainsi, une société de VTC [5] a subi un vol de données personnelles courant 2018, rendu possible par le stockage en clair d’identifiants dans le code source sous « GitHub » et l’absence de moyens de vérification de connexion comme les 2FA (authentification à deux facteurs).
3. Analyse des sanctions liées à des défauts dans le contrôle d’accès
Dans 46% des sanctions liées à la sécurité, la CNIL a identifié des vulnérabilités dans le contrôle d’accès (A5:2017-Broken Access Control) permettant par exemple, par la simple modification d’un paramètre de la requête envoyée au serveur, d’accéder aux données d’autres utilisateurs, en d’autres termes, un Direct Object Reference sur les données d’un utilisateur.
En 2018, une société dans le secteur de la distribution [9] a écopé d’une amende pour une faille permettant d’accéder librement à l’ensemble des demandes et des données renseignées par les clients, via un formulaire en ligne de demande de service après-vente. L’URL permettant l’accès aux données était http://www.example.com/self*****/requests.do?id=XXX, où XXX est l’identifiant client. La simple modification du paramètre XXX, un entier, permettait de tomber sur les données d’un autre client. Il était en outre très simple d’automatiser les requêtes pour récupérer des données en masse. De façon similaire, un acteur dans le monde du transport [13] a été sanctionné pour un défaut de contrôle d’accès permettant d’accéder aux données d’un autre utilisateur par la simple modification de l'ID dans l’URL https://www.exemple.com/api/v1/user/get?id=X.
Autre exemple, une société dans le secteur de la distribution [6] a été sanctionnée suite à une fuite de données sensibles survenue en 2018 et permise par un DOR sur son site web. La CNIL a pu aussi constater qu’il était possible d’exporter, depuis le site web, des fichiers CSV comportant des données de clients sans aucune authentification ni contrôle d’accès. À l’occasion de cette violation de données, comprenant notamment des numéros de sécurité sociale de clients, la CNIL n’a pas omis de montrer que « […] la société a réagi immédiatement après la révélation de la faille pour corriger cette dernière, [la CNIL] relève toutefois que les mesures élémentaires de sécurité n’avaient pas été prises en amont de la mise en production d’une nouvelle fonctionnalité de son site internet », soulignant ainsi la nécessité de conduire entre autres des tests d’intrusion avant les mises en production.
La même année, la CNIL a sanctionné pour ce même défaut une association [7]. Suite à la réponse de l’association qui a dit que le défaut était facilement corrigeable, la CNIL n’a pas hésité à rappeler que si le défaut était rapidement corrigeable, c’est qu’il aurait pu être tout aussi facilement évité ! « Tout en soulignant la diligence de l’association qui a réagi rapidement après la révélation de l’incident pour le corriger, la formation restreinte relève que les mesures élémentaires de sécurité n’avaient pas été prises en amont du développement de son site internet […] La formation restreinte estime que l’association aurait dû mettre en place de telles mesures élémentaires qui, au surplus, ne requéraient pas de développements importants, ni coûteux. ».
Bien qu’il s’agisse d’un défaut de sécurité fréquemment relevé, la CNIL a eu l’occasion de sanctionner à nouveau sur ce fondement lors de ses toutes premières sanctions prononcées sur la base du RGPD. Elle a ainsi sanctionné respectivement en mai et en juillet 2019 un promoteur immobilier [8] et un assureur automobile suite à la divulgation de documents clients accessibles via la modification de paramètres dans les URL d’accès. Ainsi et à titre d’exemple, sur le site web du promoteur immobilier, les URL permettant de télécharger des documents étaient de la forme https://www.example.example.com/documents/upload/******/XXX.pdf, où XXX est un nombre entier. La modification de la valeur de XXX permettait à toute personne ayant connaissance de l’URL de télécharger les documents (comprenant notamment des jugements de divorce), sans que la création préalable d’un compte sur le site ne soit nécessaire.
4. Analyse des sanctions liées à l’exposition de données sensibles
Dans 32% des sanctions liées à la sécurité, une vulnérabilité liée à la protection des données en transit et au repos (A3 : 2017 - comme Sensitive Data Exposure) a été identifiée. Les faits observés sont l’utilisation de protocoles vulnérables ou d’algorithmes cryptographiques faibles et l’absence totale de protocoles de sécurité comme l’utilisation de HTTP.
Un acteur du e-commerce [10] a ainsi été sanctionné en 2016 en raison de l’absence de sécurisation de son site, la version accessible par défaut utilisant HTTP. En particulier, les pages de connexion des utilisateurs et les pages comportant un formulaire de renseignement de données à caractère personnel étaient transmises en HTTP, donc non sécurisées. La même année, un autre e-commerçant [11] a été sanctionné puisqu’il conservait au repos les numéros de cartes bancaires de ses clients en clair dans des champs de commentaires.
Plus récemment, la CNIL a sanctionné peu avant les fêtes de fin d’année un acteur du monde des jouets innovants pour enfants [12] pour non-respect de la vie privée des joueurs. En effet, tout équipement disposant de Bluetooth était en mesure de détecter un jouet allumé et de s’appairer à celui-ci, d’écouter à distance les conversations captées par le microphone des jouets et de communiquer via le jouet, sans aucune authentification. En outre, la transcription en texte des conversations échangées entre les utilisateurs et les jouets était envoyée depuis le serveur de la société vers des applications distantes via HTTP.
Un acteur de l’assurance [4] a été également sanctionné en juillet 2019, entre autres, pour avoir transmis en clair dans le corps des mails les mots de passe des utilisateurs après la création des comptes.
D’autres acteurs ont été sanctionnés, entre autres, pour avoir laissé traîner des identifiants de connexion dans des GitHub [5], l’absence de chiffrement des données au repos [16] et le stockage du sel (salt) dans la même base que les condensés (hash) des mots de passe [2].
5. Analyse des sanctions liées à une mauvaise configuration de la sécurité
Dans 14% des sanctions liées à la sécurité, la CNIL relève un défaut dans la configuration de la sécurité (A6-2017-Security Misconfiguration). En 2017, une société de transports [13] a ainsi été sanctionnée, entre autres, parce que l’API publiée par le site renvoyait des informations sur les utilisateurs qui étaient censées rester dans le backoffice. En effet, une requête comme https://www.example.com/api/car/search?dpt=75 retournait l'ensemble des voitures proposées dans le département donné en paramètre, ainsi que les données des propriétaires et des clients qui avaient loué ces voitures précédemment. Ces données étaient renvoyées dans le JSON de la réponse, mais n’étaient pas affichées sur le navigateur. Par ailleurs, dans le cadre de la sanction d’un acteur de l’assurance [4], les documents clients étaient également indexés par les moteurs de recherche comme DuckDuckGo, Bing, Qwant et Yahoo, pour cause, entre autres et selon la CNIL, d’une mauvaise configuration dans le fichier « robots.txt ».
6. Analyse des sanctions liées à d’autres défauts de sécurité
Parmi les autres failles de sécurité recensées par l’OWASP, les injections et l’utilisation de composants présentant des vulnérabilités connues, sont présentes chacune dans 5% des sanctions de la CNIL liées à la sécurité.
En 2016, un parti politique français [14] a écopé d’un avertissement pour avoir divulgué les noms de ses adhérents en raison de l’utilisation de la méthode GET qui envoie le secret d’authentification de l’utilisateur dans les paramètres de l’URL, sachant que le secret contenu au sein de l’URL était haché à l’aide de MD5 sans sel. En 2018, une société de multimédia [15] a subi une attaque de type « injection SQL », qui a permis d’exécuter des requêtes SELECT sur les tables user et user_passwords de la base de données du site web. Le rapport de la CNIL fait état de la combinaison de six facteurs pour l’exploitation, à savoir « 1. un accès frauduleux au code source de la société (stocké sur GitHub), 2. l’identification d’un bug exploitable de manière malveillante au sein des centaines de milliers de lignes de code de la plateforme, 3. le développement d’une compréhension de l’architecture de la plateforme permettant d’identifier les conditions nécessaires et suffisantes à l’exploitation malveillante du bug, 4. le développement d’un code d’exploitation spécifique à même de déclencher et de tirer profit du bug, 5. la capacité de détourner un compte d’administration pour exploiter le bug identifié, 6. la propagation de l’intrusion depuis les serveurs web vers des données tout en masquant son identité réelle par un jeu de rebonds vers des serveurs loués spécifiquement à ces fins ».
7. Analyse des autres fuites de données en dehors de la France
En Europe et dans le monde, le paysage des vulnérabilités ayant conduit à des fuites de données connues et relayées dans la presse, sanctionnées ou non, est similaire à celui des sanctions de la CNIL en France.
Outre-Manche, une compagnie aérienne [17] encourt un risque d’amende de plus de 200 millions d’euros suite au détournement d’une partie du trafic de ses utilisateurs vers un site frauduleux similaire en apparence au site web officiel. Les attaquants, le groupe Magecart a priori, ont exploité une vulnérabilité ayant permis d’ajouter des lignes de code dans le fichier modernizr-2.6.2.js.
Le régulateur britannique a également prononcé un projet d’amende de 110 millions d’euros à l’encontre d’un groupe hôtelier [18], suite à une intrusion s’étalant de 2014 à 2018, sur un système d’une société acquise en 2016. 339 millions de dossiers clients, présents notamment dans 31 pays de la zone économique européenne, ont ainsi été dérobés, comprenant des passeports et des numéros de carte de paiement, dont les clés de chiffrement étaient enregistrées sur le même serveur. Même si les causes de la première intrusion n’ont pas été complètement identifiées, les investigations post incident ont montré la présence d’un Remote Access Trojan (RAT) ainsi que MimiKatz, ce qui a permis à l’attaquant de récupérer des mots de passe et de prendre le contrôle du serveur.
Outre-Atlantique, bien que le RGPD ne soit pas applicable, on observe des failles de sécurité techniques semblables ainsi que des montants d’amende pécuniaire mirobolants. Une agence de notation de crédits personnels a ainsi été victime d’une fuite de données massives portant sur les clients de ses clients, suite à l’utilisation de composants non mis à jour, Struts en l’occurrence, et de l’utilisation d’un couple identifiant/mot de passe faible « admin/admin » (oui on parle bien d'« admin/admin » dans des documents liés à une action en justice envers cette société !). L’agence de notation de crédits personnels a conclu avec les régulateurs et les états américains un accord portant sur une amende de 700 millions d’euros pour solder le dossier [19].
D’autres autorités de contrôle ont fait preuve d’originalité dans les sanctions. Un groupe hôtelier [20] a ainsi été sanctionné par l’autorité roumaine pour avoir divulgué la liste papier imprimée et utilisée pour contrôler les clients ayant réservé un petit-déjeuner, laquelle a été photographiée par des personnes non autorisées, extérieures à l’entreprise, et publiée en ligne. La dernière sanction du contrôleur roumain attire également l’attention sur des mauvaises pratiques, pouvant sembler aberrantes, mais pourtant courantes. Ainsi, une banque roumaine [21] procédait de fait à des vérifications de solvabilité d’individus enregistrés sur la plateforme de son partenaire, en utilisant l’application WhatsApp comme moyen d’échange des données !
8. Quelle responsabilité pour les sous-traitants ?
Dans le cas des vulnérabilités techniques, il est parfois difficile de dire qui est responsable, si, par exemple, le site web d’un acteur A a été développé par un acteur B. Une sanction amène un éclairage sur le sujet, et indique que la violation des données de A relève de la responsabilité de A. Ainsi, un acteur de la grande distribution sanctionné par la CNIL avait argumenté que la faute était du fait du prestataire qui développait son site et hébergeait l’URL mise en cause dans la vulnérabilité. Mais cet argumentaire n’a pas été retenu par la CNIL, laquelle a maintenu la sanction [8]. Ainsi, un organisme ne peut pas se défaire de sa responsabilité d’assurer la sécurité des données personnelles collectées, notamment par la conduite de tests d’intrusion, d’audits de codes sources, d’audits de configuration ou d’autres types d’audits avant toute mise en production des applications, même celles développées et/ou hébergées par un prestataire. Et il faut noter que, si le RGPD prévoit bien la responsabilité des sous-traitants, il n’exonère pas pour autant les responsables de traitement.
Conclusion
Les sanctions de la CNIL à date révèlent que la sécurité technique reste un élément prépondérant de la question de la protection des données personnelles. L’article 32 représente 1% du RGPD, mais est invoqué dans près de trois quarts des sanctions de la CNIL. Les exemples mentionnés font état de vulnérabilités de sécurité plutôt bien connues par la communauté de la sécurité des SI, et maîtrisables quand on a pris le temps et les mesures pour les mettre sous contrôle en avance de phase.
La CNIL a profité de chaque sanction pour rappeler, dans ses délibérations, les règles de sécurité de base en la matière, à savoir la mise de place de mécanismes d’authentification, la mise en place de politique de mot de passe, le chiffrement des données au repos et en transit, la mise en place de contrôle d’accès et le fait de procéder à un protocole complet de test en amont de la mise en production d’un site Internet. Par ailleurs, la CNIL a publié sur son site web plusieurs guides portant sur la sécurité des données personnelles [22] [23].
Enfin, notons que les sanctions publiques prononcées par la CNIL, entre 2016 et 2019, et liées à la sécurité l’ont été pour près de 3/4 d’entre elles suite à un signalement citoyen. Un peu comme si la CNIL avait son propre programme de bug bounty (citoyen) !
Remerciements
Nous remercions Vincent Maret, associé Cybersécurité et Protection des Données chez KPMG, pour sa relecture et ses conseils.
Références
[1] https://www.cnil.fr/fr/securite-des-sites-web-les-5-problemes-les-plus-souvent-constates
[2] https://www.legifrance.gouv.fr/affichCnil.do?id=CNILTEXT000034473080
[3] https://www.legifrance.gouv.fr/affichCnil.do?id=CNILTEXT000035175069
[4] https://www.legifrance.gouv.fr/affichCnil.do?id=CNILTEXT000038810992
[6] https://www.legifrance.gouv.fr/affichCnil.do?id=CNILTEXT000037013610
[10] https://www.legifrance.gouv.fr/affichCnil.do?id=CNILTEXT000032909770
[11] https://www.legifrance.gouv.fr/affichCnil.do?id=CNILTEXT000033445256
[13] https://www.legifrance.gouv.fr/affichCnil.do?id=CNILTEXT000035272571
[14] https://www.legifrance.gouv.fr/affichCnil.do?id=CNILTEXT000033373161
[17] https://www.cnil.fr/fr/securite-des-donnees-les-regles-essentielles-pour-demarrer
[18] https://www.cnil.fr/fr/principes-cles/guide-de-la-securite-des-donnees-personnelles
[19] https://epic.org/privacy/data-breach/equifax/
[20] https://www.dataprotection.ro/index.jsp?page=O_noua_amenda_GDPR&lang=ro
[21] https://www.dataprotection.ro/?page=Comunicat_Presa_09_10_2019&lang=ro
