Résumé

  • Le cas de l'exposition des numéros de téléphone d'Authy est important parce qu'une application d'authentification peut devenir un répertoire de ciblage si les contrôles d'exposition des points de terminaison et d'énumération échouent.
  • Qui avait le contrôle pratique sur l'exposition des points de terminaison d'Authy, l'énumération des numéros de téléphone, les contrôles de débit d'abus, les notifications aux utilisateurs, les conseils anti-hameçonnage, les paramètres de protection des comptes par défaut et la preuve qu'une application d'authentification n'est pas devenue un répertoire de ciblage?
  • La question de responsabilité tient à ce qu'un service d'authentification stocke des données que des attaquants peuvent utiliser pour cibler les personnes mêmes qui s'appuient sur lui pour leur protection, de sorte que la prévention de l'énumération et la spécificité des notifications deviennent des devoirs de confiance essentiels.
  • Les utilisateurs d'Authy, les équipes de sécurité, les analystes de fraude, les titulaires de comptes mobiles, les développeurs, les régulateurs et les acheteurs de services d'authentification avaient besoin de preuves que l'exposition des numéros de téléphone était contenue et traduite en conseils de protection exploitables.
  • Cet article traite les rapports publics de la divulgation, les documents de sécurité et de confidentialité de Twilio, la documentation d'Authy et de Verify, et les directives de normes publiques comme des pistes de preuves distinctes.

Pourquoi ce cas appartient à un dossier sur les risques et la responsabilité

Twilio a fait de l'exposition des numéros de téléphone d'Authy un test de responsabilité en matière d'abus d'identité parce que les services d'authentification détiennent des données de confiance que les attaquants peuvent réutiliser même sans obtenir le jeton secret lui-même. Un numéro de téléphone associé à une application d'authentification n'est pas seulement une information de contact. Il peut devenir un signal pour l'hameçonnage, les tentatives de SIM-swap, l'ingénierie sociale, les abus de récupération de compte, le spam ciblé et le harcèlement.

L'exposition est particulièrement sensible parce que la population touchée s'est auto-sélectionnée: il s'agit de personnes qui ont adopté un outil d'authentification parce qu'elles souhaitaient une protection plus forte.

Le déclencheur public est limité mais lourd de conséquences. Des rapports publics ont décrit la divulgation de Twilio selon laquelle des acteurs malveillants ont identifié des données associées à des comptes Authy via un point de terminaison non authentifié. La question de responsabilité ne se limite pas à savoir si les attaquants ont obtenu des codes d'authentification.

Il s'agit de savoir si le service a permis l'énumération des numéros de téléphone, comment les contrôles de débit et l'authentification des points de terminaison ont échoué ou ont été contournés, à quelle vitesse l'exposition a été contenue, avec quelle spécificité les utilisateurs ont été informés et si les conseils correspondaient aux voies d'abus qui découlent du ciblage des numéros de téléphone. La différence est importante parce que les utilisateurs ne peuvent pas changer de numéro de téléphone aussi facilement qu'un mot de passe.

La page de sécurité actuelle de Twilio àhttps://www.twilio.com/en-us/security, sa page de confidentialité àhttps://www.twilio.com/en-us/legal/privacy, sa page de statut àhttps://status.twilio.com/, la documentation d'Authy àhttps://www.twilio.com/docs/authyet la documentation de Verify àhttps://www.twilio.com/docs/verifyfournissent le contexte officiel de la manière dont les services d'identité, les données des utilisateurs et les contrôles de confiance sont présentés publiquement. Des rapports tels quehttps://www.bleepingcomputer.com/news/security/twilio-confirms-data-breach-after-hackers-leak-33m-authy-user-phone-numbers/ethttps://www.securityweek.com/twilio-says-hackers-identified-phone-numbers-of-authy-users/fournissent la chronologie publique de la divulgation d'Authy. Ces sources doivent être conservées dans des voies distinctes: les documents de l'entreprise montrent les engagements de contrôle publics et la documentation; les articles de presse fournissent un reportage public contemporain; les sources de normes fournissent le vocabulaire de contrôle.

Ce cas appartient à une série sur les risques et la responsabilité parce que les dommages causés par l'abus d'identité sont souvent différés, fragmentés et difficiles à attribuer. Une liste de numéros de téléphone associée à des utilisateurs d'une application d'authentification peut être utilisée plus tard dans des escroqueries ciblées. Un utilisateur peut recevoir un message ou un appel convaincant sans comprendre pourquoi il a été sélectionné. Une équipe de fraude peut constater une augmentation des tentatives de SIM-swap sans savoir quelle exposition antérieure a contribué au ciblage.

Un développeur qui évalue des fournisseurs d'identité peut vouloir savoir si le fournisseur traite la prévention de l'énumération comme un contrôle de premier ordre. L'incident immédiat n'est donc qu'une partie du dossier. Le problème permanent est de savoir si les preuves publiques permettent aux utilisateurs et aux organisations de réduire les abus ultérieurs.

Une application d'authentification peut devenir une surface de ciblage

