Résumé

Pourquoi ce cas relève d'un dossier de risque et de responsabilité

DoorDash relève d'un dossier de risque et de responsabilité car une plateforme de livraison détient plusieurs types de personnes dans un seul système d'exploitation. Les consommateurs utilisent le service pour envoyer de la nourriture, des courses ou d'autres commandes à des domiciles, lieux de travail, hôtels, hôpitaux, écoles et lieux temporaires. Les Dashers utilisent la plateforme pour leurs revenus, leur navigation, la vérification d'identité, les paiements bancaires, les workflows fiscaux et d'assistance, et l'accès à leur compte.

Les commerçants dépendent de la plateforme pour les commandes, le contact client, la continuité des revenus, les opérations de menu et la réputation locale. Une faille dans cet environnement n'expose pas une table de comptes uniforme. Elle expose un marché multi-acteurs où le même incident peut créer des risques différents pour chaque classe de entités.

Le principal document public est l'avis de sécurité de DoorDash à l'adressehttps://blog.doordash.com/important-security-notice-about-your-doordash-account-ddd90ddf5996. DoorDash a indiqué avoir pris connaissance d'une activité inhabituelle impliquant un prestataire de services tiers, avoir lancé une enquête et déterminé qu'un tiers non autorisé avait accédé à certaines données d'utilisateurs de DoorDash le 4 mai 2019. L'avis indiquait qu'environ 4,9 millions de consommateurs, Dashers et commerçants ayant rejoint DoorDash le 5 avril 2018 ou avant étaient concernés. Il précisait également que les utilisateurs ayant rejoint après le 5 avril 2018 n'étaient pas concernés. Cette limite de date est importante car elle montre que l'entreprise ne se contentait pas d'estimer un total à l'échelle de la plateforme; elle définissait une population liée à l'ancienneté du compte et à la disponibilité des données.

L'avis de DoorDash, tel que décrit dans les reportages contemporains, identifiait plusieurs catégories exposées. Pour les consommateurs, les Dashers et les commerçants, les données affectées pouvaient inclure des informations de profil telles que les noms, adresses e-mail, adresses de livraison, historique des commandes, numéros de téléphone et mots de passe hachés et salés. Pour certains consommateurs, les quatre derniers chiffres des cartes de paiement étaient concernés, mais les informations complètes de carte de paiement, comme les numéros de carte complets ou les codes CVV, n'auraient pas été consultées.

Pour certains Dashers et commerçants, les quatre derniers chiffres des comptes bancaires étaient concernés. DoorDash a également indiqué qu'environ 100 000 Dashers avaient vu leurs numéros de permis de conduire consultés. Ces distinctions sont au cœur du dossier de responsabilité.

L'incident est important car les données de livraison sont opérationnellement intimes. Une adresse de livraison peut être un domicile, un lieu de travail, un refuge, une clinique, une école, un hôtel ou une résidence temporaire. L'historique des commandes peut révéler des horaires, des routines, des préférences religieuses ou alimentaires, des besoins médicaux, la structure familiale, les déplacements locaux ou les habitudes économiques. Un numéro de téléphone permet un contact direct. Un mot de passe haché crée un risque de réutilisation des identifiants si le mot de passe est faible ou réutilisé ailleurs.

Les quatre derniers chiffres de cartes ou de comptes bancaires peuvent faciliter l'ingénierie sociale même si les identifiants complets ne sont pas exposés. Un numéro de permis de conduire peut créer un risque d'usurpation d'identité pour les travailleurs qui dépendent de la plateforme pour leurs revenus.

La question évidente est donc pratique: qui contrôlait l'accès du prestataire de services tiers, la conservation des données de livraison, les limites de notification aux consommateurs et aux Dashers, le risque de contact pour les commerçants, la délimitation des données de paiement et bancaires partielles, l'exposition des permis de conduire et la preuve que la voie d'accès a été fermée? L'avis public de DoorDash a répondu en partie à cette question en nommant les groupes et les catégories de données concernés.

Il n'a pas divulgué l'identité du fournisseur, la méthode technique exacte d'entrée, l'architecture complète de conservation, le contrat complet du fournisseur ou chaque modification de contrôle post-incident.

L'accès par un tiers a modifié la limite de responsabilité

L'expression « prestataire de services tiers » est la charnière du dossier. Un consommateur voit généralement l'application et la marque DoorDash, pas les fournisseurs de la plateforme. Un Dasher voit l'application Dasher, les workflows de gains, les canaux d'assistance, les vérifications d'antécédents et les processus de paiement. Un commerçant voit les tablettes, l'intégration des commandes, les outils de menu, les contacts d'assistance et les workflows de règlement. La limite de sécurité qui a échoué peut se situer chez un prestataire de services, mais la relation de confiance reste avec DoorDash.

C'est pourquoi l'incident n'est pas simplement une histoire de fournisseur. C'est une histoire de responsabilité de plateforme.

Le rapport de TechCrunch à l'adressehttps://techcrunch.com/2019/09/26/doordash-data-breach/situait la divulgation publique en septembre 2019 et décrivait la population concernée et les catégories de données. Le rapport The Verge à l'adressehttps://www.theverge.com/2019/9/26/20885549/doordash-data-breach-hack-security-4-9-million-users-drivers-merchantssoulignait que la faille affectait les clients, les livreurs et les commerçants, et que certains numéros de permis de conduire étaient concernés. CNET à l'adressehttps://www.cnet.com/tech/services-and-software/doordash-says-data-breach-affected-4-9-million-users/et BleepingComputer à l'adressehttps://www.bleepingcomputer.com/news/security/doordash-discloses-data-breach-affecting-49-million-users/ont également documenté les catégories de données et le cadrage du prestataire de services tiers.