Les applications d'authentification sont commercialisées et adoptées comme des outils défensifs. Ce cadrage est généralement juste: les codes basés sur une application peuvent réduire le risque de vol de mot de passe et certains modèles d'hameçonnage. Mais les outils défensifs collectent toujours des métadonnées, et ces métadonnées peuvent devenir utiles pour les attaquants. Un numéro de téléphone associé à un compte Authy donne des informations sur l'utilisateur.

Il suggère que le numéro peut être lié à des comptes protégés par une authentification multifacteur, que l'utilisateur peut s'appuyer sur une identité mobile et qu'un scénario d'ingénierie sociale peut être adapté à un contexte d'authentification.

Le problème de responsabilité ne se limite donc pas à la prise de contrôle de compte. Si les attaquants énumèrent les numéros de téléphone associés à un service d'authentification, ils n'ont peut-être pas besoin des jetons d'authentification pour causer des dommages. Ils peuvent envoyer des messages d'hameçonnage se faisant passer pour le service, tenter des SIM-swap auprès des opérateurs, cibler les flux de récupération de compte sur d'autres services ou constituer des listes pour de futures attaques par identifiants. La page du MITRE sur la collecte d'informations téléphoniques sur les victimes àhttps://attack.mitre.org/techniques/T1589/002/et sa page sur la technique d'hameçonnage àhttps://attack.mitre.org/techniques/T1566/ne constituent pas des conclusions spécifiques sur Authy. Elles fournissent le vocabulaire public expliquant pourquoi les données de contact exposées peuvent devenir du matériel de ciblage opérationnel.

C'est pourquoi la spécificité des notifications est importante. Si une entreprise dit seulement aux utilisateurs que leurs numéros de téléphone ont été exposés, ceux-ci peuvent comprendre cela comme un problème de confidentialité.

Si l'entreprise explique les voies d'abus probables, les utilisateurs peuvent le traiter comme un problème de sécurité: se méfier des messages ayant pour thème Authy, renforcer la protection du compte opérateur, examiner les paramètres de récupération de compte, vérifier les messages par les canaux officiels et avertir les services d'assistance que les attaquants peuvent faire référence à l'application d'authentification. Le même fait peut produire un comportement de protection différent selon la manière dont il est présenté.

Un fournisseur de services d'authentification a un contrôle pratique sur l'authentification des points de terminaison, la limitation de débit, la détection des abus, la journalisation, les notifications publiques, les conseils de mise à jour de l'application et les paramètres par défaut qui réduisent le risque après exposition. Les utilisateurs ont un contrôle pratique sur la sécurité de leurs appareils, la réponse à l'hameçonnage, les codes PIN opérateur lorsqu'ils sont disponibles et l'hygiène de récupération de compte.

Les équipes de sécurité ont le contrôle sur la formation des employés, les scripts des services d'assistance et les alertes. Mais tous ces contrôles en aval dépendent des premières preuves du fournisseur: ce qui a été exposé, pendant quelle période, via quel type de point de terminaison et quels abus ont été observés ou sont plausibles.

Le cas Authy est donc un cas de frontière de confiance. Les utilisateurs faisaient confiance au service pour les aider à protéger d'autres comptes. Le service détenait également des données qui pouvaient aider les attaquants à identifier ces utilisateurs. La responsabilité consiste à se demander si le dossier public de Twilio a rendu ce double rôle suffisamment clair pour que les utilisateurs et les acheteurs puissent agir.

L'exposition d'un point de terminaison est une défaillance de gouvernance avant d'être un titre de journal

Un point de terminaison non authentifié n'est pas simplement une erreur de codage. Dans un service d'identité, c'est une défaillance de gouvernance parce que cela signifie qu'un chemin accessible au public a exposé des données d'association sensibles sans la preuve d'autorisation appropriée, le contrôle de débit ou la résistance aux abus. L'entrée de la CWE sur l'absence d'authentification àhttps://cwe.mitre.org/data/definitions/306.htmlet la restriction incorrecte des tentatives d'authentification excessives àhttps://cwe.mitre.org/data/definitions/307.htmlfournissent un vocabulaire de contrôle utile. Elles ne décident pas de ce qui s'est passé à l'intérieur de Twilio. Elles montrent pourquoi cette classe de problèmes appartient à un dossier de responsabilité.

La gouvernance des points de terminaison devrait répondre à des questions de base avant un incident. Quels points de terminaison révèlent si un objet d'identité existe? Quels points de terminaison peuvent être interrogés à grande échelle? Quels points de terminaison renvoient des réponses différentes pour les utilisateurs valides et invalides? Quels points de terminaison exposent des données de contact, des données de contact masquées, la présence d'un compte, le statut de l'appareil ou des indices de récupération? Quels contrôles détectent les modèles d'énumération? Quels journaux sont conservés assez longtemps pour reconstituer l'échelle?

Quelles équipes produit sont propriétaires de la décision de rendre un point de terminaison public, authentifié, limité en débit ou déprécié?

Si ces questions ne trouvent pas de réponse avant l'exposition, elles deviennent beaucoup plus difficiles après. Un fournisseur peut être en mesure de fermer rapidement le point de terminaison, mais il a encore du mal à prouver combien d'enregistrements ont été interrogés, si le trafic d'attaque était complet ou partiel, quels utilisateurs ont été touchés et si des points de terminaison connexes ont été abusés. Cette incertitude devient un coût public. Les utilisateurs doivent savoir s'ils sont personnellement exposés à un risque ultérieur. Les équipes de sécurité doivent savoir si elles doivent avertir les employés.