Des reportages supplémentaires de CNBC à l'adressehttps://www.cnbc.com/2019/09/26/doordash-says-data-breach-affected-4point9-million-users.html, ZDNet à l'adressehttps://www.zdnet.com/article/doordash-says-data-breach-impacted-4-9-million-users/, et The Register à l'adressehttps://www.theregister.com/2019/09/27/doordash_data_breach/sont utiles comme contexte public de chronologie et d'impact. Ces reportages ne remplacent pas l'avis de DoorDash lui-même, mais ils renforcent le fait que le public a compris l'incident comme un problème de entités à l'échelle du marché impliquant clients, coursiers, commerçants, identifiants financiers partiels et données de permis de conduire, plutôt qu'un simple événement de mot de passe consommateur.

Ces reportages sont utiles car ils montrent comment le public a appris l'incident: non pas d'abord par un dépôt réglementaire dense, mais par un avis de plateforme amplifié par la presse technologique. Mais ils ne répondent pas aux questions de gouvernance des fournisseurs. À quel accès le prestataire de services tiers avait-il? Était-ce un accès direct à la base de données, un accès d'assistance, un accès analytique, un accès au cloud ou une autre voie? L'accès était-il restreint par classe de entité, géographie, plage de dates ou élément de données? Les exportations étaient-elles journalisées?

DoorDash ou le fournisseur a-t-il détecté l'activité en premier? Le fournisseur a-t-il conservé des données en dehors du contrôle immédiat de DoorDash? Les archives publiques ne répondent pas à ces questions.

La position responsable consiste à identifier ces questions sans prétendre connaître les faits privés. Les archives publiques confirment un événement d'accès non autorisé impliquant un fournisseur tiers. Elles soutiennent l'inférence que la gestion de l'accès des fournisseurs et la surveillance étaient au cœur de la remédiation. Elles ne permettent pas de nommer un fournisseur non divulgué, d'alléguer une mauvaise conduite intentionnelle ou de revendiquer une vulnérabilité technique particulière. La limite des preuves est importante car la responsabilité de la plateforme n'exige pas de spéculation.

Elle exige une liste disciplinée de ce que le public peut vérifier et de ce qui reste inconnu.

Les adresses de livraison ne sont pas de simples champs de contact

Les adresses de livraison sont l'un des champs ordinaires les plus sensibles du dossier DoorDash. Dans de nombreux résumés de failles, les adresses peuvent être traitées comme des informations de profil de routine. Dans un marché de livraison, l'adresse est le centre opérationnel du produit. Elle peut révéler où une personne dort, travaille, reçoit de la nourriture tard le soir, soutient un parent, commande pendant une maladie, fréquente une école ou séjourne en voyage. Les adresses répétées et les historiques de commandes peuvent révéler des habitudes.

Même une seule adresse peut créer un risque si elle est liée à un nom, un numéro de téléphone et un compte de plateforme.

Cet article ne prétend pas que DoorDash a divulgué l'historique complet de livraison de chaque utilisateur ou que les attaquants ont utilisé les données pour du harcèlement ou du pistage. Le fait public confirmé est plus étroit: les adresses de livraison et l'historique des commandes faisaient partie des catégories de données signalées comme concernées pour certains utilisateurs. L'inférence étayée est que ces catégories créent des préoccupations de sécurité personnelle, de phishing, d'usurpation d'identité et de risque de localisation au-delà de la simple récupération de compte.

Une plateforme détenant des données de livraison devrait donc traiter l'exposition des adresses et de l'historique des commandes comme plus qu'un problème de profil marketing.

C'est là qu'intervient l'économie des abus de contact dans ce dossier. Un acteur malveillant disposant d'un nom, d'un numéro de téléphone, d'une adresse e-mail, d'une adresse de livraison et d'un contexte de commande peut élaborer un message plus plausible qu'un spammeur générique. Le message peut se faire passer pour un remboursement, une plainte de livreur, un litige avec un restaurant, un paiement échoué, une vérification de compte ou un problème de livraison. Les quatre derniers chiffres d'une carte de paiement ou d'un compte bancaire peuvent rendre le message authentique.

Un contact de commerçant peut être ciblé par de fausses réclamations d'assistance de plateforme. Un Dasher peut être ciblé par de faux messages de paiement ou de vérification d'identité.

Les archives publiques ne prouvent pas que ces voies d'abus se sont produites après l'incident de 2019. Elles montrent pourquoi la combinaison de données est importante. La responsabilité en matière de sécurité doit évaluer les combinaisons, pas les champs isolés. Un numéro de téléphone seul peut être moins sensible qu'un numéro de téléphone plus une adresse de livraison plus un historique de commandes plus une identité de plateforme. Les quatre derniers chiffres seuls peuvent être moins utiles que les quatre derniers chiffres plus un prétexte d'assistance de plateforme.

Un mot de passe haché peut être moins risqué s'il est fort, mais plus risqué s'il est réutilisé. La plateforme doit expliquer le risque combiné dans les avis et la remédiation.