Les régulateurs doivent comprendre la défaillance de contrôle et l'étendue de l'incident. Les acheteurs ont besoin de preuves que l'inventaire des points de terminaison et la détection des abus du service ont changé.

Le matériel de l'OWASP sur la sécurité des API concernant la consommation illimitée de ressources àhttps://owasp.org/API-Security/editions/2023/en/0xa4-unrestricted-resource-consumption/est pertinent parce que l'énumération dépend souvent de l'échelle. Une seule requête peut sembler inoffensive. Des millions de requêtes peuvent transformer un service en annuaire. La question de gouvernance est de savoir si le service traite l'échelle elle-même comme un signal de risque. Les limites de débit, la détection d'anomalies, les exigences d'authentification, la normalisation des réponses et les blocages d'abus ne sont pas des suppléments optionnels pour les métadonnées d'identité. Ils font la différence entre une fonction de recherche et un canal d'extraction.

Le dossier public de responsabilité devrait donc éviter une conclusion étroite du type « point de terminaison corrigé ». Un point de terminaison corrigé indique aux utilisateurs que le chemin connu a été fermé. Il ne leur dit pas si le fournisseur a examiné les points de terminaison voisins, modifié les règles de révision de conception, amélioré les contrôles de débit, testé l'énumération ou mis à jour la journalisation. Pour un service d'authentification, la réparation doit atteindre le processus qui a permis l'exposition du point de terminaison.

La notification aux utilisateurs doit traduire l'exposition en protection

La notification aux utilisateurs n'est utile que si elle modifie ce que les utilisateurs et les équipes de sécurité peuvent faire. Pour l'exposition des numéros de téléphone d'Authy, une notification utilisable distinguerait plusieurs faits. Elle dirait si les jetons d'authentification, les mots de passe de compte, les données de départ, les sauvegardes ou les secrets de l'appareil ont été impliqués. Elle dirait quelles données de contact ou d'association de compte ont été exposées.

Elle identifierait les risques ultérieurs probables: hameçonnage, smishing, ciblage de SIM-swap, usurpation d'identité du support d'Authy et abus de récupération de compte sur d'autres services. Elle recommanderait des mesures de protection que les utilisateurs peuvent prendre de manière réaliste.

Les conseils anti-hameçonnage de la CISA à l'adressehttps://www.cisa.gov/news-events/news/avoiding-social-engineering-and-phishing-attacks, ses conseils MFA « Secure Our World » àhttps://www.cisa.gov/secure-our-world/turn-mfaet ses conseils sur les mots de passe àhttps://www.cisa.gov/secure-our-world/use-strong-passwordsmontrent la base de référence publique pour les conseils d'action. Le but n'est pas que chaque utilisateur concerné ait besoin d'un programme de sécurité. Le but est que la notification relie les données exposées à une liste d'actions courte et réaliste. Un utilisateur qui apprend seulement « votre numéro de téléphone a peut-être été exposé » peut ne rien faire. Un utilisateur qui apprend « les attaquants peuvent maintenant se faire passer pour Authy ou votre opérateur; ne partagez pas les codes; vérifiez les messages par les canaux officiels; protégez votre compte mobile » a de meilleures chances de réduire les dommages.

La notification doit également respecter la charge des utilisateurs. Dire aux utilisateurs « d'être vigilants » est faible alors que le fournisseur peut donner des conseils plus précis. La vigilance est une responsabilité sans contrôle. De meilleurs conseils nomment des comportements spécifiques à ne pas suivre, des paramètres spécifiques à vérifier et des canaux de support spécifiques à utiliser.

Ils expliquent également ce que le fournisseur a déjà fait: suppression du point de terminaison, mises à jour de l'application, surveillance des abus, modifications du contrôle de débit, mises à jour forcées le cas échéant et notification supplémentaire si de nouveaux abus apparaissent.

Les équipes de sécurité ont besoin d'une version différente de la notification. Si les employés utilisent Authy pour leurs comptes professionnels, l'équipe de sécurité doit savoir si elle doit émettre des avertissements internes, surveiller l'hameçonnage sur le thème d'Authy, mettre à jour les scripts du service d'assistance, examiner les utilisateurs à haut risque et demander aux opérateurs ou aux propriétaires de comptes de renforcer les processus de récupération. Une notification destinée aux consommateurs peut ne pas suffire pour les équipes de risque d'entreprise.

Les fournisseurs de services d'identité doivent supposer qu'une exposition affectant les authentificateurs a des conséquences organisationnelles, même si les champs de données sont limités.

Enfin, la notification doit préserver l'incertitude sans se cacher derrière. Si Twilio ne savait pas si tous les numéros de téléphone interrogés ont été utilisés ultérieurement, il pourrait le dire. S'il avait des preuves que seule l'association de numéros de téléphone était impliquée, il pourrait dire quelles preuves soutiennent cette limite. S'il recommandait des mises à jour de l'application, il pourrait expliquer si la mise à jour était nécessaire pour le confinement ou seulement pour la défense en profondeur. Les utilisateurs n'ont pas besoin d'une fausse certitude. Ils ont besoin d'un dossier de décision.