Les Dashers portaient un risque différent de celui des consommateurs

La population des Dashers mérite un traitement séparé car les Dashers sont des travailleurs ou des entrepreneurs indépendants utilisant la plateforme pour leurs revenus. L'avis de DoorDash indiquait qu'environ 100 000 Dashers avaient vu leurs numéros de permis de conduire consultés. Les reportages publics indiquaient également que certains Dashers et commerçants avaient vu les quatre derniers chiffres de leurs comptes bancaires concernés. Ce n'est pas le même profil de risque que les quatre derniers chiffres de carte de paiement d'un consommateur. Un Dasher peut dépendre du compte pour ses gains.

Les données de vérification d'identité peuvent être plus difficiles à remplacer qu'un mot de passe. Les fragments de compte bancaire peuvent être utilisés dans des escroqueries d'assistance ou des prétextes de prise de contrôle de compte.

La différence est importante pour la conception des notifications. Un consommateur peut avoir besoin de changer un mot de passe, de surveiller les comptes de paiement, de se méfier du phishing et d'examiner l'exposition des adresses. Un Dasher peut également avoir besoin de surveiller les faux contacts d'assistance, les changements de paiement, la manipulation de documents fiscaux, les abus de vérification d'identité ou les escroqueries de désactivation de compte.

Un commerçant peut avoir besoin de surveiller les fausses notifications de plateforme, les demandes de mise à jour de compte bancaire, les plaintes de clients et les risques de continuité des commandes. Traiter toutes les parties concernées comme des « utilisateurs » peut masquer ces différences.

Ce n'est pas une affirmation que DoorDash a ignoré ces différences. L'avis public identifiait les consommateurs, les Dashers et les commerçants comme catégories, et les reportages contemporains ont préservé cette distinction. L'analyse de responsabilité demande si la remédiation et les communications aux utilisateurs correspondaient à cette distinction. Si les numéros de permis de conduire sont concernés pour les Dashers, l'avis doit le dire clairement à ces Dashers. Si les quatre derniers chiffres bancaires sont concernés pour certains Dashers ou commerçants, les conseils doivent aborder le risque de paiement et de contact bancaire.

Si les consommateurs ont une exposition d'adresse et d'historique de commandes, les conseils doivent aborder le phishing et le risque de contact lié à la localisation.

Les dépôts ultérieurs de DoorDash en tant qu'entreprise publique, y compris l'index des dépôts pour les relations investisseurs à l'adressehttps://ir.doordash.com/financials/sec-filings/default.aspxet sa déclaration d'enregistrement à l'adressehttps://www.sec.gov/Archives/edgar/data/1792789/000119312520292381/d752207ds1.htm, ne sont pas des sources médico-légales spécifiques à l'incident pour la faille de 2019. Ils sont utiles car ils décrivent une entreprise qui dépend des consommateurs, des Dashers, des commerçants, de la technologie, des paiements, des données, de la confidentialité et de la confiance à grande échelle. Un marché avec plusieurs groupes de entités doit rendre compte des incidents de sécurité en des termes que chaque groupe peut comprendre et sur lesquels il peut agir.

Les commerçants ont fait de l'événement un problème de continuité pour les PME

Le sujet évident inclut la continuité de service pour les PME car les commerçants sont souvent des petites ou moyennes entreprises qui dépendent des plateformes de livraison pour leurs revenus et l'accès aux clients. Une faille affectant les données de profil des commerçants ou les fragments de compte bancaire n'est pas seulement un problème de confidentialité. Elle peut créer un risque de continuité. Un restaurant peut recevoir de faux appels concernant la vérification des paiements, l'intégration des menus, les remboursements de commandes, le remplacement de tablettes, les formulaires fiscaux ou la suspension de compte.

Un fraudeur disposant d'un contexte partiel peut rendre ces messages plus convaincants.

Encore une fois, une analyse de sécurité publique nécessite de la retenue. Le fait public confirmé est que les commerçants étaient inclus dans la population concernée et que certains quatre derniers chiffres de comptes bancaires étaient concernés pour certains Dashers et commerçants. L'inférence étayée est que les contacts des commerçants et les workflows de paiement sont des cibles d'abus plausibles lorsque des données de contact liées à la plateforme et des fragments financiers sont exposés. Les archives publiques ne prouvent pas qu'un commerçant spécifique a subi une perte particulière à cause de la faille.

La question de responsabilité est de savoir si DoorDash et ses prestataires ont traité les données des commerçants comme des données de continuité d'activité plutôt que comme des données de profil ordinaires.

La continuité des PME est également importante car les petits commerçants peuvent avoir moins de capacité de sécurité qu'un grand partenaire entreprise. Une grande chaîne peut avoir une équipe de sécurité, des contrôles antifraude, des workflows de gestion des fournisseurs et des contacts dédiés chez DoorDash. Un petit restaurant peut avoir un gérant avec un téléphone mobile, une boîte e-mail partagée et une tablette au comptoir. Si ce restaurant reçoit une fausse demande d'assistance après une faille, la clarté de l'avis de la plateforme et la surveillance anti-abus deviennent une partie de la résilience.

Un opérateur de marché doit concevoir des conseils de réponse pour le entité légitime le moins doté en ressources, pas seulement pour les partenaires sophistiqués.