Les numéros de téléphone sont difficiles à changer et faciles à transformer en armes

Un numéro de téléphone n'est pas un mot de passe. Il est intégré dans les comptes des opérateurs, les dossiers bancaires, les applications de messagerie, les flux de travail du service client, les flux de récupération, les contacts familiaux, les archives publiques et les systèmes gouvernementaux ou professionnels. Lorsqu'un numéro de téléphone associé à une application d'authentification est exposé, la réponse disponible pour l'utilisateur est limitée. Il ne peut pas simplement cliquer sur « réinitialiser le numéro de téléphone » dans tous les aspects de sa vie.

Cela rend la prévention et la notification plus importantes que le transfert de charge après coup.

Les risques ultérieurs sont bien connus. Les conseils de la FTC sur les SIM-swap àhttps://consumer.ftc.gov/articles/sim-swap-scams-how-protect-yourselfet les conseils de la FCC sur la fraude téléphonique àhttps://www.fcc.gov/consumers/guides/cell-phone-fraudsont des ressources de protection des consommateurs, même si certains sites publics peuvent appliquer une protection par robot pour l'accès automatisé. Ils montrent pourquoi l'exposition de numéros mobiles appartient à un dossier sur les abus d'identité. Les attaquants qui connaissent le numéro et la posture de sécurité d'une cible peuvent essayer de convaincre un opérateur, un service d'assistance ou la cible elle-même.

Les directives d'identité numérique du NIST àhttps://pages.nist.gov/800-63-3/sp800-63b.htmlsont également pertinentes car les authentificateurs, les canaux hors bande et la récupération de compte ont des propriétés d'assurance différentes. Encore une fois, cet article n'utilise pas le NIST comme une conclusion concernant Twilio. Il utilise le NIST pour expliquer pourquoi les numéros de téléphone et les systèmes d'authentification doivent être gérés avec soin. Un numéro de téléphone peut être un identifiant pratique, mais la commodité ne le rend pas à faible risque lorsqu'il est lié à une présence de service d'authentification.

La norme de responsabilité devrait demander comment la conception du fournisseur a minimisé l'exposition des numéros de téléphone avant l'événement. Les numéros de téléphone étaient-ils renvoyés uniquement lorsque cela était nécessaire? Les réponses étaient-elles normalisées pour empêcher le test de présence de compte? Les points de terminaison étaient-ils authentifiés? Les tentatives d'énumération étaient-elles limitées en débit et détectées? Les journaux étaient-ils suffisants pour notifier précisément les utilisateurs touchés? Les principes de minimisation des données ont-ils été appliqués aux workflows de support, d'analyse et de produit?

La confidentialité et la sécurité se rejoignent à ce stade. Moins de métadonnées inutiles sont exposées, plus le répertoire de ciblage que les attaquants peuvent construire est petit.

Les utilisateurs peuvent et doivent prendre des mesures de protection, mais l'action de l'utilisateur n'efface pas la responsabilité du fournisseur. Une entreprise qui exploite une application d'authentification a un devoir accru d'éviter de rendre les utilisateurs plus faciles à cibler. Si sa réponse publique repose principalement sur le fait de dire aux utilisateurs de surveiller les messages suspects, le dossier est incomplet. Elle doit également expliquer ce qui a changé à l'intérieur du service pour réduire la probabilité que les données de contact des utilisateurs puissent être à nouveau énumérées.

Les acheteurs de services d'authentification ont besoin de preuves, pas de réassurance

Les entreprises, les développeurs et les organisations réglementées qui évaluent les services d'authentification ont besoin de preuves que le service traite la prévention des abus comme une exigence produit. Ils ne peuvent pas se fier uniquement à une page de confiance, à un aperçu de la sécurité ou à une politique de confidentialité générale.

Ces documents sont importants, mais la responsabilité des acheteurs exige des preuves plus spécifiques: inventaires des points de terminaison, contrôles du débit d'abus, surveillance, examen de sécurité des API publiques, manuels de notification d'incident, limites de conservation des données et paramètres par défaut qui réduisent l'exposition des utilisateurs.

La documentation de l'API Verify de Twilio àhttps://www.twilio.com/docs/verify/api, l'aperçu de Verify àhttps://www.twilio.com/docs/verifyet l'explication de l'authentification à deux facteurs àhttps://www.twilio.com/docs/glossary/what-is-two-factor-authentication-2famontrent le contexte produit dans lequel les services d'identité sont achetés et intégrés. La documentation d'Authy àhttps://www.twilio.com/docs/authymontre le contexte hérité et produit pour l'utilisation de l'authentification. Ces pages ne répondent pas à toutes les questions sur l'incident. Elles aident les acheteurs à comprendre quelles surfaces et hypothèses doivent être examinées après une exposition.