La même logique s'applique aux Dashers. Un Dasher peut ne pas avoir d'équipe de sécurité d'entreprise. Le Dasher peut compter sur les notifications mobiles, les SMS, les e-mails et l'assistance dans l'application. Lorsqu'une faille expose des données pouvant faciliter les abus de contact, les communications de la plateforme doivent être courtes, spécifiques et exploitables. L'avis ne doit pas exiger des personnes concernées qu'elles déduisent leur propre risque à partir d'une liste dense de catégories de données.

Les limites de date et le moment de la notification sont devenus des questions de preuve

DoorDash a divulgué que les consommateurs, Dashers et commerçants concernés avaient rejoint la plateforme le 5 avril 2018 ou avant, et que l'accès non autorisé avait eu lieu le 4 mai 2019. L'avis public a été émis en septembre 2019. Ces dates créent des questions de responsabilité. La limite de date de création de compte suggère que DoorDash a identifié une population de données avec une date limite. La date d'accès suggère une lecture non autorisée ponctuelle. La date de notification soulève la question de l'enquête, de la délimitation et du moment de la notification.

Un écart de temps n'est pas toujours une preuve de retard sans raison. Les enquêtes sur les failles prennent du temps. Une entreprise peut avoir besoin d'identifier la voie d'entrée, d'arrêter l'accès, de valider les journaux, de déterminer les données concernées, de notifier les régulateurs, de préparer des messages spécifiques aux utilisateurs et d'éviter des déclarations publiques inexactes. Mais un dossier responsable devrait expliquer suffisamment la chronologie pour montrer pourquoi les personnes concernées ont été informées quand elles l'ont été.

Les archives publiques indiquent que DoorDash a enquêté avec des experts en sécurité et a pris des mesures pour bloquer tout accès ultérieur. Elles ne fournissent pas la chronologie complète de la détection à la notification.

La page de signalement des failles du procureur général de Californie à l'adressehttps://oag.ca.gov/privacy/databreach/reportingest pertinente car de nombreux incidents de plateforme nord-américains impliquent des obligations de notification aux États lorsque des informations personnelles sont concernées. Le guide de réponse aux failles de la FTC à l'adressehttps://www.ftc.gov/business-guidance/resources/data-breach-response-guide-businessest également utile car il présente le confinement, l'évaluation, la notification et la communication comme des obligations commerciales après une faille de données. Ces sources ne sont pas des conclusions sur la conformité légale de DoorDash. Elles définissent les attentes publiques en matière de responsabilité concernant le moment et le contenu des notifications.

La limite de date soulève également des questions de conservation. Si la population concernée était liée aux utilisateurs ayant rejoint le 5 avril 2018 ou avant, cela signifie que certaines données d'utilisateurs plus anciens sont restées sous une forme accessible en mai 2019. Cela peut être légitime. Les plateformes de livraison ont besoin d'enregistrements de comptes, de données fiscales et de paiement, d'historiques de commandes, d'enregistrements d'assistance, de contrôles antifraude, de conservation légale et d'analyses commerciales. Mais la conservation doit être justifiée par champ et classe de entité.

Un incident de sécurité devrait rendre le fichier de conservation lisible: quels champs étaient encore nécessaires, quels champs auraient pu être minimisés, quels anciens enregistrements étaient segmentés, et quelles voies fournisseurs pouvaient les lire.

Les données partielles de paiement et bancaires comptent quand même

DoorDash et les reportages publics ont souligné que les numéros complets de carte de paiement et les codes CVV n'avaient pas été consultés. Cette limitation est importante et doit être créditée. Elle réduit le risque immédiat d'utilisation frauduleuse des cartes de paiement. L'exposition rapportée des quatre derniers chiffres de cartes de paiement et des quatre derniers chiffres de comptes bancaires est une catégorie différente. Ces fragments sont souvent utilisés pour la vérification, l'assistance client, la recherche de compte et la plausibilité de l'ingénierie sociale.

Ce ne sont pas des identifiants complets, mais ils peuvent aider un attaquant à paraître crédible.

Le bon cadrage de la responsabilité n'est pas alarmiste. Un quatre derniers chiffres seul ne permet pas à quelqu'un de vider un compte bancaire. Mais en combinaison avec un nom, un numéro de téléphone, un e-mail, un historique de livraison, un rôle sur la plateforme et un prétexte d'assistance plausible, il peut augmenter les chances qu'une personne concernée croie un faux message. C'est pourquoi cet article traite les données financières partielles comme un contexte facilitant les abus plutôt que comme une compromission totale des paiements. La différence est importante car les mesures d'atténuation recommandées diffèrent.

Les utilisateurs peuvent ne pas avoir besoin de remplacer leurs cartes uniquement parce qu'un quatre derniers chiffres a été exposé, mais ils doivent être attentifs aux escroqueries de vérification.

Pour les Dashers et les commerçants, la question des quatre derniers chiffres bancaires est particulièrement liée aux workflows de paiement. Un faux message d'assistance peut prétendre qu'un paiement a échoué, qu'un compte bancaire doit être revérifié, qu'un formulaire fiscal est manquant ou qu'un règlement de commerçant est bloqué. L'attaquant n'a pas besoin des coordonnées bancaires complètes pour engager la conversation. L'équipe anti-abus de la plateforme, les scripts d'assistance et le langage des notifications doivent anticiper cela.

La réponse de sécurité ne s'arrête pas au confinement des données; elle se poursuit dans la surveillance des abus et le durcissement des canaux d'assistance.

Les directives de la FTC à l'adressehttps://www.ftc.gov/business-guidance/resources/start-security-guide-businessethttps://www.ftc.gov/business-guidance/resources/protecting-personal-information-guide-businesssont utiles pour le principe de base: collectez ce dont vous avez besoin, conservez-le uniquement le temps nécessaire, protégez ce que vous conservez et gérez les prestataires de services. Ce sont des principes généraux de sécurité des entreprises, pas des conclusions spécifiques à DoorDash. Ils s'appliquent clairement aux données financières partielles car les fragments se trouvent souvent dans les systèmes d'assistance, de rapprochement et d'expérience utilisateur même lorsque les détails complets de paiement sont tokenisés ou détenus ailleurs.

Les contrôles de la chaîne d'approvisionnement sont au cœur du dossier de remédiation

La norme NIST SP 800-161 Rev. 1 à l'adressehttps://csrc.nist.gov/publications/detail/sp/800-161/rev-1/finalfournit un vocabulaire utile pour la gestion des risques liés à la chaîne d'approvisionnement. Elle souligne que les organisations doivent identifier, évaluer et gérer les risques découlant des fournisseurs, des systèmes, des services et des dépendances externes. L'incident de DoorDash en 2019 correspond à ce vocabulaire car l'avis public plaçait l'activité inhabituelle chez un prestataire de services tiers. Le fournisseur peut ne pas être nommé, mais la classe de dépendance est nommée.

Un dossier post-incident responsable devrait donc couvrir l'inventaire des fournisseurs, la cartographie des accès aux données, l'approbation des accès, le moindre privilège, la journalisation, le contrôle des exportations, la détection des anomalies, les obligations contractuelles de sécurité, les obligations de notification d'incident, la résiliation des accès inutiles et l'examen périodique. Il devrait également couvrir si les fournisseurs peuvent accéder aux données par classe de entité. Un fournisseur qui a besoin d'informations d'assistance client peut ne pas avoir besoin des numéros de permis de conduire des Dashers.

Un fournisseur qui a besoin d'analyses peut ne pas avoir besoin de fragments de paiement. Un fournisseur qui a besoin de données d'intégration de commerçant peut ne pas avoir besoin de l'historique des commandes des consommateurs. La segmentation par objectif est la référence de responsabilité.

La norme NIST SP 800-53 Rev. 5 à l'adressehttps://csrc.nist.gov/publications/detail/sp/800-53/rev-5/finalet le cadre de cybersécurité de la NIST à l'adressehttps://www.nist.gov/cyberframeworkfournissent un langage de contrôle supplémentaire: application des accès, gestion des comptes, journalisation des audits, gestion des incidents, évaluation des risques, protection de la chaîne d'approvisionnement, gestion de la configuration et reprise. Ces contrôles ne prouvent pas ce que DoorDash a fait ou n'a pas fait. Ils définissent ce à quoi un lecteur devrait s'attendre d'une réponse de remédiation mature après qu'un accès tiers a exposé des données personnelles et de marché.

Les contrôles de sécurité critiques du CIS à l'adressehttps://www.cisecurity.org/controlsfournissent un vocabulaire pratique complémentaire pour l'inventaire, la gestion des comptes, la protection des données, la gestion des journaux d'audit et la gestion des prestataires de services. Dans ce cas, ces contrôles se traduisent par des questions de preuve simples: quels fournisseurs avaient accès, quels champs pouvaient-ils lire, quelles exportations ont eu lieu, quels journaux prouvent la réponse, et quels comptes ont été supprimés ou restreints après l'incident?

Les inconnues publiques restent importantes. DoorDash n'a pas nommé publiquement le fournisseur tiers dans l'avis. Il n'a pas publié de rapport médico-légal complet, de diagramme de flux de données détaillé, de conditions contractuelles, d'autorisations d'accès exactes, de calendriers de conservation complets ou d'un dossier de correspondance avec les régulateurs. C'est courant, mais cela signifie que le public ne peut évaluer la réponse qu'à travers les faits divulgués, les reportages externes et les signaux de gouvernance ultérieurs. Le rôle de cet article est de préserver cette limite de preuve.

La souveraineté et la localisation des données sont restées largement non résolues dans le domaine public

L'événement est catégorisé comme Amérique du Nord car l'activité de DoorDash en 2019 et la base de entités concernés étaient principalement nord-américaines. Néanmoins, les plateformes de livraison stockent et traitent les données via des services cloud, des fournisseurs, des processeurs de paiement, des outils d'assistance, des systèmes d'analyse et des prestataires de sécurité qui peuvent avoir des propriétés de localisation différentes.

L'avis public de DoorDash n'a pas fourni de carte détaillée de l'endroit où les données concernées étaient stockées, de l'endroit où le fournisseur tiers les a traitées, ou si des copies existaient dans différentes régions.

Cet écart de localisation est important pour la gouvernance. Les consommateurs, les Dashers et les commerçants peuvent être soumis à différentes attentes de confidentialité étatiques, provinciales ou nationales. Les données de permis de conduire peuvent impliquer des documents d'identité d'État. Les données de paiement des commerçants peuvent impliquer des relations bancaires professionnelles. Les adresses de livraison peuvent identifier des domiciles et des lieux de travail.