Le dossier de responsabilité des acheteurs devrait demander si le fournisseur peut fournir un récit de contrôle clair. Quels éléments de données sont nécessaires pour l'authentification? Lesquels sont facultatifs? Lesquels sont exposés aux chemins de support ou d'API? Quels points de terminaison peuvent confirmer l'existence d'un compte? Quels signaux d'abus sont surveillés? Que se passe-t-il lorsqu'une énumération est détectée? Comment les utilisateurs sont-ils notifiés? Le fournisseur peut-il produire rapidement une liste des utilisateurs touchés?

Quel chemin de mise à jour de l'application ou de configuration existe si un contrôle doit être modifié?

Les acheteurs devraient également demander comment le fournisseur sépare les preuves de statut des preuves de sécurité. Une page de statut de service peut indiquer si les produits sont opérationnels. Elle peut ne pas dire si un point de terminaison a été abusé pour l'énumération. La page de statut de Twilio àhttps://status.twilio.com/est utile pour la transparence opérationnelle, mais les incidents de sécurité nécessitent une spécificité supplémentaire. Si un événement de sécurité ne dégrade pas la disponibilité, il peut quand même dégrader la confiance. Le dossier public de responsabilité ne devrait pas forcer les lecteurs à confondre disponibilité et assurance de sécurité.

Enfin, les acheteurs ont besoin de savoir comment le fournisseur soutient la communication en aval. Si une entreprise utilise les services d'identité Authy ou Twilio pour ses clients ou ses employés, elle peut avoir besoin de sa propre notification, de ses scripts de support et de son évaluation des risques. Un fournisseur qui ne fournit que des déclarations génériques affaiblit ce travail en aval. Un fournisseur qui fournit des faits délimités, des voies d'abus, des contrôles recommandés et des engagements de suivi aide les acheteurs à protéger les mêmes utilisateurs dont la confiance était en jeu.

Les contrôles d'abus doivent être mesurés comme des contrôles opérationnels

La prévention des abus est souvent discutée comme une fonction de sécurité, mais dans ce cas, c'est un contrôle opérationnel. L'authentification des points de terminaison, les limites de débit, la détection des anomalies, la normalisation des réponses, les défenses contre les robots, la journalisation et les alertes décident si un produit peut être interrogé jusqu'à exposer des données. Ils décident également si le fournisseur peut reconstituer ce qui s'est passé. Si une entreprise ne peut pas mesurer les abus, elle ne peut pas notifier avec précision.

Les contrôles CIS àhttps://www.cisecurity.org/controlset le Cybersecurity Framework du NIST àhttps://www.nist.gov/cyberframeworkfournissent un vocabulaire de haut niveau utile pour l'inventaire des actifs, la journalisation, la surveillance, le contrôle d'accès, la réponse aux incidents et l'amélioration. Ils ne remplacent pas un dossier spécifique au fournisseur. Le dossier spécifique au fournisseur devrait dire comment l'exposition du point de terminaison d'Authy a été fermée, quelles surfaces adjacentes ont été examinées, quels changements de contrôle de débit ont été effectués, quels signaux détecteront les futures énumérations et quelles preuves déclencheraient une nouvelle notification.

Les contrôles d'abus doivent également être testés par rapport à la réalité économique. Les attaquants peuvent distribuer les requêtes, ralentir, faire tourner l'infrastructure et mélanger l'énumération avec le trafic légitime. Une simple limite de débit peut ne pas suffire si les réponses valides et invalides diffèrent en termes de temps, de message ou de structure. Un service mature teste donc la résistance à l'énumération dans le cadre de la sécurité du produit, et pas seulement pendant la réponse aux incidents. Pour les services d'authentification, la confidentialité de la présence du compte est une fonctionnalité, pas un luxe.

Le problème de la preuve est que bon nombre de ces contrôles sont invisibles pour les utilisateurs. Les utilisateurs ne peuvent pas inspecter les inventaires de points de terminaison ou la logique de limitation de débit. Cette invisibilité augmente le devoir de divulgation du fournisseur. La notification publique n'a pas besoin de révéler des seuils de détection sensibles, mais elle peut décrire les catégories de contrôles et les engagements de réparation.

Elle peut dire si le point de terminaison a été supprimé ou authentifié, si la surveillance des abus a été étendue, si les utilisateurs touchés ont été notifiés, si des mises à jour de l'application ont été recommandées et si des catégories de données supplémentaires ont été exclues.

Le risque de preuves faibles est la répétition. Si le dossier public s'arrête à « nous avons corrigé le point de terminaison », la prochaine évaluation n'aura aucune base pour juger si le système de contrôle s'est amélioré. Si le dossier identifie les catégories de contrôles qui ont changé, les futurs acheteurs, régulateurs et utilisateurs pourront tenir le fournisseur à une norme plus élevée sans avoir besoin du code source privé. C'est à cela que servent les preuves de responsabilité.

La localité des données et la confidentialité façonnent les conséquences

Le manifeste inclut la souveraineté des données et la localité parce que les services d'identité fonctionnent à travers les juridictions, les opérateurs, les utilisateurs, les applications, les fournisseurs et les systèmes de support. Une exposition de numéros de téléphone n'est pas seulement un problème technique d'API. C'est aussi un problème de données personnelles. Les utilisateurs de différentes juridictions peuvent avoir des attentes de notification différentes, les régulateurs peuvent poser des questions différentes et les acheteurs d'entreprise peuvent avoir besoin de comprendre où les données de compte sont traitées ou conservées.