Si un fournisseur tiers peut accéder à ces champs, la plateforme doit être en mesure de dire en interne quelles juridictions, clauses contractuelles, règles de conservation et règles de notification s'appliquent. Le public peut ne pas avoir besoin d'une carte d'infrastructure précise, mais les régulateurs et les responsables internes de la responsabilité en ont besoin.

Cet article ne prétend pas à une violation transfrontalière spécifique. Il traite la souveraineté et la localisation des données comme une préoccupation de gouvernance étayée avec des détails publics incomplets. Les faits confirmés sont le contexte de la plateforme nord-américaine, le cadrage du prestataire de services tiers et les catégories de données concernées. L'inférence étayée est que la cartographie de la localisation et les limites de traitement des données par les fournisseurs seraient pertinentes pour une réponse responsable. L'inconnue est la carte réelle de stockage et de traitement des données concernées.

Les divulgations ultérieures des risques de DoorDash en tant qu'entreprise publique, disponibles viahttps://ir.doordash.com/financials/sec-filings/default.aspx, fournissent un contexte général selon lequel la confidentialité, la sécurité des données, les paiements, la confiance dans la plateforme et les dépendances tierces sont des risques commerciaux importants. Elles ne résolvent pas la question de la localisation de 2019. Elles montrent pourquoi la question de la responsabilité est restée pertinente au-delà d'une seule annonce: les marchés transportent des données sensibles à travers les groupes de entités et les partenaires opérationnels comme élément central du modèle commercial.

L'historique des commandes a changé la sensibilité des identifiants ordinaires

L'historique des commandes est une partie importante du dossier DoorDash car il modifie le sens des identifiants ordinaires. Un nom, une adresse e-mail, un numéro de téléphone et une adresse de livraison sont déjà des informations personnelles. Lorsque ces champs sont connectés à l'historique des commandes, ils peuvent révéler l'heure, le lieu, le choix du commerçant, la préférence alimentaire, la routine domestique et parfois le contexte de santé ou religieux.

Un avis de faille qui liste « historique des commandes » comme catégorie de données devrait donc déclencher une analyse plus approfondie de ce que l'historique contenait et de son niveau de détail. Incluait-il les noms des restaurants, les achats au niveau des articles, les horodatages, les instructions de livraison, les litiges de remboursement, les notes d'assistance, ou seulement des métadonnées de commande de haut niveau? Les archives publiques ne répondent pas à toutes ces questions.

La différence est importante car les instructions de livraison peuvent être plus sensibles que la commande elle-même. Les instructions peuvent identifier des accès aux bâtiments, des membres de la famille, des bureaux d'accueil sur le lieu de travail, des aménagements pour personnes handicapées, des codes de porte, des préférences de dépôt sécurisé, des chambres d'hôtel ou des notes sur quand appeler. Les reportages publics sur l'incident de 2019 n'ont pas établi que les instructions de livraison étaient incluses, et cet article ne prétend pas qu'elles l'étaient.

Le point de responsabilité est qu'une plateforme répondant à une exposition de données de livraison doit regarder au-delà des étiquettes de champ. « Adresse de livraison » et « historique des commandes » sont des catégories larges. L'analyse des risques pour l'utilisateur dépend du schéma réel, de la période de conservation et du lien avec les notes d'assistance ou de livraison.

L'historique des commandes affecte également le risque pour les commerçants. Si les enregistrements des commerçants sont connectés aux habitudes de commande des clients, un attaquant peut élaborer des escroqueries d'assistance plus plausibles pour les commerçants. Si un petit restaurant reçoit un message faisant référence à une vraie plateforme de livraison, une commande récente ou un contexte de paiement, le restaurant peut le considérer comme légitime. Les catégories de données publiques confirmées ne prouvent pas que chaque commerçant avait un historique de commandes détaillé exposé.

Elles montrent pourquoi un opérateur de marché doit vérifier si le risque côté commerçant est dérivé des données des consommateurs, des données des Dashers, des données de paiement ou d'un mélange des trois.

Pour les consommateurs, le scénario d'abus est le contact direct. Un faux message de remboursement peut mentionner une plateforme, une adresse de livraison, un restaurant et un chiffre de paiement partiel. Pour les Dashers, le scénario peut impliquer la vérification d'identité, le renouvellement du permis, la réactivation du compte ou le dépannage des paiements. Pour les commerçants, il peut s'agir de la vérification des règlements, du remplacement de la tablette, des litiges de rétrofacturation ou de l'intégration des menus. La même faille de données peut créer différents scripts pour différentes cibles.

La responsabilité exige que les équipes de réponse modélisent ces scripts, puis durcissent les canaux d'assistance, et pas seulement ferment la voie d'accès d'origine.

La délimitation par rôle devrait guider la notification, pas l'inverse

La population concernée de DoorDash comprenait les consommateurs, les Dashers et les commerçants. Cette division en trois parties n'est précieuse que si elle guide la délimitation et la conception des notifications. Un consommateur qui n'a eu que des données de profil et un quatre derniers chiffres de carte de paiement exposés ne devrait pas recevoir les mêmes conseils pratiques qu'un Dasher dont le numéro de permis de conduire a été consulté. Un commerçant avec un quatre derniers chiffre de compte bancaire exposé ne devrait pas être traité comme si le seul problème était la réutilisation du mot de passe.

Le rôle du entité modifie les risques probables, l'action recommandée et la charge d'assistance.