Un service mondial ne peut pas traiter la localité comme une réflexion après coup une fois que l'exposition se produit.

La page de confidentialité de Twilio àhttps://www.twilio.com/en-us/legal/privacyest pertinente car elle fait partie de la promesse publique sur le traitement des données personnelles. La page de sécurité àhttps://www.twilio.com/en-us/securityest pertinente car elle encadre les contrôles de confiance. Mais le dossier public de l'incident devrait relier ces engagements généraux à la catégorie de données exposées. Quelles données étaient associées aux comptes Authy? L'exposition était-elle limitée aux numéros de téléphone ou incluait-elle des identifiants de compte, des métadonnées d'appareil, des indicateurs de statut ou d'autres champs? Les utilisateurs touchés ont-ils été notifiés dans toutes les juridictions? Les décisions de conservation et de minimisation des données ont-elles été examinées? Des processeurs ou des systèmes de support ont-ils été impliqués?

La responsabilité en matière de confidentialité ne doit pas être réduite à savoir si les données exposées étaient « sensibles » au sens juridique étroit. Les numéros de téléphone liés à la présence d'une application d'authentification sont sensibles au sens pratique de la sécurité car ils peuvent soutenir le ciblage. C'est pourquoi l'article utilise un langage d'abus d'identité. Les mêmes données peuvent être ordinaires dans un contexte et à haut risque dans un autre. Un numéro de téléphone dans un annuaire professionnel public est différent d'un numéro de téléphone dans une liste d'utilisateurs d'authentificateur.

La question de la localité affecte également la réponse organisationnelle. Une multinationale dont les employés utilisent Authy peut avoir besoin de coordonner les notifications, les communications avec les comités d'entreprise, les évaluations des régulateurs et les conseils au service d'assistance. Un utilisateur consommateur peut avoir besoin de conseils spécifiques à l'opérateur. Un développeur peut avoir besoin de décider si les identifiants basés sur le numéro de téléphone sont appropriés pour son propre produit. Un bon dossier public soutient toutes ces décisions en clarifiant la catégorie d'exposition et les voies d'abus.

Le test de responsabilité clé est de savoir si le langage de la confidentialité et le langage de la sécurité se rencontrent. La confidentialité explique quelles données sont détenues et comment elles peuvent être utilisées. La sécurité explique comment les abus sont prévenus et contenus. Dans une exposition Authy, les deux dossiers doivent converger sur les mêmes faits: quelles données ont été exposées, pourquoi le point de terminaison existait, comment l'énumération était possible, ce qui a changé et ce que les utilisateurs doivent faire.

La reprise d'identité est un problème opérationnel en aval

L'exposition des numéros de téléphone devient coûteuse parce que le travail de récupération incombe à de nombreuses organisations qui ne partagent pas un seul plan de contrôle. Twilio peut contrôler le point de terminaison Authy et les conseils de l'application. Un opérateur contrôle la friction du SIM-swap, les codes PIN de compte, les processus de portabilité et le comportement du service client. Une banque contrôle ses propres alertes de connexion et ses règles de récupération de compte. Un employeur contrôle la vérification du service d'assistance.

Un consommateur contrôle les messages auxquels il faut faire confiance et les comptes à examiner. L'utilisateur exposé est souvent la seule personne à devoir coordonner tous ces endroits. C'est pourquoi la notification du fournisseur ne peut pas s'arrêter à une déclaration étroite de champ de données.

Une notification de récupération utile devrait dire aux utilisateurs et aux organisations quel type de travail en aval est proportionné. Si seule l'association de numéros de téléphone a été exposée, les utilisateurs n'auront peut-être pas besoin de réinitialiser tous leurs comptes.

Ils devront peut-être traiter les messages ayant pour thème Authy comme suspects, éviter de partager des codes, vérifier les paramètres de sécurité de l'opérateur, examiner les méthodes de récupération de compte à haute valeur et dire aux services d'assistance internes de ne pas faire confiance aux appelants qui font référence à l'application d'authentification comme preuve de légitimité. C'est un manuel différent de celui d'une compromission de jeton secret, et la notification devrait clarifier la différence.

Cette distinction est importante pour les équipes de sécurité. Si le numéro de téléphone d'un employé apparaît dans une liste d'utilisateurs d'authentificateur, l'employeur peut avoir besoin de surveiller l'ingénierie sociale contre le support informatique, la paie, le service client ou la récupération de comptes privilégiés. L'attaquant n'a pas besoin de vaincre l'authentificateur directement s'il peut convaincre un employé du support de réinitialiser le facteur, d'inscrire un nouvel appareil ou d'approuver une demande de récupération risquée. Le numéro de téléphone devient un accessoire de confiance dans un scénario social.

C'est pourquoi les conseils anti-abus doivent atteindre les services d'assistance et les équipes de fraude, pas seulement les utilisateurs individuels de l'application.

Le même problème apparaît pour les développeurs et les propriétaires de produits qui construisent des flux d'identité basés sur le numéro de téléphone. S'ils utilisent un numéro de téléphone comme identifiant stable, un canal de récupération et un signal de risque en même temps, alors une exposition dans un service peut créer une pression dans un autre. Un utilisateur ciblé après la divulgation d'Authy peut être confronté à des escroqueries sur des services qui n'ont aucun lien direct avec Authy.