La délimitation par rôle commence par un inventaire des données. La plateforme doit savoir quels champs appartiennent à chaque classe de entité, quels systèmes les stockent, quels prestataires de services peuvent les lire et quels journaux montrent l'accès. Elle doit également savoir si une personne peut apparaître dans plus d'un rôle. Un utilisateur peut être à la fois consommateur et Dasher. Un opérateur de commerçant peut également être consommateur. Un Dasher peut avoir changé d'adresse e-mail, de numéro de téléphone ou de compte bancaire depuis son inscription.

Si la logique de notification est trop simple, certaines personnes peuvent recevoir des conseils incomplets ou des messages en double qui n'expliquent pas leur exposition complète.

La limite de création de compte du 5 avril 2018 dans l'avis public est un exemple utile de délimitation. Elle suggère que DoorDash pouvait séparer les comptes plus anciens concernés des comptes plus récents. La couche suivante de responsabilité serait la délimitation au niveau des champs: combien de personnes avaient des adresses de livraison exposées, combien avaient un historique de commandes exposé, combien avaient les quatre derniers chiffres de carte de paiement exposés, combien de Dashers avaient des numéros de permis exposés, et combien de commerçants ou de Dashers avaient les quatre derniers chiffres de compte bancaire exposés.

Les reportages publics conservent le chiffre approximatif de 100 000 permis de conduire de Dashers, mais les archives sont moins granulaires pour tous les autres champs.

Ce manque de granularité ne signifie pas automatiquement que la délimitation interne était mauvaise. Les entreprises donnent souvent aux utilisateurs concernés des notifications plus spécifiques que la déclaration publique. Mais un examen public de la responsabilité ne peut évaluer que ce qui est public. L'examen peut créditer DoorDash d'avoir distingué les classes de entités et les exclusions concernant les données de paiement complètes. Il devrait également enregistrer l'inconnue publique: si chaque personne concernée a reçu une notification adaptée correspondant aux éléments de données exacts exposés.

La supervision des fournisseurs doit s'étendre aux équipes d'assistance et de lutte contre les abus

Le risque lié aux tiers est souvent décrit comme une fonction de sécurité, d'approvisionnement ou juridique. Le dossier DoorDash montre pourquoi les équipes d'assistance et de lutte contre les abus appartiennent également au dossier de remédiation. Une fois qu'une faille expose des données de contact, des identifiants financiers partiels et des rôles de entités, les attaquants peuvent se tourner vers l'abus des canaux d'assistance.

Un faux contact d'assistance peut faire pression sur un consommateur pour révéler un code à usage unique, sur un Dasher pour modifier les détails de paiement, ou sur un commerçant pour autoriser une mise à jour bancaire. Ces scénarios peuvent se dérouler des jours ou des mois après la fermeture de l'accès d'origine.

Une réponse responsable devrait donc inclure de nouveaux scripts d'assistance, des bannières d'avertissement, une formation des agents, des voies d'escalade et des règles de surveillance de la fraude. Les équipes d'assistance doivent savoir ce que DoorDash ne demandera jamais par téléphone, e-mail, SMS ou chat. Les utilisateurs doivent savoir quels canaux dans l'application sont authentiques. Les commerçants doivent savoir comment les changements de paiement sont vérifiés. Les Dashers doivent savoir comment les mises à jour de permis de conduire ou de comptes bancaires sont traitées.

Ces actions ne remplacent pas la remédiation de l'accès des fournisseurs. Elles font partie de la réduction des dommages rendus possibles par les données exposées.

La supervision des fournisseurs doit également traiter les copies fantômes. Un prestataire de services tiers peut traiter des journaux, des exportations, des fichiers d'analyse, des tickets d'assistance ou des sauvegardes. Même si l'accès non autorisé d'origine est bloqué, les intervenants doivent savoir si des copies subsistent dans l'environnement du fournisseur, si les propres fournisseurs du prestataire ont reçu des données, si des exportations ont été téléchargées, ou si la suppression ou la quarantaine a été vérifiée. L'avis public n'a pas fourni ces détails.

La leçon étayée est qu'une réponse de plateforme à une faille doit tracer les données au-delà de la base de données principale de la plateforme.

C'est aussi une question de continuité d'activité. Si les commerçants perdent confiance dans l'assistance de la plateforme, ils peuvent ignorer les notifications légitimes ou tomber dans le piège de fausses notifications. Si les Dashers perdent confiance dans les communications de paiement, ils peuvent manquer de véritables étapes de protection de compte. Si les consommateurs se méfient des avis de remboursement ou de compte, ils peuvent ne pas agir sur de véritables avertissements. La remédiation de sécurité doit préserver la capacité des communications légitimes de la plateforme à être reconnues.

C'est pourquoi la clarté des notifications, les canaux d'assistance authentifiés et la surveillance des abus post-faille font partie de la responsabilité plutôt que des suppléments de relations publiques.

Faits confirmés, inférences étayées et inconnues

Les faits publics confirmés incluent la déclaration de DoorDash selon laquelle une activité inhabituelle impliquait un prestataire de services tiers, qu'un tiers non autorisé a accédé à certaines données d'utilisateurs de DoorDash le 4 mai 2019, et qu'environ 4,9 millions de consommateurs, Dashers et commerçants ayant rejoint la plateforme le 5 avril 2018 ou avant étaient concernés.

Les faits publics confirmés incluent également les catégories de données rapportées: noms, adresses e-mail, adresses de livraison, historique des commandes, numéros de téléphone, mots de passe hachés et salés, les quatre derniers chiffres de cartes de paiement pour certains, les quatre derniers chiffres de comptes bancaires pour les Dashers et commerçants, et environ 100 000 numéros de permis de conduire de Dashers.

Les inférences étayées incluent la conclusion que la gestion de l'accès des fournisseurs, la segmentation par classe de entité, la minimisation des données, la révision de la conservation, les notifications tenant compte des abus et la remédiation spécifique au marché étaient des thèmes centraux de responsabilité. Il est également raisonnable d'inférer que les adresses de livraison, l'historique des commandes, les numéros de téléphone et les chiffres financiers partiels peuvent augmenter le risque de phishing, d'usurpation d'identité et de harcèlement lorsqu'ils sont combinés.

Il est raisonnable d'inférer que les Dashers et les commerçants avaient besoin de conseils différents de ceux des consommateurs car leurs données exposées et leur dépendance à la plateforme différaient.

Les inconnues incluent l'identité du fournisseur tiers, la méthode technique d'accès, la source de la détection, la chronologie complète de la détection à la notification, le schéma de données complet, le nombre exact de personnes concernées par chaque élément de données, la carte géographique de stockage et de traitement, la liste complète des mesures de remédiation post-incident, les communications avec les régulateurs, et si des abus en aval spécifiques se sont produits à cause de la faille.

Les inconnues incluent également si chaque utilisateur concerné a reçu une notification adaptée correspondant aux éléments de données exacts impliqués.

Ces limites sont importantes car la responsabilité publique n'est pas la même chose que la spéculation. Cet article n'accuse pas DoorDash, un fournisseur ou un employé de mauvaise conduite délibérée, de fraude ou de comportement criminel.

Il dit que les archives publiques soutiennent une conclusion plus étroite: un événement d'accès par un prestataire de services tiers a exposé des catégories de données de marché de livraison qui nécessitaient des notifications spécifiques aux entités, une remédiation des risques fournisseurs et la preuve que les risques des consommateurs, des Dashers et des commerçants n'étaient pas réduits à une seule catégorie d'utilisateurs générique.

Ce que ce cas enseigne sur la responsabilité des plateformes

La faille de DoorDash en 2019 enseigne que la sécurité des marchés doit suivre la relation de données, pas seulement la relation d'application. Les consommateurs, les Dashers et les commerçants font l'expérience d'une seule marque, mais leurs données circulent à travers de nombreux systèmes opérationnels. Une plateforme ne peut pas externaliser la responsabilité en pointant du doigt un prestataire de services. Elle peut externaliser des fonctions, mais elle reste l'entité qui a structuré la relation de données, sélectionné les fournisseurs, défini l'accès, conservé les enregistrements, notifié les personnes concernées et réparé la confiance.

Une réponse responsable d'une plateforme de livraison inclurait un inventaire des accès des fournisseurs, une segmentation des données par objectif, une conservation courte pour les champs d'assistance et d'analyse inutiles, une journalisation solide des exportations des fournisseurs, des voies de révocation rapides, des clauses contractuelles exigeant une notification rapide des incidents, un examen régulier des accès des fournisseurs et des notifications aux utilisateurs qui séparent les risques des consommateurs, des Dashers et des commerçants.

Elle inclurait également une surveillance des abus après la notification car les données de livraison exposées peuvent être utilisées dans l'ingénierie sociale longtemps après la fermeture de l'accès à la base de données.

Le cas montre également pourquoi « les informations complètes de paiement n'ont pas été consultées » est nécessaire mais insuffisant. Exclure les numéros de carte complets et les codes CVV est significatif. Mais les fragments financiers partiels, les adresses, les numéros de téléphone, les historiques de commandes et les permis de conduire peuvent toujours créer un risque. Un avis mature crédite les exclusions tout en expliquant les risques restants. Un dossier de remédiation mature demande ensuite pourquoi les données partielles existaient, quel fournisseur pouvait les lire et comment un accès similaire sera empêché.

Le même test de maturité s'applique à la mesure après l'événement. DoorDash avait besoin de connaître non seulement le nombre global de personnes concernées, mais aussi la répartition des champs entre consommateurs, Dashers et commerçants. Un total unique peut aider le public à comprendre l'ampleur, mais il ne dit pas à un Dasher si les données de permis étaient impliquées, à un commerçant si les fragments de paiement étaient impliqués, ou à un consommateur si l'historique de livraison était impliqué. La mesure au niveau des champs est ce qui transforme une annonce de faille en un support responsable.

La dernière leçon de responsabilité est que les données de livraison sont locales, même lorsque la plateforme est basée sur le cloud. Les enregistrements concernés décrivent des lieux, des routines, des travailleurs, des restaurants et des relations bancaires. Ce ne sont pas des lignes abstraites dans un service distant. Lorsqu'une voie d'accès tiers les expose, la plateforme doit prouver qu'elle peut rendre compte des conséquences réelles de son modèle de données.

L'incident de DoorDash en 2019 reste un test instructif car il a forcé une entreprise à notifier plusieurs classes de entités à propos d'un seul événement lié à un fournisseur, tout en laissant le public avec des inconnues essentielles sur l'identité du fournisseur, les contrôles d'accès, la localisation et la remédiation complète.