Le dossier de responsabilité devrait donc pousser les acheteurs à examiner leurs propres hypothèses: si les numéros de téléphone sont trop utilisés, si les réponses de présence de compte peuvent être énumérées, si les scripts de support reposent trop sur la connaissances de l'appelant et si les changements à haut risque nécessitent une preuve plus forte.

Il y a aussi un problème de calendrier. Les abus d'identité n'arrivent pas toujours immédiatement après la divulgation. Les listes peuvent être copiées, revendues, enrichies et réutilisées des mois plus tard. Une déclaration publique indiquant qu'aucune compromission immédiate de compte n'a été observée peut être exacte tout en étant incomplète comme guide de protection. Les utilisateurs doivent savoir que le ciblage différé est plausible lorsque des données de contact sont exposées. Les équipes de sécurité doivent savoir combien de temps garder les avertissements actifs.

Les fournisseurs doivent dire si la surveillance se poursuit après le premier avis et s'ils mettront à jour les utilisateurs si de nouveaux modèles d'abus apparaissent.

C'est là que la responsabilité diffère des relations publiques d'incident. Un instinct de relations publiques peut préférer réduire l'événement aussi rapidement que possible. Un dossier de responsabilité réduit ce qui peut être réduit tout en préservant le risque qui demeure. Il peut dire que les secrets d'authentification n'étaient pas montrés comme exposés, tout en disant que le ciblage des numéros de téléphone crée un risque réel de suite. Il peut dire que le point de terminaison a été fermé, tout en disant que les utilisateurs doivent traiter les messages non sollicités comme suspects.

Il peut dire que l'entreprise n'a pas connaissance de certains abus, tout en expliquant ce qu'elle surveillera par la suite.

Le fardeau de la récupération devrait également être mesuré. Combien d'utilisateurs ont été notifiés? Combien de notifications ont rebondi ou échoué? Les utilisateurs à haut risque ou les clients d'entreprise ont-ils reçu des conseils supplémentaires? Les mises à jour de l'application ont-elles été réellement installées? Les équipes de support ont-elles vu une augmentation des demandes? Les canaux de signalisation d'abus ont-ils reçu des signalements d'hameçonnage sur le thème d'Authy? Les opérateurs ou les équipes de fraude ont-ils reçu des indicateurs qui pourraient les aider à protéger les utilisateurs touchés?

Certains de ces faits peuvent rester privés, mais un fournisseur mature devrait savoir quels indicateurs montreraient si les conseils ont atteint les personnes qu'ils étaient censés protéger.

Pour les utilisateurs, l'attente équitable n'est pas la perfection. C'est un chemin clair. Ils ne devraient pas avoir à déduire de blogs de sécurité épars ce que signifie l'exposition d'un numéro de téléphone d'une application d'authentification. Ils devraient recevoir une explication délimitée de ce qui a été exposé, de ce qui ne l'a pas été, des abus à attendre, des actions utiles, des actions inutiles et de l'endroit où trouver des mises à jour. Pour les entreprises, l'attente équitable est un dossier du fournisseur qui peut être transformé en conseils internes sans inventer des faits manquants.

Si les preuves du fournisseur ne peuvent pas soutenir cela, les organisations en aval sous-réagiront ou surréagiront, et les deux résultats transfèrent le coût du propriétaire du service aux personnes qui en dépendent.

Le même dossier devrait conserver les preuves visibles par le client après le premier cycle d'actualité. Si un utilisateur signale plus tard une tentative de SIM-swap, un message d'hameçonnage ou un appel de support suspect, le fournisseur et l'organisation de l'utilisateur ont besoin d'un moyen de relier ce signalement à la fenêtre d'exposition sans exagérer la causalité. Cela nécessite des identifiants d'incident, des dates de notification, des catégories de données, des conseils sur la version de l'application et un routage des signalements d'abus qui restent disponibles après la correction du point de terminaison.

Un ticket technique fermé ne suffit pas. Les abus d'identité peuvent se manifester lentement, et le dossier de responsabilité doit rester utile lorsque les dommages en aval apparaissent après que le fournisseur a déjà déclaré la remédiation terminée.

À quoi ressembleraient de meilleures preuves

De meilleures preuves commenceraient par l'étendue du point de terminaison. Elles nommeraient, au niveau du produit, la fonction qui permettait d'interroger les données associées au compte, si l'authentification était requise, comment l'abus a été détecté, comment le point de terminaison a été fermé ou modifié et si les points de terminaison voisins ont été examinés. Elles n'auraient pas besoin de divulguer les détails de l'exploitation qui créent de nouveaux risques. Elles devraient donner suffisamment d'informations pour que les utilisateurs et les acheteurs comprennent la classe de défaillance.

De meilleures preuves sépareraient ensuite les données exposées des données non exposées. Si les jetons d'authentification, les secrets de sauvegarde, les mots de passe ou l'accès au compte n'étaient pas impliqués, le dossier devrait dire quelles preuves soutiennent cette limite. Si des numéros de téléphone ou des données d'association de compte étaient impliqués, le dossier devrait dire combien d'utilisateurs ont été touchés, quelle période a été examinée et quel niveau de confiance s'applique au décompte. Le but n'est pas de faire honte au fournisseur. C'est d'empêcher les utilisateurs et les équipes de sécurité de deviner.

De meilleures preuves traduiraient également le risque en action. Les utilisateurs devraient savoir de quels messages se méfier, s'il faut mettre à jour l'application, s'il faut examiner les paramètres multi-appareils, s'il faut renforcer les comptes opérateur, s'il faut être attentif à l'hameçonnage sur le thème d'Authy et si d'autres notifications suivront. Les équipes de sécurité devraient recevoir des conseils distincts pour la formation des employés et les abus du service d'assistance.

Les développeurs et les acheteurs devraient recevoir des leçons de contrôle sur l'inventaire des points de terminaison, la résistance à l'énumération et la minimisation des données.

Enfin, de meilleures preuves définiraient la réparation. La réparation n'est pas terminée lorsqu'un point de terminaison est fermé. La réparation comprend un inventaire des points de terminaison examiné, des contrôles de débit d'abus, des améliorations de la journalisation, des alertes, la notification des utilisateurs, des conseils de mise à jour de l'application et une déclaration de suivi si de nouvelles preuves modifient l'évaluation des risques. Pour un service d'authentification, la réparation signifie également prouver que le produit n'est pas devenu un répertoire de ciblage durable.

C'est la norme que le cas devrait laisser derrière lui. Les services d'authentification ne méritent la confiance que lorsqu'ils peuvent montrer comment ils protègent les métadonnées autour de l'authentification, et pas seulement le secret d'authentification lui-même.

Fichier de preuves pour le lecteur

L'article utilise les sources publiques suivantes comme fichier de lecture pour l'exposition des numéros de téléphone d'Authy de Twilio, l'abus de point de terminaison non authentifié, les conseils aux clients, la confiance dans les applications d'authentification et le dossier de responsabilité en matière d'abus d'identité. Les pages de l'entreprise sont traitées comme des preuves des engagements de contrôle publics et du contexte du produit. Les articles de presse sont utilisés pour la chronologie et le contexte de divulgation publique.

Les normes et les conseils gouvernementaux fournissent un vocabulaire de contrôle et un contexte de protection des utilisateurs, et non des conclusions sur les systèmes privés de Twilio.

Ce fichier de preuves est délibérément plus large qu'une seule notification parce que la responsabilité des applications d'authentification croise la conception des points de terminaison, la minimisation des données de contact, la détection des abus, les conseils aux utilisateurs, le risque d'hameçonnage, la récupération de numéro mobile et la réponse des équipes de sécurité. Le dossier public doit soutenir les utilisateurs individuels, les acheteurs d'entreprise, les équipes de fraude, les développeurs, les équipes de confidentialité et les régulateurs.

Questions pour l'examen du conseil d'administration

Un examen du conseil d'administration devrait commencer par la propriété du point de terminaison. Qui a approuvé le point de terminaison qui exposait les données associées au compte? Qui a examiné son exigence d'authentification, la conception de la réponse et les contrôles de débit? Qui a surveillé les tentatives d'énumération? Qui a décidé quand le point de terminaison devait être fermé ou modifié? Qui a confirmé que les points de terminaison voisins ne pouvaient pas être abusés de la même manière?

L'examen devrait ensuite porter sur la notification. Qui a décidé de ce qui a été dit aux utilisateurs? La notification expliquait-elle la différence entre l'exposition d'un numéro de téléphone et la compromission d'un jeton d'authentification? Fournissait-elle des mesures de protection réalistes? Soutenait-elle les équipes de sécurité d'entreprise ainsi que les utilisateurs individuels? Expliquait-elle ce que Twilio avait changé et ce qui restait incertain?

L'examen devrait vérifier si les contrôles anti-abus se sont améliorés après l'événement. Les inventaires de points de terminaison ont-ils été mis à jour? Les réponses de présence de compte ont-elles été normalisées? Les limites de débit et les défenses contre les robots ont-elles été examinées? Les journaux et les alertes étaient-ils suffisants pour détecter les futures énumérations? Les décisions de minimisation de la vie privée ont-elles été réexaminées pour les numéros de téléphone et les données d'association de compte? Les voies d'abus liées aux opérateurs et à l'hameçonnage ont-elles été intégrées dans les conseils?

Pour ce cas spécifique, l'examen devrait répondre directement à la question du manifeste: Qui avait le contrôle pratique sur l'exposition des points de terminaison d'Authy, l'énumération des numéros de téléphone, les contrôles de débit d'abus, la notification des utilisateurs, les conseils anti-hameçonnage, les paramètres de protection des comptes par défaut et la preuve qu'une application d'authentification n'est pas devenue un répertoire de ciblage?

La réponse devrait inclure des dates, des classes de points de terminaison, des propriétaires de contrôle, des preuves de notification des utilisateurs, des changements dans la surveillance des abus, l'incertitude non résolue et la preuve que la réparation a atteint la frontière de confiance dont les utilisateurs dépendaient.